Articles / Speeding up Linux Device Dr...

Speeding up Linux Device Driver Development

Linux often sits far on the trailing edge of hardware support and plays catch-up on everything from USB to video cards. Vlatko Kosturjak offers his thoughts on how to improve the situation so new hardware is usable under Linux ASAP. Recently, I got a Logitech USB Web camera which I wanted to use with my laptop, which is running Linux Mandrake. I eagerly connected it. The USB daemon recognized that I had plugged in a device and tried to find a module which would be suitable for it. Unfortunately, none was found. At that point, I knew Hell was waiting for me. I searched the Web and Usenet for information on how to make my new camera work under Linux, but with no luck. I read the kernel documentation about Logitech Web cameras. I even found some support, but only for the parallel version. The documentation also stated that Logitech refuses to give any specs or info on their products. I downloaded the 2.4 kernel, compiled and installed it -- but still with no luck. I even thought about modifying that parallel driver to support USB, but had no time for that.

As an average programmer, I'm skilled enough to make necessary modifications to the kernel, but an average desktop user surely won't cope with it; he has problems even with compiling downloaded kernel source. In order for Linux to become a desktop OS, this should be fixed very soon.

Not very happy with the situation, I decided to write this article and share some ideas on how things should be done to improve device drivers for various hardware devices under Linux.

First, let's face the current model of Linux device drivers: Most drivers are shipped with the kernel source already. A small number of them comes on various CDs, either in binary or source form. Those, however, are usually outdated. While the process of writing a device driver, making the required hardware, copying software CDs, and releasing goes on, time passes. Meanwhile, new versions of the kernel are released, with the latest-and-greatest fixes/features and also with a new-and-improved API for device drivers which is, of course, incompatible with the old one.

So I thought about making a universal API for device drivers in the Linux kernel core that wouldn't change for a long time. If it ever needs to change, the old API should be preserved for compatibility. The standard API means that I can both compile the source (with same headers/function calls) and load the binary module of a certain device driver under any Linux version.

Perhaps this concept should be adopted by other free OSes as well (*BSDs, for example), so that device drivers can become more and more universal as more OSes adopt the concept and standard.

Resolving platform-specific issues could be done through a top-level device driver API that would be translated to some bytecode variant, just like Java. This would mainly be intended as a temporary solution for close-minded companies; it would just buy time while companies that don't recognize the power of Open Source come to their senses. If that would take too long, a just-in-time driver compiler could be implemented that would speed up the driver itself (just like a JIT compiler for Java). That would make close-minded companies happy enough to release drivers, but their drivers won't be as fast as those of their competitors, who published them in source form. This could lead the closed source company to release their drivers in source form too. Voila! We'll soon have an Open Source world!

This would greatly speed up kernel core development as well as device drivers development because most of the drivers would be developed and shipped separately from the kernel source. A single developer could concentrate on writing either core or device drivers, whichever he's currently working on. It is also easier to debug such code. I emphasize that the process of developing and testing drivers would speed up because you could first test them with the specialized driver API, and then rewrite them into fast C/C++/asm variants.

If Linux wants to be the OS for an average desktop machine, some of these points must be taken seriously until the world becomes fully Open Source. If not, maybe some new Open Source desktop OS should take these ideas for realization.

RSS Recent comments

21 Feb 2001 16:46 amr42

ITs called I2O, and it exists already in Linux Kernel
The exact thing that you are talking about is called I2O and is already an industry standard and in the 2.4 version of the Linux kernel. This still suffers from the problem that nobody writes I2O drivers.

21 Feb 2001 16:52 random

Re: ITs called I2O, and it exists already in Linux Kernel

> The exact thing that you are talking
> about is called I2O and is already an
> industry standard and in the 2.4 version
> of the Linux kernel. This still suffers
> from the problem that nobody writes I2O
> drivers.

Or makes i2o devices. i2o devices are special
made, and for instance, don't cover devices on the
USB bus (unless someone were to make an i2o_usb
module that allowed it).

They're also designed to take the load of
performing tasks off the processor. This means
that things like network cards and storage cards
benefit from it (although linux's i2o support
sucks), but things like webcam which are limited
by the USB bus won't.

21 Feb 2001 16:56 stikves

Ask that to Linus
Linus does not like the idea of stable kernel interfaces. He says they slow down development (because you have to be backwards compatible). And thay "allow binary only drivers" which are the main reason of crashes on windows platform.
I would like that happen too, but i fear i will not be able tyo see in in foreseeable future.

21 Feb 2001 16:58 random

This has been proposed many times before
For the sblive driver originally, etc.

There was also an effort out there to make a
unified ABI (application binary interface) to
allow drivers to be written for one OS and be used
on many, but it was shot down with the same reason
that this one can be:

Interfaces change because they simply don't work
one way with an updated model, or were poorly
implemented.

The other reason why vendors don't support linux
most of the time for commidity hardware such as
webcam is low returns on investments. They're
already writing drivers for Win98 WDM/Win2k WDM
(they're not the same binary wise, and you still
have to verify that the drivers work correctly on
both OSs), Win95, Win95SE, and sometimes Win NT4.

Not to mention MacOS if its USB gear.

Linux's USB implementation is rather young, and
probably a moving target. The returns that these
companies make developing drivers for 4 or 5 OSs
already is probably pretty low.

Not to mention the fact of licensing issues, etc.
Sometimes companies don't own the technology that
they use in devices and the company that controls
it won't release programming information.

The only way to fix this is for linux to get
enough market share to be able to make demands for
hardware support.

21 Feb 2001 17:00 kreppel

not realistic
a fixed API for drivers ?

naah, that would mean a frozen driver api design (and the design should evoluate because of other needs in the future than now will have to be addressed differently, we saw redesigns of all major kernel subsystems yet, not only because the new design is better, but because it does fit the needs of today)
or, if the design changes, a backwards compatibility layer, i don't think its a good solution.

bytecode drivers ?

nope, because the windows equivalent of those drivers will be faster, and everyone will start saying windows is faster than linux for most hardware.

the current system ?

yeah! opensource drivers get integrated in the kernel, bugs are fixed, performance gets better, we have a _lot_ of drivers supported, and if the api changes , the drivers are adapted too. companies can release binary-only drivers for stable kernel series that already matured (like current 2.2.x) with modversions on, so the drivers will work on every late 2.2.x kernel.

21 Feb 2001 17:34 darrellpf

Free programming available
I had exactly the same experience. My USB Quickcam
works only on my Windows side, on the rare
occasion that I decide to boot it.

If Logitech were to post the hardware
documentation I would happily write a driver for
it, for free. It isn't going to cost anything for
Logitech to increase their market share.

If companies were slightly more enlightened, they
would seed some of their hardware to a few open
source programmers who are even slightly likely to
succeed is much cheaper than hiring a programmer
to write a driver.

Sending out 20 free quickcams to 20
wanna-be-device-driver-writers is much cheaper
than hiring a programmer to do the work.

darrell

21 Feb 2001 18:10 bluelang

API is not the issue.
Does Microsoft write drivers for Logitech hardware?

The solution is a large enough user base to make
linux driver development economically viable to
the hardware companies.

The other solution is to research your purchases
ahead of time.

The third solution is to write them yourself.

A stable API would only mean that people could get
more use out of drivers they write themselves.
That doesn't actually encourage driver writing,
not does it solve the problem - companies think
linux drivers are a waste of money, and, to a
large extent, they are correct,

What is not a waste of time is opening the specs
for writing the drivers, but that's a whole
'nother can of worms.

See ya,
blue

21 Feb 2001 18:13 bluelang

Re: Free programming available
% Sending out 20 free quickcams to 20
> wanna-be-device-driver-writers is much
> cheaper than hiring a programmer to do the
> work.

Driver is here:

wwwbode.informatik.tu-...

21 Feb 2001 18:36 hvenzke

RE: Logitec , harwdware under linux....

The situation on *newest* hardware are since years the same :

Just after you can buy such new "staff" no driver
exist.

A few days / weeks / moth or Years later - one day there exist one fine driver - even there are mutch users with programmer skill....

some examples are given :
- winmodem
- sound drivers
- usb staff
- mutch mutch more

be shure : linux driver Programming works like a snowball system - even more users than faster writing ..

Kindy regards ,
One Linux user that uses Linux for 9j now.

>

21 Feb 2001 18:44 johnjones

UDI SCO have been @ it
right what you want is UDI which means that
Solaris and Linux oh not forgeting unixware ALL
sahre drivers

so go and help out program their USB for them

projectudi.sourceforge...

this has been going for about 2 years

regards

john jones

21 Feb 2001 18:47 cnbishop

Re: ITs called I2O, and it exists already in Linux Kernel

I2O... that's an Intel market-creation scheme, right? If I understand right, OS Vendor support for I2O is dropping sharply because there simply is no demand for it. It's a catch-22, but at least until some IHV produces an I2O device that people want, on which end of that catch-22 do we want to be?

> The exact thing that you are talking
> about is called I2O and is already an
> industry standard and in the 2.4 version
> of the Linux kernel. This still suffers
> from the problem that nobody writes I2O
> drivers.

21 Feb 2001 18:55 cnbishop

Re: UDI SCO have been @ it
Hey John;

Yeah. But what did Matt say about UDI and Linux? The part that we could understand, I mean.

I so wish that more people knew about UDI, and could implement it very well, and that the kernel would start using it on a peer level with the binary drivers.

Hardware vendors think of the OS world as Windows, Mac, Solaris, Linux and Unix. They release 3 drivers for one, and think they need to release only one driver for the rest. They NEED UDI, but don't know it. What? The ability to write drivers not only for all UNIX-like OSes at once, but for all versions at once? AND be furute-proof? That's even better than their current bet of planning and fearing driver rewrites for all new M$ OSes. In this case, they'd write it just the once, get three, and need never revisit the code again except for bugfixes and features.

Then again, I wish for a lot of things.

- bish

> right what you want is UDI which means
> that
> Solaris and Linux oh not forgeting
> unixware ALL
> sahre drivers
>
> so go and help out program their USB
> for them
>
> projectudi.sourceforge...
>
> this has been going for about 2 years
>
>
> regards
>
> john jones

21 Feb 2001 21:04 jetson123

it's not going to happen in Linux
Linus has said that he doesn't care about making things easy to add to the kernel, so I doubt this is going to happen. That attitude has both plusses and minuses. I think it was a good attitude to have for the initial kernel and the small systems it ran on. On current machines, things are different.

What I would want for kernel extensions and drivers is a safe language together with dynamically bound methods. That would make kernel modules less version dependent, more easily debugged, and less error prone. That's nearly impossible to achieve in C. A well-written C library might do the trick, or kernel support for some other languages (but there aren't a lot of choices, and they are all pretty obscure: Modula-2, Oberon, Objective-C, natively compiled Java come to mind).

Sorry, I guess we have to wait another 10 years for this one.

21 Feb 2001 21:07 jetson123

Re: it's not going to happen in Linux

> nearly impossible to achieve in C. A
> well-written C library might do the
> trick,

Gasp--something seems to be unquoting plusses in HTML postings. What I was saying is that a well-written C-plus-plus library might do the trick, and it would link in fairly easily with the existing kernel. But last I heard, the Linux kernel developers even refused to make the minor changes to remove C-plus-plus keyword conflicts from the kernel.

21 Feb 2001 22:24 k31

Device Drivers
The real problem with device drivers is that companies have gotten into the habit of not releasing specs for their hardware. Which is much more literally like buying a car with the hood welded shut that the case of closed source software.

Anyhow, if the hardware could be reverse engineered, drivers could be written in whatever language (C, C , ASM?) given that they were accessing a given set of structures which the device describes.

That is, all devices are basically memory ranges which have different meanings according to the device's state.

So, a small langauge with keywords like state, struct, byte, bit, word, dword... would probally be enough to describe the device.

Writing the driver, and the userland interface, is another two stories... but the device description should be seperate to enable easier revision of the driver.

22 Feb 2001 02:42 cssl

Re: Device Drivers

> So, a small langauge with keywords
> like state, struct, byte, bit, word,
> dword... would probally be enough to
> describe the device.

This could be a module itself... Just to start testing things... It shouldn't be too hard to create a language that could easily be translated to a secure subset of C.

What I find more disturbing is that to add support for a new filesystem I have to recompile the whole kernel... :-(

22 Feb 2001 05:46 kost

Re: not realistic

> a fixed API for drivers ?
> naah, that would mean a frozen driver
> api design (and the design should
> evoluate because of other needs in the
> future than now will have to be
> addressed differently, we saw redesigns
> of all major kernel subsystems yet, not
> only because the new design is better,
> but because it does fit the needs of
> today)
> or, if the design changes, a
> backwards compatibility layer, i don't
> think its a good solution.

there would be STABLE versions of protocol which should be
backward compatible... so, for new design it would be released new version of device drivers API (e.g. v2)...

> bytecode drivers ?
> nope, because the windows equivalent
> of those drivers will be faster, and
> everyone will start saying windows is
> faster than linux for most hardware.

If you read text more detailed, it's not permanent solution,
but just temporary one. Until close-minded companies realize that open-sourceing specs is bettter. If not, It is easier to reverse-engineer bytecode variant than usual one... ;-)

> the current system ?
>
> yeah! opensource drivers get
> integrated in the kernel, bugs are
> fixed, performance gets better, we have
> a _lot_ of drivers supported, and if the
> api changes , the drivers are adapted
> too. companies can release binary-only
> drivers for stable kernel series that
> already matured (like current 2.2.x)
> with modversions on, so the drivers will
> work on every late 2.2.x kernel.

That's why we always play catch-up for latest piece of
hardware.... ;-)

22 Feb 2001 12:51 itsme

Re: it's not going to happen in Linux

> Linus has said that he doesn't care
> about making things easy to add to the
> kernel, so I doubt this is going to
> happen. That attitude has both plusses
> and minuses. I think it was a good
> attitude to have for the initial kernel
> and the small systems it ran on. On
> current machines, things are
> different.

I don't think that the speed of current machines should be a factor. One of Linux's greatest assets is its speed and robustness. Bloating the kernel by adding features to make up for something that should be provided by the hardware manufacturers isn't the right way to go. IMHO, the correct way to go about this is to make the manufacturers see that developing drivers for Linux is worth their while. Several companies have already started seeing this and ship linux drivers out with their products, but others are a little slower to adapt.

22 Feb 2001 16:39 pe1rxq

Why didn't you asked this on the linux-kernel mailinglist????
If you had read some archives of linux-kernel you
would know why this doesn't work:

1 A 'stable' api means that you will be stuck with
old mistakes for a long time, there is a reason
why kernel interfaces change, namely to make them
better.

2 You are making it easier for the manufacturors
to make binary only drivers, and thus they will
never need to give their specs away. This might
work well if you have a popular system. But don't
expect them to release a driver for x86, ppc, arm,
mips, superh or whatever linux runs on this week.

3 You already don't have to work on the kernel for
writing a device driver, when making a modular
driver you only have to know a few kernel
functions that you have to call.
I have written several drivers and know almost
nothing (but learning) about the inner works of
the kernel.

4 Building layer upon layer upon layer will make
your driver slower and slower and slower.

5 Most important: Linus doesn't like it :)

Jeroen

22 Feb 2001 18:12 r0b0

Re: API is not the issue.

> Does Microsoft write drivers for
> Logitech hardware?
>
> The solution is a large enough user
> base to make
> linux driver development economically
> viable to
> the hardware companies.

yes. i think it should become a widely accepted approach to ask the device manufacturer to supply driver for the os you use. i think everytime you buy a new piece of hardware and you wont be given a driver for your os, write an e-mail to the device manufacturer and ask for it.

i do it sometimes myself... but ... who else does?

R0B0

23 Feb 2001 01:14 vii

You can do it
I was in the same position except this time with a
Microtek USB scanner. I rang up Microtek branches
all over the world trying to get the specs out of
them. I ended up reverse engineering the protocol
with a guy I met on a mailing list called Oliver
Neukum and writing the driver. This is pretty
easy, though it might sound daunting. I wrote a
program called usb-robot now at
usb-robot.sourceforge.net. to help.

23 Feb 2001 04:59 kost

Re: Why didn't you asked this on the linux-kernel mailinglist????

> If you had read some archives of
> linux-kernel you
> would know why this doesn't work:
> 1 A 'stable' api means that you will
> be stuck with
> old mistakes for a long time, there is
> a reason
> why kernel interfaces change, namely
> to make them
> better.

If you read the text detailed, it's just a temporary solution, and that solution leads to the opening of specs or releasing drivers with source code... IT'S NOT PERMANENT!

23 Feb 2001 08:00 CauthenB

Why not use UDI?
Why not use UDI? The Universal Driver Interface.

It can be found here:

freshmeat.net/projects...

23 Feb 2001 09:39 pe1rxq

Re: Why didn't you asked this on the linux-kernel mailinglist????

%
> If you read the text detailed, it's
> just a temporary solution, and that
> solution leads to the opening of specs
> or releasing drivers with source code...
> IT'S NOT PERMANENT!

It is not a temporary solution, otherwise you
wouldn't need an API that didn't change between
versions. And why should a manufacturor release
any specs if he can just use the API indefenitly?

Jeroen

23 Feb 2001 21:14 jjramsey

API or ABI?
As far as I can tell, the Linux device driver API is stable; otherwise, modules would not only have to be recompiled when the Linux kernel is updated, but would also have to be edited by hand to make them compliant with the new API.

What Linus seems to be rejecting is an ABI which would keep modules binary compatible across kernel versions, but would involve, at least according to Linus, assorted cruft and ugly hacks to build up in the kernel.

It seems that in the comments and the article, the concepts of an API and an ABI get mixed up.

24 Feb 2001 10:13 dgcarnal

Re: it's not going to happen in Linux
WHO?
A list of the companies that have issued Linux drivers for their equipment would be a boon. Perhaps as an adjunct to the Equipment HOW TOs accompanied by the reply one gets when asking companies for their cooperation. I have been looking into this and found out that HP for one says they do not support linux drivers. Hp's French division has linux drivers for a lot of server based equipment. Looks like the short term profit motive outweighs the long term health of the company.

>
> % Linus has said that he doesn't
> care
> % about making things easy to add to
> the
> % kernel, so I doubt this is going
> to
> % happen. That attitude has both
> plusses
> % and minuses. I think it was a
> good
> % attitude to have for the initial
> kernel
> % and the small systems it ran on.
> On
> % current machines, things are
> % different.
>
>
> I don't think that the speed of
> current machines should be a factor. One
> of Linux's greatest assets is its speed
> and robustness. Bloating the kernel by
> adding features to make up for something
> that should be provided by the hardware
> manufacturers isn't the right way to go.
> IMHO, the correct way to go about this
> is to make the manufacturers see that
> developing drivers for Linux is worth
> their while. Several companies have
> already started seeing this and ship
> linux drivers out with their products,
> but others are a little slower to
> adapt.

24 Feb 2001 15:56 zzzzz

newbus architecture
You should check out the newbus architecture in FreeBSD 4.x (I believe taken from the NetBSD kernel). It's a very abstract way of writing device drivers and the API will be unchanged throughout the 4.x series. Compare this to the linux kernel where there are no such promises of compatibility and drivers are written on a very adhoc basis.

24 Feb 2001 20:19 lubricated

don't be dumb
The best way to speed up linux driver development
is to not buy stuff that doesn't have a linux
driver.

Hit the companies where it hurts.

Don't be stupid and make sure something works
before you buy it.

You should have bought a diffrent camera. I'm sure
there is one that works.

I really do not feel sorry for you in any way.
Most people who have problems with hardware under
linux do not cause themselves problems. Usually
it's hardware they have had before they started
using linux, not after.

25 Feb 2001 01:34 leonbrooks

About as temporary as income tax
(which BTW was introduced to Oz in 1939 as a
``temporary measure''.

> If you read the text detailed, it's
> just a temporary solution, and that
> solution leads to the opening of specs
> or releasing drivers with source code...
> IT'S NOT PERMANENT!

How are you going to enforce this wish? Microsoft,
with all of their billions and market pressure,
seem unable to turn the trick. How do you propose
coercing driver authors to put the effort into
moving a driver from slow, buggy, working,
antiquated to efficient, safe, beta-again, fresh?

25 Feb 2001 01:36 leonbrooks

Re: newbus architecture

> Compare this
> to the linux kernel where there are no
> such promises of compatibility and
> drivers are written on a very adhoc
> basis.

Compare this with the Halloween Letters where
Vinod bemoan's NT's lack of ``one week drivers'' -
and wonder how Microsoft even got this far...

25 Feb 2001 18:51 floda

Re: it's not going to happen in Linux
Advansys SCSI adapters ship with Linux drivers. Netgear NICs ship with Linux drivers. At least one sound card (Zoltrix Nightingale) ships with Linux drivers.

All source, some of it borrowed under GPL, and some of it written by the manufacturer under GPL.

26 Feb 2001 04:29 bignose

Releasing specs is the only answer.

> The other reason why vendors don't support linux
> most of the time for commidity hardware such as
> webcam is low returns on investments. They're
> already writing drivers for Win98 WDM/Win2k WDM
> (they're not the same binary wise, and you still
> have to verify that the drivers work correctly on
> both OSs), Win95, Win95SE, and sometimes Win NT4.

They shouldn't have to write drivers for yet
another OS. If they bent to the pressure from
Linux users and released drivers for Linux
kernels, then they'd just come under pressure
again when the *BSD users what to use it. This,
as you say, is a foolish way to spend resources.

The way for these companies to support all
operating systems, maximising their market share,
is to release hardware specs sufficient for other
people to write the drivers for whatever OS they
choose. Zero investment on the company's part,
and the market decides which platforms they want
supported.

> The returns that these
> companies make developing drivers for
> 4 or 5 OSs already is probably pretty low.

They are hardware companies; why are they spending
so much time and money on writing software and
keeping it current?

> Not to mention the fact of licensing issues, etc.
> Sometimes companies don't own the technology that
> they use in devices and the company that controls
> it won't release programming information.

Then they have painted themselves into a corner,
and they have no-one to blame for their wasted
efforts on writing and maintaining drivers for a
dozen platforms.

This is where the pressure needs
to come from; the hardware companies should
realise that they must get themselves in a
position to
release full specs for their hardware, otherwise
companies that are able to do so will eat their
lunch because they can be supported on every
current operating system with no extra investment
from the company.

> The only way to fix this is for linux to get
> enough market share to be able to make
> demands for hardware support.

No, this is just as short-term as asking for BeOS
as an extra platform; it places more burden on the
hardware company for very little return, and is no
help at all when then ext great platform arrives
with its hordes of users screaming for support.

Hardware companies -- don't spend
another cent
on writing binary-only drivers that you must
continue to support for as long as your users
scream at you -- do release full specs to your
hardware so that people can use your hardware in
many more places than you can spend money to support.

26 Feb 2001 12:33 davidhofstee

it is clear you are a dreamer...
Your ideas resemble my own thoughts at times. Your observation that drivers are coming way too slow is correct. But then you fall in your own trap. You write articles... and fall back into that habit, but the quality of the content drops dramatically due to that fact. Fact is, that the proof of the pudding is in the eating. Try _prooving_ that your solution is right, and then Linus will listen :-) (maybe). I even looked at your programs, and found that they were all lightweight. Fortunately, kernels are not lightweight. Don't consider it a flame (hell, I'd be flaming myself for being such a lousy programmer), just being descriptive here. Remember Theo de Raadt's words: just a few excellent coders out there (or something).

27 Feb 2001 00:52 loopus

Re: Why not use UDI?

> Why not use UDI? The Universal Driver
> Interface.
>
> It can be found here:
>
> freshmeat.net/projects...
>
>

Indeed... UDI is available on some platforms, and might go to Itanium. WHat does that mean? Write the driver once for linux, it goes to Itanium. Write it once for Itanium, Linux users can use it. Less wasted time on multiple mobile standards.

28 Feb 2001 13:45 richardww

Why wont companies give out information on devices?
Can anyone really see a good reason for a hardware manufacturer to not give out information on protocols?

Is it because they think people will steal their ideas?

Is it because they don't own the protocols?

Does anyone know of a website where I can state my opinion about companie's not releasing the information to write drivers? If there isn't I may well create one.

28 Feb 2001 13:57 richardww

Closed but freely available source code?
If a company made a linux driver for hardware, it wouldn't neccessarily have to be binary compatible for that kernel - source but maybe not binary.

There could be written a program that detects hardware and, if there isn't a locally available driver, looks at an internet database of drivers. The drivers would be in some kind of encrytped(perhaps) source code so that a companie's precious secrets could be left intact. It would then download and install the driver without letting the users at the source code.

04 Mar 2001 11:24 jwreschnig

I figure this might be relevant
The
FSF's view on UDI (which is a superset of
what's being proposed here).

06 Mar 2001 03:50 doudou

Re: Closed but freely available source code?
(sorry, i' very bad in english)
At least one company do that already: nVidia. You can download SRPMS for nVidia's DRI kernel driver and compile it for your own kernel. It worked well on my computer.

> If a company made a linux driver for
> hardware, it wouldn't neccessarily have
> to be binary compatible for that kernel
> - source but maybe not binary.
> There could be written a program that
> detects hardware and, if there isn't a
> locally available driver, looks at an
> internet database of drivers. The
> drivers would be in some kind of
> encrytped(perhaps) source code so that a
> companie's precious secrets could be
> left intact. It would then download and
> install the driver without letting the
> users at the source code.

09 Mar 2001 08:51 x400

Re: Why wont companies give out information on devices?

> Can anyone really see a good reason for
> a hardware manufacturer to not give out
> information on protocols?
> Is it because they think people will
> steal their ideas?
> Is it because they don't own the
> protocols?
>
> Does anyone know of a website where I
> can state my opinion about companie's
> not releasing the information to write
> drivers? If there isn't I may well
> create one.

Ummmm, because they have a serious insecurity problem and they don't know what a REAL Operating System is.
Life would be much easier for all of Linux users if we had our "hands" on it.(if u get my drift).
heh

25 Jul 2001 12:41 kost

Re: don't be dumb

> The best way to speed up linux driver development
> is to not buy stuff that doesn't have a linux driver.
> Hit the companies where it hurts. Don't be stupid and make % sure something works before you buy it.
> You should have bought a diffrent camera. I'm sure
> there is one that works. I really do not feel sorry for you in
> any way. Most people who have problems with
> hardware under linux do not cause themselves
> problems. Usually it's hardware they have had before
> they started using linux, not after.

Heh, I usually don't buy hardware that is not
supported under Linux, but that camera I got for my birthday ( I DIDN'T bought it), so we have a problem, but we didn't solve it... :-)

14 Mar 2006 20:48 vikramkg

Accessing the device file
hi

I am new to the devcie driver .. i need to access the hard disk directly without the the help of the file system ... and my project is just making the mark of the canged block in the hard disk

Screenshot

Project Spotlight

GenScriber

A genealogy records transcription editor.

Screenshot

Project Spotlight

Google Map GPS Cell Phone Tracker

Web server and phone client applications for periodically tracking android, iOS, Windows Phone, and Jave ME cellphones.