Re: [RFC PATCH 0/6] Support for Linux kernel thread aware debug

[Andreas Arnez <arnez@linux.ibm.com>]

On Tue, Jan 29 2019, John Baldwin wrote:

> I just have one minor suggestion / comment about file names.  I maintain
> FreeBSD kernel patches for gdb out-of-tree (for various reasons), and those
> patches use some similar things (e.g. a different OSABI).  My comment has
> to do with the filenames.  Other osabi-specific files tend to use more
> verbose names such as 'linux-arm-nat.c'.  I wonder if it makes sense to
> spell out linux here as well.  I have been using 'arm-fbsd-kern.c' as a
> complement to 'arm-fbsd-tdep.c' for the kernel gdbarch.  The architecture
> independent files follow the patter 'fbsd-k*.c' (e.g. fbsd-kld.c for modules
> and fbsd-kthr.c for thread enumeration), but I would be happy to move those
> to something like 'fbsd-kern-ld.c' and 'fbsd-kern-thr.c'.  For your current
> patchset that might mean something like 'linux-kern-tdep.c' instead of
> 'lk-tdep.c'.  I would also be fine with 'arm-linux-kern-tdep.c' instead of
> 'arm-linux-kern.c' perhaps if other folks feel like that is more consistent.

I believe it was me who originated the "lk" notation, so maybe I should
provide my few cents on its rationale here:

1. The string "linux" in GDB source file names specifically means
"GNU/Linux user-space runtime".  For instance, "aarch64-linux-tdep.c"
implements target-dependent code for GNU/Linux user-space programs on
AArch64 hardware.  Thus "linux" is reserved for this particular purpose,
and collisions should better be avoided.

2. In principle, the Linux kernel runtime is just another runtime
environment, like the GNU/Linux user-space runtime or the QNX Neutrino
runtime (say).  And since all runtimes are named by a single short word
so far ("linux", "nbsd", "nto", etc.), it seems consistent to use the
same scheme for the Linux kernel runtime as well.  In particular this
means not to use any dashes or underscores.

3. The runtime name becomes part of many identifiers.  Any additional
characters make these identifiers more bulky.  Thus, in my opinion, the
name should be as short as possible.

If "lk" is not considered clear enough, alternatives could be something
like "lxk", "lkr" (for "Linux kernel runtime"), "linuxk", or "linuxkr".
For the FreeBSD kernel I suggest "fbsdk" or "fbsdkr".

--
Andreas