Re: splice export version

[Roland McGrath <roland at redhat dot com>]

> Wouldn't this normally be GLIBC_2.4.1?  Roland's said that further 2.4
> releases will come off of HEAD for now.

Well, that doesn't mean that Ulrich noticed what I said or agreed with it.
I also said before that there would not be future GLIBC_x.y.z version set
names, or new ABIs introduced in minor releases.  There hasn't been any
real discussion here yet about plans, just the initial thoughts from me.

I see three options for dealing with these new syscalls.

1. We branch glibc-2_4-branch now (just before the GLIBC_2.5 additions).

2. We put those new calls in a GLIBC_2.4.1 version set instead.

3. We back out the new syscalls for now, and put them back in later.

I do not like #1.  For a while to come, I would expect the 2.4 branch to be
exactly the trunk minus those new syscalls.  It's just a whole set of extra
hassles for someone (usually me) to maintain yet another branch.  I think
branching does more harm than good right now.

In either #1 or #3, it will be quite some time before anyone out there is
actually using the GLIBC_2.5 version set in a standard system library, and
so noone would be in a position to call the new syscall stubs very soon.
(And they are just syscall stubs, so applications doing fancy newfangled
kernel tweakery can cope without great difficulty.)

The rationale for the previously stated policy against #2 is that ABI
changes should be infrequent.  Users, and especially people trying to
distribute binaries, often complain of being confounded by seemingly minor
updates that cause compiling applications to yield binaries that won't run
on an un-updated installation of the same major OS version.  2.4.1 is not a
harmless bug-fix release if it introduces a new version set.  That said,
this version set would be a pure addition of obscure new functions with new
names (with no new versions of existing symbols relative to 2.4)--meaning
the only binaries that might require the newer libc would be applications
explicitly using these arcane bleeding-edge new Linux system calls.  So
it's the best case of what we decided before was an entirely bad class of
things to do.

I favor #3, backing out the new syscalls and holding off on all ABI
additions on the trunk for another month or two while we get a
stabilization release or two out.  It seems to me that this won't actually
delay anyone's practical effective date of access to the new functions.  I
don't know of any other ABI changes or additions that might be developed
soon.  If anyone is planning something, I hope they'll mention it now.

Ulrich, what do you think?


Thanks,
Roland