Re: Potentially serious problem with kernel-headers...
Hi,
>>"Patrick" == Patrick Ouellette <pouellet@eng.utoledo.edu> writes:
Patrick> 1. Linux kernel headers are in a more or less constant state
Patrick> of flux depending on the kernel version
Unmm, I think that is an exaggeration. This would have been an
accurate assesment of the situation way back in 0.9X days; but now "a
constant state of flux" is an overstatement; not that they are
static, mind you, but that the APIs and data structures are
"supposed" to be quite stable.
Patrick> 2. The method for insulating applications from this constant change
Patrick> should be the libc library
If at all possible. If the underlying data structure has
changed radically, then a simple wrapper may not be enough --
rtemember that glibc is not a Linux only entity; changes are slow.
Patrick> 3. The libc library would need to change constantly to keep
Patrick> up with changes in the kernel internal structures defined
Patrick> in the constantly changing kernel headers
Umm, yes. The idea is that Linux is supposed to be mature
enough that user visible changes should occur once in a blue moon.
Patrick> 4. The libc library does not change as fast as the kernel,
Patrick> so application developers who wish to use features that
Patrick> have been added or modified in recent kernels use kernel
Patrick> headers to build their applications. This causes the
Patrick> application to break when an internal kernel structure is
Patrick> modified (i.e. a new kernel revision is released).
Personally, this is not really a good idea for application
developers (portability of code is important to me, and portable code
would not suffer from this). However, if you are writing device
drivers, you need the internals. (Darn UNIX. The HURD should solve
this)
Patrick> Brain dead solutions to the problems are:
Patrick> 1. Force all applications to be complied under a particular
Patrick> kernel version and put the disclaimer on a release that
Patrick> says - applications are only built/checked against
Patrick> kernel x.y.z <not very user friendly>
This is overkill, and mostly unnecessary. How many applications
have broken due to a kernel upgrade? (I know, personally, of 5)
. Certainly, some things need to be tied to a kernel version (pcmcia
modules come to mind). Requiring it for all application is highly
undesirable.
Patrick> 2. Require all applications to use libc only calls and not
Patrick> to have things that directly depend on internal kernel
Patrick> structures <yea, right - everyone will write code that
Patrick> uses only approved OS hooks -- Apple seems to be the
Patrick> closest to this and we all know how much marketshare
Patrick> they have, not that this is about marketshare.
Actually, this is not far from being the state of affairs --
most applications, especially GNU applications, are already readily
portable. Wanna know how many OS's gcc or Perl compile cleanly on?
Patrick> 3. Find a set of well known and tested kernel structures
Patrick> and build a set of kernel headers using these, provided
Patrick> they have proven to be stable and unchanging then you
Patrick> have to argue over what is stable and unchanging>, and
Patrick> tell users they are "own their own" for new "bleeding
Patrick> edge" items until they migrate to the stable realm.
This is the current state of affairs, and this, as you have
seen, does not work for all applications. If an application needs
non-portable internal kernel structures; then they are indeed at the
mercy of the kernel -- just having libc pretned the internal
structure has not changed does not buy you anything. The application
shall fail (possibly quite subtly) if the kernel data structures
change.
Patrick> 4. Let everyone do what they want. Attempt no
Patrick> standardization and deal with each issue as it happens
Patrick> <not really an option for a system as large as Debian>
Tell people to write portable applications. Or else explicitly
depend on a specific kernel version. There is really no middle ground.
Patrick> 5. Give up and play with blocks.
manoj
--
"Cogito ergo I'm right and you're wrong." Blair Houghton
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: