This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Minimum Linux kernel version for glibc 2.17


On Wed, 9 May 2012, Mike Frysinger wrote:

> i would prefer to keep the version checking in the features header accurate.  
> seems like the cost is already sunk, and removing them doesn't really gain 
> anything ?  we use this header verbatim in uClibc, so it'd be nice to not have 
> to fork it ...

I don't really think the checking is particularly accurate at present.  
The current state of the code (without my patch to remove pre-2.2 support) 
has a comment that various numbers are just set to correspond to 2.2.0 
without having checked exact versions, and I mentioned bug 9894 regarding 
other inaccuracies.  If there are fewer conditionals, the checking is a 
smaller task and it's more likely people will actually check.

I think readability of the code is an important consideration; if an 
internal macro isn't used, it shouldn't normally be defined, and if a 
condition is not relevant for plausible systems on which current glibc 
might be used, the code shouldn't be conditional.

Another reason as far as I'm concerned for pruning the old conditionals 
from this file is the desire to move to making libc architectures look 
more like ports architectures and have (among other things) their own 
kernel-features.h files instead of architecture conditionals in a common 
file.  Again, this is easier to do, and easier to review, if there are 
fewer conditionals present in the file - if, where the version at which a 
feature was added was different for different architectures, all those 
versions are old enough that the define and conditionals can be removed 
completely.

There's a place for historical information about feature support in 
different Linux kernel versions, but I don't think the glibc source code 
is that place.  Maybe there should be a page on some wiki (is there a 
generic Linux one?) about features in the Linux syscall interface and when 
they were introduced, where you could put information being removed from 
kernel-features.h.

That pre-2.2-removal patch does change

-/* When did the `setresuid' syscall became available?  */
-#if __LINUX_KERNEL_VERSION >= 131584 && !defined __sparc__
+/* When did the `setresuid' syscall became available?  By 2.2.0 except
+   on SPARC.  */
+#if !defined __sparc__
 # define __ASSUME_SETRESUID_SYSCALL    1
 #endif

which does not remove any information (131584 == 0x020200) but when 
removing pre-2.4 support I'd expect to remove all references to 
__ASSUME_SETRESUID_SYSCALL since it will then be true for all 
architectures.

The pre-2.2 removal patch also does

 /* The sendfile syscall was introduced in 2.2.0.  */
-#if __LINUX_KERNEL_VERSION >= 131584
-# define __ASSUME_SENDFILE             1
-#endif
+#define __ASSUME_SENDFILE              1

keeping the comment with a specific version number and the #define because 
__ASSUME_SENDFILE is used in nscd rather than Linux-specific code, but 
removing the conditionals because pre-2.2 conditionals are no longer 
relevant to glibc.  I'd expect the same to apply naturally to other cases 
where the macro needs to stay: refer to the old versions in comments.

I'd imagine the patches go in a sequence:

* pre-2.2 removal (sent)

* pre-2.4 removal

* pre-2.6.0 removal

* pre-2.6.16-final removal

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]