Re: libc bump subproject

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hi all,
: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
:tasks.
:
: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.
:
:Joerg

    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
      long time.

    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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>