Linkable Modules

Linkable Modules

Post by Geraldo Sazia » Fri, 16 Aug 2002 21:06:39



I read that linkable modules for the kernel, for example device drivers, can
only be used with the EXACT version of the kernel for which they were
compiled. It seems to me that this makes supporting device drivers very
cumbersome.

Is there a better way (besides compiling a driver from source)?

 
 
 

Linkable Modules

Post by Joshua Jone » Fri, 16 Aug 2002 22:42:07



> I read that linkable modules for the kernel, for example device drivers, can
> only be used with the EXACT version of the kernel for which they were
> compiled. It seems to me that this makes supporting device drivers very
> cumbersome.
> Is there a better way (besides compiling a driver from source)?

Not that I know of.  In the past, one could force the module to load
even if it was not compiled for the kernel version running.  However,
this has the potential for some problems.  Also, if you think about
it, why wouldn't you want your driver to be open source?  The benefits
of open source code really are evident with something like this, mostly
in that errors in driver code can be discovered and corrected more
quickly than if it were closed source, in which case errors would be
found when your code failed, which would hopefully not be in a
production system :-)

Also, while different kernel releases in the same stable version may
be significantly different in performance, typically the "driver
writer's API" will not change, so a driver written for 2.4 should
work with any release in this version, with only minor adjustments
made.  And if a script for building/installing the driver is provided,
the process should be no more difficult than downloading and installing
a driver for any other OS.

--
 Joshua Jones
 josh(at)homemail.com  |  jonesjos(at)us.ibm.com

 
 
 

Linkable Modules

Post by Geraldo Sazia » Fri, 16 Aug 2002 23:10:10




> > I read that linkable modules for the kernel, for example device drivers,
can
> > only be used with the EXACT version of the kernel for which they were
> > compiled. It seems to me that this makes supporting device drivers very
> > cumbersome.

> > Is there a better way (besides compiling a driver from source)?

> Not that I know of.  In the past, one could force the module to load
> even if it was not compiled for the kernel version running.  However,
> this has the potential for some problems.  Also, if you think about
> it, why wouldn't you want your driver to be open source?  The benefits
> of open source code really are evident with something like this, mostly
> in that errors in driver code can be discovered and corrected more
> quickly than if it were closed source, in which case errors would be
> found when your code failed, which would hopefully not be in a
> production system :-)

I don't know, but I DO know that many manufacturers are very secretive about
their drivers, for whatever reason. Maybe it's because of secret stuff in
their hardware, maybe it's because of liabillity questions, but anyway, most
manufacturers are hesistant to open up the specs on their hardware.

Also, this system forces a user to a) get a driver for his/her particular
kernel version or b) recompile the driver source from scratch and install it
using insmod. Both of these options are far from optimal especially with new
hardware and kernels being released almost every day.

Quote:

> Also, while different kernel releases in the same stable version may
> be significantly different in performance, typically the "driver
> writer's API" will not change, so a driver written for 2.4 should
> work with any release in this version, with only minor adjustments
> made.  And if a script for building/installing the driver is provided,
> the process should be no more difficult than downloading and installing
> a driver for any other OS.

Manufacturers aren't going to compile and release drivers for every stable
kernel version out there. And installing a driver should done through other
means than having to type 'make install'.
 
 
 

Linkable Modules

Post by Joshua Jone » Tue, 20 Aug 2002 01:07:32



> Also, this system forces a user to a) get a driver for his/her particular
> kernel version or b) recompile the driver source from scratch and install it
> using insmod. Both of these options are far from optimal especially with new
> hardware and kernels being released almost every day.

So, what's your solution?

Just like in any other environment, the manufacturer can choose to
support or not support newer kernels.  In the Windows world, new
releases are few and far between, so driver writers don't worry with
this problem too much AFAIK.  Likely, a linux driver writer will not choose
to support _every_ kernel released, only ones in major releases,
such as a popular distribution's modified release of the kernel source
even.

Quote:> Manufacturers aren't going to compile and release drivers for every stable
> kernel version out there. And installing a driver should done through other
> means than having to type 'make install'.

Says who?  What's so hard about that?  Personally, I prefer this simple
command to clicking "Start, Settings, Control Panel, Add New Hardware,
Next, Next, Next, Back, Back, Specify Location, Browse, <find file>,
Next, Finish."  If 'make install' is too difficult, then there may be
some precompiled RPMs out there, though personally I don't find this any
easier.

--
 Joshua Jones
 josh(at)homemail.com  |  jonesjos(at)us.ibm.com

 
 
 

Linkable Modules

Post by Kasper Dupon » Tue, 20 Aug 2002 05:59:53




> > Also, this system forces a user to a) get a driver for his/her particular
> > kernel version or b) recompile the driver source from scratch and install it
> > using insmod. Both of these options are far from optimal especially with new
> > hardware and kernels being released almost every day.

> So, what's your solution?

The only solution to that is to define some
standards and COMPLY to them. It would be so
much easier if we could use the same driver
for all IDE controlers, and another driver
for all SCSI controlers. How many differenet
do we currently have? 50 different IDE drivers
and 100 different SCSI drivers?

Quote:

> Just like in any other environment, the manufacturer can choose to
> support or not support newer kernels.  In the Windows world, new
> releases are few and far between, so driver writers don't worry with
> this problem too much AFAIK.  Likely, a linux driver writer will not choose
> to support _every_ kernel released, only ones in major releases,
> such as a popular distribution's modified release of the kernel source
> even.

The manufactures might think supporting some
versions should be enough, but I don't think
it is. If different manufactures does not
support the same versions you will have a
problem if you have more than one hardware
component in your computer. (Most people do.)
And my kernel with my 11 favourite pathces is
never the one hardware manufactures choose to
compile their drivers for.

--
Kasper Dupont -- der bruger for meget tid p? usenet.


 
 
 

Linkable Modules

Post by M?ns Rullg? » Tue, 20 Aug 2002 06:11:04



> The manufactures might think supporting some
> versions should be enough, but I don't think
> it is. If different manufactures does not
> support the same versions you will have a
> problem if you have more than one hardware
> component in your computer. (Most people do.)
> And my kernel with my 11 favourite pathces is
> never the one hardware manufactures choose to
> compile their drivers for.

They will _never_ have a version for my private patches...

--
M?ns Rullg?rd

 
 
 

Linkable Modules

Post by Alexander Vi » Tue, 20 Aug 2002 06:44:00




Quote:

>The manufactures might think supporting some
>versions should be enough, but I don't think
>it is. If different manufactures does not
>support the same versions you will have a
>problem if you have more than one hardware
>component in your computer. (Most people do.)
>And my kernel with my 11 favourite pathces is
>never the one hardware manufactures choose to
>compile their drivers for.

So you have 11 patches of varying quality atop of the kernel with spots
of different degrees of brittleness _AND_ on top of that you want not
one, but several pieces of code from people who seem to be chronically
unable to hire a half-decent C programmer?  Wow.

Guess what?  You are *ed.

Vendor drivers are crap.  They don't magically become better when they
get merged into the tree, but there's at least _some_ barrier keeping
more outrageous *out.  And they do get some cleanups and fixes.
And no, Windows drivers are not better.  The sad truth is, there is
a lot of programmers, but very few decent ones.  And few of those
can do asynchronous code.

So if you run vendor drivers you are running code from hell-knows-who
with priveleges higher than that of any suid-root program and you
rely on aforementioned hell-know-who to audit it.  Could you spell
"suicidally stupid"?

--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

 
 
 

Linkable Modules

Post by Kasper Dupon » Tue, 20 Aug 2002 14:29:39





> >The manufactures might think supporting some
> >versions should be enough, but I don't think
> >it is. If different manufactures does not
> >support the same versions you will have a
> >problem if you have more than one hardware
> >component in your computer. (Most people do.)
> >And my kernel with my 11 favourite pathces is
> >never the one hardware manufactures choose to
> >compile their drivers for.

> So you have 11 patches of varying quality atop of the kernel with spots
> of different degrees of brittleness

Probably not that varying, most of them I wrote myself, and some of the
others I actually reviewed before applying them. (I don't review every
-ac patch from start to end.)

Quote:> _AND_ on top of that you want not
> one, but several pieces of code from people who seem to be chronically
> unable to hire a half-decent C programmer?  Wow.

Luckily I don't currently have any hardware needing such drivers. So
I'm mostly speaking about other people who might have a more unlucky
hardware combination.

Quote:

> Guess what?  You are *ed.

> Vendor drivers are crap.

Sometimes the vendor is the only people who know the specs. They
should be in the best possible position to write a good driver.

Quote:> They don't magically become better when they
> get merged into the tree,

At least at that point they become opensource, and it is so much
easier to fix a bug when you have the source. Theoretically I
could fix bugs in binary only drivers as well, but that is not
easy.

Quote:> but there's at least _some_ barrier keeping
> more outrageous *out.  And they do get some cleanups and fixes.

Sure.

Quote:> And no, Windows drivers are not better.

I have heard claims stating that broken drivers are responsible
for most Windows crashes. (Was it Microsoft who said that?)

Quote:> The sad truth is, there is
> a lot of programmers, but very few decent ones.  And few of those
> can do asynchronous code.

> So if you run vendor drivers you are running code from hell-knows-who
> with priveleges higher than that of any suid-root program and you
> rely on aforementioned hell-know-who to audit it.  Could you spell
> "suicidally stupid"?

Well, in case I needed the driver I would also be using their
hardware. The driver could not do more damage to my system
than the hardware itself could possibly have done.

--
Kasper Dupont -- der bruger for meget tid p? usenet.


 
 
 

Linkable Modules

Post by Joshua Jone » Tue, 20 Aug 2002 22:52:53



>> And no, Windows drivers are not better.
> I have heard claims stating that broken drivers are responsible
> for most Windows crashes. (Was it Microsoft who said that?)

Wouldn't a true microkernel help with this problem (for any OS)?

--
 Joshua Jones
 josh(at)homemail.com  |  jonesjos(at)us.ibm.com

 
 
 

Linkable Modules

Post by Kasper Dupon » Wed, 21 Aug 2002 00:36:41




> >> And no, Windows drivers are not better.

> > I have heard claims stating that broken drivers are responsible
> > for most Windows crashes. (Was it Microsoft who said that?)

> Wouldn't a true microkernel help with this problem (for any OS)?

A microkernel will help, though it is not going to solve all
problems. If your harddisk driver is broken VM is going to
break microkernel or not. And why do you say for any OS? As
soon as we start talking microkernel we are no longer talking
about any OS. But of course compatibility layers can be
implemented on top of the microkernel. In either case I don't
think a microkernel is going to perform as good as the
current system.

--
Kasper Dupont -- der bruger for meget tid p? usenet.


 
 
 

Linkable Modules

Post by Robert Kais » Wed, 21 Aug 2002 00:27:07





>>> And no, Windows drivers are not better.

>> I have heard claims stating that broken drivers are responsible
>> for most Windows crashes. (Was it Microsoft who said that?)

> Wouldn't a true microkernel help with this problem (for any OS)?

Depends on how you look at it. In a true microkernel system, a device
driver runs (in user mode) in its own address space. Thus it can
not harm the kernel or other components of the OS e.g by overwriting
their data or code. OTOH, if the driver is responsible for a device
that is vital for the function of the system (e.g. the disk driver
that handles the root filesystem), then a bug in that driver will
effectively bring down the system.

Still, such a bug is easier to find in a microkernel system since
it manifests itself as it happens (i.e. when a bad pointer is
dereferenced), rather than at some seeminly unrelated point because
the pointer has corrupted some crucial kernel data structures.

Rob

----------------------------------------------------------------
Robert Kaiser                     email: rkaiser AT sysgo DOT de
SYSGO RTS GmbH                    http://www.elinos.com
Klein-Winternheim / Germany       http://www.sysgo.de

 
 
 

Linkable Modules

Post by Joshua Jone » Wed, 21 Aug 2002 13:31:02



>> Wouldn't a true microkernel help with this problem (for any OS)?
> And why do you say for any OS? As
> soon as we start talking microkernel we are no longer talking
> about any OS.

Apologies, I meant to get away from windows-specific discussion,
as in "this problem exists for many OSes," but I wasn't clear.

Quote:> In either case I don't
> think a microkernel is going to perform as good as the
> current system.

Definitely not, but performance isn't why we have microkernels
in the first place :-)  Although Liedtke's (spelling?) classic
u-kernel paper gives compelling evidence for microkernels and
performance, if done properly...

--
 Joshua Jones
 josh(at)homemail.com  |  jonesjos(at)us.ibm.com

 
 
 

Linkable Modules

Post by Robert Kais » Thu, 22 Aug 2002 17:19:04





>>> Wouldn't a true microkernel help with this problem (for any OS)?

>> And why do you say for any OS? As
>> soon as we start talking microkernel we are no longer talking
>> about any OS.

> Apologies, I meant to get away from windows-specific discussion,
> as in "this problem exists for many OSes," but I wasn't clear.

>> In either case I don't
>> think a microkernel is going to perform as good as the
>> current system.

> Definitely not, but performance isn't why we have microkernels
> in the first place :-)  Although Liedtke's (spelling?) classic
> u-kernel paper gives compelling evidence for microkernels and
> performance, if done properly...

Yep. The TU Dresden implemented a user space Linux server on top
of Liedtke's microkernel "L4" and it was only some 5% slower than
native Linux on the same hardware. That it _is_ slower is inevitable,
because there is always some overhead.

OTOH, I believe that sheer kernel speed is getting more and more
irrelevant these days: Consider -say- a Linux system with a KDE
desktop. Such a system spends so much of its time in user space
code that I doubt one would even notice a 5% decrease in kernel
performance.

(Also see http://www.cs.washington.edu/homes/bershad/Papers/)

Rob

----------------------------------------------------------------
Robert Kaiser                     email: rkaiser AT sysgo DOT de
SYSGO RTS GmbH                    http://www.elinos.com
Klein-Winternheim / Germany       http://www.sysgo.de