Mainline bootstrap failure in toplev.c

Mainline bootstrap failure in toplev.c

[Wolfgang Bangerth]

Hi all,
for several weeks now (I believe since my box has been upgraded to 
Mandrake), mainline doesn't bootstrap any more for me. In stage1 
I get this:

stage1/xgcc -Bstage1/ -B/ices/bangerth/tmp/build-gcc/gcc-install/i686-pc-linux-gnu/bin/   -O2 -g -fomit-frame-pointer -DIN_GCC   -fno-common   -DHAVE_CONFIG_H    -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -DTARGET_NAME=\"i686-pc-linux-gnu\" -c ../../gcc/gcc/toplev.c -o toplev.o -save-temps
../../gcc/gcc/toplev.c: In function 'toplev_main':
../../gcc/gcc/toplev.c:544: sorry, unimplemented: inlining failed in call to 'floor_log2': redefined extern inline functions are not considered for inlining
../../gcc/gcc/toplev.c:1675: sorry, unimplemented: called from here
../../gcc/gcc/toplev.c:544: sorry, unimplemented: inlining failed in call to 'floor_log2': redefined extern inline functions are not considered for inlining
../../gcc/gcc/toplev.c:1679: sorry, unimplemented: called from here
../../gcc/gcc/toplev.c:544: sorry, unimplemented: inlining failed in call to 'floor_log2': redefined extern inline functions are not considered for inlining
../../gcc/gcc/toplev.c:1681: sorry, unimplemented: called from here
../../gcc/gcc/toplev.c:544: sorry, unimplemented: inlining failed in call to 'floor_log2': redefined extern inline functions are not considered for inlining
../../gcc/gcc/toplev.c:1685: sorry, unimplemented: called from here

make then stops. Frankly, I don't know what these messages mean, but when
trying to find out what that could be, I realized that floor_log2 is
implemented multiple times: first, in toplev.h we have

  extern int floor_log2                  (unsigned HOST_WIDE_INT);
  [...]
  extern inline int
  floor_log2 (unsigned HOST_WIDE_INT x)
  {
    return x ? HOST_BITS_PER_WIDE_INT - 1 - (int) CLZ_HWI (x) : -1;
  }

Then, in toplev.c, the same function is reimplemented:
  int
  floor_log2 (unsigned HOST_WIDE_INT x)
  {
    [...]
  }
 
That in itself strikes me as odd and wrong. In addition, the inline keyword
in the first definition is expanded to
  __inline__ __attribute__((always_inline)) __attribute__((always_inline))
which presumably is the cause of the problem.

Is this a problem that others have seen before me?

Thanks
  Wolfgang

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Mainline bootstrap failure in toplev.c

[Andrew Pinski]

On Dec 1, 2004, at 10:32 AM, Wolfgang Bangerth wrote:

>
> Hi all,
> for several weeks now (I believe since my box has been upgraded to
> Mandrake), mainline doesn't bootstrap any more for me. In stage1
> I get this:


> That in itself strikes me as odd and wrong. In addition, the inline 
> keyword
> in the first definition is expanded to
>   __inline__ __attribute__((always_inline)) 
> __attribute__((always_inline))
> which presumably is the cause of the problem.
>
> Is this a problem that others have seen before me?


Yes this is caused by the newer linux kernel headers which define
inline as "__inline__ __attribute__((always_inline))".  So this is the
normal linux kernel headers fucking up the build.  This was reported
back when the linux kernel headers changed and when the error was added
to gcc.

Thanks,
Andrew Pinski

Re: Mainline bootstrap failure in toplev.c

[Wolfgang Bangerth]

> Yes this is caused by the newer linux kernel headers which define
> inline as "__inline__ __attribute__((always_inline))".  So this is the
> normal linux kernel headers [expletive deleted to get around spam block] up 
> the build.  This was reported

Ah, thanks. (I have other gripe with the kernel on this machine, since it 
doesn't allow the use any other compiler in /usr/include/linux/compiler.h 
unless it identifies itself as gcc...)


> back when the linux kernel headers changed and when the error was added
> to gcc.

Apparently it didn't help, as there are now systems out there on which gcc 
doesn't bootstrap. So we need to find a workaround. However, I'd like again 
to ask whether it is intentional that we have two different implementations 
of the same function? This strikes me as wrong, and the lack of comments 
doesn't indicate that this was a conscious decision. It is hardly worth 
noting, I guess, that removing one of the definitions allows the bootstrap to 
continue...

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Mainline bootstrap failure in toplev.c

[Richard Henderson]

On Wed, Dec 01, 2004 at 09:55:59AM -0600, Wolfgang Bangerth wrote:
> ... it is intentional that we have two different implementations 
> of the same function?

I did intentionally make use of the semantics of "extern inline", yes.


r~

Re: Mainline bootstrap failure in toplev.c

[Wolfgang Bangerth]

> I did intentionally make use of the semantics of "extern inline", yes.

OK, thanks for the clarification.

The question remains as to what to do on systems with headers that some people 
describe with words I dare not repeat here?

Thanks
  Wolfgang

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Mainline bootstrap failure in toplev.c

[Richard Henderson]

On Wed, Dec 01, 2004 at 11:18:21AM -0600, Wolfgang Bangerth wrote:
> The question remains as to what to do on systems with headers that
> some people describe with words I dare not repeat here?

Fixinclude them.


r~

Re: Mainline bootstrap failure in toplev.c

[Joe Buck]

On Wed, Dec 01, 2004 at 09:20:09AM -0800, Richard Henderson wrote:
> On Wed, Dec 01, 2004 at 11:18:21AM -0600, Wolfgang Bangerth wrote:
> > The question remains as to what to do on systems with headers that
> > some people describe with words I dare not repeat here?
> 
> Fixinclude them.

We will then get angry e-mails from Mr. Torvalds and friends, since if
the headers are fixincluded, future kernel builds won't see them.
Of course, they can use explicit -I directives to get the non-modified
headers.

Re: Mainline bootstrap failure in toplev.c

[Zack Weinberg]

Richard Henderson <rth@redhat.com> writes:

> On Wed, Dec 01, 2004 at 11:18:21AM -0600, Wolfgang Bangerth wrote:
>> The question remains as to what to do on systems with headers that
>> some people describe with words I dare not repeat here?
>
> Fixinclude them.

Uh, why is linux/compiler.h getting dragged into the compilation of a
user space program in the first place?  (That definition of inline is
not appropriate for anything other than the kernel - in fact I don't
think it's appropriate for the kernel, but that's an unrelated can of
worms.) 

zw

Re: Mainline bootstrap failure in toplev.c

[Wolfgang Bangerth]

> Fixinclude them.

This would change the semantics of kernel headers in the same way (but 
opposite direction) of how it changed the semantics of the function 
definition in toplev.h.

While I'm just as angry at the kernel people as you are, I'm not sure that's 
the best way to go.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Mainline bootstrap failure in toplev.c

[Paul Brook]

On Wednesday 01 December 2004 17:38, Joe Buck wrote:
> On Wed, Dec 01, 2004 at 09:20:09AM -0800, Richard Henderson wrote:
> > On Wed, Dec 01, 2004 at 11:18:21AM -0600, Wolfgang Bangerth wrote:
> > > The question remains as to what to do on systems with headers that
> > > some people describe with words I dare not repeat here?
> >
> > Fixinclude them.
>
> We will then get angry e-mails from Mr. Torvalds and friends, since if
> the headers are fixincluded, future kernel builds won't see them.
> Of course, they can use explicit -I directives to get the non-modified
> headers.

I'd expect kernel builds should be using their own headers, not the installed 
system ones.

Paul

Re: Mainline bootstrap failure in toplev.c

[Joe Buck]

On Wed, Dec 01, 2004 at 05:51:19PM +0000, Paul Brook wrote:
> On Wednesday 01 December 2004 17:38, Joe Buck wrote:
> > On Wed, Dec 01, 2004 at 09:20:09AM -0800, Richard Henderson wrote:
> > > On Wed, Dec 01, 2004 at 11:18:21AM -0600, Wolfgang Bangerth wrote:
> > > > The question remains as to what to do on systems with headers that
> > > > some people describe with words I dare not repeat here?
> > >
> > > Fixinclude them.
> >
> > We will then get angry e-mails from Mr. Torvalds and friends, since if
> > the headers are fixincluded, future kernel builds won't see them.
> > Of course, they can use explicit -I directives to get the non-modified
> > headers.
> 
> I'd expect kernel builds should be using their own headers, not the installed 
> system ones.

But this *is* one of "their own headers".  The bug is that, on most
GNU/Linux systems, kernel headers are included by some of the headers in
/usr/include.

Re: Mainline bootstrap failure in toplev.c

[Daniel Jacobowitz]

On Wed, Dec 01, 2004 at 05:51:19PM +0000, Paul Brook wrote:
> On Wednesday 01 December 2004 17:38, Joe Buck wrote:
> > On Wed, Dec 01, 2004 at 09:20:09AM -0800, Richard Henderson wrote:
> > > On Wed, Dec 01, 2004 at 11:18:21AM -0600, Wolfgang Bangerth wrote:
> > > > The question remains as to what to do on systems with headers that
> > > > some people describe with words I dare not repeat here?
> > >
> > > Fixinclude them.
> >
> > We will then get angry e-mails from Mr. Torvalds and friends, since if
> > the headers are fixincluded, future kernel builds won't see them.
> > Of course, they can use explicit -I directives to get the non-modified
> > headers.
> 
> I'd expect kernel builds should be using their own headers, not the installed 
> system ones.

Correct.  Fixincluding them should be fine.

-- 
Daniel Jacobowitz

Re: Mainline bootstrap failure in toplev.c

[Daniel Jacobowitz]

On Wed, Dec 01, 2004 at 09:55:32AM -0800, Joe Buck wrote:
> On Wed, Dec 01, 2004 at 05:51:19PM +0000, Paul Brook wrote:
> > On Wednesday 01 December 2004 17:38, Joe Buck wrote:
> > > On Wed, Dec 01, 2004 at 09:20:09AM -0800, Richard Henderson wrote:
> > > > On Wed, Dec 01, 2004 at 11:18:21AM -0600, Wolfgang Bangerth wrote:
> > > > > The question remains as to what to do on systems with headers that
> > > > > some people describe with words I dare not repeat here?
> > > >
> > > > Fixinclude them.
> > >
> > > We will then get angry e-mails from Mr. Torvalds and friends, since if
> > > the headers are fixincluded, future kernel builds won't see them.
> > > Of course, they can use explicit -I directives to get the non-modified
> > > headers.
> > 
> > I'd expect kernel builds should be using their own headers, not the installed 
> > system ones.
> 
> But this *is* one of "their own headers".  The bug is that, on most
> GNU/Linux systems, kernel headers are included by some of the headers in
> /usr/include.

This is a _copy_ of those files, provided by the distributor, living in
/usr/include.  The kernel will not reference them during build.

-- 
Daniel Jacobowitz

Re: Mainline bootstrap failure in toplev.c

[Joe Buck]

On Wed, Dec 01, 2004 at 12:56:31PM -0500, Daniel Jacobowitz wrote:
> On Wed, Dec 01, 2004 at 09:55:32AM -0800, Joe Buck wrote:
> > But this *is* one of "their own headers".  The bug is that, on most
> > GNU/Linux systems, kernel headers are included by some of the headers in
> > /usr/include.
> 
> This is a _copy_ of those files, provided by the distributor, living in
> /usr/include.  The kernel will not reference them during build.

Then this is bug in the distro; it changes the meaning of
"inline" for any program that inadvertently includes that copied header.
In this case, a fixincludes approach is harmless, as long as kernel
compiles never use the copy.

Re: Mainline bootstrap failure in toplev.c

[Daniel Jacobowitz]

On Wed, Dec 01, 2004 at 10:03:03AM -0800, Joe Buck wrote:
> On Wed, Dec 01, 2004 at 12:56:31PM -0500, Daniel Jacobowitz wrote:
> > On Wed, Dec 01, 2004 at 09:55:32AM -0800, Joe Buck wrote:
> > > But this *is* one of "their own headers".  The bug is that, on most
> > > GNU/Linux systems, kernel headers are included by some of the headers in
> > > /usr/include.
> > 
> > This is a _copy_ of those files, provided by the distributor, living in
> > /usr/include.  The kernel will not reference them during build.
> 
> Then this is bug in the distro; it changes the meaning of
> "inline" for any program that inadvertently includes that copied header.
> In this case, a fixincludes approach is harmless, as long as kernel
> compiles never use the copy.

Right.  Debian has fixed this some time ago; I imagine most other Linux
distributions have also.

-- 
Daniel Jacobowitz

Re: Mainline bootstrap failure in toplev.c

[Richard Henderson]

On Wed, Dec 01, 2004 at 09:38:15AM -0800, Joe Buck wrote:
> We will then get angry e-mails from Mr. Torvalds and friends, since if
> the headers are fixincluded, future kernel builds won't see them.

That's false.  The actual kernel build uses -nostdinc.


r~

Re: Mainline bootstrap failure in toplev.c

[Wolfgang Bangerth]

> Uh, why is linux/compiler.h getting dragged into the compilation of a
> user space program in the first place?

Through the following chain:

  signal.h
  bits/sigcontext.h
  asm/sigcontext.h
  linux/compiler.h

The redefinition of "inline" is guarded like so:
  #if __GNUC_MINOR__ >= 1 && defined __KERNEL__
  # define inline		__inline__ __attribute__((always_inline))
  # define __inline__	__inline__ __attribute__((always_inline))
  # define __inline	__inline__ __attribute__((always_inline))
  #endif

I have no idea, however, why __KERNEL__ is apparently set during gcc 
bootstrapping.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Mainline bootstrap failure in toplev.c

[Richard Henderson]

On Wed, Dec 01, 2004 at 02:12:30PM -0600, Wolfgang Bangerth wrote:
> I have no idea, however, why __KERNEL__ is apparently set during gcc 
> bootstrapping.

Can you please find out?  Whatever it is, *that's* the place we
probably need to fixinclude.


r~

Re: Mainline bootstrap failure in toplev.c

[Wolfgang Bangerth]

> Can you please find out?  Whatever it is, *that's* the place we
> probably need to fixinclude.

This happens only when compiled with stage1/xgcc. And the reason is a little 
more complicated than I had thought: in /usr/include/linux/compiler.h, we 
have
  #if __GNUC__ > 3
  # include <linux/compiler-gcc+.h>	/* catch-all for GCC 4, 5, etc. */
  #elif __GNUC__ == 3
  # include <linux/compiler-gcc3.h>

For mainline, we have __GNUC__==4, so we include the second include file in 
the first stage, and the first include file when compiling with stage1/xgcc. 
Now, in /usr/include/compiler-gcc+.h we find the evil:

  #ifndef __KERNEL__
  #define inline		__inline__ __attribute__((always_inline))
  #define __inline__		__inline__ __attribute__((always_inline))
  #define __inline		__inline__ __attribute__((always_inline))
  #endif

Note *ifndef*, whereas in /usr/include/compiler-gcc3.h we had the exact 
opposite condition of whether __KERNEL__ is defined. I would claim that this 
is a genuine typo/bug in the kernel headers.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Mainline bootstrap failure in toplev.c

[Andreas Schwab]

Wolfgang Bangerth <bangerth@ices.utexas.edu> writes:

>> Can you please find out?  Whatever it is, *that's* the place we
>> probably need to fixinclude.
>
> This happens only when compiled with stage1/xgcc. And the reason is a little 
> more complicated than I had thought: in /usr/include/linux/compiler.h, we 
> have
>   #if __GNUC__ > 3
>   # include <linux/compiler-gcc+.h>	/* catch-all for GCC 4, 5, etc. */
>   #elif __GNUC__ == 3
>   # include <linux/compiler-gcc3.h>

Are you using kernel headers from before 2.6.3?  Since 2.6.3 this
block as a whole is protected by __KERNEL__.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Mainline bootstrap failure in toplev.c

[Wolfgang Bangerth]

> > This happens only when compiled with stage1/xgcc. And the reason is a
> > little more complicated than I had thought: in
> > /usr/include/linux/compiler.h, we have
> >   #if __GNUC__ > 3
> >   # include <linux/compiler-gcc+.h>	/* catch-all for GCC 4, 5, etc. */
> >   #elif __GNUC__ == 3
> >   # include <linux/compiler-gcc3.h>
>
> Are you using kernel headers from before 2.6.3?  Since 2.6.3 this
> block as a whole is protected by __KERNEL__.

This is
  Linux version 2.4.25-9mdksmp (qateam@updates.mandrakesoft.com) (gcc version
  3.3.2 (Mandrakelinux 10.0 3.3.2-7mdk)) #1 SMP Thu Sep 23 14:41:57 MDT 2004
I don't know what local patches Mandrake has.

It would still seem to be a bug if linux/compiler-gcc+.h used #ifndef 
__KERNEL__. Or was that fixed as well?

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Mainline bootstrap failure in toplev.c

[Andreas Schwab]

Wolfgang Bangerth <bangerth@ices.utexas.edu> writes:

> It would still seem to be a bug if linux/compiler-gcc+.h used #ifndef 
> __KERNEL__. Or was that fixed as well?

There was never any use of __KERNEL__ in linux/compile-gcc+.h in any
released version of the kernel sources.  Looks like a bug specific to
Mandrake.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Mainline bootstrap failure in toplev.c

[Wolfgang Bangerth]

> There was never any use of __KERNEL__ in linux/compile-gcc+.h in any
> released version of the kernel sources.  Looks like a bug specific to
> Mandrake.

OK, good to know. I'll see whether I can find a place to report bugs with 
mandrake...

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Mainline bootstrap failure in toplev.c

[Kai Henningsen]

bangerth@ices.utexas.edu (Wolfgang Bangerth)  wrote on 01.12.04 in <200412011149.59155.bangerth@ices.utexas.edu>:

> > Fixinclude them.
>
> This would change the semantics of kernel headers in the same way (but
> opposite direction) of how it changed the semantics of the function
> definition in toplev.h.
>
> While I'm just as angry at the kernel people as you are, I'm not sure that's
> the best way to go.

Don't be angry at the kernel people.

Be angry at the glibc and/or Mandrake people.

The official kernel point of view is that raw kernel includes shall not be  
exposed to user programs at all. Libc should instead offer sanitized  
versions. And that's been their point of view for many years now.

It's not their fault that glibc doesn't follow that rule.

The below was back when everyone used symlinks to point /usr/include/ 
{linux,asm} to the actual kernel (I hear some people *still* do that,  
seven years later!), but parts of it still apply to copies.

======

>> "Linus" == Linus Torvalds said on Wed, 22 Jan 1997:

Linus> The kernel headers used to make sense exporting to user space,
Linus> but the user space thing has grown so much that it's really not
Linus> practical any more. The problem with Debian is just that they
Linus> are different, not that they are doing anything wrong. That
Linus> leads to differences between the distributions, and that in
Linus> turn obviously can result in subtle problems.

Linus> As of glibc, the kernel headers will really be _kernel_
Linus> headers, and user level includes are user level
Linus> includes. Matthias Ulrich did that partly because I've asked
Linus> him to, but mainly just because it is no longer possible to try
Linus> to synchronize the libc and the kernel the way it used to
Linus> be. The symlinks have been a bad idea for at least a year now,
Linus> and the problem is just how to get rid of them
Linus> gracefully. Personally, I'm counting on glibc, which we are
Linus> already using on alpha.

Linus> Just to give you some idea of exactly why the includes really
Linus> can't be handled by simple symlinks: the main problem is
Linus> version skew. Lots of people want to upgrade their library
Linus> without affecting the kernel, and probably even more people
Linus> want to be able to upgrade their kernel without affecting their
Linus> compilation environment. Right now doing that has been
Linus> extremely fragile.

Linus> Just to give _one_ example of why the symlinks are bad: NR_OPEN
Linus> and "fd_set". I have had no end of problems making NR_OPEN
Linus> larger in the kernel, exactly _because_ of the damn
Linus> sym-links. If I just make NR_OPEN larger (the right thing to
Linus> do), the problem is that people with old libraries will now
Linus> compile against a header file that doesn't match the library
Linus> any more. And when the library internally uses another  NR_OPEN
Linus> than the new program does, "interesting" things happen.

Linus> In contrast, with separate header files, this doesn't make any
Linus> difference.  If I change NR_OPEN in the kernel, the compilation
Linus> environment won't notice UNTIL the library and associated
Linus> header files are changed: thus the user will continue to compile
Linus> with the old values, but because we'll still be binary
Linus> compatible, the worst thing that happens is that new programs
Linus> won't take advantage of new features unless the developer has
Linus> upgraded his library. Compare that to breaking subtly.

Linus> NR_OPEN is just _one_ example, and actually it's one of the
Linus> easier ones to handle (because the only thing that really makes
Linus> much of a difference when it comes to NR_OPEN is the fd_set
Linus> size - but it certainly bit some people). Another major problem
Linus> is name-space pollution: the POSIX/ANSI/XOpen rules are not
Linus> only complex, but they are actually contradictory too. And the
Linus> kernel header files really can't reasonably support all of the
Linus> intricacies very cleanly.

Linus> One specific example of why we want separate header files for
Linus> libraries and kernel is offered by glibc: Matthias wanted to
Linus> have a "sigset_t" that will suffice for the future when the
Linus> POSIX.1b realtime signals are implemented. But at the same time
Linus> he obviously wants to be able to support programming on
Linus> Linux-2.0 and the current 2.1 that do not have that support.

Linus> The _only_ reasonably clean way to handle these kinds of
Linus> problems is to have separate header files: user programs see a
Linus> larger sigset_t, and then the library interaction with the
Linus> kernel doesn't necessarily use all of the bits, for
Linus> example. Then later, when the kernel support is actually there,
Linus> it's just a matter of getting a new shared library, and voila,
Linus> all the realtime signals work.

Linus> The symlink approach simply wouldn't work for the above: that
Linus> would have required everybody who uses the library to have a
Linus> recent enough kernel that whatever magic all the above entails
Linus> would be available in the kernel header files. But not only
Linus> don't I want to pollute the kernel header files with user level
Linus> decisions, it's actually possible that somebody wants to run
Linus> glibc on a 1.2.x kernel, for example. We _definitely_ do not
Linus> want him to get a 32-bit sigset_t just because he is happy with
Linus> an old kernel.

Linus> Anyway, this email got longer than intended, but I just wanted
Linus> to make clear that the symlinks will eventually be going away
Linus> even in non-Debian distributions. Debian just happened to do it
Linus> first - probably because Debian seems to be more interested in
Linus> technical reasons than any old traditions. And technically, the
Linus> symlinks really aren't very good.

Linus> The _only_ reason for the symlinks is to immediately give
Linus> access to new features in the kernel when those happen. New
Linus> ioctl numbers etc etc. That was an overriding concern early on:
Linus> the kernel interfaces expanded so rapidly even in "normal"
Linus> areas that having the synchronization that symlinks offered was
Linus> a good thing.

Linus> However, the kernel interfaces aren't really supposed to change
Linus> all that quickly any more, and more importantly: the technical
Linus> users know how to fix things any way they want, so if they want
Linus> a new ioctl number to show up they can actually edit the header
Linus> files themselves, for example. But having separation is good
Linus> for the non-technical user, because there are less surprises
Linus> and package dependencies.

Linus> Anyway, something like the patch that David suggested will
Linus> certainly go in, although I suspect I'll wait for it to become
Linus> "standard" and the glibc first real release to take place.


======

MfG Kai