libc bump subproject
dillon at apollo.backplane.com
Thu Apr 7 14:21:20 PDT 2005
:On Thu, Apr 07, 2005 at 12:20:41PM -0700, Matthew Dillon wrote:
:> * Bump ino_t (and thus stat.st_ino and dirent.d_fileno and others)
:> to 64 bits. This has been needed for a very long time. (If I
:> thought I could get away with making it 128 bits I would).
:> * Bump nlink_t (and thus stat.st_nlink) to 32 bits.
:> * Bump stat.st_gen to 64 bits. This has also been needed for a very
:> long time.
:I was going to check the whole list and clean some other interfaces too.
:> But even more to the point, remember way back a year or so ago I was
:> talking about creating a system call compatibility layer in userland?
:> One that is mapped by the system but which runs in userland and replaces
:> the current in-libc system call generator?
:Sure do I rembmer that :) That's why I bring the message based syscall
:interface in. It makes the whole thing a lot easier.
:I also want to work on symbol versioning for rtld, but that needs time.
Symbol versioning might be a good fit with the compatibility layer
The great thing about the compatibility layer idea is that we can
automate the generation of the version A <-> B handling code, and
the optimal 'the versions are the same' case degenerates down into
a direct system call. GCC can't break structures down into
program-accessible data structures (not without a lot of fuss, anyway),
but DICE's C parser can and that means we can automate the generation
of the code which does copies between two different versions of the
And *that*, folks, is a big deal. It means we would be able to change
user<->kernel structures like the 'stat' structure with impunity.
I wish there were more of me, I've got dozens of things I want to do
all at once :-(. I'd love to retarget DICE to IA32, for example.
<dillon at xxxxxxxxxxxxx>
More information about the Kernel