The kernel and character set encodings

Posted Feb 20, 2004 2:24 UTC (Fri) by flewellyn (subscriber, #5047)
Parent article: The kernel and character set encodings

Why does the kernel even use "/" and NUL? Seriously, pathnames should be internally coded as structures, not strings. The only parsing of pathname strings should occur in the C library, including syscall wrappers. The kernel should not have any notion, internally, of pathname separators. It's just silly.

Instead, I propose something like this: stick each element of the pathname into an array element, innermost first (that is, the "root" directory would be LAST element of the array), and use a special token to indicate ROOT. You could have the array live in a struct, with the other struct element being the length of the array, if you like. Something like this:

struct pathname {
int length;
char* elements[];
}

This way you could get at the file's name with a simple elements[0], and walk the directory tree from root to the file like this:

for (i = length; i >=0; i--) {blah blah blah whatever};

No worrying about parsing out the "/" separators.

The kernel and character set encodings

Posted Feb 20, 2004 17:37 UTC (Fri) by Ross (guest, #4065) [Link] (1 responses)

But you are using C strings to denote the elements which means they are
still NUL terminated. To fix it you need a second array for the path
component lengths. I think you are unlikely to convince any of the kernel
guys this isn't too ugly to live.

The kernel and character set encodings

Posted Feb 20, 2004 22:32 UTC (Fri) by spitzak (guest, #4593) [Link]

I agree that a length is needed, not just for encoding NUL, but to allow
a slash-seperated name to be quickly converted to this form, without a
need to malloc and copy a block of memory for each piece.

One possibly less-ugly scheme is to use Plan9's "walk" style. You have
"file descriptors" that represent a filename, unopened as yet. These are
created by copying an
existing one (a small set, such as one for "/", are provided when the
program starts up, like stdin/out). There is then a call something like
walk(fd,char* name,int length) which moves fd to the subdirectory in
name[0..length-1]. When you finally are at the desired file you call
open(fd,mode). Existing open() calls would be turned into a bunch of walk
calls followed by a new open.

With this, no arrays are passed to the kernel, and it does not have to
store these arrays.