libc bump subproject
dillon at apollo.backplane.com
Thu Apr 7 12:26:04 PDT 2005
:just to keep track of what needs to be done for the major bumps,
:I'll like to post my TODO list here, others might want to add
:1. Import citrus code.
:- I'll update the patch in the next days to include my latest local
: fixes, there are some minor issues (e.g. for the moment no LC_TIME
: and LC_MONETARY support until I get a clean version ready).
:2. Get struct statfs 64bit clean.
:- This changes e.g. the ABI of fts(3), but is IMO a necessary thing
: in the medium term anyway. This will be done via a new system call
: to keep the current code running. The old version can be moved into
: a COMPAT_FREEBSD_4 option later.
:3. Visibility check for all global symbols.
:- I want to verify that no internal global symbols without __libc prefix
: exist and reduce the exported list to the necessary minimum.
:- Not started yet, planned for next week.
:4. Merge Eirik's sysmessage changes from libcr.
:- Maybe combine this with the upper step to get the naming cleaner,
: esp. in combination with the use in the thread libraries.
There are some significant system types that need to be adjusted as
well. If we are going to make ABI changes, we're gonna want to do
them all in one shot.
Here are a few more:
* 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
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?
Well, I think its time may have come.
This basically means moving the low level system call ABI out of libc
and into its own library. This library would be mapped by the system
based on two ABI version numbers... one supplied by the program startup
code, and one supplied by the system. This theoretically would allow
the system to map the appropriate 'compatibility' system call library
rather then us having to constantly add new system call numbers whenever
we make a change. This would allow us to guarentee backwards
compatibility from operating system X to running program Y simply by
adding the appropriate library to handle X<->Y.
We would also use the same methodology to e.g. (eventually) switch to
syscall messaging, deal with low level threading issues (dealling with
blocking system calls), and so forth.
<dillon at xxxxxxxxxxxxx>
More information about the Kernel