Re: Observation re third parties supporting Debian kernels
On Sun, Sep 25, 2005 at 03:58:31PM +1000, Andrew Pollock wrote:
> On Sat, Sep 24, 2005 at 12:58:39PM +0200, Sven Luther wrote:
> > On Sat, Sep 24, 2005 at 07:02:57PM +1000, Andrew Pollock wrote:
> > > Hi,
> > >
> > > I attended a product briefing at Computer Associates on Thursday, and one of
> > > the products that was discussed more than demonstrated was something called
> > > eTrust Access Control[1], which, from my interpretation, sounds like it
> > > achieves something similar to what SE Linux probably does. That's not really
> > > the point of this email though.
> > >
> > > I asked one of the engineering types about their Linux support for this
> > > product during one of the breaks. It can enforce a policy on Windows, a few
> > > commercial Unix variants, and on "Linux". When I pressed the engineer on
> > > what Linux distros were supported, it was just RedHat Enterprise Linux.
> > >
> > > He did mention that they'd looked into supporting Debian, but slammed the
> > > lid back down on it after they had discovered (and I'm paraphrasing)
> > > "multiple kernels with the same version number".
> >
> > Seems like uninformed non-sense, but then maybe due to the previous messy
> > situation. I think these guys are lying when speakign about linux support
> > anyway, and only mean linux/x86 anyway.
>
> Possibly (uninformed). I didn't go into details with the guy. I don't even
> know what version of Debian they'd looked at, and yes, Linux/x86 is
> absolutely correct. These guys are coming from the world where there were
> only commercial Unices, so in that case, there'd be one commercial Unix per
> CPU architecture, so the model of distributing binaries would work. I'm not
> suggesting that it's a good model...
I think that a few things are worth noting.
Firstly, it is pretty common practice amongst Linux distributions
to ship multiple flavours (though they might be called other things)
of the same kernel for the same architecture. I am pretty sure that
Red Hat do this, well at least they used to. They do it in a slightly
different way (I'm not going to be drawn on saying more than that :)
way. But its much the same thing from a vendor point of view.
The reason this is done is simple, performance. People want it, and
there is a school of thought that having various flavours is the way to
go. I believe that the Ubuntu kernel people are looking into just how
much the performance win is, and if it is worth it or not. The
Debian kernel team would certainly be happy to trim down the number of
flavours if it turns out the optimisation value is slim. But I think
at the least you are going to have a cover-all (in i386 terms that
probably means 386 or 486) kernel that runs on everything and
an optimised (in i386 that probably means p4 or pIII) kernel that
works faster on a hardware that is in wide-spread use.
Secondly, the Kernel ABI changes, so unfortunately this means
the ABI presented by distributions changes. This happens at least
every time the upstream kernel is changed (e.g. 2.6.12->2.6.13).
Distributions tend to try and avoid ABI changes between upstream
changes, but sometimes they are unaviodable. ABI changes hurt because
external modules have to be recompiled.
In Debian these changes are managed by an ABI number in the kernel
package (this was missing for some architectures, such as powerpc in
Sarge, but should be there for all architectures in Etch). This at
least allows people to control the change - essetianlly they have
to opt to get a kernel with a new ABI installed.
And as for why the ABI changes, upstream have stated repeatedly that
this is just they way they opperate and people who want their
drivers supported should get them into the kernel, and make them GPL.
If a vendor doesn't want to play that game, unfortunately they
get the cold sholder from kernel upstream. And there is only so
much distributions can do to soften that. And frankly, if their
code isn't GPL, well, you heard what Christoph had to say...
Lastly, as Sven mentioned, Debian does have infastructure to allow
out of tree modules to be built. Its not perfect, but I think its
superiour to a lot of other distributions support. Improvements are
always welcome, but I think that the main problem here is a
communication issue, not a techincal issue.
--
Horms
Reply to: