Re: libc bump subproject

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:
: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@xxxxxxxxxxxxx>