Linux Driver Project Status Report as of April 2008

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



De:  Greg KH
Enviado el: lun 07/04/2008 23:48
Para: devel at linuxdriverproject.org
Asunto: Linux Driver Project Status Report as of April 2008

>  The Linux Driver Project (LDP) is alive and well, with over 300
  developers wanting to participate, many drivers already written and
  accepted into the Linux kernel tree, and many more being currently
  developed.  
 
Good work. I show some of my personal thoughts.
 
 
>The main problem is a lack of projects.  It turns out that
  there really isn't much hardware that Linux doesn't already support.
  Almost all new hardware produced is coming with a Linux driver already
  written by the company, or by the community with help from the
  company.
We could create generic drivers, so when a class of hardware is found, it
can be loaded by default . Later, the user can install a customized driver
or customize the generic driver.

One can help downstream to create more easy to use driver handlers. I.e. my
Ubuntu 7.10 box detects my Huawei E220, but it is difficult to handle it to
connect to the Internet (i.e. it detects three devices)

>  There are two main classes of hardware, video input devices and
  wireless network cards, that is not well supported by Linux, 

I agree. And there are some specialized Linux distros whose drivers one
cannot use directly in other ones (i.e. Debian /Ubuntu ). Also, creating
generic drivers it is very important (I imagine in the future one is moving
also to the open hardwar, in a similar way to what happens with the PC
compatible hardware ).

>  Because of this, our main effort has turned into one of education.
  Educating vendors of how to become members of the Linux kernel
  community, proper coding standards and procedures, and how to get
  their code into the kernel tree.  Much of our recent effort has been
  in code cleanup and shepherding into the kernel.org releases.


I would add : and also easification (simplification).  One would use a
hardware as much easily as in propieterary operating systems.


>  - Very few companies signed up for drivers.

>It's this last point that made me worry.  Yes, a number of companies did
ask for drivers to be written, and we have done so, but not as many as I
originally imagined.  The drivers we were writing were in the narrow
vertical markets, all interesting devices and companies, but nothing
really "mainstream".


>And still no major companies showed up.

>So what to do.


So, we have to go to generic drivers as soon as possible.

>I tried my best with a general announcement of, "Tell me all of the
hardware that you know of that is not supported by Linux!"  The response
by users was overwhelming.  My inbox was flooded with hundreds of
messages, and the wiki page:
        http://www.linuxdriverproject.org/twiki/bin/view/Main/DriversNeeded
was created.


>This is the community's best list of devices that are not currently
supported on Linux as of today.


I suggest create also a practical database of hardware and drivers for it
(i.e. Printer XXX has XXX moduel in the Kernel). This is now made by
downstream distros, but it is kernel data. So a more generic Linux / *nix
database would be created.


>User Complaints

>But wait, what about all of those email responses that I received.  It
turns out that they can be categorized into four different groups:

  >1) Printer and Scanner support.

  >2) Older devices no longer manufactured that people really want to see
     working on their Linux machines someday.


This is the problem with propietary hardware and drivers. 


>  3) Wireless device support

 (this includes USB cell modems and mobile phone bultin modems).

  >4) Video input device support.


>So that leave wireless and video input devices.  Luckily both classes of
these devices have a very active and productive developer community
surrounding them.


Yes, and more and more users employs Linux tu share Internet connection
using WiFi or similar devices.


>There are still some wireless vendors that do not provide Linux support
directly.  Two of these, Atheros and Broadcom have drivers created by
the community through reverse engineering efforts.  These drivers
usually lag the introduction of the hardware by a number of months due
to the lack of vendor support. 

At least basic functions (basic driver) can be done using this hardware
(i.e. basic function to connect to an ad-hoc or router), upto the moment
when all the functionalities are added. 

 

>When the LDP project was started, the structure of having a project
manager for the individual project, and a number of developers working
on each one was established.  Over the past year, this has worked for
some projects, while for others, it has failed badly.  Some project
teams have disappeared, including both project managers and developers.
This is quite common for opensource projects, so we need a way to route
around the problem of this, allowing everyone to participate in a more
open model.


I agree. I.e. we could use a similar system to OpenWrt for WiFi drivers and
documentation (about the correspondence between the hardware make and model
and the module name).


>This tree provides a place where developers can provide changes,
updates, and see where they can help out if they wish to do so in a much
easier manner.  It also provides a way for companies participating to
observe the status of their code in a much more open manner.

Good. 

Regards.

Pedro.





[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux