[tulip] Re: Linksys LNE100TX Driver Problems <- Possible issue

[Donald Becker]

On Tue, 8 Aug 2000, Keith Owens wrote:

> >   ln -s ../src/linux/include/asm .
> >   ln -s ../src/linux/include/linux .
> 
> You realize that Linus is going to come round to your place and make
> you use Windows now?
> 
> There has just been a big argument about these symlinks on l-k and
> Linus says "NO WAY".  /usr/include/asm and /usr/include/linux have to

Not everyone agreed with Linus on this point, at least not with the current
state of affairs.

He did not consider all of the issues, and was not identifying the distinct
uses of the kernel header files.  Some are published interfaces, while
others are internal cruft.

One example is when a new kernel supports new ioctl() calls.  A program can
test for missing calls on older kernels, but without the proper constants
and structures in the header files it must have local copies of everything.

OTOH, there is a lot of bogus cruft that should never have been been in *.h
files in the first place.  Quick rules:
  If only one file needs the symbolic constant, don't put it in a header file
  If a constant is only needed in one place, a symbolic name is likely bogus.

Much of /usr/src/linux/include is really ugly, and should never been seen by
user code.  Check out <linux/fs.h> or <linux/blk.h>.  Wait at least two
hours after eating.

> exist but they should not be symlinks to any old kernel.  They should
> be real directories containing the headers that glibc was built with.
> It is the only way to avoid random compile problems when the kernel
> changes.

A good point of not having the links is that it's a obvious which structures
and variables are interface layers and should not change.

IMNSHO, the proper solution is to not to mix the different uses of header
files.


Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf-II Cluster Distribution
Annapolis MD 21403