Free Linux Driver Development!
Yes, that's right, the Linux kernel community is offering all companies

free Linux driver development.  No longer do you have to suffer through

all of the different examples in the Linux Device Driver Kit, or pick

through the thousands of example drivers in the Linux kernel source

tree trying to determine which one is the closest to what you need to

do.
All that is needed is some kind of specification that describes how your

device works, or the email address of an engineer that is willing to

answer questions every once in a while.  A few sample devices might be

good to have so that debugging doesn't have to be done by email, but if

necessary, that can be done.
In return, you will receive a complete and working Linux driver that is

added to the main Linux kernel source tree.  The driver will be written

by some of the members of the Linux kernel developer community (over

1500 strong and growing).  This driver will then be automatically

included in all Linux distributions, including the "enterprise" ones.

It will be automatically kept up to date and working through all Linux

kernel API changes.  This driver will work with all[1] of the different

CPU types supported by Linux, the largest number of CPU types supported

by any operating system ever before in the history of computing.
As for support, the driver will be supported through email by the

original developers, when they can help out, and by the "enterprise"

Linux distributors as part of their service agreements with their

customers.
If your company is worried about NDA issues surrounding your device's

specifications, we have arranged a program with OSDL/TLF's Tech Board to

provide the legal framework where a company can interact with a member

of the kernel community in order to properly assure that all needed NDA

requirements are fulfilled.
Now your developers will have more time to work on drivers for all of

the other operating systems out there, and you can add "supported on

Linux" to...
[ message continues ]

Hi Greg,
Although I am a bit of a cynic, I really hope that this endeavor works

the way you hope.
I'd also like to offer my services to this quest of yours. If you get

any SD, MMC or SDIO requests, feel free to pass them along to me. I am

not a big fan of debug-by-email though, so I'd prefer vendors who either

can provide samples or where the hardware is cheap and freely available

so I can just go out and by one.
Rgds

--

     -- Pierre Ossman
  Linux kernel, MMC maintainer        http://www.kernel.org

  PulseAudio, core developer          http://pulseaudio.org

  rdesktop, core developer          http://www.rdesktop.org

-

Great, thanks for letting me know, I've added you to the list.
greg k-h

-

for any DVB/DAB/DMB (PCI based) devices, if any vendors would like to

offer sample device and specs, would like to join the bandwagon.
regards,

manu

-

thanks, I've added you to the list.
greg k-h

-

As I'm not an expert in any kind of device, so I would like to join

for any device which its type has not been assigned to any person yet

(wild card?). Also, I would code for small LCDs.
--

Miguel Ojeda

http://maxextreme.googlepages.com/index.htm

-

Thanks, I've added you to the list.
I'll be doing a public update soon as people are wondering what is going

on :)
thanks,
greg k-h

-

Bravo!  Now, is there a message in the same spirit that can be

tailored to embedded space, especially to SoC vendors and (even more

importantly) their customers?  Something along the lines of:
"We understand that embedded hardware is frequently buggy and that SoC

vendors are doing well if their own internal software people can get

enough help from the chip guys to bring up enough customer-driven use

cases to win a few design-ins.
We sympathize with embedded developers who stay up nights with an

O-scope and a JTAG emulator reverse-engineering the hardware behavior,

trying to figure out which this order of operations works and this

other one doesn't.
We have the software tools and the competence to quantify the

potential gains from current toolchains and kernels, aggressive

compilation options, and in-tree power/latency management strategies,

so that you can build a business case against "fire and forget" SDKs

based on ancient compilers, obsolete kernels, and unmaintained

out-of-tree patches.
We will help platform integrators bridge the gap between the chip

architects' claims about device performance and the condition in which

the BSP guys toss drivers over the fence.
You can hang onto the hardware and profit from coaching and code

review, or you can send us a board and whatever doco you've got, and

we'll figure it out.
All we ask is that 1) SoC vendors authorize customers to do an NDA

with OSDL and pass vendor NDA material along to us; 2) when the

product ships, all participants are free to exercise GPL rights with

respect to the chip support and driver code produced; and 3) platform

integrators cooperate with the rework usually needed as code merges

towards Linus's tree."
Or is this a pipe dream?
Cheers,

- Michael

-

Oh, I would love to see something like that happen :)
As I come from an embedded background, I love to see Linux running in

tiny systems.  So anything I can do to help out with that I'd love to

offer.
But being able to read the minds of SOC hardwre engineers and decode all

of the documentation errors they produce is enough to drive one crazy,

my condolences go out to everyone in that situation...
good luck,
greg k-h

-

Thanks.  It gets even better when they change things between

revisions of the same HW block.
Out of interest are you was this geared to any particular SoC's/

architectures?
- k

-

I had in mind the sort of ARM-, PPC-, and MIPS-based SoCs that wind up

in handhelds, mobiles, set-tops, and consumer-grade WiFi devices.

That's an area I know passably well, having done both Linux-based and

proprietary-OS-based board support for some years, usually in a

"platform integrator" sort of role.
Part of the reason that most software-defined-radio WiFi vendors have

been slow to cooperate with the kernel community is that their driver

code is pretty fragile and blows chunks when poked in unexpected ways.

 This is not surprising, given the way these companies are structured

and the fact that there has been little market pressure to make it

otherwise.  The field support folks may not have the resources or even

the source code necessary to fix the driver, and they often feel like

the only answer is to lock down the rest of the system to limit usage

patterns to those that the driver writer happened to see in his

Faraday cage.
Especially if there's a corner case that sends the RF power open-loop,

they worry that the FCC (or more likely ETSI) will come down on them

for making it too easy for hobbyists to build ISM foghorns with ugly

spurs in licensed spectrum.  If you want vendor participation in

creating open source drivers for these things, I think you have to get

them engaged long before they enter regulatory test, and understand

their damage control requirements, and keep the discourse relatively

private until the go-to-market stage, at which point they've

presumably decided they can brazen out the remaining hack potential.
Another part of the problem is that embedded vendors come from a world

of destructive competition between BSP houses, where "fork, fire, and

forget" is as much a vendor lock-in tactic as a short-term perspective

on cost efficiency.  They've never had the experience of having their

heads knocked together by a purchaser with overwhelming market power

and the technical resources to identify the guilty (as the early 2-D

graphics board vendors did with MI...
[ message continues ]

How about a kernel driver for the m-cubed tbalancer bigNG ?
http://www.t-balancer.com/english/bng.htm  (see support section of site)
Complete documentation is available, and devs are friendly (see

forums), there is already a userspace utility that works well but a

kernel driver would be even better, especially for something that

controls system cooling!
Andy

-

Why would a userspace driver not work out for this.  We already can

saturate the USB bus with a userspace program, and since it requires a

userspace interaction to do something with the data, I don't really see

what a kernel driver could do to help thing out.
That being said, perhaps it would fit with the other USB data

acquisition drivers that we already have.  Feel free to take this up

with me off-list if you want to.
Hm, wait, in looking at the specs for the device, it uses a

usb-to-serial chip that we already support quite well (with the

pl2303.ko driver.)  So all you need to do is write some userspace

software that interacts with the device properly.  No new kernel driver

is needed at all, as Linux already supports this hardware :)
thanks,
greg k-h

-

That is unfortunately not quite true.  I have a (unfortunately

proprietary) driver for a USB device that simply cannot be implemented

in userspace.  The USB device is a measurement device that pushes

close to 800 kBytes/second of data through a FT245 chip.  The

measurement device does no flow control at all, it just presents a

sample every 125 us to the FT245 and with only 256 bytes of buffer in

the FT245 the only way to handle that is to have two URBs in flight at

the same time, and I haven't found any way to do that in a robust and

non-racey way from userspace.  So the comment "The USB subsystem has

changed a lot over time, and it has been possible to create userspace

USB drivers using usbfs/libusb/gadgetfs that operate as fast as the

USB bus allows." from feature-removal-schedule.txt is wrong I

think. :-(
Personally I'd much prefer to release the driver as open source, but

as a consultant you don't get to decide what the customer does.  So

now they sit there with a driver that warns them that it'll stop

working after february 2008.
On a different topic, my personal pet peeve is USB scanners.  There

seems to be just a handful of different manufacturers of chips used in

USB scanners: Realtek and Genesys covers 90% of the scanners.  The

SANE team has done a wonderful job of reverse engineering a lot of

scanners, but the models change so fast that there seems to be no

chance of keeping up.  If the chip manufacturers just released specs

for their chips and the scanner manufacturers could then document what

settings to use Linux could have support for almost all USB scanners

on the market, and it would probably cost them very little to do that.

If I could find a good (4800-9600 dpi) scanner which said "supported

by SANE" on the box I'd buy it immedately.
  /Christer
--

"Just how much can I get away with and still go to heaven?"
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

-

People do that today just fine with multiple userspace urbs in flight

using usbfs directly.  So it is possible and can be done.
If there are issues with the usbfs code to prevent you from doing this,

please let us know.
Or perhaps your device just needs to add some flow control to it :)
good luck,
greg k-h

-

Physical processes are hard to pause. :-)
But yes, adding a 16kByte FIFO before the FT245 would have made life

so much easier for me, but unfortunately the thing that drives the

hardware choice is cost, cost and cost.  
  /Christer
--

"Just how much can I get away with and still go to heaven?"
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

-

Just curious, it is a coincidence or a thoughtful action that this offer

(which is undoubtedly very attractive and will definitely help the Linux

user base grow) is published on the very same day when a well-known

software giant releases a new Major Version of their closed-source

operating system?
Thanks,
-

As I don't pay attention to other closed source operating systems, it

must have been coincidence.  :)
thanks,
greg k-h

-

> All that is needed is some kind of specification that describes how your

 > device works, or the email address of an engineer that is willing to

 > answer questions every once in a while.  A few sample devices might be

 > good to have so that debugging doesn't have to be done by email, but if

 > necessary, that can be done.
 > This driver will work with all[1] of the different

 > CPU types supported by Linux, the largest number of CPU types supported

 > by any operating system ever before in the history of computing.
 > As for support, the driver will be supported through email by the

 > original developers, when they can help out, and by the "enterprise"

 > Linux distributors as part of their service agreements with their

 > customers.
I'm all for openness of device programming specs, but I think it's a

bit disingenous to suggest that all a company has to do to get a

driver written and supported is throw some documentation over the

wall.  And it's crazy to suggest that the driver will work on every

platform and be supported by enterprise distros.
Just look at the in-tree drivers: there are tons of them that don't

work on big-endian platforms, or have 64-bit problems, or have no SMP

support.  And that doesn't even count drivers that are so bitrotted

they won't even build any more.  And there are plenty of documented

devices that no one cares enough about to submit a driver for.
In the real world, a vendor that wants to make sure a device is

supported by Linux had better pay someone to write the driver and keep

it working.  Of course, if the device is popular enough or simple

enough, docs are all that's needed, but in many cases no one competent

to write the driver is going to volunteer to do it.
 - R.

-

Why is that crazy, we do that already today with the majority of drivers
Any specific examples?  I have a long list of people who wish to write
That's not true at all.  We have a whole raft of drivers in the kernel

that are supported only by the community (like the whole USB stack for

example) that vendors rely on working properly.
And again, I have a whole list of people who are competent to write

drivers wanting to do so (myself included), yet do not have any new

devices with specs to do it.
thanks,
greg k-h

-

Greg KH <greg@kroah.com> writes:
Maybe not entirely a new driver, as there already exist out-of-kernel

vendor GPL driver, but if somebody is willing to resolve the issue

described here:
<http://article.gmane.org/gmane.linux.serial/1221>
please contact me, and I'll be willing to help in testing as I have the

hardware.
-- Sergei.

-

Do you have a pointer to the driver source anywhere?
I suggest just posting it as a patch to the tree as documented in

Documentation/SubmittingPatches and seeing how that goes.
thanks,
greg k-h

-

Sure, here it is:
That won't go, I'm afraid:
1. Vendor driver doesn't compile for recent kernels. I did compile it,

   but using brute-force approach that is not appropriate for the

   kernel.
2. There is generic driver in the kernel that supports this card among

   others, should I add the ID of this particular card, but doesn't

   support baud rates higher than 115200.
3. Vendor driver is rather close to the generic one being in the kernel,

   so maybe it's better to improve generic one instead of adding yet

   another driver to the tree.
-- Sergei Organov.

-

Firstly can you post a patch which adds the relevant identifiers to the

current pcmcia serial driver so that 115,200 works but nothing higher.

After that I'd like to take a look at the needed changes for higher speed

support using the 2.6.20-mm work which adds arbitary speed support.
Alan

-

Wrinting a driver for shiny new hardware is cool.
But understanding and maintaining an already existing driver and working

on bug reports for this driver is something not-so-cool that would be

required in many areas of the kernel.
Would someone from your long list of people e.g. be willing to maintain 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

What?  Throw a fresh-faced newbie instantly into the tar-pit of despair

that floppy.c is?  Do you want everyone just to run screaming from
Seriously, if you need help with something like this, bring it up on the

kernel-janitors list, there are lots of people there that are willing to

help out with stuff like long-term maintenance and bug fixing but don't

know where to start.
That's also where the majority of the people who have volunteered to

help are also hanging out at.
thanks,
greg k-h

-

Doing a from-scratch rewrite of floppy.c only supporting new

hardware and no obscure formats ("newfloppy.c") would be an excellent

newbie project imho.  This means for someone who is still pretty

new, but wants to get their fingers wet with more complicated changes.
Then over time (old-)floppy.c could be phased out.
If anybody is interested...? (non newbies would be welcome too of course)
-Andi

-

floppy.c is not really that ugly or complicated...
It just needs some care:
* cleanup of the over-usage of macros (DP macro etc)

* DocBook documentation would be nice

* make debugging printks optional by using macros in a smart way

  (see libata code for examples)

* tracking and fixing current regressions
Once the above is done there would be more room

for the future cleanups and improvements like:
* using bios directly in copy_buffer()

  (or avoiding copy completely if possible - need somebody to look at code)

* map user pages instead of memcpy-ing them in fd_copy{in,out}()

* unifying/merging arch specific code into floppy.c (not sure of this one)

* smarter way to handle IRQs
floppy.c rewrite offers an unique chance to learn by practice

from doing simple tasks (macros cleanup) to more advances ones

(involving block layer mechanisms) up to really difficult ones

(IRQ/"actual work" handling methods).
I could help with reviewing patches in case anybody is interested

and have patience to deal with few days delays for reply.  However
* this is unlikely that we need to add support for new hardware

* by doing the rewrite from scratch we will lose changes history

  and possibility to easily track regressions

* for a long time we would have to deal with both drivers
This is just not worth it IMHO.
Bart

-

* piece of shit FSM buried in various continuation methods.

* one hell of a problem with regression testing.

-

Good points. I'll try cleaning up the existing driver instead of doing

a complete rewrite.
--

Jesper Juhl <jesper.juhl@gmail.com>

Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html

Plain text mails only, please      http://www.expita.com/nomime.html

-

Considering how widespread floppies are, these two sentences are

contradictions.
If the goal is to phase out the old floppy driver, a new driver will

have to gain support for more or less all hardware the old driver 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

How much different hardware does the (old)floppy.c do? I imagine that

today, where floppies phase out, there will be, in descending order:
 * USB floppy drives (atm handled by sd.c, could be better to have sf.c)

 * FDCs on mainboards

 * 1.44M drives

 * 1.2M drives
Even a working 2.88M, as cool as it sounds, never landed in my hands ever

since I've been into computing. Perhaps the oldest, smallest disk I once

had was a 360K 5.25", but the B floppy drive to read it was already

multi-compliant that read up to 1.2M disks.
Jan

--

ft: http://freshmeat.net/p/chaostables/

-

On Wed, 2007-01-31 19:24:54 +0100, Jan Engelhardt <jengelh@linux01.gwdg.de>=
I do own a machine that has one :)  Those original IBM PS/2 machines

had them.
On the other hand, Linux' floppy.c could do a bit better to help

archiveing some of the scurrile floppy formats. There is at least one

floppy imaging project to store floppy images for uncommon formats. It

would be nice it the Linux driver could handle something like that...
MfG, JBG
--=20

      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481

Signature of:         Alles wird gut! ...und heute wirds schon ein bi=C3=9F=

chen besser.

the second  :

So what is wrong with the current floppy driver (other than being 120k

of code apparently)?
As for floppies that should work, well I imagine on x86 that would have

to be 360k and 1200k 5-1/4", and 720k, 1200k and 1440k 3-1/2".  Would

perhaps be nice to still support 160, 180 and 320k on the 5-1/4" drive

too just in case anyone ever wants to read one.  Of course some people

might also want support for the higher capacity formats on the 1440k

drive.  2880k would perhaps be nice too for those few people that have

one (I have only ever seen them on decstations, where I haven't seen any

driver ever), and I think a few IBMs.  I have never seen a 2880k disk.
In non x86 land, I would think there is a seperate floppy driver given

the odd formats of some of those systems.
--

Len Sorensen

-

Do the special formats (entries 9, 12, 13, 16, 17 in floppy.c)
Note that I was able to format a floppy with 1680k [21 spt] once under

Linux (including using it). No other OS (including the BIOS) could do

something with it though, and it had to be accessed explicitly through

/dev/fd0u1680. Maybe also the 1760k [22 spt] one, but can't remember.
With regular "1.44M" disks you get in any store, to be noted.
I'm glad to still have a 5.25" drive buried in a 386 [linux 2.6.13] :=)
Jan

--

ft: http://freshmeat.net/p/chaostables/

-

When you say newbie?  Do you mean coding newbie?  Or... just someone who

hasn't done a driver before?
either way I'd like to be somewhat involved in the process so I see how

things are done.
--martin
-

Sounds like a fun little project. I'll bite.
--

Jesper Juhl <jesper.juhl@gmail.com>

Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html

Plain text mails only, please      http://www.expita.com/nomime.html

-

Let me know when you have something and I'll go buy those floppies,

test it and fix a bug or two if I find 'em.
Trent

-

Sure. Will do. Thanks.
--

Jesper Juhl <jesper.juhl@gmail.com>

Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html

Plain text mails only, please      http://www.expita.com/nomime.html

-

Other than with the ISA drivers example, at least everyone has the 
The idea of some kind of task list already appeared in this thread - 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

Wrong. I abandoned all floppy drives some years ago. I'd actually

vote for removing the floppy driver from the kernel completely.
Well, at work i probably have an USB floppy lying around somewhere,

but i doubt that it uses floppy.c ;-),

--

Stefan Seyfried

QA / R&D Team Mobile Devices        |              "Any ideas, John?"

SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out."

-

Is that your model of how the kernel should work? Take out anything you

don't personally need?
I'm guesstimating the 20-30% of the old laptops I rehab on Linux for

kids who have none lack the ability to boot off CD. Or write a CD, for

that matter. The ability of Linux to run on old hardware is another 
--

Bill Davidsen <davidsen@tmr.com>

   "We have more to fear from the bungling of the incompetent than from

the machinations of the wicked."  - from Slashdot

-

Oh. I must have forgotten those smilies.
Yes, i know.

--

Stefan Seyfried

QA / R&D Team Mobile Devices        |              "Any ideas, John?"

SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out."

-

I don't think time has come for that yet, still millions of people do

use Floppy on Linux ;-)
~Akula2

-

How about not even then?  There are few uses for the floppy drive today

within linux, this is true.  BUT, that floppy is often the only was

software can be gotten from a vintage computer and published, or from a

publishing site back to that vintage computer.  Please don't take away

our last data path to what is to many of us, a very old and trusted dear

friend.  OS9, and later Nitros9, on a TRS-80 Color Computer, was my

teacher about unix-like systems, running a multiuser/multitasking

operating system on a machine with only 64k of ram, although my current

machine has 2 megs in it.  And I occasionally still miss some of the

things I could do on that little machine that I have not been able to do

since, like start an assembly that generates an output listing, and

switch to another monitor or window & list that listing to the screen a

maximum of 256 bytes behind the writing of that listing to the disk file

it was going to.
The floppy may not be usefull to linux anymore, but in support of other 
--

Cheers, Gene

"There are four boxes to be used in defense of liberty:

 soap, ballot, jury, and ammo. Please use in that order."

-Ed Howdershelt (Author)

Yahoo.com and AOL/TW attorneys please note, additions to the above

message by Gene Heskett are:

Copyright 2007 by Maurice Eugene Heskett, all rights reserved.

-

--

Cheers, Gene

"There are four boxes to be used in defense of liberty:

 soap, ballot, jury, and ammo. Please use in that order."

-Ed Howdershelt (Author)

Yahoo.com and AOL/TW attorneys please note, additions to the above

message by Gene Heskett are:

Copyright 2007 by Maurice Eugene Heskett, all rights reserved.

-

On Tue, Feb 06, 2007 at 07:07:50PM +0530, Sunil Naidu wrote:

 > On 2/5/07, Stefan Seyfried <seife@suse.de> wrote:

 > > On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:

 > > > On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:

 > >

 > > Wrong. I abandoned all floppy drives some years ago. I'd actually

 > > vote for removing the floppy driver from the kernel completely.

 >

 > I don't think time has come for that yet, still millions of people do

 > use Floppy on Linux ;-)

 > Maybe by 2.6.30 or so...
The release of any new kernel doesn't make all existing hardware

on the planet stop working.  I still get requests to enable

drivers in the Fedora kernel for 10 year old ISA sound cards.
In some parts of the world, buying a new computer isn't an option.

One of Linux's strengths is that we keep working on old hardware

without forcing the user to upgrade their system every time

like certain commercial OS's.
		Dave
--

http://www.codemonkey.org.uk

-

Bart

-

I have a floppy drive!  Will have to go buy some disks though.  What's

wrong with it?
Trent

-

There isn't something specific wrong.
It's simply that the last time someone completely understood this 120 kB

driver was in the last millenium.
That comes up every few months when some bug report arrives or in the 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

It'd be interesting to join forces with the BSD guys in this field, they surely

support initiatives like this!

-

I have worked with the BSD developers in the past, sharing

specifications and knowledge about how certian devices work in order to

help them get drivers up and running.  So this sharing has happened in

the past, and still continues today.
thanks,
greg k-h

-

> > I'm all for openness of device programming specs, but I think it's a

 > > bit disingenous to suggest that all a company has to do to get a

 > > driver written and supported is throw some documentation over the

 > > wall.  And it's crazy to suggest that the driver will work on every

 > > platform and be supported by enterprise distros.

 >

 > Why is that crazy, we do that already today with the majority of drivers

 > in Linux.
Well, we can disagree about the majority of drivers.  My feeling is

that most of the drivers that are really used by lots of people get

support beyond just a dump of docs -- in fact often vendors are

maintaining them, eg e1000, tg3, cciss, etc., to pick some running on

the boxes I have around here.
 > > Just look at the in-tree drivers: there are tons of them that don't

 > > work on big-endian platforms, or have 64-bit problems, or have no SMP

 > > support.  And that doesn't even count drivers that are so bitrotted

 > > they won't even build any more.

 >

 > Like Jeff said, many of these are quite old.
OK, but why isn't your army of volunteers fixing them?
 > > And there are plenty of documented devices that no one cares enough

 > > about to submit a driver for.

 >

 > Any specific examples?  I have a long list of people who wish to write

 > new drivers but just don't know which hardware is not yet supported.
I have a Cisco USB webcam that supposedly conforms to the "USB Video

Device Class", but nothing happens when I plug it into my Linux box.

I assume the device class is specified as part of the USB spec...
And I seem to recall there's more SATA chipset documentation than Jeff

Garzik has time to implement support for.
 > > In the real world, a vendor that wants to make sure a device is

 > > supported by Linux had better pay someone to write the driver and keep

 > > it working.  Of course, if the device is popular enough or simple

 &...
[ message continues ]

One of the problems if lack of hardware. It's very hard to fix a

prehistoric serial driver if you don't have an ISA bus box with the

needed slot let alone the card.
UVC is "interesting", in a bad kind of interesting sort of way. See

http://developer.berlios.de/projects/linux-uvc however
-

If you recal, tg3 was created by the community because the vendor

refused to open their driver up.  They only reluctantly now support it

because it went into the main kernel tree and the distros then refused

to accept the closed driver.
So there's a perfict example of what I'm talking about :)
Also, look at the rest of the system (ide, SATA, USB, firewire, driver

core, PCI, etc.)  None of that was done by a vendor, but by the
They don't know about them, or they don't have the hardware to test?

Seriously, let the kernel-janitor's project know about any issues you

have and they will be glad to jump on it.  Those people are just

chomping a the bit to do something a bit bigger than "compiler warning
Are you sure?  That spec just came out not so long ago and I haven't

seen any real devices support it just yet.  That said, I do know of a

few people who are working on implementing the standard, try asking on
Um, that's how Linux has gotten to where it is today and continues to

grow. Just because none of us wanted to do IB drivers, doesn't mean that

the model doesn't work for devices that are actually sane :)
thanks,
greg k-h

-

> > OK, but why isn't your army of volunteers fixing them?

 >

 > They don't know about them, or they don't have the hardware to test?

 > Seriously, let the kernel-janitor's project know about any issues you

 > have and they will be glad to jump on it.  Those people are just

 > chomping a the bit to do something a bit bigger than "compiler warning

 > cleanups" :)
I thought you said hardware to test wasn't necessary?
It's not particularly hard to find drivers that need work -- just

looking at everything protected by CONFIG_BROKEN would find plenty of

things to jump on.  Or do "git grep 'cli(' drivers/".
 > > I have a Cisco USB webcam that supposedly conforms to the "USB Video

 > > Device Class", but nothing happens when I plug it into my Linux box.

 > > I assume the device class is specified as part of the USB spec...

 >

 > Are you sure?  That spec just came out not so long ago and I haven't

 > seen any real devices support it just yet.  That said, I do know of a

 > few people who are working on implementing the standard, try asking on

 > the linux-usb-devel mailing list to find out what their status is.
A quick web search finds http://linux-uvc.berlios.de/ but I don't see

any signs that anyone plans to submit it upstream.
 > > I'm disagreeing with a stronger assertion -- your original email said

 > > that if a vendor just dumps out hardware documentation and donates a

 > > few devices, then that vendor will definitely get a driver that will

 > > be picked up by enterprise distros and run on every Linux platform.

 > > And that just isn't true, or at least experience shows it hasn't been

 > > true until now.
 > Um, that's how Linux has gotten to where it is today and continues to

 > grow. Just because none of us wanted to do IB drivers, doesn't mean that

 > the model doesn't work for devices that are actually sane :)
I disagree -- Linux today gets drivers not just from ...
[ message continues ]

If you want a sign, here it is: I plan to submit the driver upstream :-)
After more than a year of development, the Linux UVC driver is now stable

enough to be included in the kernel. There is a show stopper though: V4L2.
The UVC specification defines a set of standard controls. Most of them are

part of the V4L2 specification as well (brightness, contrast, ...), but some

of them aren't. Those controls are currently exposed through private controls

(which drivers are allowed to expose by V4L2), but I don't want to keep

private controls around for standard controls defined by UVC.
Once V4L2 will be updated (hopefully soon, I keep trying :-)), I will submit

the driver upstream.
Regards,
Laurent Pinchart

-

Which of these actively maintained and supported drivers work on only

one platform[1], and are excluded from enterprise distros?  Can we truly

count them as "many", as you repeatedly claim?
	Jeff
[1] obviously excluding drivers for hardware where its only possible to

occur on one platform, like SoC devices
-

> Which of these actively maintained and supported drivers work on only

 > one platform[1], and are excluded from enterprise distros?  Can we

 > truly count them as "many", as you repeatedly claim?
Why do we restrict this to actively maintained and supported drivers

(I think abandonware drivers are highly relevant here...)?  And why

are you asking about drivers that work on only one platform?  Greg

promised support for every platform that has the right bus to plug a

device into.  So things like drivers that don't work on SMP or 64-bit

or big-endian platforms also violate that pledge, even if there's more

than one 32-bit little-endian uniprocessor platform where the driver

does work.
Anyway, grepping for stuff like BROKEN or !64BIT or X86 in the Kconfig

dependencies under drivers/ finds tons of hits.  I don't have time to

scan through and figure out which meet your criteria, and I honestly

don't know how enterprise distros decide what to support.  For example

RHEL4 seems to ship aha152x (which depends on ISA && SCSI && !64BIT),

but what will RH do if someone actually wants support for it?
I don't really understand why it's so hard to accept that sometimes

even open specs aren't enough to get great Linux support.
 - R.

-

You were complaining about drivers that work on only one platform.

Thus, I asked for list of said drivers, drivers that break Greg's pledge.
Translation:  you don't have a clue what you are talking about, because

you haven't even bothered to do such a search yourself.
This is /your/ criteria we are discussing.  /You/ keep talking about

"many" (your words) non-portable and broken drivers.  And now you

actively avoid citing examples.  Oh, except for one:  aha154x, an

ancient ISA driver.  So, yes, I concede that if a vendor appears and

wants to push in a new driver for ancient ISA hardware that nobody in

the planet uses... it might not find a volunteer.  Hooray for goofy 
And hooray for shifting arguments.  If this is your summary of the

thread, do you now concede that Greg was not being disingenuous?  Open

specs was not the sum toto of Greg's piece.
	Jeff
-

> You were complaining about drivers that work on only one

 > platform. Thus, I asked for list of said drivers, drivers that break

 > Greg's pledge.
When did I ever say "one platform"?  If I did, it was an error -- I've

tried to consistently talk about not every platform.
 > I'm betting they are uniformly ancient ISA or m68k or whatnot drivers.
So what?  Greg didn't restrict his offer to "mainstream" devices.  And

Greg said "[the driver] will be automatically kept up to date and

working through all Linux kernel API changes."  Not "we'll maintain

the driver until we lose interest."  And anyway, if I dig for a few

minutes I find modern mainstream stuff like ipw2200 that is seemingly

x86-only.  (Although of course ipw2200 is straight from Intel)
 > And hooray for shifting arguments.  If this is your summary of the

 > thread, do you now concede that Greg was not being disingenuous?  Open

 > specs was not the sum toto of Greg's piece.
Perhaps "disingenous" was the wrong choice of word, though, since you

and Greg seem to sincerely believe that a spec dump is all that a

vendor needs to do.  I'll concede that maybe I should have used the

word "naive" instead.  But I absolutely feel that Greg should not be

making promises on behalf of "the Linux kernel community."
Go back and reread Greg's original email.  He said:
 > All that is needed is some kind of specification that describes how

 > your device works, or the email address of an engineer that is willing

 > to answer questions every once in a while. A few sample devices might

 > be good to have so that debugging doesn't have to be done by email,

 > but if necessary, that can be done.
Let me repeat Greg's words one more time: "All that is needed is some

kind of specification."  So I honestly don't know what you mean by

"open specs was not the sum toto of Greg's piece."
Here is what he promised once that spec is released:
 > In return, you will receive a complete and working Linux d...
[ message continues ]

How is that clear?  As noted in the specific examples I provided, that 
The only difference between Greg's offer and offers made by other

developers to vendors is that his was public on LKML, and the subject

line concluded with an exclamation point.
I tell hardware vendors the same thing all the time -- just get the

specs to me or another capable developer, and we'll work with you to get

Linux support going.
So far, we have ATA, USB, ethernet, audio, and several other positive

examples of this working in the real world.  And your counter-examples?

  Ancient ISA drivers.
	Jeff
-

> > To me, it's clear that historically the community hasn't delivered on

 >

 > How is that clear?  As noted in the specific examples I provided, that

 > is how a large number of popular drivers and subsystems have been

 > developed.
Yes, I agree that it often works.  What I'm arguing is that it doesn't

ALWAYS work.  And Greg is promising (in effect, on my behalf) that "If

you give us specs, then we WILL have drivers."  As I've said several

times, I'm all for encouraging vendors to open specs.  The only thing

I don't like is marketing open specs by making promises that we may

not be able to keep.
 > The only difference between Greg's offer and offers made by other

 > developers to vendors is that his was public on LKML, and the subject

 > line concluded with an exclamation point.

 >

 > I tell hardware vendors the same thing all the time -- just get the

 > specs to me or another capable developer, and we'll work with you to

 > get Linux support going.
There's a big difference, because Greg's offer goes to every vendor,

present and future, and promises a perfect driver in return for a spec

dump.  I have no problem with what you're telling vendors.  And I

think it's worth noting that you say, "we'll work with you to get

Linux support going."  You don't say, "all we need is specs to get

your driver into enterprise distros" -- you say that vendors need to

"work" with us, not just dump specs.
 > So far, we have ATA, USB, ethernet, audio, and several other positive

 > examples of this working in the real world.  And your

 > counter-examples? Ancient ISA drivers.
I think that's somewhat of a misrepresentation.  So far in this

thread, I've also raised Ralink wireless (stuck out-of-tree until

after the HW is EOLed) and USB Video Class (apparently also stuck out

of tree, in spite of vendor support from Logitech).  And Dave Airlie

mentioned XGI 3d HW.
Again, yes, I admit that releasing specs usually is the best way to

get Linux s...
[ message continues ]

I really think we can keep these promises.  A number of us have been

doing just that for many years now, and I don't see any reason why we

would stop doing that now.
I would _love_ to be inundated with specs, so many that we run out of

developers to work on the devices.  But I really don't see that

happening any time soon, as there's not that many devices that Linux

doesn't already support.
And if such a situation does happen, perhaps I will be able to convince

some distro companies to pony up the development man-power to help us

from going back on our promise...  I know quite a few companies would

love to help out just a "problem" as it is in their best interest to

have Linux support as many devices as possible.
So please, don't be so down on the offer, you don't have to do any work

if you don't want to :)
thanks,
greg k-h

-

Heh, never underestimate a well-placed ! :)
Also, one big and new portion is the fact that we now have in place a

system to handle NDAs for those companies that do not wish to provide

specs to the whole world.
thanks,
greg k-h

-

I can't talk for every subsystem, but what we have under the DVB

subsystem, for the devices that we have access to specs we have well

behaved drivers, many have even complimented that they work much

better than their windows counterparts.
I have even received mails from some vendors that some of the Linux

drivers behave better than their own windows drivers.
We can't count on reverse eng 'd drivers (or even drivers written with

a lot of guess work due to lack of specifications), they don't behave

nice. So at least if the vendors were to provide some specs in that

direction, it would help to make those drivers better.
So i think to a certain as to what i can say, probably you are wrong.
regards,

manu

-

For almost all _new_ drivers, this is the case.  They are well supported

and build on all platforms.
Yes, there are plenty of old drivers that are marked BROKEN (look at the

scsi tree for some examples there), and some that still use cli (which

the kernel janitors keep trying to fix up but the very fact that no one

has the hardware to test their changes keeps that effort from going

anywhere.)  But that is not the case for new stuff, nor is it the case
Yeah, sometimes you really need someone who has the device in a machine

that still boots :)
thanks,
greg k-h

-

I would much rather see a driver bit rot due to lack of interest than

see hardware go to the scrap heap because the vendor stoped caring about

it and you are SOL.  Happens every time a new windows version comes out.

lots of working hardware suddenly becomes useless.  At least on linux I

can keep using it if I want to until I decide not to try and maintain

the driver (if no one else is doing it).  A driver with bitrot is a lot

better than no driver at all.
--

Len Sorensen

-

Check your history...  tg3 was written by me and DaveM, and only after

years was it picked up by the vendor as their official Linux driver. 
I seriously doubt you can come up with even a single concrete example here.
Regardless, libata has 55+ drivers and counting, all for the price of 
What experience?  AFAICS, pretty much all modern hardware in use outside

of ATI/NVIDIA graphics is supported by Linux.
All visible evidence points to support for Greg's assertion.
	Jeff
-

Not trying to slight Jeff here in any way, but I thought I'd point out

one driver-less SATA chip that seems to have docs available.
When looking for a sata controller I came across several inexpensive

ones based on an Initio chipset, and at first glance it seems that they

have docs out there*: http://www.initio.com/products/sata.htm
but no drivers yet.  Just in case anyone is interested :)
-Eric
*knowing next to nothing about SATA, I have no idea if these docs are

sufficient.

-

2.6.20-mm, although it can't do some things currently and the docs are

not really adequate.

-

The driver is in libata-dev.git#upstream and queued for 2.6.21.
	Jeff
-

Woo!  that was fast.  Ok I stand corrected. :)
-Eric

-

Be warned.  The driver is marked HIGHLY EXPERIMENTAL and it seem to work

only on my machine.  Seems to have some problem with LBA48 support.
The datasheet initio posted on the website just contains register

descriptions, which is much better than nothing but I still had to do a

LOT of trial-and-error to make that thing quasi-working.  I've tried to

contact them in many ways but couldn't get any response.  I'll probably

get back to it in a few weeks.
I can write ATA drivers for most hardware in a few days given 1.

actually useful datasheet 2. hardware at hand 3. an ENGINEER to talk to

when I get stuck.  So, sign me up.
It will be nice to have some central web site / wiki / whatever to

monitor progress, arbitrate jobs, provides link to relevant info and

people (probably some of them being open-by-request) and possibly

provide links to bugzilla entries.
--

tejun
-

So far most of the companies have not really wanted the publicity,

that's why I have not posted anything publically about it.  But I do

have a place to make all of this public if it turns out that it is ok to

do so.
thanks,
greg k-h

-

> > Well, we can disagree about the majority of drivers.  My feeling is

 > > that most of the drivers that are really used by lots of people get

 > > support beyond just a dump of docs -- in fact often vendors are

 > > maintaining them, eg e1000, tg3, cciss, etc., to pick some running on

 > > the boxes I have around here.

 >

 > Check your history...  tg3 was written by me and DaveM, and only after

 > years was it picked up by the vendor as their official Linux

 > driver. You have picked an excellent counter-example to your own

 > argument.
OK, fair enough, I forgot about tg3.  But on the other hand, you wrote

it without docs, actually _in spite of_ Broadcom, right?
Which I think makes my point that documentation is neither necessary

nor sufficient for a good Linux driver.  Documentation helps, but if

no one competent cares about the device then the driver won't get

written.  On the other hand, if the device is important enough, the

driver will get written without documentation or vendor support.
 > > OK, but why isn't your army of volunteers fixing them?

 >

 > Because nobody has hardware for them?
Greg said hardware wasn't necessary...
 > > And I seem to recall there's more SATA chipset documentation than Jeff

 > > Garzik has time to implement support for.

 >

 > I seriously doubt you can come up with even a single concrete example here.
Sorry, I thought you said there was interesting stuff to do with the

Promise documentation you got.  I guess Nvidia ADMA is pretty much

done now.
 > What experience?  AFAICS, pretty much all modern hardware in use

 > outside of ATI/NVIDIA graphics is supported by Linux.
Sure, popular hardware support is pretty good.  But there are still

pretty serious gaps, for example Ralink wireless drivers are still not

upstream even with the vendor trying to help (and I think Ralink

wireless is a good example of how we can't really keep the promises

Greg is mak...
[ message continues ]

To repeat -- that's how most Linux drivers have been written, 
I did not say "no developers [...]"
How so?  They appear to be working with wireless devs to get their 
Yes, large chunks of legacy ISA drivers, m68k drivers, and similar

situations where the userbase has dwindled to a handful over a decade.
	Jeff
-

> > OK, fair enough, I forgot about tg3.  But on the other hand, you

 > > wrote

 > > it without docs, actually _in spite of_ Broadcom, right?

 > > Which I think makes my point that documentation is neither necessary

 > > nor sufficient for a good Linux driver.  Documentation helps, but if

 > > no one competent cares about the device then the driver won't get

 > > written.  On the other hand, if the device is important enough, the

 > > driver will get written without documentation or vendor support.

 >

 > That's your point??  I thought your point was (quoting your words)

 >

 > > it's a

 > > bit disingenous to suggest that all a company has to do to get a

 > > driver written and supported is throw some documentation over the

 > > wall.  And it's crazy to suggest that the driver will work on every

 > > platform and be supported by enterprise distros.

 >

 > To repeat -- that's how most Linux drivers have been written,

 > /particularly/ the ones used most by users of enterprise distros.
I thought you wrote tg3 without docs and without help from Broadcom?
To repeat, my point is that the drivers used most by users of

enterprise distros will get written with or without vendor docs or

help.  Drivers for hardware that only a few people care about probably

won't be written and definitely won't be maintained by volunteers even

if the vendor publishes docs.  And I think that's pretty much what I

said in both of the paragraphs you quoted above.
 - R.

-

You're changing your story.  After first over-simplifying what Greg

posted, you were complaining about Greg being disingenuous, when in fact

Greg was doing nothing but describing (in a new and different way) how

Linux drivers are already written.
Furthermore, presuming that drivers "definitely won't be maintained by

volunteers" is rather presumptuous considering that volunteers are

lining up, according to Greg.
I'm glad I didn't have a negative nelly like you around when I first got

into fbdev driver hacking, my entry into the Linux kernel world.  "Don't

bother, son, nobody wants you around anyway."
	Jeff
-

Someone has to have the hardware to test with.  Hence my "debug by
The Ralink wireless drivers are working to get their stuff upstream.  I

think there is only some wireless infrastructure needed to complete

before it gets into mainline, but you will have to ask them about this.
There was a wireless-mini-summit a week or so ago, so those developers

all know what is going on in that space right now.  They are facing a

number of different regulatory issues, combined with lack of

specifications from some vendors.  I don't think that the developers who
The ISDN maintainer has a large rewrite almost done, and anyone is

welcome to help him out if they are still using and needing that old

hardware.  As almost no one objects to the current code, I'm guessing

that there is no such real need :)
thanks,
greg k-h

-

> The Ralink wireless drivers are working to get their stuff upstream.  I

 > think there is only some wireless infrastructure needed to complete

 > before it gets into mainline, but you will have to ask them about this.

 >

 > There was a wireless-mini-summit a week or so ago, so those developers

 > all know what is going on in that space right now.  They are facing a

 > number of different regulatory issues, combined with lack of

 > specifications from some vendors.  I don't think that the developers who

 > actually have specs are complaining about anything right now.
OK, one last reply before I give up on this thread...
Sure, Ralink drivers will get upstream eventually.  But by the time

the drivers get merged, Ralink will have stopped making the chips that

it supports (or so I read, http://www.linuxemporium.co.uk/products/wireless/)!

I don't think that taking a year or two to merge a driver is going to

impress a vendor, especially since the reverse-engineered Broadcom

wireless driver is probably going to go upstream at just about the

same time.
An uncharitable vendor might decide it's not worth publishing specs,

since the Linux guys can reverse engineer the Windows driver just as

fast anyway.
 - R.

-

And ndiswrapper gives fire to just releasing the Windows one :(
Jan

--

-

ndiswrapper is a way to make it work "now" as opposed to "correct".  There

is a lot that you cannot do with ndiswrapper that a proper driver can.
--

"Invoking the supernatural can explain anything, and hence explains nothing."

                   - University of Utah bioengineering professor Gregory Clark

-

The fear is that a vendor might not open things because it works

"reasonably enough" (for them as well as the enduser) at "this time".

E.g. I got sis162u.inf for some usb wireless adapter, it works

enough, but of course I am not too happy with the binary blob because

it might have some not-so-"correct" core that could silently oops me

away.
Jan

--

-

Of course, the vendors need to realize that such problems will be blamed

on the hardware and not on the drivers.  "But I was using the Windows

drivers!"
--

"Invoking the supernatural can explain anything, and hence explains nothing."

                   - University of Utah bioengineering professor Gregory Clark

-

Logically this makes sense from a user perspective, but I tend to doubt

ndiswrapper is really a motivator for a vendor?  One would think that

vendors would rather not have a crash-y solution for their hardware.
	Jeff
-

I'm sort of with Roland on this, the timelines aren't usually worth it

for a company to bother especially with complicated hardware, the time

taken to do a community graphics driver for any GPU where specs have

been available approaches infinity, unless the vendor actually does

the driver or pays someone to do the driver the hope of a community

supported driver reaching maturity while the product is still

available is slim.... for anyone desparate to start writing device

drivers, XGI have recently dropped a load of specs for their cards,

I'm not seeing anyone other than the usual GPU ppl step up an do

anything and as I said the time it takes a single volunteer to write a

GPU driver is a lot longer than the card...
Dave.

-

All this sounds like a lack of organisation on the side of the

community to me.  Greg saying that he and others are twiddling their

thumbs because they don't know what hardware needs drivers says that

too.  Where is the list of hardware-without-drivers?  Until recently

there hasn't even been a list of hardware-with-binary-only-drivers

[1].  So anyone who has the necessary skills and thinks gee, I might

have a go at writing a linux kernel driver, has no idea where to go or

what to do.  I wonder how many vendors have a policy of just ignoring

emails from hackers asking for specifications because they have

already given the specifications to Redhat or someone else, but

hackers just keep asking them again and again.
Trent
1. see http://developer.osdl.org/dev/opendrivers/wiki/index.php/Binary_Kernel_M...

for a partial list.

-

I think this is a quite fair criticism, and I would love to see someone

step up and help with this sort of organization.
For example, I didn't know that XGI graphics specs were available at

all, otherwise it might have been something fun to tackle.
	Jeff
-

Just to pony up my experience in all of this, which I think is probably

quite representative of many other drivers:
A bunch of years ago I picked up a USB Ethernet device at the store

because it seemed really cool and I hoped it worked under Linux.  Turns

out that it didn't.  I had never written a kernel driver before, and

dealing with USB was an alien concept to me.  I searched around and

found that FreeBSD had a driver and I tried to use that in combination

with other USB Ethernet drivers in the kernel as reference to get

something working.  There was a basic spec sheet from the vendor, but a

lot of detail was missing and for someone who was new to spec sheets and

such, it wasn't much of a source.  I wound up coming across a driver

that Tivo had written for the device so I started working to hammer that

into shape to be added to the kernel.  The driver was quite a mess and

had a lot of issues and took a good amount of work, but eventually I was

able to get it to give me basic operation.  As I published updates and

such, I found that there were a lot of folks that were wanting these

devices to work.
I eventually was contacted by the manufacturer to add support to their

newer chips and they even provided some code to make the devices work.

The code was not suitable for inclusion because it was circuitous,

spaghetti, impossible to understand, brute-force style code that just

could not be maintained (which I think is quite common with vendor

drivers, and really makes me shudder when I think of what the code

behind many Windows drivers must look like).  I kept hammering on the

code to get it to be understandable and modular and got it sent

upstream.  For one of the chips, it wound up taking a lot longer than I

had hoped, mainly due to a lack of time on my end and lack of interest

from the community - I wasn't seeing much of a 'Hey, can we get this

chip working?' so it seemed that the devices weren't out there in many

hands.
At this point, the driver supports 19 devices and seems...
[ message continues ]

Putting the "codingstyle" control aside, often it's because things look

too hackish. Take ipt_ROUTE as an example. It won't get included, since

the "proper" way to do it would be using MARK and iproute2. But many users

don't get that [no criticism here], because ipt_ROUTE is so much easier.

(Probably because iproute2 and other netlink-using tools, like tc, lack

thorough documentation.)
Jan

--

ft: http://freshmeat.net/p/chaostables/

-

Doing it by MARK a tables and rules is an ugly method, and like anything

with is spread over many places (the mangle table to MARK), then 'rules'

and 'tables', spreading an action into many places increases the chances

of getting parts out of sync and having the whole not work as intended.

And the 'ip' man page defines everything in BNF, which was hot stuff

when Algol-60 came out (1960) but which is only readable to people who

use it frequently.
The ipt_ROUTE allows putting all parts of of the action, from defining

the set of matching packets to specifying the desired result, the

routing. And if that changes, it need only change in one place.
Making good administration difficult because it fits some pedantic metal

model is NOT a good way to decide which features to offer in a kernel.
--

Bill Davidsen <davidsen@tmr.com>

   "We have more to fear from the bungling of the incompetent than from

the machinations of the wicked."  - from Slashdot

-

Also sometimes the authors know it's hackish, or just don't expect it

to be generally useful to the world.  I happen to own an out-of-tree

filesystem which I have little desire to have reviewed for mainline:

only a dozen people use it at most, and I know it would get pinged

mercilessly for using buffer heads and general insanity if it ever

made it past "use FUSE instead" (which would admittedly be a perfectly

fine response).  It works though, so I keep it up to date with the VFS

changes.
I do have some interest in working on various device drivers, though.

Greg, assuming this somehow kicks off some avalanche of specs, will

there be a ML for hooking up driver writers with specs and willing

users?
--

Bob Copeland %% www.bobcopeland.com

-

I don't really want to create yet-another-mailing list for something

like this.
So far I've just been taking down people's names and email addresses and

a short description of what types of drivers they would like to work on.

We already have a nice list of people willing to help out.
Anyone else is welcome to email me if they wish to join in.
thanks,
greg k-h

-

Most vendors are likely to focus on examples that are in the statistical

(and competitive) majority, where publishing specs led to a driver

supported by an enterprise distro.
	Jeff
-

And seems to do 802.11b only and screw up the eeprom settings so that

the windows driver gets confused next time you boot windows.  Lovely

driver.  If the bios on the laptop in question would let me change the

minipci card I would.  To something with a ralink on it.
Seems the ralink driver maintainers are doing a lot of the work on the

core wifi infastructure too.  Lots of work beyond just the driver then.
--

Len Sorensen

-

Nah, why do you think it will screw up the eeprom?

Did you try to completely power off the machine before rebooting

into windows?
I _really_ _really_ _really_ think that there is no chance of writing

the eeprom by accident. It is protected by some write-enable bit in

PCI config space. There is only one place where we enable that bit

and where we actually _write_ to the eeprom shadow mmio space. That's

the eeprom writing code. It will output _lots_ of kernelmessages that

you really can't miss when that happens. And it's only called on behalf

of a private ioctl user request. _And_ it verifies the data with a CRC

check. So you really can't call it by accident.
Are you suggesting that bcm43xx people don't, or what?

Are you living on another planet than me? Mine is called "Earth".
--

Greetings Michael.

-

No at the time I don't think I powered it off, and I suspect that is

probably what went wrong.  The windows driver probably didn't like the
I suspect I can't.  I still can't make it connect successfully to

anything yet, but that could just be a configuration problem, or it not
I have just mainly seen messages about devicescape from the ralink
Sometimes I might be.  At least on the days I have to deal with problems

in Windows (it's not even my machine, so I don't get to pick what it

runs all the time. :)  I haven't had particularly much luck getting a

stable wireless going on linux yet, although I haven't put much effort

into it yet either.  I figure in a couple of years there will be so many

wifi devices around that wireless won't work anymore anyhow so it isn't

a high priority.  I like simple trustworthy wires.
--

Len Sorensen

-

For what it's worth, hostap + Prism chips of various kinds has worked

quite solidly for 7-8 years or so, and I shipped handheld products

with it in 2001 or so and ran all of my wireless infrastructure gear

on it until I switched to off-the-shelf Broadcom- and Atheros-based

gear a couple of years ago (running OpenWRT and variants thereof).

The apparent inability of any wireless vendor to fix a low-level

firmware bug without breaking at least one common order of operations

in the driver API is hardly Linux's fault.
As it stands, there's enough of a learning and fiddling curve with

every WiFi driver that it's usually not very time-efficient to get

WiFi working under Linux on any single box that shipped with Windows.

But given a controlled configuration and some up-front time

investment, it's not that hard to switch over your local environment

(my neighbors and I have a WDS mesh set up), at which point you may be

the only people within RF range whose WiFi doesn't go belly-up when

some mangled frame comes along.  In this case, it's the last 20% of

the effort that produces 80% of the value.  (Bye-bye, telco monopoly;

the only live wires remaining into our house are the AC mains.)
Cheers,

- Michael

-

I can't remember that kind of corruption ever being reported to the
So are the bcm43xx maintainers.
Erik
--

+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --

| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

-

Well I assumed it messed up the eeprom settings, since we had to go into

the advanced driver settings and change it from 802.11b only back to

auto mode and I would think those settings are stored in the eeprom if

booting a 2.6.18 kernel and loading the bcm43xx driver can cause it to

stop working, then it has to be an eeprom setting.
Actually I suppose the other posibility is that you simply have to power

cycle before booting windows after linux to avoid any left over settings

in the chip from being a problem.  That may be what I did.  Given I

couldn't get the card to connect using the bcm43xx driver anyhow, I

didn't spend too much time trying (I am fairly sure I set the AP to
Excellent.  Is the bcm43xx planning to get 802.11g mode working at some

point?  Is broadcom ever going to help out with any specs for their

hardware or do they still mistakenly believe that end users are not

their customers?  Given the behaviour of broadcom over the years I know

I don't intend to buy anything with a broadcom chip in it again, which

means broadcom's behaviour directly means they will get less sales to the

laptop makers, since some people will actively avoid anything with

broadcom's hardware in it. :)
--

Len Sorensen

-

That's what my laptop needs. Not for the wireless card, but somehow

windows locks up if I just reboot the machine. Of course no nice Oops
... the documentation isn't. Right now the only available documentation

comes from reverse engineering. It's actually rather amazing that the

authors came this far, no vendor documentation yet still a lot of
That's my take as well. They already lost us on the Gig ethernet cards.

A couple of years ago we considered Broadcom based cards, but given the

lack of vendor driver support, we got Intel E1000 based cards instead.

We also considered NatSemi gigE cards, but the Intels were much faster.

Right now we use about 15 E1000's with probably more to come (they go

in every new machine). Not a high figure but still a lost sale for

Broadcom.
As for wireless, for personal use I needed a wireless PCMCIA/CardBus

card and a Linksys bcm4318 based card was the only reasonably supported

card I could get. It works but still has its peculiarities.
Erik
--

+-- Erik Mouw -- www.harddisk-recovery.nl -- 0800 220 20 20 --

| Eigen lab: Delftechpark 26, 2628 XH, Delft, Nederland

| Files foetsie, bestanden kwijt, alle data weg?!

| Blijf kalm en neem contact op met Harddisk-recovery.nl!

-

> You mean the bcm43xx wireless driver that's been upstream for months?
Sorry, yes.  For some reason I thought it was blocked on the dscape

merge but obviously I was wrong.  So a reverse-engineered driver got

upstream WAY FASTER than a driver where the vendor published specs and

GPLed source.
Why did that happen?  I would argue that it was because way more

people cared about the broadcom driver (since the chip was in apple

laptops and the wrt54g among other things).  That developer and user

interest is more important than the info provided by the vendor.
Anyway, I broke my first promise to drop this thread, but I'll make

the promise again now...
 - R.

-

That may be partially true. But the main reason is that the rt2x00

team chose to depend upon the heretofore unmergeable devicescape stack.

In contrast, the bcm43xx driver had a port for the ieee80211+softmac

stack that was ready for merge much earlier.  This is more a result

of confusion in one area of kernel development than an indictment of

Linux drivers in general.
FWIW, we are closing-in on a merge for the devicescape stack.

(No, really!)  So, hopefully wireless will soon cease to be such a

fertile ground for bad examples...
Thanks,
John

--

John W. Linville

linville@tuxdriver.com

-

The vast majority of these were submitted ages ago.  Standards for

acceptance and maintenance have risen since the days of ISA drivers and

floppy tape drives.
I think it's quite disingenuous to imply that a few bad apples are a

representative sample.
	Jeff
-

> The vast majority of these were submitted ages ago.  Standards for

 > acceptance and maintenance have risen since the days of ISA drivers

 > and floppy tape drives.
What are our standards for maintenance?  How can we tell in advance if

something is going to be maintained (cf. drivers/net/chelsio)?
I don't think you can seriously argue that just posting documentation

is going to guarantee that a device is going to get a high-quality

driver that runs on all architectures and that enterprise distros will

support.  And I don't think it's a good strategy to try convince

vendors to open docs by using happy talk about an idealized fantasy world.
 - R.

-

Look up from infiniband once in and while, and... surprise... that's

what is actually happening.  It sure seems to me like the drivers

maintained by hardware vendors directly is in the distinct minority,

illuminating irrefutable evidence that hardware vendors do in fact

receive high quality drivers in exchange for documentation (and

hardware) availability.  IMO the drivers of the highest quality are 
Agreed.  That's why Greg was describing the real world of Linux kernel

development, rather than an idealized fantasy world.
How do you think you got all these highly portable ATA, USB, network,

and sound drivers, hmmm?  The vast majority was just documentation and

hardware access.  That's been the Linux way since 1993 (1991?).
	Jeff
-

Jeff Garzik wrote:
Great offer to folks for drivers, but it sends a mixed message.  OSDL 
-

Well, if the hardware is nice and is useful to many, there will be at

least a few handful who would ready to put in some effort to it. (We

are talking complex hardware only, not simple ones) Of course

development takes some time, in the order of a few months as opposed

to weeks. The vendor can of course the pay the author as well, which

will result in even better support.
regards,

manu

-

Sounds very nice indeed. Just happened to do a driver in a similar

status, where the vendor did not want to make the specs and other

stuff open, but was in a position to support an OSS driver for the

STB0899 demodulator driver from ST Microelectronics
I think many vendors will be ready to jump in.
the STB0899 demodulator driver is now available at
http://linuxtv.org/hg/~manu/stb0899-c5
It needs some fixes with regards to our DVB API. (bumping it up to 3.2

from 3.1) It's almost ready to rock now, with new delivery systems.
regards,

manu

-

Let us know when it's ready, since the invite is here, success stories

of people using the program could go here as well.
Greg, did this go to the "announce" group as well? It should, some

people read that even if they can't cope with LKML volume.
--

Bill Davidsen <davidsen@tmr.com>

   "We have more to fear from the bungling of the incompetent than from

the machinations of the wicked."  - from Slashdot

-

What "announce" group?
I noticed it hit /., so it is now being spread to a group wider than

lkml.
thanks,
greg k-h

-

Based on the initial response so far, a number of them seem very
Glad to see that we are getting more device support :)
thanks,
greg k-h

-

Not only that, we will be adding in even more delivery systems like

DVB-S2, DVB-H, DSS and other than that, we will be having algorithm

based tuning rather than dumb tuning.
regards,

manu

-

Very nice spin indeed.
This reminds of the the utterly broken dl2k network driver (which has

got interrupt handling problems and doesn't properly synchronize with

DMA transfers, IIRC).  Hardware specs are available, and I guess I

could even provide a hardware sample, maybe even two.  (If the

community provides driver support, it shouldn't matter if the vendor

actually supports development.)

-

Have you tried contacting the network driver developers to work these

issues out?
thanks,
greg k-h

-

Yes, sort of: <http://article.gmane.org/gmane.linux.kernel/448446>

There weren't any replies, unfortunately.  Do you think a repost would

make sense?
Our subsequent debugging revealed that either all the cards in our

sample were simply broken (but they seemed to work just fine with the

driver from FreeBSD-current), or something related to the DMA handling

in the driver was not quite right.  It looked as if the kernel and the

NIC couldn't agree on the contents of the ring buffer.

-

Try sending it to the netdev mailing list instead.  Not all of the

network driver developers read the whole lkml firehose.
thanks,
greg k-h

-

(How many do we support? How many does NetBSD?)
Wonderful idea!
Jan

--

ft: http://freshmeat.net/p/chaostables/

-

We support at least 25 separate architectures, with a _huge_ variety of

different variations within those architectures.  We passed NetBSD a

number of years ago (sorry, don't have their numbers around right now.)
thanks,
greg k-h

-

Don't they claim 50+? Already browsing

ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-3.1 gives more than 2

screenfuls [à 25].
Jan

--

ft: http://freshmeat.net/p/chaostables/

-

I don't know exactly how many architectures does netbsd run, but Linux seems

to support arches that netbsd doesn't, like: 64 bit MIPS, PPC 970 (available in

netbsd but not yet integrated i think), Cell, S390, M32R, Nec v850, frv, cris?,

xtensa, mmuless cpus (apparently there're lots of mmuless cpus), Itanium

(netbsd development ongoing)
Sure, Linux doesn't support vax and the like, but it does support lots of

architectures that matter. In  http://netbsd.org/Ports/#ports-by-cpu there's a

more Linux-like view of the architectures supported. Although Netbsd people

will argue that porting a architecture to Linux is more difficult and that Linux

gets support just because there's a lot of $$$ around it.
Anyway, even if Linux wasn't the OS with more architectures supported

it'd be the _second_ on the list. Which is quite impressive anyway, and

nothing to be ashamed of.
-

e's a
Well, there *is* a 2.6.x based VAX port, though it needs some updates

to incorporate the last few months of upstream development. But NetBSD

still does better hardware support.
MfG, JBG
--=20

      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481

Signature of:               http://www.eyrie.org/~eagle/faqs/questions.html

the second  :

Hi,
a few years ago, I installed NetBSD 1.6 on my VLC4000. It hanged every now

and then (several times a month). I finally tried OpenBSD 3.1 and it never

hanged nor crashed since. It's been running 3.7 fine from its release till

now. I don't know if NetBSD's VAX support has stabilized now, but I thought

it might be of interest to you to be aware that at least another OS runs

fine on this hardware.
Best regards,

Willy
-

Already knew that :)  There isn't much traffic on the VAX related

development lists (neither for *BSD not for Linux), but things are

slowly progressing.  These days, we try to work together (eg. we wrote

a graphics driver or two together, after we disassembled the machine's

ROMs.)  So unfortunately the userbase is small, but we perfectly work

together.
MfG, JBG
--=20

      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481

Signature of:               The real problem with C++ for kernel modules is:

the second  :                                 the language just sucks.

                                                   -- Linus Torvalds

A real one time argument. There's much more $ around Windows and yet,

there are (I presume) almost only drivers for x86 (and slowly coming,

x86_64). IA64? Well, you probably don't run desktop peripherals there,

but vendors don't have a driver at hand easily.
Jan

--

-

Don't get confused by the fact that the majority of the NetBSD platforms

are sub-architectures.  I'm talking about 25 unique CPU architectures.

Or is it 20.  I haven't looked in a while, the tree is there for anyone

else to look at :)
And even then, I think just the pure number of variants of ARM and PPC

that we support is greater than NetBSD's sub-arch support too...
thanks,
greg k-h

-

Greg KH wrote on 30-01-07 02:29:
s/affect/effect/
and maybe
s/build/manufacture/ ??
bjd
-

We probably *want* to encourage them to come talk to us when the device is

still a "build" because it's in the design/prototype stage - that way we avoid

having to work around design brain damage and features that could have been

added but weren't because The Other OS wouldn't have used them.
Also, the people we want to talk to *are* the "build" people - it's quite

possble they farm out the mass manufacture to some other company that just

does the actual assembly of boards based on a CAD/CAM model they're given.

Heh, gotta love the grammer police (you were not the only one to point

these mistakes out by a long shot...)
thanks,
greg k-h

-

Mind if I include this offer on http://kernelnewbies.org/UpstreamMerge ?
--

Politics is the struggle between those who want to make their country

the best in the world, and those who believe it already is.  Each group

calls the other unpatriotic.

-

Please do, spread it around as much as you want.
thanks,
greg k-h

-