Dan McGee wrote:
> On Sat, Apr 25, 2009 at 2:47 PM, Gerardo Exequiel Pozzi
> <vmlinuz386@xxxxxxxxxxxx> wrote:
>
>> Allan McRae wrote:
>>
>>> Hi all,
>>>
>>> The gcc-4.4.0 toolchain rebuild is now in [testing]. Here is a rough
>>> ChangeLog:
>>>
>> Awesome, Thanks
>> I will build some things in a chroot, to see how it behaves.
>>
>>> glibc:
>>>
>>>
>> One note here, (low priority): in the ".install" post_upgrade() there is
>> a line "init u". If glibc is installed in a chroot and don't have
>> sysvinit package, because isn't needed, when glibc is upgrading will
>> show a warning about can't execute init, so you can replace this line
>> with a "[ -x /sbin/init ] && /sbin/init u" ?
>>
>> And a question: why still support older kernels from 2.6.16?,
>> considering that minimal kernel that udev support is 2.6.22, maybe can
>> change the line --enable-kernel=2.6.16 with a superior version >= 2.6.22
>>
>> >From glibc manual: "This option is currently only useful on GNU/Linux
>> systems. The version parameter should have the form X.Y.Z and describes
>> the smallest version of the Linux kernel the generated library is
>> expected to support. The higher the version number is, the less
>> compatibility code is added, and the faster the code gets."
>>
>
> It might be worth bumping this up a bit, although not to the current
> kernel version. I think 2.6.22 is a wise choice. If you take a look at
> sysdeps/unix/sysv/linux/kernel-features.h, you can see that moving to
> 2.6.22 would enable the __ASSUME_PSELECT, __ASSUME_PPOLL,
> __ASSUME_ATFCTS, __ASSUME_SET_ROBUST_LIST, __ASSUME_FUTEX_LOCK_PI,
> __ASSUME_PRIVATE_FUTEX, and __ASSUME_UTIMENSAT options, which cut down
> on some unnecessary glibc workaround code.
>
> If we do bump this, it is a newsworthy item to let users know that our
> userspace is only compatible with kernels 2.6.22 and up after this
> upgrade- this is important for people running in a Xen context among
> other things with a kernel provided by someone else.
>
> Sidenote:
> * Bumping to 2.6.23 would add __ASSUME_FALLOCATE
> * Bumping to 2.6.24 would add __ASSUME_ADJ_OFFSET_SS_READ
> * Bumping to 2.6.27 would add assumes for CLOEXEC, NONBLOCK, PIPE2, and PACCEPT
>
> -Dan
>
>
Hi Dan, thanks for your response.
Some time ago I had investigated this: The "documentation vs source" is
a bit confusing, it talks that the option "enable-kernel" will drop
support for runing glibc in older kernels, but don't talk about enabling
new features. But when reading the source "apparently" the option
"enable-kernel" not only drop old code, also add new features, but, look
this...
(this is the glibc-2.9-4 from [core])
$ nm /lib/libc-2.9.so | grep have_fallocate
001463ac b __have_fallocate
$ nm /lib/libc-2.9.so | grep have_o_cloexec
001463b0 b __have_o_cloexec
etc.
And can use this , so if i am not wrong, as said the documentation, this
option only drop support for older kernels not enables new code.
Doing a bit deep research...
For example in the case of the O_CLOEXEC for the open()
(from sysdeps/unix/opendir.c)
#ifdef __ASSUME_O_CLOEXEC
# define check_have_o_cloexec(fd) 1
#else
static int
check_have_o_cloexec (int fd)
{
if (__have_o_cloexec == 0)
__have_o_cloexec = (__fcntl (fd, F_GETFD, 0) & FD_CLOEXEC) == 0 ? -1
: 1;
return __have_o_cloexec > 0;
}
#endif
So in each call for open() with a O_CLOEXEC flag, will check if the
current kernel suport it, then use it.
This is that the enable-kernel do, just remove these runtime-checks for
features.
Cheers,
--
Gerardo Exequiel Pozzi ( djgera )
http://www.djgera.com.ar
KeyID: 0x1B8C330D
Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
