Re: libc bump subproject
:
: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.
:
:Joerg
Symbol versioning might be a good fit with the compatibility layer
idea.
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
same structure.
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.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 6 之 14 篇)：