[lkml]   [2003]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Orinoco-devel] orinoco_usb Request For Comments
On Thu, Jun 26, 2003 at 06:03:23PM -0400, Pavel Roskin wrote:
> On Thu, 26 Jun 2003, Manuel Estrada Sainz wrote:
> > I now believe that it is stable enough for the kernel, and I would like
> > to get it integrated in the official kernel tree.
> >
> > At first I tried convincing David to accept the changes in the standard
> > orinoco driver but he was (rightfully) skeptic. Then Jean Tourrilhes
> > opened my eyes, the changes touch carefully crafted locking semantics
> > and could give trouble (although it has been working well for quite a
> > while), and suggested adding it as an independent (alternative) driver.
> I think it's a reasonable request. It's a pity that the future work on
> the Orinoco driver won't be integrated into your driver automatically. In
> particular, scanning, monitor mode and switching to the separate wireless
> handlers may be useful for the USB driver as well.
> But indeed, Orinoco USB is very different from other Orinoco cards. There
> is a firmware that stands between the driver and the PCMCIA card, and that
> firmware is less transparent than, say, PLX bridges.
> It's a tough call, and it's up to you to make.

I am not going that drastic jet, I'll provide all functionality:

hermes-exp.o orinoco-exp_cs.o orinoco-exp_plx.o
orinoco-exp.o orinoco-exp_pci.o orinoco-exp_tmd.o

And keep merging with David's code. If in the end David likes the code
we merge the two and live happily for ever after, and if not the most
similar the two variants are, the easier periodic merging will be.

Well, over time I may get tired of the situation, drop all but usb and
run apart, but not now.

> > It has happened before with rtl8139/8139too and others, while the new
> > driver probes it's merits stability conscious people can still use the
> > standard driver.
> I don't know what happened to rtl8139/8139too but I think the situation is
> different from your description. Unless you are going to make more
> development on Orinoco USB than David Gibson does on Orinoco, the Orinoco
> USB is not going to be the development version. Besides, the drivers
> support different hardware, so there is no choice for users.

orinoco-exp will support (it already does, though it is not called
orinoco-exp jet) all the hardware that standard orinoco supports plus
ORiNOCO USB devices, maybe it could even be extended to support Prism2
USB devices.

Actually, orinoco-exp could be used as a test bed for monitor mode,
scanning, hermesap, ... and merge it back to the standard orinoco as it
probes to work right. For now it should be a test bed for USB support :)

> As far as I know, Orinoco USB devices are quite rare, so the pool of
> testers is going to be small compared to the standard Orinoco driver that
> supports Symbol and Intersil cards as well.

Not so rare, take a look at the statistics in alioth:

36 Downloads in 24hours, keep in mind that the W200 wireless module is
the default networking add-on for Compaq Evo series.

I have around 80 happy subscribers on the orinoco-usb-devel mailing
list already. And it didn't even get into the kernel jet.

> > Please comment, how much of that or what else needs to be done to get
> > it in the kernel?
> If you are going to create a separate driver, you should rename the
> module. I wouldn't bother with separate modules. Just link hermes,
> orinoco and orinoco_usb to one driver, say orinoco-usb.

No, I want to stay as similar to standard orinoco as possible to make
merging easier.

> You may also need to rename all files if you want the driver to live in
> drivers/net/wireless rather than in drivers/usb/net.

Yes, that was my plan.

> That's of course assumes that you want to use separate versions of
> hermes.c and orinoco.c. But maybe you want to share them with the Orinoco
> driver now or in the future? Then I'd like to know about your plans.

For now I plan to duplicate it all, so I can get my code in without
bothering standard orinoco, but I would like to merge as much as
possible in the future. I hope that having both versions side by side
will increase the mind share in finding a good way to do the merge.

And also get the testing of some adventurous PCI/PCMCIA users.

> > Oh, and since I am at it, I wouldn't mind cleaning kcompat.h for
> > inclusion in 2.4 kernels to make driver porting easier. I have also
> > been working in porting lirc so I could put it all together (the
> > kcompat.h stuff) for 2.4 inclusion.
> That's a separate and very interesting topic. It's good to encourage
> developers to write for the current development kernel, but on the other
> hand, if kcompat.h is shared between all drivers, changes in it (caused
> by further changes in 2.5.x API) would break drivers in the stable
> kernels.

Didn't think of that. But 2.5 API should be pretty frozen by now,
shouldn't it?

> Perhaps backported drivers should not share their compatibility code
> unless there is some kind of coordination between their maintainers.

But then you duplicate the effort times the number of independent
drivers. At least there could be a recommended kcompat.h header, even if
not in the kernel proper, so driver developers can just go get it when
they are ready to update their drivers, instead of having to updated it
themselfs. Maybe placing it in the Documentation directory would make
it clear that it should not be used directly but copied for each driver

--- Manuel Estrada Sainz <>
------------------------ <> -------------------
Let us have the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:36    [W:0.060 / U:3.992 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site