Re: Etiquette of getting a driver into the kernel

Re: Etiquette of getting a driver into the kernel

[Pete Zaitcev]

>[...] Some kind soul on the net mailed me a newer
> version, which does work a lot more reliably. The email address given for
> the original author (in the source) doesn't seem to answer requests like
> "is there a newer version of this driver", or "Is this driver GPL'd ?".
> 
>  Basically, I've a patch for it against 2.4.15, and I'm wondering how I
> should go about getting it into the kernel, so others can debug it for me :)

You must resolve the licensing issue first. Once you are
done, send it to linux-usb-devel@lists.sourceforge.net.
The USB subsystem has an active maintainer currently.

-- Pete

Re: Etiquette of getting a driver into the kernel

[John P. Looney]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

On Sat, Nov 24, 2001 at 01:46:08PM -0500, Pete Zaitcev mentioned:
> You must resolve the licensing issue first. Once you are
> done, send it to linux-usb-devel@lists.sourceforge.net.
> The USB subsystem has an active maintainer currently.

 Thanks. I don't think that'll happen. It turns out that the driver
maintainer doesn't want the driver circulated, as newer versions of the
device are usb-storage compliant, and don't need a specific driver. He
reckons it would confuse people. Ah well.

John

-- 
_______________________________________
John Looney             Chief Scientist
a n t e f a c t o     t: +353 1 8586004
www.antefacto.com     f: +353 1 8586014


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Etiquette of getting a driver into the kernel

[John P. Looney]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

 I've a Phison "usb multiple card reader". Nice little device, though I
think the driver isn't the best (block size of 1k when reading & writing
gets 80k/sec, block size of 32k gets 850k/sec).

 The device came with a driver for linux on a floppy, as a patch against
2.4.2. It needed a little beating to get it to compile, and it caused
not-a-few kernel panics. Some kind soul on the net mailed me a newer
version, which does work a lot more reliably. The email address given for
the original author (in the source) doesn't seem to answer requests like
"is there a newer version of this driver", or "Is this driver GPL'd ?".

 Basically, I've a patch for it against 2.4.15, and I'm wondering how I
should go about getting it into the kernel, so others can debug it for me :)

John

-- 
_______________________________________
John Looney             Chief Scientist
a n t e f a c t o     t: +353 1 8586004
www.antefacto.com     f: +353 1 8586014


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Etiquette of getting a driver into the kernel

[bert hubert]

On Fri, Nov 23, 2001 at 10:28:28AM +0000, John P. Looney wrote:

>  Basically, I've a patch for it against 2.4.15, and I'm wondering how I
> should go about getting it into the kernel, so others can debug it for me :)

It is both a social and a technical ritual, like a raindance. First you
start by removing the obviously ugly parts of your patch, and then continue
to polish it 'till it shines. Then you send a loving message to the relevant
subsystem maintainer, asking for his/her advice.

'How would you like to see this driver' is the question to ask. Mostly you
will then hear that you did everything wrong, that your tabstyle sucks, that
this would not survive 10 seconds on my 64G quad xeon and that it would be
far easier to modify driver x-y-z to support your hardware too, where x-y-z
is not in the least related to your problem.

This is the time to persist. What you are seeing is part of a necessary
ritual. Challenge the subsystem maintainer and show your respect by
following the saner parts of his message. Clean up your coding style, use
kernel infrastructure as suggested, heed arcane hints about locks that need
or to need to be held.

Resubmit and argue. Lobby. Document. Resubmit and argue. Keep sending patches. 

And in due time if everything is right, the subsystem maintainer will accept
your patch and feed it to Marcelo or Linus.

Some maintainers are more stubborn then others, by the way. But always keep
in mind that code is king and that it may take a while to bang it into
shape.

Regards,

bert hubert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
Trilab                                 The Technology People
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet