RE: Potentially serious problem with kernel-headers...
Forgive my stupidity, but if I understand this thread so far there
are a couple of issues that are self-feeding: (be kind, I don't follow
the kernel or libc lists)
1. Linux kernel headers are in a more or less constant state of flux
depending on the kernel version
2. The method for insulating applications from this constant change
should be the libc library
3. The libc library would need to change constantly to keep up with
changes in the kernel internal structures defined in the constantly
changing kernel headers
4. The libc library does not change as fast as the kernel, so application
developers who wish to use features that have been added or modified in
recent kernels use kernel headers to build their applications. This
causes the application to break when an internal kernel structure is
modified (i.e. a new kernel revision is released).
Brain dead solutions to the problems are:
1. Force all applications to be complied under a particular kernel version
and put the disclaimer on a release that says - applications are only
built/checked against kernel x.y.z <not very user friendly>
2. Require all applications to use libc only calls and not to have things
that
directly depend on internal kernel structures <yea, right - everyone
will write
code that uses only approved OS hooks -- Apple seems to be the closest
to this
and we all know how much marketshare they have, not that this is about
marketshare>
3. Find a set of well known and tested kernel structures and build a set of
kernel
headers using these, provided they have proven to be stable and
unchanging
<then you have to argue over what is stable and unchanging>, and tell
users they
are "own their own" for new "bleeding edge" items until they migrate to
the
stable realm.
4. Let everyone do what they want. Attempt no standardization and deal
with each issue
as it happens <not really an option for a system as large as Debian>
5. Give up and play with blocks.
FWIW, I don't see any of the commercial OS vendors who do a good job with
this problem either.
Lots of stuff breaks in the MS-DOS/Windows world from version to version.
Apple fairs slightly
better, only because they warned developers to use only published system
calls when writing
applications for early Macs. When Apple updated the Mac OS for the first
"major" time lots
of applications (and lots of games if I recall) didn't work on the new
version. After that the
Mac developer world became a whole lot more compatible (as far as OS changes
went).
IBM has a similar problem on AIX upgrades. I was sysadmin for a box that we
wanted to upgrade
and after the upgrade we found lots of mission critical (for us) programs no
longer worked.
Glad I made multiple backups *before* the upgrade :-).
Perhaps we need a better name for the headers package. Something more
inline with the fact that
they are a best compromise for the current generation of the kernels we are
using. Maybe we need
to have libc headers and discourage the use of kernel headers.
Just some thoughts on the issue - maybe they will cause someone's synaptic
paths to short out and
come up with the greatest solution ever seen......
Pat
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: