On Friday 31 August 2007, Karel Zak wrote: > On Wed, Aug 29, 2007 at 07:43:45AM -0400, Mike Frysinger wrote: > > in the ionice.c function is a big old list of ifdef's to handle the > > syscall not being set yet ... you can easily pick out the architectures > > that'll fail on (i just get a mips report), so perhaps that should be put > > into configure.in ? if so, i can post a patch ... > > Yes. I think the best solution is create an UTIL_SYSCALL_CHECK > autoconf macro rather than use AC_COMPILE_IFELSE for all SYS_ checks. > > I've a little played with this ionice code in 2.13: > > http://www.mail-archive.com/util-linux-ng@xxxxxxxxxxxxxxx/msg00429.html > > .. I wasn't sure if all actively used glibc versions already support > SYS_ionice_{set,get}. > > The private __NR_<syscall> definitions are bad thing and it should be > used only when the syscall is really new and unsupported by glibc. > > The question is how long we have to support compilation against > incomplete (old, without relevant SYS_) glibc versions. I'm think one > major util-linux-ng release is enough. Mix old glibc, new kernel and > new util-linux is crazy idea... it isnt a glibc issue at all though ... glibc automatically generates the SYS_ list at build time based on the linux headers you compile against and the __NR_ list they contain ... so you'd be proposing "what is the min kernel version needed for util-linux" and in this case, it'd be like "if you want to use util-linux on mips, you need to be using linux-2.6.22+" which seems extreme to me i'd say at this point in time, we should actively be supporting 2.6 and actively not trying to kill support for 2.4, but anything older is fair game for puntage -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
