Re: Free Linux Driver Development!

[Erik Mouw]

On Tue, Jan 30, 2007 at 05:23:44PM -0500, Lennart Sorensen wrote:
> On Tue, Jan 30, 2007 at 05:12:31PM -0500, Jeff Garzik wrote:
> > You mean the bcm43xx wireless driver that's been upstream for months?
> 
> 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.

I can't remember that kind of corruption ever being reported to the
bcm43xx-dev mailing list.

>  If the bios on the laptop in question would let me change the
> minipci card I would.  To something with a ralink on it.

You could use a CardBus or USB card.

> 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.

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Jesper Juhl]

On 01/02/07, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:

On 31 Jan 2007 11:08:14 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
> >
> > 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
> > kernel development never to be seen again?

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
please don't add me to MAINTAINERS as floppy diver maintainer.

:)

> 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.

* 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.



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

--
Jesper Juhl <[EMAIL PROTECTED]>
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Bartlomiej Zolnierkiewicz]

On 31 Jan 2007 11:08:14 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:

Greg KH <[EMAIL PROTECTED]> writes:
>
> 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
> kernel development never to be seen again?


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
please don't add me to MAINTAINERS as floppy diver maintainer.

:)


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.


* 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jan Engelhardt]

On Jan 31 2007 18:59, Lee Revell wrote:
> On 1/31/07, Theodore Tso <[EMAIL PROTECTED]> wrote:
>>
>> More specifically, Dave said that it "seemed rude" to just take the
>> driver and send updates, but maybe the best way of dealing with
>> out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
>> kind of spec release, and just have someone in the community forcibly
>> take the code, fix it up, and then get it merged.
>
> But if the maintainer is unwilling to work with the kernel developers,
> the driver won't get bugfixes or updates for new hardware.

Talk about util-linux and rpm, whose maintainers were/are unwilling to give
back the project to those who would really like to work on it.

At least I don't differentiate between userspace and kernelspace when it
comes to "hijacking projects back for the better". foobar is left where it
is, and is commonly forked into foobar-ng. It's just naming. Just pull in
lirc and tag it lirc-ng.


Jan
-- 
ft: http://freshmeat.net/p/chaostables/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jeff Garzik]

Lee Revell wrote:

On 1/31/07, Mark Lord <[EMAIL PROTECTED]> wrote:

I believe a BIG reason why lots of open-source drivers are out-of-tree
right now, is because lkml is perceived as being wayy too fussy
and petty about 80-column lines, brackets, etc.. for new code.

It's just not worth the effort/abuse for many maintainers to pursue it.


That seems like the easy part - it seems like anyone bright enough to
write a working Linux driver would be good enough with their editor or
perl or bash to knock that out in 10 minutes.



Or simply running it through scripts/Lindent, which fixes 97% of all 
issues automatically.  The remaining 3% become fixing Lindent's lack of 
C99 knowledge, etc.


Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Trent Waddington]

On 2/1/07, Nicolas Mailhot <[EMAIL PROTECTED]> wrote:

Not all of them.
It seems it's kosher to rewrite a corp GPL driver but not a "community" one.


As I said, Greg didn't say it was rude to write a new driver without consulting
the author of an existing driver.. corp *or* community.. so who said
it was?  You can rewrite whatever you feel like rewriting.  Greg was
talking about what is polite usage of someone elses code.  In
particular, doing stuff they've specifically said they don't want you
to do with it is rude.


From a practical standpoint it makes sense, I think: the guy who wrote

the code is often the best person to maintain it, so don't piss him
off.  If you want to rewrite it, then you would be the guy offering to
maintain it..

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Nicolas Mailhot]

Le Jeu 1 février 2007 10:03, Trent Waddington a écrit :
> On 2/1/07, Nicolas Mailhot <[EMAIL PROTECTED]> wrote:
>> Well, reengineering nvidia/ati DRM is rude to ati/nvidia, so was
>> creating
>> tigon3, so was rewriting from scratch the GPL drivers some ATA vendors
>> published in the past, so was spurning the SATA/SAS stack adaptec
>> offered...
>
> It is rude, but they're writing proprietary modules, and *that* is
> rude, so screw 'em.

Not all of them.
It seems it's kosher to rewrite a corp GPL driver but not a "community" one.

And as others noted blocking merging is rude too.

-- 
Nicolas Mailhot

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Trent Waddington]

On 2/1/07, Nicolas Mailhot <[EMAIL PROTECTED]> wrote:

Well, reengineering nvidia/ati DRM is rude to ati/nvidia, so was creating
tigon3, so was rewriting from scratch the GPL drivers some ATA vendors
published in the past, so was spurning the SATA/SAS stack adaptec
offered...


It is rude, but they're writing proprietary modules, and *that* is
rude, so screw 'em.


If the answer is no, then there is a big pile of device documentation (in
the form of source code) waiting to be used.


Greg didn't say it was rude to write a new driver without consulting
the author of an existing driver.. just that taking their code without
asking them if they would prefer to put it in the tree themselves is a
bit rude.

Admittably there is a point where this whole politeness thing could
get out of hand, but I think a good rule of thumb is to ask the author
if they're ok with you doing X with their code, and if they say no,
well, try to be gracious about it.  Not that they *should* say no,
this *is* free software after all.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Nicolas Mailhot]

Le Jeu 1 février 2007 00:44, Greg KH a écrit :
> On Wed, Jan 31, 2007 at 06:00:15PM -0500, Theodore Tso wrote:

>> More specifically, Dave said that it "seemed rude" to just take the
>> driver and send updates, but maybe the best way of dealing with
>> out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
>> kind of spec release, and just have someone in the community forcibly
>> take the code, fix it up, and then get it merged.  Maybe it's being
>> "rude", but so is not responding to requests to get it merged.
>
> No, I'm going by Linus's rule here, if a person doesn't want their code
> in the kernel tree, then I'm not going to forcefully put it there.
> That's just being rude.

Well, reengineering nvidia/ati DRM is rude to ati/nvidia, so was creating
tigon3, so was rewriting from scratch the GPL drivers some ATA vendors
published in the past, so was spurning the SATA/SAS stack adaptec
offered...

Does politeness extend to accepting some devices will never see in-tree
drivers because someone wrote a GPL out-of-tree driver first (and refuses
to push it)? People are more squeamish about using an out-of-tree driver
as reference instead of leaked specs or rev-engeneered windows drivers
(despite out-of-tree drivers being under the GPL ie with authorisation do
do whatever people want with the code).

If the answer is no, then there is a big pile of device documentation (in
the form of source code) waiting to be used.

-- 
Nicolas Mailhot

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Nicolas Mailhot]

Le Jeu 1 février 2007 00:44, Greg KH a écrit :
 On Wed, Jan 31, 2007 at 06:00:15PM -0500, Theodore Tso wrote:

 More specifically, Dave said that it seemed rude to just take the
 driver and send updates, but maybe the best way of dealing with
 out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
 kind of spec release, and just have someone in the community forcibly
 take the code, fix it up, and then get it merged.  Maybe it's being
 rude, but so is not responding to requests to get it merged.

 No, I'm going by Linus's rule here, if a person doesn't want their code
 in the kernel tree, then I'm not going to forcefully put it there.
 That's just being rude.

Well, reengineering nvidia/ati DRM is rude to ati/nvidia, so was creating
tigon3, so was rewriting from scratch the GPL drivers some ATA vendors
published in the past, so was spurning the SATA/SAS stack adaptec
offered...

Does politeness extend to accepting some devices will never see in-tree
drivers because someone wrote a GPL out-of-tree driver first (and refuses
to push it)? People are more squeamish about using an out-of-tree driver
as reference instead of leaked specs or rev-engeneered windows drivers
(despite out-of-tree drivers being under the GPL ie with authorisation do
do whatever people want with the code).

If the answer is no, then there is a big pile of device documentation (in
the form of source code) waiting to be used.

-- 
Nicolas Mailhot

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Trent Waddington]

On 2/1/07, Nicolas Mailhot [EMAIL PROTECTED] wrote:

Well, reengineering nvidia/ati DRM is rude to ati/nvidia, so was creating
tigon3, so was rewriting from scratch the GPL drivers some ATA vendors
published in the past, so was spurning the SATA/SAS stack adaptec
offered...


It is rude, but they're writing proprietary modules, and *that* is
rude, so screw 'em.


If the answer is no, then there is a big pile of device documentation (in
the form of source code) waiting to be used.


Greg didn't say it was rude to write a new driver without consulting
the author of an existing driver.. just that taking their code without
asking them if they would prefer to put it in the tree themselves is a
bit rude.

Admittably there is a point where this whole politeness thing could
get out of hand, but I think a good rule of thumb is to ask the author
if they're ok with you doing X with their code, and if they say no,
well, try to be gracious about it.  Not that they *should* say no,
this *is* free software after all.

Trent
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Nicolas Mailhot]

Le Jeu 1 février 2007 10:03, Trent Waddington a écrit :
 On 2/1/07, Nicolas Mailhot [EMAIL PROTECTED] wrote:
 Well, reengineering nvidia/ati DRM is rude to ati/nvidia, so was
 creating
 tigon3, so was rewriting from scratch the GPL drivers some ATA vendors
 published in the past, so was spurning the SATA/SAS stack adaptec
 offered...

 It is rude, but they're writing proprietary modules, and *that* is
 rude, so screw 'em.

Not all of them.
It seems it's kosher to rewrite a corp GPL driver but not a community one.

And as others noted blocking merging is rude too.

-- 
Nicolas Mailhot

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Trent Waddington]

On 2/1/07, Nicolas Mailhot [EMAIL PROTECTED] wrote:

Not all of them.
It seems it's kosher to rewrite a corp GPL driver but not a community one.


As I said, Greg didn't say it was rude to write a new driver without consulting
the author of an existing driver.. corp *or* community.. so who said
it was?  You can rewrite whatever you feel like rewriting.  Greg was
talking about what is polite usage of someone elses code.  In
particular, doing stuff they've specifically said they don't want you
to do with it is rude.


From a practical standpoint it makes sense, I think: the guy who wrote

the code is often the best person to maintain it, so don't piss him
off.  If you want to rewrite it, then you would be the guy offering to
maintain it..

Trent
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jeff Garzik]

Lee Revell wrote:

On 1/31/07, Mark Lord [EMAIL PROTECTED] wrote:

I believe a BIG reason why lots of open-source drivers are out-of-tree
right now, is because lkml is perceived as being wayy too fussy
and petty about 80-column lines, brackets, etc.. for new code.

It's just not worth the effort/abuse for many maintainers to pursue it.


That seems like the easy part - it seems like anyone bright enough to
write a working Linux driver would be good enough with their editor or
perl or bash to knock that out in 10 minutes.



Or simply running it through scripts/Lindent, which fixes 97% of all 
issues automatically.  The remaining 3% become fixing Lindent's lack of 
C99 knowledge, etc.


Jeff


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jan Engelhardt]

On Jan 31 2007 18:59, Lee Revell wrote:
 On 1/31/07, Theodore Tso [EMAIL PROTECTED] wrote:

 More specifically, Dave said that it seemed rude to just take the
 driver and send updates, but maybe the best way of dealing with
 out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
 kind of spec release, and just have someone in the community forcibly
 take the code, fix it up, and then get it merged.

 But if the maintainer is unwilling to work with the kernel developers,
 the driver won't get bugfixes or updates for new hardware.

Talk about util-linux and rpm, whose maintainers were/are unwilling to give
back the project to those who would really like to work on it.

At least I don't differentiate between userspace and kernelspace when it
comes to hijacking projects back for the better. foobar is left where it
is, and is commonly forked into foobar-ng. It's just naming. Just pull in
lirc and tag it lirc-ng.


Jan
-- 
ft: http://freshmeat.net/p/chaostables/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Bartlomiej Zolnierkiewicz]

On 31 Jan 2007 11:08:14 +0100, Andi Kleen [EMAIL PROTECTED] wrote:

Greg KH [EMAIL PROTECTED] writes:

 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
 kernel development never to be seen again?


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
please don't add me to MAINTAINERS as floppy diver maintainer.

:)


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.


* 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Jesper Juhl]

On 01/02/07, Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:

On 31 Jan 2007 11:08:14 +0100, Andi Kleen [EMAIL PROTECTED] wrote:
 Greg KH [EMAIL PROTECTED] writes:
 
  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
  kernel development never to be seen again?

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
please don't add me to MAINTAINERS as floppy diver maintainer.

:)

 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.

* 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.



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

--
Jesper Juhl [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Erik Mouw]

On Tue, Jan 30, 2007 at 05:23:44PM -0500, Lennart Sorensen wrote:
 On Tue, Jan 30, 2007 at 05:12:31PM -0500, Jeff Garzik wrote:
  You mean the bcm43xx wireless driver that's been upstream for months?
 
 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.

I can't remember that kind of corruption ever being reported to the
bcm43xx-dev mailing list.

  If the bios on the laptop in question would let me change the
 minipci card I would.  To something with a ralink on it.

You could use a CardBus or USB card.

 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.

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Sergei Organov]

Greg KH [EMAIL PROTECTED] writes:

 On Wed, Jan 31, 2007 at 08:41:03PM +0300, Sergei Organov wrote:
 Greg KH [EMAIL PROTECTED] writes:
 [...]
  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.
 
 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.

 Do you have a pointer to the driver source anywhere?

Sure, here it is:

http://www.quatech.com/ManualsDriversFirmware/Communication/serial-qtpcmcia-1.23.tar.gz

 I suggest just posting it as a patch to the tree as documented in
 Documentation/SubmittingPatches and seeing how that goes.

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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Alan]

 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.

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Lennart Sorensen]

On Thu, Feb 01, 2007 at 02:59:03PM +0100, Erik Mouw wrote:
 I can't remember that kind of corruption ever being reported to the
 bcm43xx-dev mailing list.

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
802.11g only though which may have been a problem).

 You could use a CardBus or USB card.

I just don't like things sticking out that are breakable.

 So are the bcm43xx maintainers.

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Michael Buesch]

On Tuesday 30 January 2007 23:23, Lennart Sorensen wrote:
 On Tue, Jan 30, 2007 at 05:12:31PM -0500, Jeff Garzik wrote:
  You mean the bcm43xx wireless driver that's been upstream for months?
 
 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

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.

But prove me wrong and show the code that writes to eeprom. :)

 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.

Are you suggesting that bcm43xx people don't, or what?
Are you living on another planet than me? Mine is called Earth.

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Lennart Sorensen]

On Thu, Feb 01, 2007 at 04:46:38PM +0100, Michael Buesch wrote:
 Nah, why do you think it will screw up the eeprom?
 Did you try to completely power off the machine before rebooting
 into windows?

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
state of the chip after linux had poked it.

 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.

Well it must have just been the state of some registers then.

 But prove me wrong and show the code that writes to eeprom. :)

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
liking WPA encryption yet.

 Are you suggesting that bcm43xx people don't, or what?

I have just mainly seen messages about devicescape from the ralink
driver.

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

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Al Viro]

On Thu, Feb 01, 2007 at 02:12:22PM +0100, Bartlomiej Zolnierkiewicz wrote:
 On 31 Jan 2007 11:08:14 +0100, Andi Kleen [EMAIL PROTECTED] wrote:
 Greg KH [EMAIL PROTECTED] writes:
 
  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
  kernel development never to be seen again?
 
 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
 
* piece of shit FSM buried in various continuation methods.
* one hell of a problem with regression testing.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: QUATECH driver (was Free Linux Driver Development!)

[Sergei Organov]

Alan [EMAIL PROTECTED] writes:
 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.

 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.

OK, I'll try to recover what I did (as I've dropped the change after I
saw it can't do 460,800), and submit the patch.

 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.

I expect it'll be rather hard for me to test the changes then, as my IBM
ThinkPad T43 suffers from kernel IDE/SATA/PATA issues, and running every
new kernel was a big pain so far (it currently runs 2.6.16.8) :(

-- Sergei.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Michael K. Edwards]

On 2/1/07, Lennart Sorensen [EMAIL PROTECTED] wrote:

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.


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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Erik Mouw]

On Thu, Feb 01, 2007 at 09:45:06AM -0500, Lennart Sorensen wrote:
 On Thu, Feb 01, 2007 at 02:59:03PM +0100, Erik Mouw wrote:
  I can't remember that kind of corruption ever being reported to the
  bcm43xx-dev mailing list.
 
 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
 802.11g only though which may have been a problem).

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
message or so.

 Excellent.  Is the bcm43xx planning to get 802.11g mode working at some
 point?

Most certainly, the plans are there for quite some time, but...

  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?

... 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
supported cards.

  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. :)

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!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Christoph Bartelmus]

On Wed, 31 Jan 2007 21:20:06 +0100 Greg KH wrote:

 On Wed, Jan 31, 2007 at 02:06:32PM +0100, Nicolas Mailhot wrote:
 I'd really love if the same offer was extended to GPL out-of-tree
 driver trees.

 This kind of offer has _always_ been there for out-of-tree GPL
 drivers. I have contacted many different groups and driver authors
 over the years to offer my help in trying to get their code into the
 mainline kernel.

 Some take me up on the offer, others ignore it, and still others
 activly refuse to do so, saying they want to stay out-of-the tree
 (lirc is one of these examples...)

I'm the LIRC maintainer. I don't know what let's you think LIRC wants to  
stay out-of-the-tree.

I just made clear that I don't have the time to do the merging of LIRC  
drivers to the kernel myself. In fact a lot of work still needs to be  
done before LIRC drivers are ready to be included into the kernel.  
Spreading the impression that LIRC refuses to work with kernel  
developers is not particularly helpful...

Any help welcome.

Christoph

Pls Cc me on replies, I'm not subscribed.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Greg KH]

On Wed, Jan 31, 2007 at 01:37:58PM -0500, Bob Copeland wrote:
> >Putting the "codingstyle" control aside, often it's because things look
> >too hackish.
> 
> 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?

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Greg KH]

On Wed, Jan 31, 2007 at 10:15:20PM +0100, Nicolas Mailhot wrote:
> Le mercredi 31 janvier 2007 ?? 12:12 -0800, Greg KH a ??crit :
> > On Wed, Jan 31, 2007 at 02:06:32PM +0100, Nicolas Mailhot wrote:
> 
> [Reordering for the sake of argument]
> 
> > > There are many out-of-tree drivers (ivtv, lirc, various webcam 
> > > drivers,
> > > enhanced USB keyboard handlers...) with merging not planified or taking
> > > ages.
> > 
> > See my above comment about lirc.  As for the others, everyone knows
> > where we are at, and what the critera is for getting their code into the
> > tree, so it's not like we are hiding anywhere :)
> 
> The perception of many out-of-tree projects is "if I try to get in-tree
> I'll be submitted to vicious review, and I'll have to fix the code my
> myself, and that's assuming someone bothers to review it at all". What
> you've just wrote is no different:
> 
> > we will gladly take any
> > currently out-of-the-tree drivers into mainline, as long as they follow
> > our rules and coding style issues, please do so.
> 
> In other words, getting an out-of-tree driver in is a major unrewarding
> work commitment for its author (especially considering that if he was
> familiar with good kernel coding, chances are he'd have worked in-tree
> from the start, with an experimental driver)
> 
> Contrast it with "give us a partial NDAed spec and we'll write a driver
> from scratch for you".

Sometimes doing a driver from scratch is much less effort than trying to
reengineer a badly designed and written driver to get it into the kernel
tree.

Also, almost all out-of-tree driver authors know what they need to do to
get the code into the kernel tree.

Again, I've offered my services to many such groups in the past.  A lot
of them do get into the tree, and I'll continue to offer my services to
do this.

But again, that's not the main point of this announcement sorry.

> You're asking way more of people that have a lot less resources than
> hardware manufacturers. Many of those projects did try to get in-tree at
> least once before giving up.

Persistance is everything :)

> Meanwhile you're asking for specs of hardware no Linux user has, because
> no form of Linux support ever existed. This is a strange use of
> resources.

You are free to use your resources however you wish, and mine how I
wish.  Would you want it to be any other way?  :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Greg KH]

On Wed, Jan 31, 2007 at 08:41:03PM +0300, Sergei Organov wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
> [...]
> >> 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.
> 
> 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:
> 
> 
> 
> please contact me, and I'll be willing to help in testing as I have the
> hardware.

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Greg KH]

On Thu, Feb 01, 2007 at 10:07:53AM +1000, Trent Waddington wrote:
> On 2/1/07, Greg KH <[EMAIL PROTECTED]> wrote:
> >No, I'm going by Linus's rule here, if a person doesn't want their code
> >in the kernel tree, then I'm not going to forcefully put it there.
> >That's just being rude.
> 
> Makes sense when you put it that way.  However, perhaps an offer to
> take over the maintenance of the driver when incorporating it into the
> kernel tree would be welcomed more readily by some people than just
> "so when ya gunna merge?" style badgering.

You would be supprised, not all people welcome this.  Believe me, I've
tried...

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Lee Revell]

On 1/31/07, Mark Lord <[EMAIL PROTECTED]> wrote:

Randy Dunlap wrote:
> On Wed, 31 Jan 2007 18:00:15 -0500 Theodore Tso wrote:
..
>> More specifically, Dave said that it "seemed rude" to just take the
>> driver and send updates, but maybe the best way of dealing with
>> out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
>> kind of spec release, and just have someone in the community forcibly
>> take the code, fix it up, and then get it merged.  Maybe it's being
>> "rude", but so is not responding to requests to get it merged.

I believe a BIG reason why lots of open-source drivers are out-of-tree
right now, is because lkml is perceived as being wayy too fussy
and petty about 80-column lines, brackets, etc.. for new code.

It's just not worth the effort/abuse for many maintainers to pursue it.


That seems like the easy part - it seems like anyone bright enough to
write a working Linux driver would be good enough with their editor or
perl or bash to knock that out in 10 minutes.

I would think rules like "no new ioctls" and "no new /proc entries",
that might seem arbitrary to one who doesn't follow kernel
development, plus the occasionally insulting code reviewer, would be
more of an issue.

Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Mark Lord]

Randy Dunlap wrote:

On Wed, 31 Jan 2007 18:00:15 -0500 Theodore Tso wrote:

..

More specifically, Dave said that it "seemed rude" to just take the
driver and send updates, but maybe the best way of dealing with
out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
kind of spec release, and just have someone in the community forcibly
take the code, fix it up, and then get it merged.  Maybe it's being
"rude", but so is not responding to requests to get it merged.


I believe a BIG reason why lots of open-source drivers are out-of-tree
right now, is because lkml is perceived as being wayy too fussy
and petty about 80-column lines, brackets, etc.. for new code.

It's just not worth the effort/abuse for many maintainers to pursue it.


and I'm quite willing to apply Doc/CodingStyle to driver source file(s).
That's as easy as replying to an email with comments about it.


That's a very decent offer, and exactly what's needed here!

Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Trent Waddington]

On 2/1/07, Greg KH <[EMAIL PROTECTED]> wrote:

No, I'm going by Linus's rule here, if a person doesn't want their code
in the kernel tree, then I'm not going to forcefully put it there.
That's just being rude.


Makes sense when you put it that way.  However, perhaps an offer to
take over the maintenance of the driver when incorporating it into the
kernel tree would be welcomed more readily by some people than just
"so when ya gunna merge?" style badgering.

Not that I'm not a fan of badgering.

Trent
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Lee Revell]

On 1/31/07, Theodore Tso <[EMAIL PROTECTED]> wrote:

More specifically, Dave said that it "seemed rude" to just take the
driver and send updates, but maybe the best way of dealing with
out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
kind of spec release, and just have someone in the community forcibly
take the code, fix it up, and then get it merged.


But if the maintainer is unwilling to work with the kernel developers,
the driver won't get bugfixes or updates for new hardware.

Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Greg KH]

On Wed, Jan 31, 2007 at 06:00:15PM -0500, Theodore Tso wrote:
> On Wed, Jan 31, 2007 at 12:12:58PM -0800, Greg KH wrote:
> > 
> > This kind of offer has _always_ been there for out-of-tree GPL drivers.
> > I have contacted many different groups and driver authors over the years
> > to offer my help in trying to get their code into the mainline kernel.
> > 
> > Some take me up on the offer, others ignore it, and still others activly
> > refuse to do so, saying they want to stay out-of-the tree (lirc is one
> > of these examples...)
> 
> I think the point is that if we are offering free development effort
> to write a driver which goes into mainline, maybe we should provide
> more than "providing rules and guidelines" so that people can spend
> engineering $$$ to get the driver into mainline.   

I do that a lot for a lot of different drivers and companies today.  So
do other people in the community.

But again, if you wish to publicize this, that's great, but it wasn't
the main goal of my announcement.

> More specifically, Dave said that it "seemed rude" to just take the
> driver and send updates, but maybe the best way of dealing with
> out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
> kind of spec release, and just have someone in the community forcibly
> take the code, fix it up, and then get it merged.  Maybe it's being
> "rude", but so is not responding to requests to get it merged.

No, I'm going by Linus's rule here, if a person doesn't want their code
in the kernel tree, then I'm not going to forcefully put it there.
That's just being rude.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Randy Dunlap]

On Wed, 31 Jan 2007 18:00:15 -0500 Theodore Tso wrote:

> On Wed, Jan 31, 2007 at 12:12:58PM -0800, Greg KH wrote:
> > 
> > This kind of offer has _always_ been there for out-of-tree GPL drivers.
> > I have contacted many different groups and driver authors over the years
> > to offer my help in trying to get their code into the mainline kernel.
> > 
> > Some take me up on the offer, others ignore it, and still others activly
> > refuse to do so, saying they want to stay out-of-the tree (lirc is one
> > of these examples...)
> 
> I think the point is that if we are offering free development effort
> to write a driver which goes into mainline, maybe we should provide
> more than "providing rules and guidelines" so that people can spend
> engineering $$$ to get the driver into mainline.   
> 
> More specifically, Dave said that it "seemed rude" to just take the
> driver and send updates, but maybe the best way of dealing with
> out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
> kind of spec release, and just have someone in the community forcibly
> take the code, fix it up, and then get it merged.  Maybe it's being
> "rude", but so is not responding to requests to get it merged.


and I'm quite willing to apply Doc/CodingStyle to driver source file(s).
That's as easy as replying to an email with comments about it.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Theodore Tso]

On Wed, Jan 31, 2007 at 12:12:58PM -0800, Greg KH wrote:
> 
> This kind of offer has _always_ been there for out-of-tree GPL drivers.
> I have contacted many different groups and driver authors over the years
> to offer my help in trying to get their code into the mainline kernel.
> 
> Some take me up on the offer, others ignore it, and still others activly
> refuse to do so, saying they want to stay out-of-the tree (lirc is one
> of these examples...)

I think the point is that if we are offering free development effort
to write a driver which goes into mainline, maybe we should provide
more than "providing rules and guidelines" so that people can spend
engineering $$$ to get the driver into mainline.   

More specifically, Dave said that it "seemed rude" to just take the
driver and send updates, but maybe the best way of dealing with
out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
kind of spec release, and just have someone in the community forcibly
take the code, fix it up, and then get it merged.  Maybe it's being
"rude", but so is not responding to requests to get it merged.

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Randy Dunlap]

On Wed, 31 Jan 2007 17:06:07 -0500 Dave Jones wrote:

> On Wed, Jan 31, 2007 at 12:12:58PM -0800, Greg Kroah-Hartman wrote:
> 
>  > > There are many out-of-tree drivers (ivtv, lirc, various webcam drivers,
>  > > enhanced USB keyboard handlers...) with merging not planified or taking
>  > > ages.
>  > 
>  > See my above comment about lirc.  As for the others, everyone knows
>  > where we are at, and what the critera is for getting their code into the
>  > tree, so it's not like we are hiding anywhere :)
> 
> The webcam situation has bugged me a few times.  I regularly get reports
> from our users that they buy some new ov5xx based camera, and the in-tree
> driver doesn't work.  The out of tree one is a huge delta, and even
> begat a separate driver for the later chips iirc.
> 
> I contacted the upstream author a number of times to find out why he
> stopped sending updates. No replies.   Just taking his driver and
> sending updates myself seemed kinda rude, but at the same time,
> users are losing out.

Yes, I've contacted him (or one of him :) several times also
since I own one of those not-in-tree webcams...  Always some holdup.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Dave Jones]

On Wed, Jan 31, 2007 at 12:12:58PM -0800, Greg Kroah-Hartman wrote:

 > > There are many out-of-tree drivers (ivtv, lirc, various webcam drivers,
 > > enhanced USB keyboard handlers...) with merging not planified or taking
 > > ages.
 > 
 > See my above comment about lirc.  As for the others, everyone knows
 > where we are at, and what the critera is for getting their code into the
 > tree, so it's not like we are hiding anywhere :)

The webcam situation has bugged me a few times.  I regularly get reports
from our users that they buy some new ov5xx based camera, and the in-tree
driver doesn't work.  The out of tree one is a huge delta, and even
begat a separate driver for the later chips iirc.

I contacted the upstream author a number of times to find out why he
stopped sending updates. No replies.   Just taking his driver and
sending updates myself seemed kinda rude, but at the same time,
users are losing out.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jan-Benedict Glaw]

On Wed, 2007-01-31 22:56:03 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 31, 2007 at 10:13:12PM +0100, Jan-Benedict Glaw wrote:
> > On Tue, 2007-01-30 21:23:34 +0100, Diego Calleja <[EMAIL PROTECTED]> wrote:
> > > El Tue, 30 Jan 2007 20:31:01 +0100 (MET), Jan Engelhardt <[EMAIL 
> > > PROTECTED]> escribió:
> > > > Don't they claim 50+? Already browsing 
> > > > ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-3.1 gives more than 2 
> > > > screenfuls [à 25].
> > > 
> > > 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
> > 
> > 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.
> 
> 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.

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

-- 
  Jan-Benedict Glaw  [EMAIL PROTECTED]  +49-172-7608481
Signature of:   The real problem with C++ for kernel modules is:
the second  : the language just sucks.
   -- Linus Torvalds


signature.asc
Description: Digital signature

Re: Free Linux Driver Development!

[Willy Tarreau]

Hi,

On Wed, Jan 31, 2007 at 10:13:12PM +0100, Jan-Benedict Glaw wrote:
> On Tue, 2007-01-30 21:23:34 +0100, Diego Calleja <[EMAIL PROTECTED]> wrote:
> > El Tue, 30 Jan 2007 20:31:01 +0100 (MET), Jan Engelhardt <[EMAIL 
> > PROTECTED]> escribió:
> > > Don't they claim 50+? Already browsing 
> > > ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-3.1 gives more than 2 
> > > screenfuls [à 25].
> > 
> > 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
> 
> 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.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Trent Waddington]

On 2/1/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:

That lists seems really outdata.

- RaLink has gpl drivers (SerialMonkey maintains a better version),
- Cisco IPSEC can be replaced by the userspace tool vpnc (as far as the VPN
  Concentrators I have to deal with),


It's a wiki[1], I invite everyone to fix the current information and
add any new binary-only modules they are aware of.

Trent

[1] that url again,
http://developer.osdl.org/dev/opendrivers/wiki/index.php/Binary_Kernel_Modules_List
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Jan-Benedict Glaw]

On Wed, 2007-01-31 19:24:54 +0100, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> 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

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

-- 
  Jan-Benedict Glaw  [EMAIL PROTECTED]  +49-172-7608481
Signature of: Alles wird gut! ...und heute wirds schon ein bißchen 
besser.
the second  :


signature.asc
Description: Digital signature

Re: Free Linux Driver Development!

[Jan-Benedict Glaw]

On Tue, 2007-01-30 21:23:34 +0100, Diego Calleja <[EMAIL PROTECTED]> wrote:
> El Tue, 30 Jan 2007 20:31:01 +0100 (MET), Jan Engelhardt <[EMAIL PROTECTED]> 
> escribió:
> > Don't they claim 50+? Already browsing 
> > ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-3.1 gives more than 2 
> > screenfuls [à 25].
> 
> 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

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

-- 
  Jan-Benedict Glaw  [EMAIL PROTECTED]  +49-172-7608481
Signature of:   http://www.eyrie.org/~eagle/faqs/questions.html
the second  :


signature.asc
Description: Digital signature

Re: Free Linux Driver Development!

[Jan Engelhardt]

On Jan 31 2007 11:54, Auke Kok wrote:
> Francois Romieu wrote:
>> Nicolas Mailhot <[EMAIL PROTECTED]> :
>> [...]
>> > incomplete NDAed documentation. If (as this offer implies) there are
>> > good
>> > driver authors waiting to do more drivering, why aren't those a
>> > priority?
>> 
>> So far nobody cared enough to maintain a list of said out-of-tree drivers.
>
> why not post this on the OSDL driver wiki [1]? There already is a list of
> 'binary kernel drivers'. It would seem a proper addition there.
>
> Cheers,
>
> Auke
>
> [1] http://developer.osdl.org/dev/opendrivers/wiki/index.php/Main_Page

That lists seems really outdata.

- RaLink has gpl drivers (SerialMonkey maintains a better version),
- Cisco IPSEC can be replaced by the userspace tool vpnc (as far as the VPN
  Concentrators I have to deal with),


Jan
-- 
ft: http://freshmeat.net/p/chaostables/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Nicolas Mailhot]

Le mercredi 31 janvier 2007 à 12:12 -0800, Greg KH a écrit :
> On Wed, Jan 31, 2007 at 02:06:32PM +0100, Nicolas Mailhot wrote:

[Reordering for the sake of argument]

> > There are many out-of-tree drivers (ivtv, lirc, various webcam 
> > drivers,
> > enhanced USB keyboard handlers...) with merging not planified or taking
> > ages.
> 
> See my above comment about lirc.  As for the others, everyone knows
> where we are at, and what the critera is for getting their code into the
> tree, so it's not like we are hiding anywhere :)

The perception of many out-of-tree projects is "if I try to get in-tree
I'll be submitted to vicious review, and I'll have to fix the code my
myself, and that's assuming someone bothers to review it at all". What
you've just wrote is no different:

> we will gladly take any
> currently out-of-the-tree drivers into mainline, as long as they follow
> our rules and coding style issues, please do so.

In other words, getting an out-of-tree driver in is a major unrewarding
work commitment for its author (especially considering that if he was
familiar with good kernel coding, chances are he'd have worked in-tree
from the start, with an experimental driver)

Contrast it with "give us a partial NDAed spec and we'll write a driver
from scratch for you".

You're asking way more of people that have a lot less resources than
hardware manufacturers. Many of those projects did try to get in-tree at
least once before giving up.

> > I'd really love if the same offer was extended to GPL out-of-tree driver
> > trees.
> 
> This kind of offer has _always_ been there for out-of-tree GPL drivers.
> I have contacted many different groups and driver authors over the years
> to offer my help in trying to get their code into the mainline kernel.
> 
> Some take me up on the offer, others ignore it, and still others activly
> refuse to do so, saying they want to stay out-of-the tree (lirc is one
> of these examples...)

And when resources were scarce respecting this kind of decision was the
right thing. But if there are enough resources for your offer, I
question letting whole classes of drivers we have documentation for (in
the form of code) out-of-tree (even if that means some less-than-amiable
forking).

Both the OLPC and the N800 have toy (webcam) video capabilities. The
logical next spec (next hardware generation) is stronger video with
remoting (someone will probably sell remote add-ons before).

Are they going to lack in-tree support just because the reference
framework is out-of-tree, and we respect its authors' wishes so much
nothing can happen till they change their mind ?

(And that's assuming they're dead-set on being out-of-tree. Like I wrote
before they're not getting the same deal you're offering to hardware
manufacturers)

Meanwhile you're asking for specs of hardware no Linux user has, because
no form of Linux support ever existed. This is a strange use of
resources.

Regards,

-- 
Nicolas Mailhot


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Free Linux Driver Development!

[Greg KH]

On Wed, Jan 31, 2007 at 02:06:32PM +0100, Nicolas Mailhot wrote:
> Hi,
> 
> I'd really love if the same offer was extended to GPL out-of-tree driver
> trees.

This kind of offer has _always_ been there for out-of-tree GPL drivers.
I have contacted many different groups and driver authors over the years
to offer my help in trying to get their code into the mainline kernel.

Some take me up on the offer, others ignore it, and still others activly
refuse to do so, saying they want to stay out-of-the tree (lirc is one
of these examples...)

> There are many out-of-tree drivers (ivtv, lirc, various webcam drivers,
> enhanced USB keyboard handlers...) with merging not planified or taking
> ages.

See my above comment about lirc.  As for the others, everyone knows
where we are at, and what the critera is for getting their code into the
tree, so it's not like we are hiding anywhere :)

But yes, if you wish to publicise the fact that we will gladly take any
currently out-of-the-tree drivers into mainline, as long as they follow
our rules and coding style issues, please do so.  But that wasn't the
main point to my post.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Nicolas Mailhot]

Le mercredi 31 janvier 2007 à 20:29 +0100, Francois Romieu a écrit :
> Nicolas Mailhot <[EMAIL PROTECTED]> :
> [...]
> > incomplete NDAed documentation. If (as this offer implies) there are good
> > driver authors waiting to do more drivering, why aren't those a priority?
> 
> So far nobody cared enough to maintain a list of said out-of-tree drivers.

While some out-of-tree drivers are niche & obscure lirc for example has
existed for years with tendrils in pretty much every single Linux video
app. I find it hard to believe people are "discovering" it today.

-- 
Nicolas Mailhot


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Free Linux Driver Development!

[Michael K. Edwards]

On 1/30/07, Kumar Gala <[EMAIL PROTECTED]> wrote:

Out of interest are you was this geared to any particular SoC's/
architectures?


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 MIT and the Ethernet folks did with
ARPA).  We tend to take for granted the legacy of interoperability
that comes from such head-knocking-together, especially when a new
generation of vendors doesn't play by the same rules.

In the absence of such a monopsonist, our best bet for encouraging
more openness, and someday even actual participation, from SoC people
may be to help them with the part that they do understand to be sunk
cost rather than competitive asset -- bringup efforts, workarounds for
buggy UARTs and EtherMACs and other bog-standard interfaces, and the
rest of arch/arm/mach-foo (or the MIPS/PPC equivalent).  Mainstream
that, so that their customers can actually evaluate how their
application code behaves on new toolchains and kernels (with stubs in
place of the hairier drivers), and you'll help SoC customers make the
case for open source drivers for the sexier bits.

Needless to say, uniting forces with the upstream maintainers of open
source embedded bootloaders and toolchain / userland build systems
would help too.  After the first six months of freedom from code
reviews, nobody really likes maintaining a fork.  But undoing a fork
can be a lot of work, especially when upstream is picky about code
quality; there has to be some quantifiable benefit to justify it.

In embedded space, power consumption, memory footprint, and maximum
latency are usually where the pain is perceived to be.  Even though it
would probably be more rational to rank interoperability, software
reliability, and portability to the next chip among or above these,
consumer electronics companies rarely think that way.  So if you want
to dangle a carrot in front of SoC vendors, you might try an
integration branch with OpPoint and RT/Preempt patches and guidance on
the CONFIG_EMBEDDED options.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Auke Kok]

Francois Romieu wrote:

Nicolas Mailhot <[EMAIL PROTECTED]> :
[...]

incomplete NDAed documentation. If (as this offer implies) there are good
driver authors waiting to do more drivering, why aren't those a priority?


So far nobody cared enough to maintain a list of said out-of-tree drivers.


why not post this on the OSDL driver wiki [1]? There already is a list of 
'binary kernel drivers'. It would seem a proper addition there.


Cheers,

Auke

[1] http://developer.osdl.org/dev/opendrivers/wiki/index.php/Main_Page
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Francois Romieu]

Nicolas Mailhot <[EMAIL PROTECTED]> :
[...]
> incomplete NDAed documentation. If (as this offer implies) there are good
> driver authors waiting to do more drivering, why aren't those a priority?

So far nobody cared enough to maintain a list of said out-of-tree drivers.

-- 
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Jan Engelhardt]

On Jan 31 2007 13:58, Lennart Sorensen wrote:
>On Wed, Jan 31, 2007 at 07:24:54PM +0100, Jan Engelhardt wrote:
>> 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.
>
>So what is wrong with the current floppy driver (other than being 120k
>of code apparently)?

>From my standpoint, nothing. Developers knowing it better might disagree.
(It looks a little ugly, but well, it worked last time I tried.)

>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

Do the special formats (entries 9, 12, 13, 16, 17 in floppy.c)
even cost something more than their line in that struct?

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

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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[alan]

On Wed, 31 Jan 2007, Jan Engelhardt wrote:



On Jan 31 2007 09:58, alan wrote:

On Wed, 31 Jan 2007, Jan Engelhardt wrote:

On Jan 30 2007 14:00, Roland Dreier wrote:


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.


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


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.


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.


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Lennart Sorensen]

On Wed, Jan 31, 2007 at 07:24:54PM +0100, Jan Engelhardt wrote:
> 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.

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Bob Copeland]

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


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Andrey Borzenkov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday 31 January 2007 15:49, Alan wrote:
> > Well, I have a long standing issue with pata_ali not detecting CD-ROM in
> > DMA mode. When I rarely watch DVD I rather boot into legacy IDE kernel
> > ...
>
> There is a general problem with some ATAPI devices and the probe logic
> currently. The old IDE code has some workarounds that the new libata
> layer doesn't yet do.
>

OK I hope to get chance to test new code someday ...

- -andrey
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFwOHiR6LMutpd94wRAltRAJ9eGY+ory798QPzPKvlMsiyy3iVZQCdHbJ7
BtUwkgxuPbi2jwwNqF46fMQ=
=ihjL
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jan Engelhardt]

On Jan 31 2007 09:58, alan wrote:
> On Wed, 31 Jan 2007, Jan Engelhardt wrote:
>> On Jan 30 2007 14:00, Roland Dreier wrote:
>> > 
>> > 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.
>> 
>> And ndiswrapper gives fire to just releasing the Windows one :(
>
> 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.

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
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Jan Engelhardt]

On Jan 31 2007 18:24, Adrian Bunk wrote:
>On Wed, Jan 31, 2007 at 11:08:14AM +0100, Andi Kleen wrote:
>> Greg KH <[EMAIL PROTECTED]> writes:
>> > 
>> > 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
>> > kernel development never to be seen again?
>> 
>> 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.
>>...
>
>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 
>supports...

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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[alan]

On Wed, 31 Jan 2007, Jan Engelhardt wrote:



On Jan 30 2007 14:00, Roland Dreier wrote:


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.


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


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jan Engelhardt]

On Jan 31 2007 08:34, David Hollis wrote:
>Conversely, I've seen many cases of drivers that are developed by the
>community, but kept out-of-kernel forever due to various reasons.  Some
>of them are due to the code quality and the developers not accepting the
>feedback to get the drivers into shape to be 'kernel worthy', sometimes
>it seems to be a lack of interest from the developers to merge upstream.
>Maybe because they think they would lose control or something?

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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jeff Garzik]

Jan Engelhardt wrote:

On Jan 30 2007 14:00, Roland Dreier wrote:

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.


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


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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jan Engelhardt]

On Jan 30 2007 14:00, Roland Dreier wrote:
>
>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.

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


Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Sergei Organov]

Greg KH <[EMAIL PROTECTED]> writes:
[...]
>> 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.

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:



please contact me, and I'll be willing to help in testing as I have the
hardware.

-- Sergei.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Adrian Bunk]

On Wed, Jan 31, 2007 at 11:08:14AM +0100, Andi Kleen wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
> > 
> > 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
> > kernel development never to be seen again?
> 
> 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.
>...

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 
supports...

> -Andi

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Alan]

> 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 :)

2.6.20-mm, although it can't do some things currently and the docs are
not really adequate.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Eric Sandeen]

Jeff Garzik wrote:
> Eric Sandeen wrote:
>> Jeff Garzik wrote:
>>> Roland Dreier wrote:
 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.
>> 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 :)
> 
> The driver is in libata-dev.git#upstream and queued for 2.6.21.
> 
>   Jeff

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

-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jeff Garzik]

Eric Sandeen wrote:

Jeff Garzik wrote:

Roland Dreier wrote:

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.


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 :)


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

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Eric Sandeen]

Jeff Garzik wrote:
> Roland Dreier wrote:
>> 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.

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Martin Seidl]

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

Andi Kleen wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>> 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
>> kernel development never to be seen again?
> 
> 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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[David Hollis]

On Tue, 2007-01-30 at 17:41 -0500, Jeff Garzik wrote:
> 
> 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 

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 to work quite
well on x86 and x86_64, but big-endian systems seem to show some issues
which are being worked out.  The endian-issues drive me mad since I
don't have access to any big-endian systems and have little experience
with it but I'm determined to get them resolved.  For a vendor, they
likely would care less if it doesn't work on big-endian.  If it works on
Windows, that's all that matters.  

The driver has been upstream for 3+ years or so and is included in all
distros that I'm aware of so for most people, they can go out to
BestBuy, buy the device and plug it into their Linux box and it just
works, and that is what we all want in the end.

Conversely, I've seen many cases of drivers that are developed by the
community, but kept out-of-kernel forever due to various reasons.  Some
of them are due to the code quality and the developers not accepting the
feedback to get the drivers into shape to be 'kernel worthy', sometimes
it seems to be a lack of interest from the developers to merge upstream.
Maybe because they think they would lose control or something?
Sometimes it may just be that they don't realize that they can do that.
Thankfully, these tend to be somewhat fringe devices though all would
benefit at their being upstream to make everyones lives easier.


-- 
David Hollis <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Nicolas Mailhot]

Hi,

I'd really love if the same offer was extended to GPL out-of-tree driver
trees.

There are many out-of-tree drivers (ivtv, lirc, various webcam drivers,
enhanced USB keyboard handlers...) with merging not planified or taking
ages.

The associated hardware is useful enough someone wrote a driver.
There is "documentation" in the form of a working driver.
Sometimes there are already many FLOSS apps writen that depend on them.

Yet they languish out-of-tree, effectively sterilizing alternative efforts
just because people know they exist. Someone wrote an howto on how to plug
them in an ancient kernel, and that's good enough to remove a lot of the
merging incentive.

The common wisdom seems to be their authors will hammer LKML hard enough
the driver will eventually be merged. But these authors:
- get set in their ways like any human being
- usually put new features first and merging last
- may have decided merging was too much work
- may be struggling to do it alone
- may have asked LKML about merging once, got ignored/refused (for good,
bad, or obsolete reasons), and decided to spend their time on more
constructive work

So there are many reasons why merging will not happen as things stand.

These drivers are in many ways every bit as harmful as closed binary blobs
(making users miserable, killing alternatives, being a major reason old
kernel binaries get used long after security problems were identified and
fixed, etc). Merging/reworking them is easier than starting from
incomplete NDAed documentation. If (as this offer implies) there are good
driver authors waiting to do more drivering, why aren't those a priority?

As a side effect, cleaning up our own GPL community mess would help
convince hardware manufacturers working within the main kernel is the
right workable solution.

Regards,

-- 
Nicolas Mailhot

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Alan]

> Well, I have a long standing issue with pata_ali not detecting CD-ROM in DMA
> mode. When I rarely watch DVD I rather boot into legacy IDE kernel ...

There is a general problem with some ATAPI devices and the probe logic
currently. The old IDE code has some workarounds that the new libata
layer doesn't yet do.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Jesper Juhl]

On 31/01/07, Trent Waddington <[EMAIL PROTECTED]> wrote:

On 1/31/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> Sounds like a fun little project. I'll bite.

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.


Sure. Will do. Thanks.

--
Jesper Juhl <[EMAIL PROTECTED]>
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Trent Waddington]

On 1/31/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:

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


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Jesper Juhl]

On 31 Jan 2007 11:08:14 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:

Greg KH <[EMAIL PROTECTED]> writes:
>
> 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
> kernel development never to be seen again?

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)


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

--
Jesper Juhl <[EMAIL PROTECTED]>
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Rewriting floppy.c was Re: Free Linux Driver Development!

[Andi Kleen]

Greg KH <[EMAIL PROTECTED]> writes:
> 
> 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
> kernel development never to be seen again?

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Rewriting floppy.c was Re: Free Linux Driver Development!

[Andi Kleen]

Greg KH [EMAIL PROTECTED] writes:
 
 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
 kernel development never to be seen again?

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Jesper Juhl]

On 31 Jan 2007 11:08:14 +0100, Andi Kleen [EMAIL PROTECTED] wrote:

Greg KH [EMAIL PROTECTED] writes:

 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
 kernel development never to be seen again?

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)


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

--
Jesper Juhl [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Trent Waddington]

On 1/31/07, Jesper Juhl [EMAIL PROTECTED] wrote:

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


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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Jesper Juhl]

On 31/01/07, Trent Waddington [EMAIL PROTECTED] wrote:

On 1/31/07, Jesper Juhl [EMAIL PROTECTED] wrote:
 Sounds like a fun little project. I'll bite.

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.


Sure. Will do. Thanks.

--
Jesper Juhl [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Alan]

 Well, I have a long standing issue with pata_ali not detecting CD-ROM in DMA
 mode. When I rarely watch DVD I rather boot into legacy IDE kernel ...

There is a general problem with some ATAPI devices and the probe logic
currently. The old IDE code has some workarounds that the new libata
layer doesn't yet do.

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Nicolas Mailhot]

Hi,

I'd really love if the same offer was extended to GPL out-of-tree driver
trees.

There are many out-of-tree drivers (ivtv, lirc, various webcam drivers,
enhanced USB keyboard handlers...) with merging not planified or taking
ages.

The associated hardware is useful enough someone wrote a driver.
There is documentation in the form of a working driver.
Sometimes there are already many FLOSS apps writen that depend on them.

Yet they languish out-of-tree, effectively sterilizing alternative efforts
just because people know they exist. Someone wrote an howto on how to plug
them in an ancient kernel, and that's good enough to remove a lot of the
merging incentive.

The common wisdom seems to be their authors will hammer LKML hard enough
the driver will eventually be merged. But these authors:
- get set in their ways like any human being
- usually put new features first and merging last
- may have decided merging was too much work
- may be struggling to do it alone
- may have asked LKML about merging once, got ignored/refused (for good,
bad, or obsolete reasons), and decided to spend their time on more
constructive work

So there are many reasons why merging will not happen as things stand.

These drivers are in many ways every bit as harmful as closed binary blobs
(making users miserable, killing alternatives, being a major reason old
kernel binaries get used long after security problems were identified and
fixed, etc). Merging/reworking them is easier than starting from
incomplete NDAed documentation. If (as this offer implies) there are good
driver authors waiting to do more drivering, why aren't those a priority?

As a side effect, cleaning up our own GPL community mess would help
convince hardware manufacturers working within the main kernel is the
right workable solution.

Regards,

-- 
Nicolas Mailhot

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[David Hollis]

On Tue, 2007-01-30 at 17:41 -0500, Jeff Garzik wrote:
 
 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 

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 to work quite
well on x86 and x86_64, but big-endian systems seem to show some issues
which are being worked out.  The endian-issues drive me mad since I
don't have access to any big-endian systems and have little experience
with it but I'm determined to get them resolved.  For a vendor, they
likely would care less if it doesn't work on big-endian.  If it works on
Windows, that's all that matters.  

The driver has been upstream for 3+ years or so and is included in all
distros that I'm aware of so for most people, they can go out to
BestBuy, buy the device and plug it into their Linux box and it just
works, and that is what we all want in the end.

Conversely, I've seen many cases of drivers that are developed by the
community, but kept out-of-kernel forever due to various reasons.  Some
of them are due to the code quality and the developers not accepting the
feedback to get the drivers into shape to be 'kernel worthy', sometimes
it seems to be a lack of interest from the developers to merge upstream.
Maybe because they think they would lose control or something?
Sometimes it may just be that they don't realize that they can do that.
Thankfully, these tend to be somewhat fringe devices though all would
benefit at their being upstream to make everyones lives easier.


-- 
David Hollis [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Martin Seidl]

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

Andi Kleen wrote:
 Greg KH [EMAIL PROTECTED] writes:
 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
 kernel development never to be seen again?
 
 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
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Eric Sandeen]

Jeff Garzik wrote:
 Roland Dreier wrote:
 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.

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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jeff Garzik]

Eric Sandeen wrote:

Jeff Garzik wrote:

Roland Dreier wrote:

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.


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 :)


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

Jeff



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Eric Sandeen]

Jeff Garzik wrote:
 Eric Sandeen wrote:
 Jeff Garzik wrote:
 Roland Dreier wrote:
 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.
 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 :)
 
 The driver is in libata-dev.git#upstream and queued for 2.6.21.
 
   Jeff

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

-Eric
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Alan]

 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 :)

2.6.20-mm, although it can't do some things currently and the docs are
not really adequate.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Adrian Bunk]

On Wed, Jan 31, 2007 at 11:08:14AM +0100, Andi Kleen wrote:
 Greg KH [EMAIL PROTECTED] writes:
  
  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
  kernel development never to be seen again?
 
 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.
...

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 
supports...

 -Andi

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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Sergei Organov]

Greg KH [EMAIL PROTECTED] writes:
[...]
 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.

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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jan Engelhardt]

On Jan 30 2007 14:00, Roland Dreier wrote:

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.

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


Jan
-- 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jeff Garzik]

Jan Engelhardt wrote:

On Jan 30 2007 14:00, Roland Dreier wrote:

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.


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


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



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jan Engelhardt]

On Jan 31 2007 08:34, David Hollis wrote:
Conversely, I've seen many cases of drivers that are developed by the
community, but kept out-of-kernel forever due to various reasons.  Some
of them are due to the code quality and the developers not accepting the
feedback to get the drivers into shape to be 'kernel worthy', sometimes
it seems to be a lack of interest from the developers to merge upstream.
Maybe because they think they would lose control or something?

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/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[alan]

On Wed, 31 Jan 2007, Jan Engelhardt wrote:



On Jan 30 2007 14:00, Roland Dreier wrote:


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.


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


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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Rewriting floppy.c was Re: Free Linux Driver Development!

[Jan Engelhardt]

On Jan 31 2007 18:24, Adrian Bunk wrote:
On Wed, Jan 31, 2007 at 11:08:14AM +0100, Andi Kleen wrote:
 Greg KH [EMAIL PROTECTED] writes:
  
  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
  kernel development never to be seen again?
 
 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.
...

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 
supports...

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/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Jan Engelhardt]

On Jan 31 2007 09:58, alan wrote:
 On Wed, 31 Jan 2007, Jan Engelhardt wrote:
 On Jan 30 2007 14:00, Roland Dreier wrote:
  
  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.
 
 And ndiswrapper gives fire to just releasing the Windows one :(

 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.

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
-- 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Andrey Borzenkov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday 31 January 2007 15:49, Alan wrote:
  Well, I have a long standing issue with pata_ali not detecting CD-ROM in
  DMA mode. When I rarely watch DVD I rather boot into legacy IDE kernel
  ...

 There is a general problem with some ATAPI devices and the probe logic
 currently. The old IDE code has some workarounds that the new libata
 layer doesn't yet do.


OK I hope to get chance to test new code someday ...

- -andrey
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFwOHiR6LMutpd94wRAltRAJ9eGY+ory798QPzPKvlMsiyy3iVZQCdHbJ7
BtUwkgxuPbi2jwwNqF46fMQ=
=ihjL
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Bob Copeland]

Putting the codingstyle control aside, often it's because things look
too hackish.


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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/