Free Linux Driver Development!
Yes, that's right, the Linux kernel community is offering all companies
free Linux driver development. No longer do you have to suffer through
all of the different examples in the Linux Device Driver Kit, or pick
through the thousands of example drivers in the Linux kernel source
tree trying to determine which one is the closest to what you need to
do.
All that is needed is some kind of specification that describes how your
device works, or the email address of an engineer that is willing to
answer questions every once in a while. A few sample devices might be
good to have so that debugging doesn't have to be done by email, but if
necessary, that can be done.
In return, you will receive a complete and working Linux driver that is
added to the main Linux kernel source tree. The driver will be written
by some of the members of the Linux kernel developer community (over
1500 strong and growing). This driver will then be automatically
included in all Linux distributions, including the "enterprise" ones.
It will be automatically kept up to date and working through all Linux
kernel API changes. This driver will work with all[1] of the different
CPU types supported by Linux, the largest number of CPU types supported
by any operating system ever before in the history of computing.
As for support, the driver will be supported through email by the
original developers, when they can help out, and by the "enterprise"
Linux distributors as part of their service agreements with their
customers.
If your company is worried about NDA issues surrounding your device's
specifications, we have arranged a program with OSDL/TLF's Tech Board to
provide the legal framework where a company can interact with a member
of the kernel community in order to properly assure that all needed NDA
requirements are fulfilled.
Now your developers will have more time to work on drivers for all of
the other operating systems out there, and you can add "supported on
Linux" to your product's marketing material.
This offer is in affect for all different types of devices, from USB
toys to PCI video devices to high-speed networking cards. If you build
it, we can get Linux drivers working for it.
For any questions about this program, please feel free to respond to
this email, or contact me directly at [email protected]. I will also be
available at FreedomHEC 2007 <http://freedomhec.pbwiki.com/> held
adjacent to WinHEC, if anyone wants to bring devices and work
face-to-face.
thanks,
greg k-h
[1] for the CPUs that support the bus types that your device works on.
Greg KH wrote:
> Free Linux Driver Development!
Mind if I include this offer on http://kernelnewbies.org/UpstreamMerge ?
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.
On Mon, Jan 29, 2007 at 09:19:21PM -0500, Rik van Riel wrote:
> Greg KH wrote:
> >Free Linux Driver Development!
>
> Mind if I include this offer on http://kernelnewbies.org/UpstreamMerge ?
Please do, spread it around as much as you want.
thanks,
greg k-h
Greg KH wrote on 30-01-07 02:29:
An offer they can't refuse.
> This offer is in affect for all different types of devices, from USB
> toys to PCI video devices to high-speed networking cards. If you build
> it, we can get Linux drivers working for it.
s/affect/effect/
and maybe
s/build/manufacture/ ??
bjd
>Subject: Free Linux Driver Development!
>
>Free Linux Driver Development!
>
>Yes, that's right, the Linux kernel community is offering all companies
>free Linux driver development. No longer do you have to suffer through
>all of the different examples in the Linux Device Driver Kit, or pick
>through the thousands of example drivers in the Linux kernel source
>tree trying to determine which one is the closest to what you need to
>do. [...]
Yay for quality over quantity :)
>This driver will work with all[1] of the different
>CPU types supported by Linux, the largest number of CPU types supported
>by any operating system ever before in the history of computing.
(How many do we support? How many does NetBSD?)
Wonderful idea!
Jan
--
ft: http://freshmeat.net/p/chaostables/
* Greg KH:
> Yes, that's right, the Linux kernel community is offering all companies
> free Linux driver development. No longer do you have to suffer through
> all of the different examples in the Linux Device Driver Kit, or pick
> through the thousands of example drivers in the Linux kernel source
> tree trying to determine which one is the closest to what you need to
> do.
Very nice spin indeed.
This reminds of the the utterly broken dl2k network driver (which has
got interrupt handling problems and doesn't properly synchronize with
DMA transfers, IIRC). Hardware specs are available, and I guess I
could even provide a hardware sample, maybe even two. (If the
community provides driver support, it shouldn't matter if the vendor
actually supports development.)
On 1/30/07, Greg KH <[email protected]> wrote:
> Free Linux Driver Development!
>
> Yes, that's right, the Linux kernel community is offering all companies
> free Linux driver development. No longer do you have to suffer through
> all of the different examples in the Linux Device Driver Kit, or pick
> through the thousands of example drivers in the Linux kernel source
> tree trying to determine which one is the closest to what you need to
> do.
>
> All that is needed is some kind of specification that describes how your
> device works, or the email address of an engineer that is willing to
> answer questions every once in a while. A few sample devices might be
> good to have so that debugging doesn't have to be done by email, but if
> necessary, that can be done.
>
> In return, you will receive a complete and working Linux driver that is
> added to the main Linux kernel source tree. The driver will be written
> by some of the members of the Linux kernel developer community (over
> 1500 strong and growing). This driver will then be automatically
> included in all Linux distributions, including the "enterprise" ones.
> It will be automatically kept up to date and working through all Linux
> kernel API changes. This driver will work with all[1] of the different
> CPU types supported by Linux, the largest number of CPU types supported
> by any operating system ever before in the history of computing.
>
> As for support, the driver will be supported through email by the
> original developers, when they can help out, and by the "enterprise"
> Linux distributors as part of their service agreements with their
> customers.
>
> If your company is worried about NDA issues surrounding your device's
> specifications, we have arranged a program with OSDL/TLF's Tech Board to
> provide the legal framework where a company can interact with a member
> of the kernel community in order to properly assure that all needed NDA
> requirements are fulfilled.
Sounds very nice indeed. Just happened to do a driver in a similar
status, where the vendor did not want to make the specs and other
stuff open, but was in a position to support an OSS driver for the
STB0899 demodulator driver from ST Microelectronics
I think many vendors will be ready to jump in.
the STB0899 demodulator driver is now available at
http://linuxtv.org/hg/~manu/stb0899-c5
It needs some fixes with regards to our DVB API. (bumping it up to 3.2
from 3.1) It's almost ready to rock now, with new delivery systems.
regards,
manu
> All that is needed is some kind of specification that describes how your
> device works, or the email address of an engineer that is willing to
> answer questions every once in a while. A few sample devices might be
> good to have so that debugging doesn't have to be done by email, but if
> necessary, that can be done.
> This driver will work with all[1] of the different
> CPU types supported by Linux, the largest number of CPU types supported
> by any operating system ever before in the history of computing.
> As for support, the driver will be supported through email by the
> original developers, when they can help out, and by the "enterprise"
> Linux distributors as part of their service agreements with their
> customers.
I'm all for openness of device programming specs, but I think it's a
bit disingenous to suggest that all a company has to do to get a
driver written and supported is throw some documentation over the
wall. And it's crazy to suggest that the driver will work on every
platform and be supported by enterprise distros.
Just look at the in-tree drivers: there are tons of them that don't
work on big-endian platforms, or have 64-bit problems, or have no SMP
support. And that doesn't even count drivers that are so bitrotted
they won't even build any more. And there are plenty of documented
devices that no one cares enough about to submit a driver for.
In the real world, a vendor that wants to make sure a device is
supported by Linux had better pay someone to write the driver and keep
it working. Of course, if the device is popular enough or simple
enough, docs are all that's needed, but in many cases no one competent
to write the driver is going to volunteer to do it.
- R.
On 1/30/07, Roland Dreier <[email protected]> wrote:
> > All that is needed is some kind of specification that describes how your
> > device works, or the email address of an engineer that is willing to
> > answer questions every once in a while. A few sample devices might be
> > good to have so that debugging doesn't have to be done by email, but if
> > necessary, that can be done.
>
> > This driver will work with all[1] of the different
> > CPU types supported by Linux, the largest number of CPU types supported
> > by any operating system ever before in the history of computing.
>
> > As for support, the driver will be supported through email by the
> > original developers, when they can help out, and by the "enterprise"
> > Linux distributors as part of their service agreements with their
> > customers.
>
> I'm all for openness of device programming specs, but I think it's a
> bit disingenous to suggest that all a company has to do to get a
> driver written and supported is throw some documentation over the
> wall. And it's crazy to suggest that the driver will work on every
> platform and be supported by enterprise distros.
>
> Just look at the in-tree drivers: there are tons of them that don't
> work on big-endian platforms, or have 64-bit problems, or have no SMP
> support. And that doesn't even count drivers that are so bitrotted
> they won't even build any more. And there are plenty of documented
> devices that no one cares enough about to submit a driver for.
>
> In the real world, a vendor that wants to make sure a device is
> supported by Linux had better pay someone to write the driver and keep
> it working. Of course, if the device is popular enough or simple
> enough, docs are all that's needed, but in many cases no one competent
> to write the driver is going to volunteer to do it.
Well, if the hardware is nice and is useful to many, there will be at
least a few handful who would ready to put in some effort to it. (We
are talking complex hardware only, not simple ones) Of course
development takes some time, in the order of a few months as opposed
to weeks. The vendor can of course the pay the author as well, which
will result in even better support.
regards,
manu
Roland Dreier wrote:
> Just look at the in-tree drivers: there are tons of them that don't
> work on big-endian platforms, or have 64-bit problems, or have no SMP
> support. And that doesn't even count drivers that are so bitrotted
> they won't even build any more.
The vast majority of these were submitted ages ago. Standards for
acceptance and maintenance have risen since the days of ISA drivers and
floppy tape drives.
I think it's quite disingenuous to imply that a few bad apples are a
representative sample.
Jeff
Jeff Garzik wrote:
Great offer to folks for drivers, but it sends a mixed message. OSDL
should offer to host a page somewhere to coordinate all of this.
:-)
Jeff
> Roland Dreier wrote:
>
>> Just look at the in-tree drivers: there are tons of them that don't
>> work on big-endian platforms, or have 64-bit problems, or have no SMP
>> support. And that doesn't even count drivers that are so bitrotted
>> they won't even build any more.
>
>
> The vast majority of these were submitted ages ago. Standards for
> acceptance and maintenance have risen since the days of ISA drivers
> and floppy tape drives.
>
> I think it's quite disingenuous to imply that a few bad apples are a
> representative sample.
>
> Jeff
>
>
> -
> 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/
>
> The vast majority of these were submitted ages ago. Standards for
> acceptance and maintenance have risen since the days of ISA drivers
> and floppy tape drives.
What are our standards for maintenance? How can we tell in advance if
something is going to be maintained (cf. drivers/net/chelsio)?
I don't think you can seriously argue that just posting documentation
is going to guarantee that a device is going to get a high-quality
driver that runs on all architectures and that enterprise distros will
support. And I don't think it's a good strategy to try convince
vendors to open docs by using happy talk about an idealized fantasy world.
- R.
On Tue, Jan 30, 2007 at 09:45:50AM -0800, Roland Dreier wrote:
> > All that is needed is some kind of specification that describes how your
> > device works, or the email address of an engineer that is willing to
> > answer questions every once in a while. A few sample devices might be
> > good to have so that debugging doesn't have to be done by email, but if
> > necessary, that can be done.
>
> > This driver will work with all[1] of the different
> > CPU types supported by Linux, the largest number of CPU types supported
> > by any operating system ever before in the history of computing.
>
> > As for support, the driver will be supported through email by the
> > original developers, when they can help out, and by the "enterprise"
> > Linux distributors as part of their service agreements with their
> > customers.
>
> I'm all for openness of device programming specs, but I think it's a
> bit disingenous to suggest that all a company has to do to get a
> driver written and supported is throw some documentation over the
> wall. And it's crazy to suggest that the driver will work on every
> platform and be supported by enterprise distros.
Why is that crazy, we do that already today with the majority of drivers
in Linux.
> Just look at the in-tree drivers: there are tons of them that don't
> work on big-endian platforms, or have 64-bit problems, or have no SMP
> support. And that doesn't even count drivers that are so bitrotted
> they won't even build any more.
Like Jeff said, many of these are quite old.
> 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.
> In the real world, a vendor that wants to make sure a device is
> supported by Linux had better pay someone to write the driver and keep
> it working. Of course, if the device is popular enough or simple
> enough, docs are all that's needed, but in many cases no one competent
> to write the driver is going to volunteer to do it.
That's not true at all. We have a whole raft of drivers in the kernel
that are supported only by the community (like the whole USB stack for
example) that vendors rely on working properly.
And again, I have a whole list of people who are competent to write
drivers wanting to do so (myself included), yet do not have any new
devices with specs to do it.
thanks,
greg k-h
On Tue, Jan 30, 2007 at 09:30:23PM +0400, Manu Abraham wrote:
>
> Sounds very nice indeed. Just happened to do a driver in a similar
> status, where the vendor did not want to make the specs and other
> stuff open, but was in a position to support an OSS driver for the
> STB0899 demodulator driver from ST Microelectronics
>
> I think many vendors will be ready to jump in.
Based on the initial response so far, a number of them seem very
willing.
> the STB0899 demodulator driver is now available at
>
> http://linuxtv.org/hg/~manu/stb0899-c5
>
> It needs some fixes with regards to our DVB API. (bumping it up to 3.2
> from 3.1) It's almost ready to rock now, with new delivery systems.
Glad to see that we are getting more device support :)
thanks,
greg k-h
On Tue, Jan 30, 2007 at 02:45:57PM +0100, Florian Weimer wrote:
> * Greg KH:
>
> > Yes, that's right, the Linux kernel community is offering all companies
> > free Linux driver development. No longer do you have to suffer through
> > all of the different examples in the Linux Device Driver Kit, or pick
> > through the thousands of example drivers in the Linux kernel source
> > tree trying to determine which one is the closest to what you need to
> > do.
>
> Very nice spin indeed.
>
> This reminds of the the utterly broken dl2k network driver (which has
> got interrupt handling problems and doesn't properly synchronize with
> DMA transfers, IIRC). Hardware specs are available, and I guess I
> could even provide a hardware sample, maybe even two. (If the
> community provides driver support, it shouldn't matter if the vendor
> actually supports development.)
Have you tried contacting the network driver developers to work these
issues out?
thanks,
greg k-h
On Tue, Jan 30, 2007 at 11:52:48AM +0100, Jan Engelhardt wrote:
> >This driver will work with all[1] of the different
> >CPU types supported by Linux, the largest number of CPU types supported
> >by any operating system ever before in the history of computing.
>
> (How many do we support? How many does NetBSD?)
We support at least 25 separate architectures, with a _huge_ variety of
different variations within those architectures. We passed NetBSD a
number of years ago (sorry, don't have their numbers around right now.)
thanks,
greg k-h
On Tue, Jan 30, 2007 at 08:33:04AM +0100, Bauke Jan Douma wrote:
> Greg KH wrote on 30-01-07 02:29:
> An offer they can't refuse.
>
> >This offer is in affect for all different types of devices, from USB
> >toys to PCI video devices to high-speed networking cards. If you build
> >it, we can get Linux drivers working for it.
>
> s/affect/effect/
>
> and maybe
>
> s/build/manufacture/ ??
Heh, gotta love the grammer police (you were not the only one to point
these mistakes out by a long shot...)
thanks,
greg k-h
Greg KH пишет:
> Free Linux Driver Development!
Just curious, it is a coincidence or a thoughtful action that this offer
(which is undoubtedly very attractive and will definitely help the Linux
user base grow) is published on the very same day when a well-known
software giant releases a new Major Version of their closed-source
operating system?
Thanks,
Dmitri
>
> Yes, that's right, the Linux kernel community is offering all companies
> free Linux driver development. No longer do you have to suffer through
> all of the different examples in the Linux Device Driver Kit, or pick
> through the thousands of example drivers in the Linux kernel source
> tree trying to determine which one is the closest to what you need to
> do.
>
> All that is needed is some kind of specification that describes how your
> device works, or the email address of an engineer that is willing to
> answer questions every once in a while. A few sample devices might be
> good to have so that debugging doesn't have to be done by email, but if
> necessary, that can be done.
>
> In return, you will receive a complete and working Linux driver that is
> added to the main Linux kernel source tree. The driver will be written
> by some of the members of the Linux kernel developer community (over
> 1500 strong and growing). This driver will then be automatically
> included in all Linux distributions, including the "enterprise" ones.
> It will be automatically kept up to date and working through all Linux
> kernel API changes. This driver will work with all[1] of the different
> CPU types supported by Linux, the largest number of CPU types supported
> by any operating system ever before in the history of computing.
>
> As for support, the driver will be supported through email by the
> original developers, when they can help out, and by the "enterprise"
> Linux distributors as part of their service agreements with their
> customers.
>
> If your company is worried about NDA issues surrounding your device's
> specifications, we have arranged a program with OSDL/TLF's Tech Board to
> provide the legal framework where a company can interact with a member
> of the kernel community in order to properly assure that all needed NDA
> requirements are fulfilled.
>
> Now your developers will have more time to work on drivers for all of
> the other operating systems out there, and you can add "supported on
> Linux" to your product's marketing material.
>
> This offer is in affect for all different types of devices, from USB
> toys to PCI video devices to high-speed networking cards. If you build
> it, we can get Linux drivers working for it.
>
> For any questions about this program, please feel free to respond to
> this email, or contact me directly at [email protected]. I will also be
> available at FreedomHEC 2007 <http://freedomhec.pbwiki.com/> held
> adjacent to WinHEC, if anyone wants to bring devices and work
> face-to-face.
>
> thanks,
>
> greg k-h
>
> [1] for the CPUs that support the bus types that your device works on.
> -
> 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/
>
> > I'm all for openness of device programming specs, but I think it's a
> > bit disingenous to suggest that all a company has to do to get a
> > driver written and supported is throw some documentation over the
> > wall. And it's crazy to suggest that the driver will work on every
> > platform and be supported by enterprise distros.
>
> Why is that crazy, we do that already today with the majority of drivers
> in Linux.
Well, we can disagree about the majority of drivers. My feeling is
that most of the drivers that are really used by lots of people get
support beyond just a dump of docs -- in fact often vendors are
maintaining them, eg e1000, tg3, cciss, etc., to pick some running on
the boxes I have around here.
> > Just look at the in-tree drivers: there are tons of them that don't
> > work on big-endian platforms, or have 64-bit problems, or have no SMP
> > support. And that doesn't even count drivers that are so bitrotted
> > they won't even build any more.
>
> Like Jeff said, many of these are quite old.
OK, but why isn't your army of volunteers fixing them?
> > And there are plenty of documented devices that no one cares enough
> > about to submit a driver for.
>
> Any specific examples? I have a long list of people who wish to write
> new drivers but just don't know which hardware is not yet supported.
I have a Cisco USB webcam that supposedly conforms to the "USB Video
Device Class", but nothing happens when I plug it into my Linux box.
I assume the device class is specified as part of the USB spec...
And I seem to recall there's more SATA chipset documentation than Jeff
Garzik has time to implement support for.
> > In the real world, a vendor that wants to make sure a device is
> > supported by Linux had better pay someone to write the driver and keep
> > it working. Of course, if the device is popular enough or simple
> > enough, docs are all that's needed, but in many cases no one competent
> > to write the driver is going to volunteer to do it.
>
> That's not true at all. We have a whole raft of drivers in the kernel
> that are supported only by the community (like the whole USB stack for
> example) that vendors rely on working properly.
Sure, I agree 100% that the community can deliver great drivers when
sufficient interest, documentation, and testing resources are all
available. And of course sufficient interest and testing resources
can substitute for documentation and vendor support -- cf forcedeth,
which was written with no documentation at all.
I'm disagreeing with a stronger assertion -- your original email said
that if a vendor just dumps out hardware documentation and donates a
few devices, then that vendor will definitely get a driver that will
be picked up by enterprise distros and run on every Linux platform.
And that just isn't true, or at least experience shows it hasn't been
true until now.
- R.
On Jan 30 2007 11:14, Greg KH wrote:
>On Tue, Jan 30, 2007 at 11:52:48AM +0100, Jan Engelhardt wrote:
>> >This driver will work with all[1] of the different
>> >CPU types supported by Linux, the largest number of CPU types supported
>> >by any operating system ever before in the history of computing.
>>
>> (How many do we support? How many does NetBSD?)
>
>We support at least 25 separate architectures, with a _huge_ variety of
>different variations within those architectures. We passed NetBSD a
>number of years ago (sorry, don't have their numbers around right now.)
Don't they claim 50+? Already browsing
ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-3.1 gives more than 2
screenfuls [à 25].
Jan
--
ft: http://freshmeat.net/p/chaostables/
Manu Abraham wrote:
> On 1/30/07, Greg KH <[email protected]> wrote:
>> Free Linux Driver Development!
>>
>> Yes, that's right, the Linux kernel community is offering all companies
>> free Linux driver development. No longer do you have to suffer through
>> all of the different examples in the Linux Device Driver Kit, or pick
>> through the thousands of example drivers in the Linux kernel source
>> tree trying to determine which one is the closest to what you need to
>> do.
>>
>> All that is needed is some kind of specification that describes how your
>> device works, or the email address of an engineer that is willing to
>> answer questions every once in a while. A few sample devices might be
>> good to have so that debugging doesn't have to be done by email, but if
>> necessary, that can be done.
>>
>> In return, you will receive a complete and working Linux driver that is
>> added to the main Linux kernel source tree. The driver will be written
>> by some of the members of the Linux kernel developer community (over
>> 1500 strong and growing). This driver will then be automatically
>> included in all Linux distributions, including the "enterprise" ones.
>> It will be automatically kept up to date and working through all Linux
>> kernel API changes. This driver will work with all[1] of the different
>> CPU types supported by Linux, the largest number of CPU types supported
>> by any operating system ever before in the history of computing.
>>
>> As for support, the driver will be supported through email by the
>> original developers, when they can help out, and by the "enterprise"
>> Linux distributors as part of their service agreements with their
>> customers.
>>
>> If your company is worried about NDA issues surrounding your device's
>> specifications, we have arranged a program with OSDL/TLF's Tech Board to
>> provide the legal framework where a company can interact with a member
>> of the kernel community in order to properly assure that all needed NDA
>> requirements are fulfilled.
>
>
> Sounds very nice indeed. Just happened to do a driver in a similar
> status, where the vendor did not want to make the specs and other
> stuff open, but was in a position to support an OSS driver for the
> STB0899 demodulator driver from ST Microelectronics
>
> I think many vendors will be ready to jump in.
>
> the STB0899 demodulator driver is now available at
>
> http://linuxtv.org/hg/~manu/stb0899-c5
>
> It needs some fixes with regards to our DVB API. (bumping it up to 3.2
> from 3.1) It's almost ready to rock now, with new delivery systems.
>
Let us know when it's ready, since the invite is here, success stories
of people using the program could go here as well.
Greg, did this go to the "announce" group as well? It should, some
people read that even if they can't cope with LKML volume.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
Roland Dreier wrote:
> What are our standards for maintenance? How can we tell in advance if
> something is going to be maintained (cf. drivers/net/chelsio)?
>
> I don't think you can seriously argue that just posting documentation
> is going to guarantee that a device is going to get a high-quality
> driver that runs on all architectures and that enterprise distros will
> support.
Look up from infiniband once in and while, and... surprise... that's
what is actually happening. It sure seems to me like the drivers
maintained by hardware vendors directly is in the distinct minority,
illuminating irrefutable evidence that hardware vendors do in fact
receive high quality drivers in exchange for documentation (and
hardware) availability. IMO the drivers of the highest quality are
usually in the this category.
> And I don't think it's a good strategy to try convince
> vendors to open docs by using happy talk about an idealized fantasy world.
Agreed. That's why Greg was describing the real world of Linux kernel
development, rather than an idealized fantasy world.
How do you think you got all these highly portable ATA, USB, network,
and sound drivers, hmmm? The vast majority was just documentation and
hardware access. That's been the Linux way since 1993 (1991?).
Jeff
* Greg KH:
>> This reminds of the the utterly broken dl2k network driver (which has
>> got interrupt handling problems and doesn't properly synchronize with
>> DMA transfers, IIRC). Hardware specs are available, and I guess I
>> could even provide a hardware sample, maybe even two. (If the
>> community provides driver support, it shouldn't matter if the vendor
>> actually supports development.)
>
> Have you tried contacting the network driver developers to work these
> issues out?
Yes, sort of: <http://article.gmane.org/gmane.linux.kernel/448446>
There weren't any replies, unfortunately. Do you think a repost would
make sense?
Our subsequent debugging revealed that either all the cards in our
sample were simply broken (but they seemed to work just fine with the
driver from FreeBSD-current), or something related to the DMA handling
in the driver was not quite right. It looked as if the kernel and the
NIC couldn't agree on the contents of the ring buffer.
Roland Dreier wrote:
> Well, we can disagree about the majority of drivers. My feeling is
> that most of the drivers that are really used by lots of people get
> support beyond just a dump of docs -- in fact often vendors are
> maintaining them, eg e1000, tg3, cciss, etc., to pick some running on
> the boxes I have around here.
Check your history... tg3 was written by me and DaveM, and only after
years was it picked up by the vendor as their official Linux driver.
You have picked an excellent counter-example to your own argument.
> > > Just look at the in-tree drivers: there are tons of them that don't
> > > work on big-endian platforms, or have 64-bit problems, or have no SMP
> > > support. And that doesn't even count drivers that are so bitrotted
> > > they won't even build any more.
> >
> > Like Jeff said, many of these are quite old.
>
> OK, but why isn't your army of volunteers fixing them?
Because nobody has hardware for them?
> 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.
Regardless, libata has 55+ drivers and counting, all for the price of
documentation and hardware. Another quite strong counter example.
> I'm disagreeing with a stronger assertion -- your original email said
> that if a vendor just dumps out hardware documentation and donates a
> few devices, then that vendor will definitely get a driver that will
> be picked up by enterprise distros and run on every Linux platform.
> And that just isn't true, or at least experience shows it hasn't been
> true until now.
What experience? AFAICS, pretty much all modern hardware in use outside
of ATI/NVIDIA graphics is supported by Linux.
All visible evidence points to support for Greg's assertion.
Jeff
On Tue, Jan 30, 2007 at 08:31:01PM +0100, Jan Engelhardt wrote:
>
> On Jan 30 2007 11:14, Greg KH wrote:
> >On Tue, Jan 30, 2007 at 11:52:48AM +0100, Jan Engelhardt wrote:
> >> >This driver will work with all[1] of the different
> >> >CPU types supported by Linux, the largest number of CPU types supported
> >> >by any operating system ever before in the history of computing.
> >>
> >> (How many do we support? How many does NetBSD?)
> >
> >We support at least 25 separate architectures, with a _huge_ variety of
> >different variations within those architectures. We passed NetBSD a
> >number of years ago (sorry, don't have their numbers around right now.)
>
> Don't they claim 50+? Already browsing
> ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-3.1 gives more than 2
> screenfuls [?? 25].
Don't get confused by the fact that the majority of the NetBSD platforms
are sub-architectures. I'm talking about 25 unique CPU architectures.
Or is it 20. I haven't looked in a while, the tree is there for anyone
else to look at :)
And even then, I think just the pure number of variants of ARM and PPC
that we support is greater than NetBSD's sub-arch support too...
thanks,
greg k-h
On Tue, Jan 30, 2007 at 08:40:10PM +0100, Florian Weimer wrote:
> * Greg KH:
>
> >> This reminds of the the utterly broken dl2k network driver (which has
> >> got interrupt handling problems and doesn't properly synchronize with
> >> DMA transfers, IIRC). Hardware specs are available, and I guess I
> >> could even provide a hardware sample, maybe even two. (If the
> >> community provides driver support, it shouldn't matter if the vendor
> >> actually supports development.)
> >
> > Have you tried contacting the network driver developers to work these
> > issues out?
>
> Yes, sort of: <http://article.gmane.org/gmane.linux.kernel/448446>
> There weren't any replies, unfortunately. Do you think a repost would
> make sense?
Try sending it to the netdev mailing list instead. Not all of the
network driver developers read the whole lkml firehose.
thanks,
greg k-h
On Tue, Jan 30, 2007 at 10:08:54PM +0300, Dmitri Vorobiev wrote:
> Greg KH ??????????:
> >Free Linux Driver Development!
>
> Just curious, it is a coincidence or a thoughtful action that this offer
> (which is undoubtedly very attractive and will definitely help the Linux
> user base grow) is published on the very same day when a well-known
> software giant releases a new Major Version of their closed-source
> operating system?
As I don't pay attention to other closed source operating systems, it
must have been coincidence. :)
thanks,
greg k-h
El Tue, 30 Jan 2007 11:10:20 -0800, Greg KH <[email protected]> escribi?:
> 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.
It'd be interesting to join forces with the BSD guys in this field, they surely
support initiatives like this!
On Tue, Jan 30, 2007 at 11:29:58AM -0800, Roland Dreier wrote:
> > > I'm all for openness of device programming specs, but I think it's a
> > > bit disingenous to suggest that all a company has to do to get a
> > > driver written and supported is throw some documentation over the
> > > wall. And it's crazy to suggest that the driver will work on every
> > > platform and be supported by enterprise distros.
> >
> > Why is that crazy, we do that already today with the majority of drivers
> > in Linux.
>
> Well, we can disagree about the majority of drivers. My feeling is
> that most of the drivers that are really used by lots of people get
> support beyond just a dump of docs -- in fact often vendors are
> maintaining them, eg e1000, tg3, cciss, etc., to pick some running on
> the boxes I have around here.
If you recal, tg3 was created by the community because the vendor
refused to open their driver up. They only reluctantly now support it
because it went into the main kernel tree and the distros then refused
to accept the closed driver.
So there's a perfict example of what I'm talking about :)
Also, look at the rest of the system (ide, SATA, USB, firewire, driver
core, PCI, etc.) None of that was done by a vendor, but by the
community.
> > > Just look at the in-tree drivers: there are tons of them that don't
> > > work on big-endian platforms, or have 64-bit problems, or have no SMP
> > > support. And that doesn't even count drivers that are so bitrotted
> > > they won't even build any more.
> >
> > Like Jeff said, many of these are quite old.
>
> OK, but why isn't your army of volunteers fixing them?
They don't know about them, or they don't have the hardware to test?
Seriously, let the kernel-janitor's project know about any issues you
have and they will be glad to jump on it. Those people are just
chomping a the bit to do something a bit bigger than "compiler warning
cleanups" :)
> > > And there are plenty of documented devices that no one cares enough
> > > about to submit a driver for.
> >
> > Any specific examples? I have a long list of people who wish to write
> > new drivers but just don't know which hardware is not yet supported.
>
> I have a Cisco USB webcam that supposedly conforms to the "USB Video
> Device Class", but nothing happens when I plug it into my Linux box.
> I assume the device class is specified as part of the USB spec...
Are you sure? That spec just came out not so long ago and I haven't
seen any real devices support it just yet. That said, I do know of a
few people who are working on implementing the standard, try asking on
the linux-usb-devel mailing list to find out what their status is.
> And I seem to recall there's more SATA chipset documentation than Jeff
> Garzik has time to implement support for.
If so, he should let people know :)
> I'm disagreeing with a stronger assertion -- your original email said
> that if a vendor just dumps out hardware documentation and donates a
> few devices, then that vendor will definitely get a driver that will
> be picked up by enterprise distros and run on every Linux platform.
> And that just isn't true, or at least experience shows it hasn't been
> true until now.
Um, that's how Linux has gotten to where it is today and continues to
grow. Just because none of us wanted to do IB drivers, doesn't mean that
the model doesn't work for devices that are actually sane :)
thanks,
greg k-h
On Tue, Jan 30, 2007 at 02:33:01PM -0500, Bill Davidsen wrote:
>
> Greg, did this go to the "announce" group as well? It should, some
> people read that even if they can't cope with LKML volume.
What "announce" group?
I noticed it hit /., so it is now being spread to a group wider than
lkml.
thanks,
greg k-h
On Tue, Jan 30, 2007 at 08:52:12PM +0100, Diego Calleja wrote:
> El Tue, 30 Jan 2007 11:10:20 -0800, Greg KH <[email protected]> escribi?:
>
> > 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.
>
> It'd be interesting to join forces with the BSD guys in this field, they surely
> support initiatives like this!
I have worked with the BSD developers in the past, sharing
specifications and knowledge about how certian devices work in order to
help them get drivers up and running. So this sharing has happened in
the past, and still continues today.
thanks,
greg k-h
On 1/30/07, Greg KH <[email protected]> wrote:
> Free Linux Driver Development!
>
> Yes, that's right, the Linux kernel community is offering all companies
> free Linux driver development. No longer do you have to suffer through
> all of the different examples in the Linux Device Driver Kit, or pick
> through the thousands of example drivers in the Linux kernel source
> tree trying to determine which one is the closest to what you need to
> do.
>
> All that is needed is some kind of specification that describes how your
> device works, or the email address of an engineer that is willing to
> answer questions every once in a while. A few sample devices might be
> good to have so that debugging doesn't have to be done by email, but if
> necessary, that can be done.
>
> In return, you will receive a complete and working Linux driver that is
> added to the main Linux kernel source tree. The driver will be written
> by some of the members of the Linux kernel developer community (over
> 1500 strong and growing). This driver will then be automatically
> included in all Linux distributions, including the "enterprise" ones.
> It will be automatically kept up to date and working through all Linux
> kernel API changes. This driver will work with all[1] of the different
> CPU types supported by Linux, the largest number of CPU types supported
> by any operating system ever before in the history of computing.
>
> As for support, the driver will be supported through email by the
> original developers, when they can help out, and by the "enterprise"
> Linux distributors as part of their service agreements with their
> customers.
>
> If your company is worried about NDA issues surrounding your device's
> specifications, we have arranged a program with OSDL/TLF's Tech Board to
> provide the legal framework where a company can interact with a member
> of the kernel community in order to properly assure that all needed NDA
> requirements are fulfilled.
>
> Now your developers will have more time to work on drivers for all of
> the other operating systems out there, and you can add "supported on
> Linux" to your product's marketing material.
>
> This offer is in affect for all different types of devices, from USB
> toys to PCI video devices to high-speed networking cards. If you build
> it, we can get Linux drivers working for it.
>
> For any questions about this program, please feel free to respond to
> this email, or contact me directly at [email protected]. I will also be
> available at FreedomHEC 2007 <http://freedomhec.pbwiki.com/> held
> adjacent to WinHEC, if anyone wants to bring devices and work
> face-to-face.
>
> thanks,
>
> greg k-h
>
> [1] for the CPUs that support the bus types that your device works on.
> -
> 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/
>
How about a kernel driver for the m-cubed tbalancer bigNG ?
http://www.t-balancer.com/english/bng.htm (see support section of site)
Complete documentation is available, and devs are friendly (see
forums), there is already a userspace utility that works well but a
kernel driver would be even better, especially for something that
controls system cooling!
Andy
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].
I don't know exactly how many architectures does netbsd run, but Linux seems
to support arches that netbsd doesn't, like: 64 bit MIPS, PPC 970 (available in
netbsd but not yet integrated i think), Cell, S390, M32R, Nec v850, frv, cris?,
xtensa, mmuless cpus (apparently there're lots of mmuless cpus), Itanium
(netbsd development ongoing)
Sure, Linux doesn't support vax and the like, but it does support lots of
architectures that matter. In http://netbsd.org/Ports/#ports-by-cpu there's a
more Linux-like view of the architectures supported. Although Netbsd people
will argue that porting a architecture to Linux is more difficult and that Linux
gets support just because there's a lot of $$$ around it.
Anyway, even if Linux wasn't the OS with more architectures supported
it'd be the _second_ on the list. Which is quite impressive anyway, and
nothing to be ashamed of.
On Tue, Jan 30, 2007 at 08:15:11PM +0000, Andrew Lyon wrote:
>
> How about a kernel driver for the m-cubed tbalancer bigNG ?
>
> http://www.t-balancer.com/english/bng.htm (see support section of site)
>
> Complete documentation is available, and devs are friendly (see
> forums), there is already a userspace utility that works well but a
> kernel driver would be even better, especially for something that
> controls system cooling!
Why would a userspace driver not work out for this. We already can
saturate the USB bus with a userspace program, and since it requires a
userspace interaction to do something with the data, I don't really see
what a kernel driver could do to help thing out.
That being said, perhaps it would fit with the other USB data
acquisition drivers that we already have. Feel free to take this up
with me off-list if you want to.
Hm, wait, in looking at the specs for the device, it uses a
usb-to-serial chip that we already support quite well (with the
pl2303.ko driver.) So all you need to do is write some userspace
software that interacts with the device properly. No new kernel driver
is needed at all, as Linux already supports this hardware :)
thanks,
greg k-h
On Jan 30 2007 21:23, Diego Calleja wrote:
>
>Sure, Linux doesn't support vax and the like, but it does support lots of
>architectures that matter. In http://netbsd.org/Ports/#ports-by-cpu
>there's a more Linux-like view of the architectures supported. Although
>Netbsd people will argue that porting a architecture to Linux is more
>difficult and that Linux gets support just because there's a lot of $$$
>around it.
A real one time argument. There's much more $ around Windows and yet,
there are (I presume) almost only drivers for x86 (and slowly coming,
x86_64). IA64? Well, you probably don't run desktop peripherals there,
but vendors don't have a driver at hand easily.
Jan
--
On Tue, 30 Jan 2007 08:33:04 +0100, Bauke Jan Douma said:
> Greg KH wrote on 30-01-07 02:29:
> An offer they can't refuse.
>
> > This offer is in affect for all different types of devices, from USB
> > toys to PCI video devices to high-speed networking cards. If you build
> > it, we can get Linux drivers working for it.
>
> s/affect/effect/
Correct.
> and maybe
>
> s/build/manufacture/ ??
We probably *want* to encourage them to come talk to us when the device is
still a "build" because it's in the design/prototype stage - that way we avoid
having to work around design brain damage and features that could have been
added but weren't because The Other OS wouldn't have used them.
Also, the people we want to talk to *are* the "build" people - it's quite
possble they farm out the mass manufacture to some other company that just
does the actual assembly of boards based on a CAD/CAM model they're given.
> > Well, we can disagree about the majority of drivers. My feeling is
> > that most of the drivers that are really used by lots of people get
> > support beyond just a dump of docs -- in fact often vendors are
> > maintaining them, eg e1000, tg3, cciss, etc., to pick some running on
> > the boxes I have around here.
>
> Check your history... tg3 was written by me and DaveM, and only after
> years was it picked up by the vendor as their official Linux
> driver. You have picked an excellent counter-example to your own
> argument.
OK, fair enough, I forgot about tg3. But on the other hand, you wrote
it without docs, actually _in spite of_ Broadcom, right?
Which I think makes my point that documentation is neither necessary
nor sufficient for a good Linux driver. Documentation helps, but if
no one competent cares about the device then the driver won't get
written. On the other hand, if the device is important enough, the
driver will get written without documentation or vendor support.
> > OK, but why isn't your army of volunteers fixing them?
>
> Because nobody has hardware for them?
Greg said hardware wasn't necessary...
> > And I seem to recall there's more SATA chipset documentation than Jeff
> > Garzik has time to implement support for.
>
> I seriously doubt you can come up with even a single concrete example here.
Sorry, I thought you said there was interesting stuff to do with the
Promise documentation you got. I guess Nvidia ADMA is pretty much
done now.
> What experience? AFAICS, pretty much all modern hardware in use
> outside of ATI/NVIDIA graphics is supported by Linux.
Sure, popular hardware support is pretty good. But there are still
pretty serious gaps, for example Ralink wireless drivers are still not
upstream even with the vendor trying to help (and I think Ralink
wireless is a good example of how we can't really keep the promises
Greg is making).
And there's plenty of stuff in-tree with lots of users that's in
pretty dire shape, like ISDN (and the fact that we still
CONFIG_ISDN_I4L). OK, it's not "modern" but Greg is also promising
that we'll keep everything up-to-date with any upstream kernel
changes, and there's obviously large chunks of the driver tree where
that doesn't happen.
- R.
> > OK, but why isn't your army of volunteers fixing them?
>
> They don't know about them, or they don't have the hardware to test?
> Seriously, let the kernel-janitor's project know about any issues you
> have and they will be glad to jump on it. Those people are just
> chomping a the bit to do something a bit bigger than "compiler warning
> cleanups" :)
I thought you said hardware to test wasn't necessary?
It's not particularly hard to find drivers that need work -- just
looking at everything protected by CONFIG_BROKEN would find plenty of
things to jump on. Or do "git grep 'cli(' drivers/".
> > I have a Cisco USB webcam that supposedly conforms to the "USB Video
> > Device Class", but nothing happens when I plug it into my Linux box.
> > I assume the device class is specified as part of the USB spec...
>
> Are you sure? That spec just came out not so long ago and I haven't
> seen any real devices support it just yet. That said, I do know of a
> few people who are working on implementing the standard, try asking on
> the linux-usb-devel mailing list to find out what their status is.
A quick web search finds http://linux-uvc.berlios.de/ but I don't see
any signs that anyone plans to submit it upstream.
> > I'm disagreeing with a stronger assertion -- your original email said
> > that if a vendor just dumps out hardware documentation and donates a
> > few devices, then that vendor will definitely get a driver that will
> > be picked up by enterprise distros and run on every Linux platform.
> > And that just isn't true, or at least experience shows it hasn't been
> > true until now.
> Um, that's how Linux has gotten to where it is today and continues to
> grow. Just because none of us wanted to do IB drivers, doesn't mean that
> the model doesn't work for devices that are actually sane :)
I disagree -- Linux today gets drivers not just from volunteers
writing drivers from specs, but also from vendors writing drivers and
volunteers writing drivers via reverse engineering. And many of those
drivers don't work on every platform and aren't supported by
enterprise distros. And when the community loses interest, drivers
are left to bitrot.
Hardware specs help. They help a lot. But they're neither necessary
nor sufficient for getting a high-quality Linux driver written. And
they definitely don't guarantee continuing maintenance.
- R.
On Tue, Jan 30, 2007 at 01:38:06PM -0800, Roland Dreier wrote:
> > > OK, but why isn't your army of volunteers fixing them?
> >
> > Because nobody has hardware for them?
>
> Greg said hardware wasn't necessary...
Someone has to have the hardware to test with. Hence my "debug by
email" comment.
> Sure, popular hardware support is pretty good. But there are still
> pretty serious gaps, for example Ralink wireless drivers are still not
> upstream even with the vendor trying to help (and I think Ralink
> wireless is a good example of how we can't really keep the promises
> Greg is making).
The Ralink wireless drivers are working to get their stuff upstream. I
think there is only some wireless infrastructure needed to complete
before it gets into mainline, but you will have to ask them about this.
There was a wireless-mini-summit a week or so ago, so those developers
all know what is going on in that space right now. They are facing a
number of different regulatory issues, combined with lack of
specifications from some vendors. I don't think that the developers who
actually have specs are complaining about anything right now.
> And there's plenty of stuff in-tree with lots of users that's in
> pretty dire shape, like ISDN (and the fact that we still
> CONFIG_ISDN_I4L). OK, it's not "modern" but Greg is also promising
> that we'll keep everything up-to-date with any upstream kernel
> changes, and there's obviously large chunks of the driver tree where
> that doesn't happen.
The ISDN maintainer has a large rewrite almost done, and anyone is
welcome to help him out if they are still using and needing that old
hardware. As almost no one objects to the current code, I'm guessing
that there is no such real need :)
thanks,
greg k-h
> The Ralink wireless drivers are working to get their stuff upstream. I
> think there is only some wireless infrastructure needed to complete
> before it gets into mainline, but you will have to ask them about this.
>
> There was a wireless-mini-summit a week or so ago, so those developers
> all know what is going on in that space right now. They are facing a
> number of different regulatory issues, combined with lack of
> specifications from some vendors. I don't think that the developers who
> actually have specs are complaining about anything right now.
OK, one last reply before I give up on this thread...
Sure, Ralink drivers will get upstream eventually. But by the time
the drivers get merged, Ralink will have stopped making the chips that
it supports (or so I read, http://www.linuxemporium.co.uk/products/wireless/)!
I don't think that taking a year or two to merge a driver is going to
impress a vendor, especially since the reverse-engineered Broadcom
wireless driver is probably going to go upstream at just about the
same time.
An uncharitable vendor might decide it's not worth publishing specs,
since the Linux guys can reverse engineer the Windows driver just as
fast anyway.
- R.
Roland Dreier wrote:
> > > Well, we can disagree about the majority of drivers. My feeling is
> > > that most of the drivers that are really used by lots of people get
> > > support beyond just a dump of docs -- in fact often vendors are
> > > maintaining them, eg e1000, tg3, cciss, etc., to pick some running on
> > > the boxes I have around here.
> >
> > Check your history... tg3 was written by me and DaveM, and only after
> > years was it picked up by the vendor as their official Linux
> > driver. You have picked an excellent counter-example to your own
> > argument.
>
> OK, fair enough, I forgot about tg3. But on the other hand, you wrote
> it without docs, actually _in spite of_ Broadcom, right?
>
> Which I think makes my point that documentation is neither necessary
> nor sufficient for a good Linux driver. Documentation helps, but if
> no one competent cares about the device then the driver won't get
> written. On the other hand, if the device is important enough, the
> driver will get written without documentation or vendor support.
That's your point?? I thought your point was (quoting your words)
> it's a
> bit disingenous to suggest that all a company has to do to get a
> driver written and supported is throw some documentation over the
> wall. And it's crazy to suggest that the driver will work on every
> platform and be supported by enterprise distros.
To repeat -- that's how most Linux drivers have been written,
/particularly/ the ones used most by users of enterprise distros.
> > > OK, but why isn't your army of volunteers fixing them?
> >
> > Because nobody has hardware for them?
>
> Greg said hardware wasn't necessary...
I did not say "no developers [...]"
I said "nobody"
> > > And I seem to recall there's more SATA chipset documentation than Jeff
> > > Garzik has time to implement support for.
> >
> > I seriously doubt you can come up with even a single concrete example here.
>
> Sorry, I thought you said there was interesting stuff to do with the
> Promise documentation you got.
Mikael took care of it already. And its supported by enterprise distros.
> I guess Nvidia ADMA is pretty much
> done now.
Yep. Without docs, even. And its supported by enterprise distros.
> > What experience? AFAICS, pretty much all modern hardware in use
> > outside of ATI/NVIDIA graphics is supported by Linux.
>
> Sure, popular hardware support is pretty good. But there are still
> pretty serious gaps, for example Ralink wireless drivers are still not
> upstream even with the vendor trying to help (and I think Ralink
> wireless is a good example of how we can't really keep the promises
> Greg is making).
How so? They appear to be working with wireless devs to get their
driver into the tree.
> And there's plenty of stuff in-tree with lots of users that's in
> pretty dire shape, like ISDN (and the fact that we still
> CONFIG_ISDN_I4L). OK, it's not "modern" but Greg is also promising
> that we'll keep everything up-to-date with any upstream kernel
> changes, and there's obviously large chunks of the driver tree where
> that doesn't happen.
Yes, large chunks of legacy ISA drivers, m68k drivers, and similar
situations where the userbase has dwindled to a handful over a decade.
Jeff
Roland Dreier wrote:
> Sure, Ralink drivers will get upstream eventually. But by the time
> the drivers get merged, Ralink will have stopped making the chips that
> it supports (or so I read, http://www.linuxemporium.co.uk/products/wireless/)!
> I don't think that taking a year or two to merge a driver is going to
> impress a vendor, especially since the reverse-engineered Broadcom
> wireless driver is probably going to go upstream at just about the
> same time.
You mean the bcm43xx wireless driver that's been upstream for months?
> 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.
Most vendors are likely to focus on examples that are in the statistical
(and competitive) majority, where publishing specs led to a driver
supported by an enterprise distro.
Jeff
> > There was a wireless-mini-summit a week or so ago, so those developers
> > all know what is going on in that space right now. They are facing a
> > number of different regulatory issues, combined with lack of
> > specifications from some vendors. I don't think that the developers who
> > actually have specs are complaining about anything right now.
>
> OK, one last reply before I give up on this thread...
>
> Sure, Ralink drivers will get upstream eventually. But by the time
> the drivers get merged, Ralink will have stopped making the chips that
> it supports (or so I read, http://www.linuxemporium.co.uk/products/wireless/)!
> I don't think that taking a year or two to merge a driver is going to
> impress a vendor, especially since the reverse-engineered Broadcom
> wireless driver is probably going to go upstream at just about the
> same time.
>
> An uncharitable vendor might decide it's not worth publishing specs,
> since the Linux guys can reverse engineer the Windows driver just as
> fast anyway.
I'm sort of with Roland on this, the timelines aren't usually worth it
for a company to bother especially with complicated hardware, the time
taken to do a community graphics driver for any GPU where specs have
been available approaches infinity, unless the vendor actually does
the driver or pays someone to do the driver the hope of a community
supported driver reaching maturity while the product is still
available is slim.... for anyone desparate to start writing device
drivers, XGI have recently dropped a load of specs for their cards,
I'm not seeing anyone other than the usual GPU ppl step up an do
anything and as I said the time it takes a single volunteer to write a
GPU driver is a lot longer than the card...
Dave.
> > OK, fair enough, I forgot about tg3. But on the other hand, you
> > wrote
> > it without docs, actually _in spite of_ Broadcom, right?
> > Which I think makes my point that documentation is neither necessary
> > nor sufficient for a good Linux driver. Documentation helps, but if
> > no one competent cares about the device then the driver won't get
> > written. On the other hand, if the device is important enough, the
> > driver will get written without documentation or vendor support.
>
> That's your point?? I thought your point was (quoting your words)
>
> > it's a
> > bit disingenous to suggest that all a company has to do to get a
> > driver written and supported is throw some documentation over the
> > wall. And it's crazy to suggest that the driver will work on every
> > platform and be supported by enterprise distros.
>
> To repeat -- that's how most Linux drivers have been written,
> /particularly/ the ones used most by users of enterprise distros.
I thought you wrote tg3 without docs and without help from Broadcom?
To repeat, my point is that the drivers used most by users of
enterprise distros will get written with or without vendor docs or
help. Drivers for hardware that only a few people care about probably
won't be written and definitely won't be maintained by volunteers even
if the vendor publishes docs. And I think that's pretty much what I
said in both of the paragraphs you quoted above.
- R.
> You mean the bcm43xx wireless driver that's been upstream for months?
Sorry, yes. For some reason I thought it was blocked on the dscape
merge but obviously I was wrong. So a reverse-engineered driver got
upstream WAY FASTER than a driver where the vendor published specs and
GPLed source.
Why did that happen? I would argue that it was because way more
people cared about the broadcom driver (since the chip was in apple
laptops and the wrt54g among other things). That developer and user
interest is more important than the info provided by the vendor.
Anyway, I broke my first promise to drop this thread, but I'll make
the promise again now...
- R.
Jeff Garzik <jeff <at> garzik.org> writes:
> > 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.
>
> Regardless, libata has 55+ drivers and counting, all for the price of
> documentation and hardware. Another quite strong counter example.
>
On another side, some PATA drivers are incomplete or missing.
When we switch to PATA and drop old ide stack, what will happen ?
Will all driver be ported and full-feature, or some will be obsoleted ?
Matthieu
On 1/30/07, Greg KH <[email protected]> wrote:
> On Tue, Jan 30, 2007 at 09:30:23PM +0400, Manu Abraham wrote:
> >
> > Sounds very nice indeed. Just happened to do a driver in a similar
> > status, where the vendor did not want to make the specs and other
> > stuff open, but was in a position to support an OSS driver for the
> > STB0899 demodulator driver from ST Microelectronics
> >
> > I think many vendors will be ready to jump in.
>
> Based on the initial response so far, a number of them seem very
> willing.
>
> > the STB0899 demodulator driver is now available at
> >
> > http://linuxtv.org/hg/~manu/stb0899-c5
> >
> > It needs some fixes with regards to our DVB API. (bumping it up to 3.2
> > from 3.1) It's almost ready to rock now, with new delivery systems.
>
> Glad to see that we are getting more device support :)
>
Not only that, we will be adding in even more delivery systems like
DVB-S2, DVB-H, DSS and other than that, we will be having algorithm
based tuning rather than dumb tuning.
regards,
manu
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. If the bios on the laptop in question would let me change the
minipci card I would. To something with a ralink on it.
Seems the ralink driver maintainers are doing a lot of the work on the
core wifi infastructure too. Lots of work beyond just the driver then.
--
Len Sorensen
On 1/31/07, Dave Airlie <[email protected]> wrote:
> I'm sort of with Roland on this, the timelines aren't usually worth it
> for a company to bother especially with complicated hardware, the time
> taken to do a community graphics driver for any GPU where specs have
> been available approaches infinity, unless the vendor actually does
> the driver or pays someone to do the driver the hope of a community
> supported driver reaching maturity while the product is still
> available is slim.... for anyone desparate to start writing device
> drivers, XGI have recently dropped a load of specs for their cards,
> I'm not seeing anyone other than the usual GPU ppl step up an do
> anything and as I said the time it takes a single volunteer to write a
> GPU driver is a lot longer than the card...
All this sounds like a lack of organisation on the side of the
community to me. Greg saying that he and others are twiddling their
thumbs because they don't know what hardware needs drivers says that
too. Where is the list of hardware-without-drivers? Until recently
there hasn't even been a list of hardware-with-binary-only-drivers
[1]. So anyone who has the necessary skills and thinks gee, I might
have a go at writing a linux kernel driver, has no idea where to go or
what to do. I wonder how many vendors have a policy of just ignoring
emails from hackers asking for specifications because they have
already given the specifications to Redhat or someone else, but
hackers just keep asking them again and again.
Trent
1. see http://developer.osdl.org/dev/opendrivers/wiki/index.php/Binary_Kernel_Modules_List
for a partial list.
On Tue, Jan 30, 2007 at 01:46:38PM -0800, Roland Dreier wrote:
> I disagree -- Linux today gets drivers not just from volunteers
> writing drivers from specs, but also from vendors writing drivers and
> volunteers writing drivers via reverse engineering. And many of those
> drivers don't work on every platform and aren't supported by
> enterprise distros. And when the community loses interest, drivers
> are left to bitrot.
I would much rather see a driver bit rot due to lack of interest than
see hardware go to the scrap heap because the vendor stoped caring about
it and you are SOL. Happens every time a new windows version comes out.
lots of working hardware suddenly becomes useless. At least on linux I
can keep using it if I want to until I decide not to try and maintain
the driver (if no one else is doing it). A driver with bitrot is a lot
better than no driver at all.
--
Len Sorensen
> > Like Jeff said, many of these are quite old.
>
> OK, but why isn't your army of volunteers fixing them?
One of the problems if lack of hardware. It's very hard to fix a
prehistoric serial driver if you don't have an ISA bus box with the
needed slot let alone the card.
And why bother - its hardware that works on all the cases that matter
> Device Class", but nothing happens when I plug it into my Linux box.
> I assume the device class is specified as part of the USB spec...
UVC is "interesting", in a bad kind of interesting sort of way. See
http://developer.berlios.de/projects/linux-uvc however
Roland Dreier wrote:
> I disagree -- Linux today gets drivers not just from volunteers
> writing drivers from specs, but also from vendors writing drivers and
> volunteers writing drivers via reverse engineering. And many of those
> drivers don't work on every platform and aren't supported by
> enterprise distros. And when the community loses interest, drivers
> are left to bitrot.
Which of these actively maintained and supported drivers work on only
one platform[1], and are excluded from enterprise distros? Can we truly
count them as "many", as you repeatedly claim?
Jeff
[1] obviously excluding drivers for hardware where its only possible to
occur on one platform, like SoC devices
Trent Waddington wrote:
> All this sounds like a lack of organisation on the side of the
> community to me. Greg saying that he and others are twiddling their
> thumbs because they don't know what hardware needs drivers says that
> too. Where is the list of hardware-without-drivers? Until recently
> there hasn't even been a list of hardware-with-binary-only-drivers
> [1]. So anyone who has the necessary skills and thinks gee, I might
> have a go at writing a linux kernel driver, has no idea where to go or
> what to do. I wonder how many vendors have a policy of just ignoring
> emails from hackers asking for specifications because they have
> already given the specifications to Redhat or someone else, but
> hackers just keep asking them again and again.
I think this is a quite fair criticism, and I would love to see someone
step up and help with this sort of organization.
For example, I didn't know that XGI graphics specs were available at
all, otherwise it might have been something fun to tackle.
Jeff
Matthieu CASTET wrote:
> Jeff Garzik <jeff <at> garzik.org> writes:
>
>>> 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.
>>
>> Regardless, libata has 55+ drivers and counting, all for the price of
>> documentation and hardware. Another quite strong counter example.
>>
> On another side, some PATA drivers are incomplete or missing.
Which ones are incomplete?
I know a few non-x86 drivers are missing.
> When we switch to PATA and drop old ide stack, what will happen ?
> Will all driver be ported and full-feature, or some will be obsoleted ?
All drivers for which we can find users will be ported. If any features
disappear that's a bug.
Jeff
> Which of these actively maintained and supported drivers work on only
> one platform[1], and are excluded from enterprise distros? Can we
> truly count them as "many", as you repeatedly claim?
Why do we restrict this to actively maintained and supported drivers
(I think abandonware drivers are highly relevant here...)? And why
are you asking about drivers that work on only one platform? Greg
promised support for every platform that has the right bus to plug a
device into. So things like drivers that don't work on SMP or 64-bit
or big-endian platforms also violate that pledge, even if there's more
than one 32-bit little-endian uniprocessor platform where the driver
does work.
Anyway, grepping for stuff like BROKEN or !64BIT or X86 in the Kconfig
dependencies under drivers/ finds tons of hits. I don't have time to
scan through and figure out which meet your criteria, and I honestly
don't know how enterprise distros decide what to support. For example
RHEL4 seems to ship aha152x (which depends on ISA && SCSI && !64BIT),
but what will RH do if someone actually wants support for it?
I don't really understand why it's so hard to accept that sometimes
even open specs aren't enough to get great Linux support.
- R.
> On another side, some PATA drivers are incomplete or missing.
>
> When we switch to PATA and drop old ide stack, what will happen ?
> Will all driver be ported and full-feature, or some will be obsoleted ?
At the moment unless anyone gets upset I expect to obsolete the CMD640
but nothing else PCI. Can't comment on non x86 drivers and that may be up
to port maintainers, and in part to polishing the core code to handle it
better.
Some vendors are trialling a libata switch in their upcoming
distributions and the only barrier I expect to need some quick fixing is
the HPA support.
Alan
Roland Dreier wrote:
> I thought you wrote tg3 without docs and without help from Broadcom?
We had docs and Broadcom's GPL'd driver.
> To repeat, my point is that the drivers used most by users of
> enterprise distros will get written with or without vendor docs or
> help. Drivers for hardware that only a few people care about probably
> won't be written and definitely won't be maintained by volunteers even
> if the vendor publishes docs. And I think that's pretty much what I
> said in both of the paragraphs you quoted above.
You're changing your story. After first over-simplifying what Greg
posted, you were complaining about Greg being disingenuous, when in fact
Greg was doing nothing but describing (in a new and different way) how
Linux drivers are already written.
Furthermore, presuming that drivers "definitely won't be maintained by
volunteers" is rather presumptuous considering that volunteers are
lining up, according to Greg.
I'm glad I didn't have a negative nelly like you around when I first got
into fbdev driver hacking, my entry into the Linux kernel world. "Don't
bother, son, nobody wants you around anyway."
Jeff
On Tue, Jan 30, 2007 at 02:50:49PM -0800, Roland Dreier wrote:
> > Which of these actively maintained and supported drivers work on only
> > one platform[1], and are excluded from enterprise distros? Can we
> > truly count them as "many", as you repeatedly claim?
>
> Why do we restrict this to actively maintained and supported drivers
> (I think abandonware drivers are highly relevant here...)? And why
> are you asking about drivers that work on only one platform? Greg
> promised support for every platform that has the right bus to plug a
> device into. So things like drivers that don't work on SMP or 64-bit
> or big-endian platforms also violate that pledge, even if there's more
> than one 32-bit little-endian uniprocessor platform where the driver
> does work.
For almost all _new_ drivers, this is the case. They are well supported
and build on all platforms.
Yes, there are plenty of old drivers that are marked BROKEN (look at the
scsi tree for some examples there), and some that still use cli (which
the kernel janitors keep trying to fix up but the very fact that no one
has the hardware to test their changes keeps that effort from going
anywhere.) But that is not the case for new stuff, nor is it the case
for things I am offing here.
> I don't really understand why it's so hard to accept that sometimes
> even open specs aren't enough to get great Linux support.
Yeah, sometimes you really need someone who has the device in a machine
that still boots :)
thanks,
greg k-h
Roland Dreier wrote:
> > Which of these actively maintained and supported drivers work on only
> > one platform[1], and are excluded from enterprise distros? Can we
> > truly count them as "many", as you repeatedly claim?
>
> Why do we restrict this to actively maintained and supported drivers
> (I think abandonware drivers are highly relevant here...)? And why
> are you asking about drivers that work on only one platform? Greg
> promised support for every platform that has the right bus to plug a
> device into. So things like drivers that don't work on SMP or 64-bit
> or big-endian platforms also violate that pledge, even if there's more
> than one 32-bit little-endian uniprocessor platform where the driver
> does work.
You were complaining about drivers that work on only one platform.
Thus, I asked for list of said drivers, drivers that break Greg's pledge.
I'm betting they are uniformly ancient ISA or m68k or whatnot drivers.
> Anyway, grepping for stuff like BROKEN or !64BIT or X86 in the Kconfig
> dependencies under drivers/ finds tons of hits. I don't have time to
> scan through and figure out which meet your criteria, and I honestly
Translation: you don't have a clue what you are talking about, because
you haven't even bothered to do such a search yourself.
This is /your/ criteria we are discussing. /You/ keep talking about
"many" (your words) non-portable and broken drivers. And now you
actively avoid citing examples. Oh, except for one: aha154x, an
ancient ISA driver. So, yes, I concede that if a vendor appears and
wants to push in a new driver for ancient ISA hardware that nobody in
the planet uses... it might not find a volunteer. Hooray for goofy
examples.
> I don't really understand why it's so hard to accept that sometimes
> even open specs aren't enough to get great Linux support.
And hooray for shifting arguments. If this is your summary of the
thread, do you now concede that Greg was not being disingenuous? Open
specs was not the sum toto of Greg's piece.
Jeff
> You were complaining about drivers that work on only one
> platform. Thus, I asked for list of said drivers, drivers that break
> Greg's pledge.
When did I ever say "one platform"? If I did, it was an error -- I've
tried to consistently talk about not every platform.
> I'm betting they are uniformly ancient ISA or m68k or whatnot drivers.
So what? Greg didn't restrict his offer to "mainstream" devices. And
Greg said "[the driver] will be automatically kept up to date and
working through all Linux kernel API changes." Not "we'll maintain
the driver until we lose interest." And anyway, if I dig for a few
minutes I find modern mainstream stuff like ipw2200 that is seemingly
x86-only. (Although of course ipw2200 is straight from Intel)
> And hooray for shifting arguments. If this is your summary of the
> thread, do you now concede that Greg was not being disingenuous? Open
> specs was not the sum toto of Greg's piece.
Perhaps "disingenous" was the wrong choice of word, though, since you
and Greg seem to sincerely believe that a spec dump is all that a
vendor needs to do. I'll concede that maybe I should have used the
word "naive" instead. But I absolutely feel that Greg should not be
making promises on behalf of "the Linux kernel community."
Go back and reread Greg's original email. He said:
> All that is needed is some kind of specification that describes how
> your device works, or the email address of an engineer that is willing
> to answer questions every once in a while. A few sample devices might
> be good to have so that debugging doesn't have to be done by email,
> but if necessary, that can be done.
Let me repeat Greg's words one more time: "All that is needed is some
kind of specification." So I honestly don't know what you mean by
"open specs was not the sum toto of Greg's piece."
Here is what he promised once that spec is released:
> In return, you will receive a complete and working Linux driver that
> is added to the main Linux kernel source tree.
...
> This driver will then be automatically included in all Linux
> distributions, including the "enterprise" ones. It will be
> automatically kept up to date and working through all Linux kernel
> API changes. This driver will work with all of the different CPU
> types supported by Linux, the largest number of CPU types supported
> by any operating system ever before in the history of computing.
...
> As for support, the driver will be supported through email by the
> original developers, when they can help out, and by the
> "enterprise" Linux distributors as part of their service agreements
> with their customers.
...
> This offer is in effect for all different types of devices, from USB
> toys to PCI video devices to high-speed networking cards. If you
> manufacture it, we can get Linux drivers working for it.
To me, it's clear that historically the community hasn't delivered on
this. So I don't like promising something that we haven't been able
to follow through on in the past. If a vendor takes Greg's offer, and
then the community, for whatever reason, fails to deliver on
everything, then that makes us all (including me!) look bad just
because of Greg's hyperbolic promises.
- R.
Jeff Garzik wrote:
>> I guess Nvidia ADMA is pretty much
>> done now.
>
> Yep. Without docs, even. And its supported by enterprise distros.
Well, the "docs" I was using was a half-finished, broken version of the
driver released by NVidia which had to be significantly revised, and the
public ADMA spec which the hardware was vaguely based on and which a few
things could be inferred from. If NVidia had just released the docs it
would have been much easier, I would have gladly written it from
scratch. There are still things in the driver that could likely be
improved if we had the actual hardware documents, registers that we
don't know what half the bits are for, etc.
Having the vendor release a driver without hardware information is fine,
as long as it works perfectly or they maintain it when bugs are found.
Otherwise, anyone else trying to fix it will end up with an exercise in
"why was it doing this? should it be doing this instead?"
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
On Tue, Jan 30, 2007 at 02:19:24PM -0800, Roland Dreier wrote:
> > You mean the bcm43xx wireless driver that's been upstream for months?
>
> Sorry, yes. For some reason I thought it was blocked on the dscape
> merge but obviously I was wrong. So a reverse-engineered driver got
> upstream WAY FASTER than a driver where the vendor published specs and
> GPLed source.
>
> Why did that happen? I would argue that it was because way more
> people cared about the broadcom driver (since the chip was in apple
> laptops and the wrt54g among other things). That developer and user
> interest is more important than the info provided by the vendor.
That may be partially true. But the main reason is that the rt2x00
team chose to depend upon the heretofore unmergeable devicescape stack.
In contrast, the bcm43xx driver had a port for the ieee80211+softmac
stack that was ready for merge much earlier. This is more a result
of confusion in one area of kernel development than an indictment of
Linux drivers in general.
FWIW, we are closing-in on a merge for the devicescape stack.
(No, really!) So, hopefully wireless will soon cease to be such a
fertile ground for bad examples...
Thanks,
John
--
John W. Linville
[email protected]
On 1/31/07, Roland Dreier <[email protected]> wrote:
> To me, it's clear that historically the community hasn't delivered on
> this. So I don't like promising something that we haven't been able
> to follow through on in the past. If a vendor takes Greg's offer, and
> then the community, for whatever reason, fails to deliver on
> everything, then that makes us all (including me!) look bad just
> because of Greg's hyperbolic promises.
I can't talk for every subsystem, but what we have under the DVB
subsystem, for the devices that we have access to specs we have well
behaved drivers, many have even complimented that they work much
better than their windows counterparts.
I have even received mails from some vendors that some of the Linux
drivers behave better than their own windows drivers.
We can't count on reverse eng 'd drivers (or even drivers written with
a lot of guess work due to lack of specifications), they don't behave
nice. So at least if the vendors were to provide some specs in that
direction, it would help to make those drivers better.
So i think to a certain as to what i can say, probably you are wrong.
regards,
manu
Roland Dreier wrote:
> To me, it's clear that historically the community hasn't delivered on
How is that clear? As noted in the specific examples I provided, that
is how a large number of popular drivers and subsystems have been developed.
> this. So I don't like promising something that we haven't been able
> to follow through on in the past. If a vendor takes Greg's offer, and
It's a good thing we've delivered on this, throughout Linux's history, then.
> then the community, for whatever reason, fails to deliver on
> everything, then that makes us all (including me!) look bad just
> because of Greg's hyperbolic promises.
The only difference between Greg's offer and offers made by other
developers to vendors is that his was public on LKML, and the subject
line concluded with an exclamation point.
I tell hardware vendors the same thing all the time -- just get the
specs to me or another capable developer, and we'll work with you to get
Linux support going.
So far, we have ATA, USB, ethernet, audio, and several other positive
examples of this working in the real world. And your counter-examples?
Ancient ISA drivers.
Jeff
On Tue, Jan 30, 2007 at 07:16:39PM -0500, Jeff Garzik wrote:
>
> The only difference between Greg's offer and offers made by other
> developers to vendors is that his was public on LKML, and the subject
> line concluded with an exclamation point.
Heh, never underestimate a well-placed ! :)
Also, one big and new portion is the fact that we now have in place a
system to handle NDAs for those companies that do not wish to provide
specs to the whole world.
thanks,
greg k-h
> > To me, it's clear that historically the community hasn't delivered on
>
> How is that clear? As noted in the specific examples I provided, that
> is how a large number of popular drivers and subsystems have been
> developed.
Yes, I agree that it often works. What I'm arguing is that it doesn't
ALWAYS work. And Greg is promising (in effect, on my behalf) that "If
you give us specs, then we WILL have drivers." As I've said several
times, I'm all for encouraging vendors to open specs. The only thing
I don't like is marketing open specs by making promises that we may
not be able to keep.
> The only difference between Greg's offer and offers made by other
> developers to vendors is that his was public on LKML, and the subject
> line concluded with an exclamation point.
>
> I tell hardware vendors the same thing all the time -- just get the
> specs to me or another capable developer, and we'll work with you to
> get Linux support going.
There's a big difference, because Greg's offer goes to every vendor,
present and future, and promises a perfect driver in return for a spec
dump. I have no problem with what you're telling vendors. And I
think it's worth noting that you say, "we'll work with you to get
Linux support going." You don't say, "all we need is specs to get
your driver into enterprise distros" -- you say that vendors need to
"work" with us, not just dump specs.
> So far, we have ATA, USB, ethernet, audio, and several other positive
> examples of this working in the real world. And your
> counter-examples? Ancient ISA drivers.
I think that's somewhat of a misrepresentation. So far in this
thread, I've also raised Ralink wireless (stuck out-of-tree until
after the HW is EOLed) and USB Video Class (apparently also stuck out
of tree, in spite of vendor support from Logitech). And Dave Airlie
mentioned XGI 3d HW.
Again, yes, I admit that releasing specs usually is the best way to
get Linux support. Just don't promise (on my behalf) a perfectly
portable driver that will be maintained forever if only a vendor will
release specs. Sometimes it works -- heck, usually it works -- as
long as there's a developer interested.
I think the message we should be sending is something more like:
There are lots of people who are happy to write Linux drivers, given
specs. Releasing specs is the best, easiest way to get Linux
support written at minimal cost. The advantages to this for a
hardware vendor are:
- the driver is likely to be merged upstream, which has several
benefits (continuing maintenance, distro inclusion, etc).
- the driver is likely to be portable to any platform where the
device physically has a chance at working.
And we even have this new mechanism for managing specs that you can
only release under NDA.
And that that last NDA management bit really is the big news, which
gets lost in the way Greg phrased things. (I've buried the lede in my
message too -- someone with more marketing savvy should rewrite it)
- R.
On Tue, Jan 30, 2007 at 11:10:20AM -0800, Greg KH wrote:
> On Tue, Jan 30, 2007 at 09:45:50AM -0800, Roland Dreier wrote:
>...
> > 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.
>...
Wrinting a driver for shiny new hardware is cool.
But understanding and maintaining an already existing driver and working
on bug reports for this driver is something not-so-cool that would be
required in many areas of the kernel.
Would someone from your long list of people e.g. be willing to maintain
drivers/block/floppy.c ?
> thanks,
>
> greg k-h
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
On 1/31/07, Adrian Bunk <[email protected]> wrote:
> Would someone from your long list of people e.g. be willing to maintain
> drivers/block/floppy.c ?
I have a floppy drive! Will have to go buy some disks though. What's
wrong with it?
Trent
On Wed, Jan 31, 2007 at 02:13:40AM +0100, Adrian Bunk wrote:
> On Tue, Jan 30, 2007 at 11:10:20AM -0800, Greg KH wrote:
> > On Tue, Jan 30, 2007 at 09:45:50AM -0800, Roland Dreier wrote:
> >...
> > > 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.
> >...
>
> Wrinting a driver for shiny new hardware is cool.
>
> But understanding and maintaining an already existing driver and working
> on bug reports for this driver is something not-so-cool that would be
> required in many areas of the kernel.
>
> Would someone from your long list of people e.g. be willing to maintain
> drivers/block/floppy.c ?
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?
:)
Seriously, if you need help with something like this, bring it up on the
kernel-janitors list, there are lots of people there that are willing to
help out with stuff like long-term maintenance and bug fixing but don't
know where to start.
That's also where the majority of the people who have volunteered to
help are also hanging out at.
thanks,
greg k-h
On Tue, Jan 30, 2007 at 05:07:57PM -0800, Roland Dreier wrote:
> > > To me, it's clear that historically the community hasn't delivered on
> >
> > How is that clear? As noted in the specific examples I provided, that
> > is how a large number of popular drivers and subsystems have been
> > developed.
>
> Yes, I agree that it often works. What I'm arguing is that it doesn't
> ALWAYS work. And Greg is promising (in effect, on my behalf) that "If
> you give us specs, then we WILL have drivers." As I've said several
> times, I'm all for encouraging vendors to open specs. The only thing
> I don't like is marketing open specs by making promises that we may
> not be able to keep.
I really think we can keep these promises. A number of us have been
doing just that for many years now, and I don't see any reason why we
would stop doing that now.
I would _love_ to be inundated with specs, so many that we run out of
developers to work on the devices. But I really don't see that
happening any time soon, as there's not that many devices that Linux
doesn't already support.
And if such a situation does happen, perhaps I will be able to convince
some distro companies to pony up the development man-power to help us
from going back on our promise... I know quite a few companies would
love to help out just a "problem" as it is in their best interest to
have Linux support as many devices as possible.
So please, don't be so down on the offer, you don't have to do any work
if you don't want to :)
thanks,
greg k-h
On 1/31/07, Greg KH <[email protected]> wrote:
> On Wed, Jan 31, 2007 at 02:13:40AM +0100, Adrian Bunk wrote:
> > On Tue, Jan 30, 2007 at 11:10:20AM -0800, Greg KH wrote:
> > > On Tue, Jan 30, 2007 at 09:45:50AM -0800, Roland Dreier wrote:
> > >...
> > > > 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.
> > >...
> >
> > Wrinting a driver for shiny new hardware is cool.
> >
> > But understanding and maintaining an already existing driver and working
> > on bug reports for this driver is something not-so-cool that would be
> > required in many areas of the kernel.
> >
> > Would someone from your long list of people e.g. be willing to maintain
> > drivers/block/floppy.c ?
>
> 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?
>
> :)
>
> Seriously, if you need help with something like this, bring it up on the
> kernel-janitors list, there are lots of people there that are willing to
> help out with stuff like long-term maintenance and bug fixing but don't
> know where to start.
http://bugzilla.kernel.org
:)
Bart
On Wed, Jan 31, 2007 at 11:19:15AM +1000, Trent Waddington wrote:
> On 1/31/07, Adrian Bunk <[email protected]> wrote:
> >Would someone from your long list of people e.g. be willing to maintain
> >drivers/block/floppy.c ?
>
> I have a floppy drive! Will have to go buy some disks though. What's
> wrong with it?
There isn't something specific wrong.
It's simply that the last time someone completely understood this 120 kB
driver was in the last millenium.
That comes up every few months when some bug report arrives or in the
cases when a patch breaks the floppy driver.
> Trent
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
On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
> On Wed, Jan 31, 2007 at 02:13:40AM +0100, Adrian Bunk wrote:
> > On Tue, Jan 30, 2007 at 11:10:20AM -0800, Greg KH wrote:
> > > On Tue, Jan 30, 2007 at 09:45:50AM -0800, Roland Dreier wrote:
> > >...
> > > > 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.
> > >...
> >
> > Wrinting a driver for shiny new hardware is cool.
> >
> > But understanding and maintaining an already existing driver and working
> > on bug reports for this driver is something not-so-cool that would be
> > required in many areas of the kernel.
> >
> > Would someone from your long list of people e.g. be willing to maintain
> > drivers/block/floppy.c ?
>
> 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?
>
> :)
Other than with the ISA drivers example, at least everyone has the
hardware... ;-)
> Seriously, if you need help with something like this, bring it up on the
> kernel-janitors list, there are lots of people there that are willing to
> help out with stuff like long-term maintenance and bug fixing but don't
> know where to start.
>
> That's also where the majority of the people who have volunteered to
> help are also hanging out at.
The idea of some kind of task list already appeared in this thread -
this might be the best way to publish and track such issues.
> thanks,
>
> greg k-h
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
On 1/29/07, Greg KH <[email protected]> wrote:
> Free Linux Driver Development!
>
> Yes, that's right, the Linux kernel community is offering all companies
> free Linux driver development. ...
[snip]
> [1] for the CPUs that support the bus types that your device works on.
Bravo! Now, is there a message in the same spirit that can be
tailored to embedded space, especially to SoC vendors and (even more
importantly) their customers? Something along the lines of:
"We understand that embedded hardware is frequently buggy and that SoC
vendors are doing well if their own internal software people can get
enough help from the chip guys to bring up enough customer-driven use
cases to win a few design-ins.
We sympathize with embedded developers who stay up nights with an
O-scope and a JTAG emulator reverse-engineering the hardware behavior,
trying to figure out which this order of operations works and this
other one doesn't.
We have the software tools and the competence to quantify the
potential gains from current toolchains and kernels, aggressive
compilation options, and in-tree power/latency management strategies,
so that you can build a business case against "fire and forget" SDKs
based on ancient compilers, obsolete kernels, and unmaintained
out-of-tree patches.
We will help platform integrators bridge the gap between the chip
architects' claims about device performance and the condition in which
the BSP guys toss drivers over the fence.
You can hang onto the hardware and profit from coaching and code
review, or you can send us a board and whatever doco you've got, and
we'll figure it out.
All we ask is that 1) SoC vendors authorize customers to do an NDA
with OSDL and pass vendor NDA material along to us; 2) when the
product ships, all participants are free to exercise GPL rights with
respect to the chip support and driver code produced; and 3) platform
integrators cooperate with the rework usually needed as code merges
towards Linus's tree."
Or is this a pipe dream?
Cheers,
- Michael
Jeff Garzik wrote:
>> When we switch to PATA and drop old ide stack, what will happen ?
>> Will all driver be ported and full-feature, or some will be obsoleted ?
>
> All drivers for which we can find users will be ported. If any features
> disappear that's a bug.
>
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 ...
-andrey
On Tue, Jan 30, 2007 at 06:27:29PM -0800, Michael K. Edwards wrote:
> On 1/29/07, Greg KH <[email protected]> wrote:
> >Free Linux Driver Development!
> >
> >Yes, that's right, the Linux kernel community is offering all companies
> >free Linux driver development. ...
> [snip]
> >[1] for the CPUs that support the bus types that your device works on.
>
> Bravo! Now, is there a message in the same spirit that can be
> tailored to embedded space, especially to SoC vendors and (even more
> importantly) their customers? Something along the lines of:
>
> "We understand that embedded hardware is frequently buggy and that SoC
> vendors are doing well if their own internal software people can get
> enough help from the chip guys to bring up enough customer-driven use
> cases to win a few design-ins.
>
> We sympathize with embedded developers who stay up nights with an
> O-scope and a JTAG emulator reverse-engineering the hardware behavior,
> trying to figure out which this order of operations works and this
> other one doesn't.
>
> We have the software tools and the competence to quantify the
> potential gains from current toolchains and kernels, aggressive
> compilation options, and in-tree power/latency management strategies,
> so that you can build a business case against "fire and forget" SDKs
> based on ancient compilers, obsolete kernels, and unmaintained
> out-of-tree patches.
>
> We will help platform integrators bridge the gap between the chip
> architects' claims about device performance and the condition in which
> the BSP guys toss drivers over the fence.
>
> You can hang onto the hardware and profit from coaching and code
> review, or you can send us a board and whatever doco you've got, and
> we'll figure it out.
>
> All we ask is that 1) SoC vendors authorize customers to do an NDA
> with OSDL and pass vendor NDA material along to us; 2) when the
> product ships, all participants are free to exercise GPL rights with
> respect to the chip support and driver code produced; and 3) platform
> integrators cooperate with the rework usually needed as code merges
> towards Linus's tree."
>
> Or is this a pipe dream?
Oh, I would love to see something like that happen :)
As I come from an embedded background, I love to see Linux running in
tiny systems. So anything I can do to help out with that I'd love to
offer.
But being able to read the minds of SOC hardwre engineers and decode all
of the documentation errors they produce is enough to drive one crazy,
my condolences go out to everyone in that situation...
good luck,
greg k-h
On Jan 31, 2007, at 12:26 AM, Greg KH wrote:
> On Tue, Jan 30, 2007 at 06:27:29PM -0800, Michael K. Edwards wrote:
>> On 1/29/07, Greg KH <[email protected]> wrote:
>>> Free Linux Driver Development!
>>>
>>> Yes, that's right, the Linux kernel community is offering all
>>> companies
>>> free Linux driver development. ...
>> [snip]
>>> [1] for the CPUs that support the bus types that your device
>>> works on.
>>
>> Bravo! Now, is there a message in the same spirit that can be
>> tailored to embedded space, especially to SoC vendors and (even more
>> importantly) their customers? Something along the lines of:
>>
>> "We understand that embedded hardware is frequently buggy and that
>> SoC
>> vendors are doing well if their own internal software people can get
>> enough help from the chip guys to bring up enough customer-driven use
>> cases to win a few design-ins.
>>
>> We sympathize with embedded developers who stay up nights with an
>> O-scope and a JTAG emulator reverse-engineering the hardware
>> behavior,
>> trying to figure out which this order of operations works and this
>> other one doesn't.
>>
>> We have the software tools and the competence to quantify the
>> potential gains from current toolchains and kernels, aggressive
>> compilation options, and in-tree power/latency management strategies,
>> so that you can build a business case against "fire and forget" SDKs
>> based on ancient compilers, obsolete kernels, and unmaintained
>> out-of-tree patches.
>>
>> We will help platform integrators bridge the gap between the chip
>> architects' claims about device performance and the condition in
>> which
>> the BSP guys toss drivers over the fence.
>>
>> You can hang onto the hardware and profit from coaching and code
>> review, or you can send us a board and whatever doco you've got, and
>> we'll figure it out.
>>
>> All we ask is that 1) SoC vendors authorize customers to do an NDA
>> with OSDL and pass vendor NDA material along to us; 2) when the
>> product ships, all participants are free to exercise GPL rights with
>> respect to the chip support and driver code produced; and 3) platform
>> integrators cooperate with the rework usually needed as code merges
>> towards Linus's tree."
>>
>> Or is this a pipe dream?
>
> Oh, I would love to see something like that happen :)
>
> As I come from an embedded background, I love to see Linux running in
> tiny systems. So anything I can do to help out with that I'd love to
> offer.
>
> But being able to read the minds of SOC hardwre engineers and
> decode all
> of the documentation errors they produce is enough to drive one crazy,
> my condolences go out to everyone in that situation...
>
> good luck,
>
> greg k-h
Thanks. It gets even better when they change things between
revisions of the same HW block.
Out of interest are you was this geared to any particular SoC's/
architectures?
- k
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
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
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
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
> 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
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
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]>
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/
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.
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
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
> 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.
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
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.
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
--
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
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/
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
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/
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
--
-----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-----
> 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 %% http://www.bobcopeland.com
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
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
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/
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
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
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
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
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
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
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/
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 :
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 :
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
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
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
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
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
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
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
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
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
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
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 wayyyyyy 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
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 wayyyyyy 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
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
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?
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
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
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
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
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
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
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
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 wayyyyyy 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
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/
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
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
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 -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
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.
> 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
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
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.
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
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.
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
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 -- http://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!
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.
On Thu, Feb 01, 2007 at 09:45:45PM EST, 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.
I came into this discussion late as I only read LKML in summary form, but I feel I need to address
several misconceptions here.
>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.
As Michael Buesch has explained, bcm43xx only changes the eeprom under very controlled circumstances
that never happen accidentally. It is much more likely that your Windows driver uses V4 firmware,
whereas bcm43xx uses V3. Without a power-off step to erase the firmware the results are likely to be
indeterminate.
>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).
It is _NOT_ true that bcm43xx only works with 802.11b. My AP is set in 802.11g-only mode and I have
been using bcm43xx with it for nearly a year. What is true is that none of the OFDM rates work
because of some unknown bug, probably in initialization. As a result, we are limited to a maximum
data rate of 11Mbs, but it is still running in 802.11g mode!
>> 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. :)
I certainly would hope for a even a little cooperation from Broadcom; however, it is not easy to
avoid getting their hardware, particularly with laptops. When I recently upgraded, my primary aims
were (1) a 14 inch screen as the native resolution of a larger one makes things too small for my
eyes and reduced resolution looks crappy on an LCD, and (2) an AMD 64 X2 processor to run an x86_64
OS. The kind of wireless card contained within was not an issue, although the BCM4311 that I got
turned out to be a benefit as I became the first developer with the hardware needed to find and fix
two major outstanding bugs.
While I'm on my soapbox, I want to thank the group that reverse-engineered the Broadcom chips and
the group that did the early coding on the driver. Although the current driver still has its faults,
the fact that there is a working driver that doesn't hang or crash an SMP version of Linux and
offers usable wireless service for such a complicated piece of totally undocumented hardware is a
real tribute to those two groups. Thanks guys.
Larry Finger
bcm43xx Maintainer
On Sunday 04 February 2007 07:26, Larry Finger wrote:
> What is true is that none of the OFDM rates work
> because of some unknown bug, probably in initialization. As a result, we are limited to a maximum
> data rate of 11Mbs, but it is still running in 802.11g mode!
That's also not true for me. I really don't understand why people keep saying
that rates above 11MBit don't work, because they do (and always did) on all
of my 4306 cards.
Sure, rates above 11M don't work for 4318 and similiar, but for those cards
not even 11M works, so one has to use 1M or something.
And there is absolutely no limit to 11MBit in the code.
--
Greetings Michael.
Greg KH <[email protected]> writes:
> Why would a userspace driver not work out for this. We already can
> saturate the USB bus with a userspace program
That is unfortunately not quite true. I have a (unfortunately
proprietary) driver for a USB device that simply cannot be implemented
in userspace. The USB device is a measurement device that pushes
close to 800 kBytes/second of data through a FT245 chip. The
measurement device does no flow control at all, it just presents a
sample every 125 us to the FT245 and with only 256 bytes of buffer in
the FT245 the only way to handle that is to have two URBs in flight at
the same time, and I haven't found any way to do that in a robust and
non-racey way from userspace. So the comment "The USB subsystem has
changed a lot over time, and it has been possible to create userspace
USB drivers using usbfs/libusb/gadgetfs that operate as fast as the
USB bus allows." from feature-removal-schedule.txt is wrong I
think. :-(
Personally I'd much prefer to release the driver as open source, but
as a consultant you don't get to decide what the customer does. So
now they sit there with a driver that warns them that it'll stop
working after february 2008.
On a different topic, my personal pet peeve is USB scanners. There
seems to be just a handful of different manufacturers of chips used in
USB scanners: Realtek and Genesys covers 90% of the scanners. The
SANE team has done a wonderful job of reverse engineering a lot of
scanners, but the models change so fast that there seems to be no
chance of keeping up. If the chip manufacturers just released specs
for their chips and the scanner manufacturers could then document what
settings to use Linux could have support for almost all USB scanners
on the market, and it would probably cost them very little to do that.
If I could find a good (4800-9600 dpi) scanner which said "supported
by SANE" on the box I'd buy it immedately.
/Christer
--
"Just how much can I get away with and still go to heaven?"
Christer Weinigel <[email protected]> http://www.weinigel.se
On Sun, Feb 04, 2007 at 02:29:13PM +0100, Christer Weinigel wrote:
> Greg KH <[email protected]> writes:
>
> > Why would a userspace driver not work out for this. We already can
> > saturate the USB bus with a userspace program
>
> That is unfortunately not quite true. I have a (unfortunately
> proprietary) driver for a USB device that simply cannot be implemented
> in userspace. The USB device is a measurement device that pushes
> close to 800 kBytes/second of data through a FT245 chip. The
> measurement device does no flow control at all, it just presents a
> sample every 125 us to the FT245 and with only 256 bytes of buffer in
> the FT245 the only way to handle that is to have two URBs in flight at
> the same time, and I haven't found any way to do that in a robust and
> non-racey way from userspace.
People do that today just fine with multiple userspace urbs in flight
using usbfs directly. So it is possible and can be done.
If there are issues with the usbfs code to prevent you from doing this,
please let us know.
Or perhaps your device just needs to add some flow control to it :)
good luck,
greg k-h
On Sun, Feb 04, 2007 at 03:04:58AM -0800, Parav Pandit wrote:
> Hi,
>
> So how can an individual like me having ardor, contribute in Free
> driver development? What is the eligibility criteria and process for
> contributing in this activity?
>
> In brief, I come with background of developing, verifying device
> drivers for Linux, Apple MAC OS X, DSP/BIOS RTOS for HBAs, LCD
> controllers, networking L2-L3 ASIC devices, platform management
> drivers, few Samsung SoC peripherals.
Just let me know if you are interested in participating, and what types
of devices you wish to write drivers for (USB, PCI, network, etc.)
thanks,
greg k-h
Hi Greg,
Although I am a bit of a cynic, I really hope that this endeavor works
the way you hope.
I'd also like to offer my services to this quest of yours. If you get
any SD, MMC or SDIO requests, feel free to pass them along to me. I am
not a big fan of debug-by-email though, so I'd prefer vendors who either
can provide samples or where the hardware is cheap and freely available
so I can just go out and by one.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
On 2/4/07, Greg KH <[email protected]> wrote:
>
> Just let me know if you are interested in participating, and what types
> of devices you wish to write drivers for (USB, PCI, network, etc.)
>
> thanks,
>
> greg k-h
>
I would like to participate; however, for people who is not at USA
(say, Europe), are there fair chances to get samples of devices to
work with?
--
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm
Jan Engelhardt wrote:
> 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.)
>
Doing it by MARK a tables and rules is an ugly method, and like anything
with is spread over many places (the mangle table to MARK), then 'rules'
and 'tables', spreading an action into many places increases the chances
of getting parts out of sync and having the whole not work as intended.
And the 'ip' man page defines everything in BNF, which was hot stuff
when Algol-60 came out (1960) but which is only readable to people who
use it frequently.
The ipt_ROUTE allows putting all parts of of the action, from defining
the set of matching packets to specifying the desired result, the
routing. And if that changes, it need only change in one place.
Making good administration difficult because it fits some pedantic metal
model is NOT a good way to decide which features to offer in a kernel.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
Greg KH <[email protected]> writes:
> Or perhaps your device just needs to add some flow control to it :)
Physical processes are hard to pause. :-)
But yes, adding a 16kByte FIFO before the FT245 would have made life
so much easier for me, but unfortunately the thing that drives the
hardware choice is cost, cost and cost.
/Christer
--
"Just how much can I get away with and still go to heaven?"
Christer Weinigel <[email protected]> http://www.weinigel.se
First off, compliments to this announcement, I liked it very much!
Some comment regarding those "volunteers, waiting to get some real work" :)
> > OK, but why isn't your army of volunteers fixing them?
> They don't know about them, or they don't have the hardware to test?
> Seriously, let the kernel-janitor's project know about any issues you
> have and they will be glad to jump on it. Those people are just
> chomping a the bit to do something a bit bigger than "compiler warning
> cleanups" :)
So many times i have seen good ideas brought up, kernel patches being written, posted to lkml, being developed outside mainline for a while and then being forgotten some time later due to lack of energy of some individual to get this into mainline.
If there is an noticeably number of talented programmers (unfortunately, i`m not) , so why not "feeding" them the right way ? Where is those public and transparent and moderated Linux-Kernel "ToDo"- or "Keep an eye on"-list, sorted by priorities, with sort of a "vote for this feature"-button, so those guys have something they can pick up? There is so much great stuff and ideas out there where they could put their work onto or getting involved, it just needs to be found or sort of being "managed" a little bit better.
For myself, i`m waiting for so quite some things to get "one step further", but they are more or less tied to some single individuals, for which you just cannot send some "hey, what`s up with your project"-message every second day. The interest in many nice projects often is quite low and evolution quite slow, but not only because of the fact that they aren`t great, but more because of not getting widely known. It`s not always missing specs, it`s also some missing noise/feedback for different features or missing of some "driving force" to bring things forward. How should one developer know that somebody needs a feature if those who could probably need it don`t request it? Maybe just because of the fact that they even imagine that such feature would be possible ?
Where is those efforts for fixing/integrating fantastic cowloop?
What about badram/badmem patch ?
Compressed Ccaching ?
Somebody helping with development of dm-loop or extend loop.c to support more than 256 devices ?
Replacement of proprietary, unstable and unelegant vmware-lopp for being able to mount vmware .vmdk files ? Internal Spec for this is open, dm-userspace could be some infrastructure for this, but the author seems to have other priorities....
dm-cow, zfs-fuse - anybody ?
Kernel based target for AoE (Ata over Ethernet) ? (there are two independent implementations, but both got stuck at some early experimental stage)
Just my 2 cents.
Roland K.
Sysadmin/System Engineer
ps:
This isn`t meant to criticise any of you kernel developers since you`re doing fantastic work!
_______________________________________________________________________
Viren-Scan f?r Ihren PC! Jetzt f?r jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
> From: devzero web.de
> Newsgroups: gmane.linux.kernel
> Subject: Re: Free Linux Driver Development!
> Date: Sun, 04 Feb 2007 22:37:33 +0100
> Organization: http://freemail.web.de/
> Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/489586>
> First off, compliments to this announcement, I liked it very much!
>
> Some comment regarding those "volunteers, waiting to get some real work" :)
>
>> > OK, but why isn't your army of volunteers fixing them?
>
>> They don't know about them, or they don't have the hardware to test?
>> Seriously, let the kernel-janitor's project know about any issues you
>> have and they will be glad to jump on it. Those people are just
>> chomping a the bit to do something a bit bigger than "compiler warning
>> cleanups" :)
>
> So many times i have seen good ideas brought up, kernel patches being written, posted to lkml, being developed outside mainline for a while and then being forgotten some time later due to lack of energy of some individual to get this into mainline.
>
> If there is an noticeably number of talented programmers (unfortunately, i`m not) , so why not "feeding" them the right way ? Where is those public and transparent and moderated Linux-Kernel "ToDo"- or "Keep an eye on"-list, sorted by priorities, with sort of a "vote for this feature"-button, so those guys have something they can pick up? There is so much great stuff and ideas out there where they could put their work onto or getting involved, it just needs to be found or sort of being "managed" a little bit better.
>
> For myself, i`m waiting for so quite some things to get "one step further", but they are more or less tied to some single individuals, for which you just cannot send some "hey, what`s up with your project"-message every second day. The interest in many nice projects often is quite low and evolution quite slow, but not only because of the fact that they aren`t great, but more because of not getting widely known. It`s not always missing specs, it`s also some missing noise/feedback for different features or missing of some "driving force" to bring things forward. How should one developer know that somebody needs a feature if those who could probably need it don`t request it? Maybe just because of the fact that they even imagine that such feature would be possible ?
>
> Where is those efforts for fixing/integrating fantastic cowloop?
> What about badram/badmem patch ?
> Compressed Ccaching ?
> Somebody helping with development of dm-loop or extend loop.c to support more than 256 devices ?
> Replacement of proprietary, unstable and unelegant vmware-lopp for being able to mount vmware .vmdk files ? Internal Spec for this is open, dm-userspace could be some infrastructure for this, but the author seems to have other priorities....
> dm-cow, zfs-fuse - anybody ?
> Kernel based target for AoE (Ata over Ethernet) ? (there are two independent implementations, but both got stuck at some early experimental stage)
A quick answer for philosophers:
<http://www.linuxjournal.com/article/7272>
For example, i don't know if somebody volunteered to be a bug-buddy in
google, see Andrew's 2.6.20-rc6-mm1 announcement. It seems no, as he
still forwards bugzilla reports to developers/maintainers.
I myself am new. But anyway, i can write a little bit of HOWTO
-- effectively handle (among others) LKML, to break free from myths,
-- to not afraid emacs as good editor for issues like symbol-searching (TAGS),
whitespace, spell (typos) and such,
-- having linux tree up-today with small bandwidth: mirrors, patches, quilt
of course if such things prevent people from participating.
[:(ot) As for Greg's message, imho somebody was bored. There is plenty ;]
[: of work *in* the kernel, not only in drivers/ related part of it... ;]
> Just my 2 cents.
So my.
Greetings.
--
-o--=O`C info emacs : not found /. .\ ( is there any reason to live? )
#oo'L O info make : not found o ( yes --- R.I.P. FSF+RMS )
<___=E M man gcc : not found `-- ( viva Debian Operating System )
On Sun, Feb 04, 2007 at 08:08:32PM +0100, Miguel Ojeda wrote:
> On 2/4/07, Greg KH <[email protected]> wrote:
> >
> >Just let me know if you are interested in participating, and what types
> >of devices you wish to write drivers for (USB, PCI, network, etc.)
> >
> >thanks,
> >
> >greg k-h
> >
>
> I would like to participate; however, for people who is not at USA
> (say, Europe), are there fair chances to get samples of devices to
> work with?
Not all of the companies asking for this work are in the US, so I don't
see any reason why we should limit our developers to just one country,
that wouldn't be very fair...
Just let me know what types of devices you are interested in working on.
thanks,
greg k-h
On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
> On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
> > 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?
> >
> > :)
>
> Other than with the ISA drivers example, at least everyone has the
> hardware... ;-)
Wrong. I abandoned all floppy drives some years ago. I'd actually
vote for removing the floppy driver from the kernel completely.
Well, at work i probably have an USB floppy lying around somewhere,
but i doubt that it uses floppy.c ;-),
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
Greg KH napsal(a):
> On Sun, Feb 04, 2007 at 08:08:32PM +0100, Miguel Ojeda wrote:
>> On 2/4/07, Greg KH <[email protected]> wrote:
>>> Just let me know if you are interested in participating, and what types
>>> of devices you wish to write drivers for (USB, PCI, network, etc.)
>> I would like to participate; however, for people who is not at USA
>> (say, Europe), are there fair chances to get samples of devices to
>> work with?
>
> Not all of the companies asking for this work are in the US, so I don't
> see any reason why we should limit our developers to just one country,
> that wouldn't be very fair...
>
> Just let me know what types of devices you are interested in working on.
Then, I want to be involved too. I'm interested in PCI and network devices.
thanks,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
On Mon, Feb 05, 2007 at 04:24:21PM +0100, Jiri Slaby wrote:
> Greg KH napsal(a):
> >On Sun, Feb 04, 2007 at 08:08:32PM +0100, Miguel Ojeda wrote:
> >>On 2/4/07, Greg KH <[email protected]> wrote:
> >>>Just let me know if you are interested in participating, and what types
> >>>of devices you wish to write drivers for (USB, PCI, network, etc.)
> >>I would like to participate; however, for people who is not at USA
> >>(say, Europe), are there fair chances to get samples of devices to
> >>work with?
> >
> >Not all of the companies asking for this work are in the US, so I don't
> >see any reason why we should limit our developers to just one country,
> >that wouldn't be very fair...
> >
> >Just let me know what types of devices you are interested in working on.
>
> Then, I want to be involved too. I'm interested in PCI and network devices.
Thanks, I've added you to the list.
greg k-h
On Sun, Feb 04, 2007 at 07:59:47PM +0100, Pierre Ossman wrote:
> Hi Greg,
>
> Although I am a bit of a cynic, I really hope that this endeavor works
> the way you hope.
>
> I'd also like to offer my services to this quest of yours. If you get
> any SD, MMC or SDIO requests, feel free to pass them along to me. I am
> not a big fan of debug-by-email though, so I'd prefer vendors who either
> can provide samples or where the hardware is cheap and freely available
> so I can just go out and by one.
Great, thanks for letting me know, I've added you to the list.
greg k-h
On 2/6/07, Greg KH <[email protected]> wrote:
> On Sun, Feb 04, 2007 at 07:59:47PM +0100, Pierre Ossman wrote:
> > Hi Greg,
> >
> > Although I am a bit of a cynic, I really hope that this endeavor works
> > the way you hope.
> >
> > I'd also like to offer my services to this quest of yours. If you get
> > any SD, MMC or SDIO requests, feel free to pass them along to me. I am
> > not a big fan of debug-by-email though, so I'd prefer vendors who either
> > can provide samples or where the hardware is cheap and freely available
> > so I can just go out and by one.
>
> Great, thanks for letting me know, I've added you to the list.
for any DVB/DAB/DMB (PCI based) devices, if any vendors would like to
offer sample device and specs, would like to join the bandwagon.
regards,
manu
> > On 2/4/07, Greg KH <[email protected]> wrote:
> > >
> > >Just let me know if you are interested in participating, and what types
> > >of devices you wish to write drivers for (USB, PCI, network, etc.)
Yep, would love to dive into this ocean....in available mode ;-)
> > I would like to participate; however, for people who is not at USA
> > (say, Europe), are there fair chances to get samples of devices to
> > work with?
>
> Not all of the companies asking for this work are in the US, so I don't
> see any reason why we should limit our developers to just one country,
> that wouldn't be very fair...
That's correct. There should be developers across many regions. For
example, PC growth has the highest in Asia - so more users - hence the
demand for device support !
Plus, there is huge demand coming in 2 important areas - Embedded &
Mobile space.
> Just let me know what types of devices you are interested in working on.
I would love to work on PC as well as Embedded stuff (Power, Intel, and ARM).
Devices types - Audio/Video (this needs special attention for the
Linux Desktop), USB (TV Tuner card, key for Linux Desktop), Bluetooth
(Mobiles) , GSM/GPRS/WiFi/WIMAX (my self R&D area). Plus any device
which we think important to boost Linux Desktop ;-)
> thanks,
>
> greg k-h
Thank you too,
~Akula2
On 2/5/07, Stefan Seyfried <[email protected]> wrote:
> On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
> > On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
>
> Wrong. I abandoned all floppy drives some years ago. I'd actually
> vote for removing the floppy driver from the kernel completely.
I don't think time has come for that yet, still millions of people do
use Floppy on Linux ;-)
Maybe by 2.6.30 or so...
> Stefan Seyfried
~Akula2
On Tue, Feb 06, 2007 at 07:07:50PM +0530, Sunil Naidu wrote:
> On 2/5/07, Stefan Seyfried <[email protected]> wrote:
> > On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
> > > On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
> >
> > Wrong. I abandoned all floppy drives some years ago. I'd actually
> > vote for removing the floppy driver from the kernel completely.
>
> I don't think time has come for that yet, still millions of people do
> use Floppy on Linux ;-)
> Maybe by 2.6.30 or so...
The release of any new kernel doesn't make all existing hardware
on the planet stop working. I still get requests to enable
drivers in the Fedora kernel for 10 year old ISA sound cards.
In some parts of the world, buying a new computer isn't an option.
One of Linux's strengths is that we keep working on old hardware
without forcing the user to upgrade their system every time
like certain commercial OS's.
Dave
--
http://www.codemonkey.org.uk
Stefan Seyfried wrote:
> On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
>> On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
>
>>> 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?
>>>
>>> :)
>> Other than with the ISA drivers example, at least everyone has the
>> hardware... ;-)
>
> Wrong. I abandoned all floppy drives some years ago. I'd actually
> vote for removing the floppy driver from the kernel completely.
Is that your model of how the kernel should work? Take out anything you
don't personally need?
I'm guesstimating the 20-30% of the old laptops I rehab on Linux for
kids who have none lack the ability to boot off CD. Or write a CD, for
that matter. The ability of Linux to run on old hardware is another
advantage over commercial systems.
>
> Well, at work i probably have an USB floppy lying around somewhere,
> but i doubt that it uses floppy.c ;-),
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
On Tue, Feb 06, 2007 at 10:12:04AM -0500, Bill Davidsen wrote:
> Stefan Seyfried wrote:
> >On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
> >>On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
> >>>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?
> >>>
> >>>:)
> >>Other than with the ISA drivers example, at least everyone has the hardware... ;-)
> >Wrong. I abandoned all floppy drives some years ago. I'd actually
> >vote for removing the floppy driver from the kernel completely.
>
> Is that your model of how the kernel should work? Take out anything you don't personally need?
Oh. I must have forgotten those smilies.
;-)
> I'm guesstimating the 20-30% of the old laptops I rehab on Linux for kids who have none lack the
> ability to boot off CD. Or write a CD, for that matter. The ability of Linux to run on old
> hardware is another advantage over commercial systems.
Yes, i know.
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
On Tuesday 06 February 2007 08:37, Sunil Naidu wrote:
>On 2/5/07, Stefan Seyfried <[email protected]> wrote:
>> On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
>> > On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
>>
>> Wrong. I abandoned all floppy drives some years ago. I'd actually
>> vote for removing the floppy driver from the kernel completely.
>
>I don't think time has come for that yet, still millions of people do
>use Floppy on Linux ;-)
>Maybe by 2.6.30 or so...
How about not even then? There are few uses for the floppy drive today
within linux, this is true. BUT, that floppy is often the only was
software can be gotten from a vintage computer and published, or from a
publishing site back to that vintage computer. Please don't take away
our last data path to what is to many of us, a very old and trusted dear
friend. OS9, and later Nitros9, on a TRS-80 Color Computer, was my
teacher about unix-like systems, running a multiuser/multitasking
operating system on a machine with only 64k of ram, although my current
machine has 2 megs in it. And I occasionally still miss some of the
things I could do on that little machine that I have not been able to do
since, like start an assembly that generates an output listing, and
switch to another monitor or window & list that listing to the screen a
maximum of 256 bytes behind the writing of that listing to the disk file
it was going to.
The floppy may not be usefull to linux anymore, but in support of other
older formats, it is priceless.
>> Stefan Seyfried
>
>~Akula2
>-
>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/
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
On Tuesday 06 February 2007 11:30, Gene Heskett wrote:
>On Tuesday 06 February 2007 08:37, Sunil Naidu wrote:
>>On 2/5/07, Stefan Seyfried <[email protected]> wrote:
>>> On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
>>> > On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
>>>
>>> Wrong. I abandoned all floppy drives some years ago. I'd actually
>>> vote for removing the floppy driver from the kernel completely.
>>
>>I don't think time has come for that yet, still millions of people do
>>use Floppy on Linux ;-)
>>Maybe by 2.6.30 or so...
>
>How about not even then? There are few uses for the floppy drive today
>within linux, this is true. BUT, that floppy is often the only was
Gahh, s/was/way above. Old fingers seem to have minds of their own... :)
>software can be gotten from a vintage computer and published, or from a
>publishing site back to that vintage computer. Please don't take away
>our last data path to what is to many of us, a very old and trusted dear
>friend. OS9, and later Nitros9, on a TRS-80 Color Computer, was my
>teacher about unix-like systems, running a multiuser/multitasking
>operating system on a machine with only 64k of ram, although my current
>machine has 2 megs in it. And I occasionally still miss some of the
>things I could do on that little machine that I have not been able to do
>since, like start an assembly that generates an output listing, and
>switch to another monitor or window & list that listing to the screen a
>maximum of 256 bytes behind the writing of that listing to the disk file
>it was going to.
>
>The floppy may not be usefull to linux anymore, but in support of other
>older formats, it is priceless.
>
>>> Stefan Seyfried
>>
>>~Akula2
>>-
>>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/
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
On Tue, Feb 06, 2007 at 07:05:10PM +0530, Sunil Naidu wrote:
> >Just let me know what types of devices you are interested in working on.
>
> I would love to work on PC as well as Embedded stuff (Power, Intel, and
> ARM).
> Devices types - Audio/Video (this needs special attention for the
> Linux Desktop), USB (TV Tuner card, key for Linux Desktop), Bluetooth
> (Mobiles) , GSM/GPRS/WiFi/WIMAX (my self R&D area). Plus any device
> which we think important to boost Linux Desktop ;-)
Thanks, I've added you to to the list.
greg k-h
On Tue, Feb 06, 2007 at 12:29:03PM +0400, Manu Abraham wrote:
> On 2/6/07, Greg KH <[email protected]> wrote:
> >On Sun, Feb 04, 2007 at 07:59:47PM +0100, Pierre Ossman wrote:
> >> Hi Greg,
> >>
> >> Although I am a bit of a cynic, I really hope that this endeavor works
> >> the way you hope.
> >>
> >> I'd also like to offer my services to this quest of yours. If you get
> >> any SD, MMC or SDIO requests, feel free to pass them along to me. I am
> >> not a big fan of debug-by-email though, so I'd prefer vendors who either
> >> can provide samples or where the hardware is cheap and freely available
> >> so I can just go out and by one.
> >
> >Great, thanks for letting me know, I've added you to the list.
>
> for any DVB/DAB/DMB (PCI based) devices, if any vendors would like to
> offer sample device and specs, would like to join the bandwagon.
thanks, I've added you to the list.
greg k-h
On Tue, 06 Feb 2007 19:07:50 +0530, Sunil Naidu wrote:
> On 2/5/07, Stefan Seyfried <[email protected]> wrote:
>> On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
>> > On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
>>
>> Wrong. I abandoned all floppy drives some years ago. I'd actually vote
>> for removing the floppy driver from the kernel completely.
>
> I don't think time has come for that yet, still millions of people do use
> Floppy on Linux ;-)
So, I am not the only person on earth who still makes sure the floppy gets
included when building a new custom PC?
Akemi
On 2/6/07, Greg KH <[email protected]> wrote:
> On Tue, Feb 06, 2007 at 12:29:03PM +0400, Manu Abraham wrote:
> > On 2/6/07, Greg KH <[email protected]> wrote:
> > >On Sun, Feb 04, 2007 at 07:59:47PM +0100, Pierre Ossman wrote:
> > >> Hi Greg,
> > >>
> > >> Although I am a bit of a cynic, I really hope that this endeavor works
> > >> the way you hope.
> > >>
> > >> I'd also like to offer my services to this quest of yours. If you get
> > >> any SD, MMC or SDIO requests, feel free to pass them along to me. I am
> > >> not a big fan of debug-by-email though, so I'd prefer vendors who
> either
> > >> can provide samples or where the hardware is cheap and freely available
> > >> so I can just go out and by one.
> > >
> > >Great, thanks for letting me know, I've added you to the list.
> >
> > for any DVB/DAB/DMB (PCI based) devices, if any vendors would like to
> > offer sample device and specs, would like to join the bandwagon.
>
> thanks, I've added you to the list.
>
> 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/
>
As I'm not an expert in any kind of device, so I would like to join
for any device which its type has not been assigned to any person yet
(wild card?). Also, I would code for small LCDs.
--
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm
> > > I have a Cisco USB webcam that supposedly conforms to the "USB Video
> > > Device Class", but nothing happens when I plug it into my Linux box.
> > > I assume the device class is specified as part of the USB spec...
> >
> > Are you sure? That spec just came out not so long ago and I haven't
> > seen any real devices support it just yet. That said, I do know of a
> > few people who are working on implementing the standard, try asking on
> > the linux-usb-devel mailing list to find out what their status is.
>
> A quick web search finds http://linux-uvc.berlios.de/ but I don't see
> any signs that anyone plans to submit it upstream.
If you want a sign, here it is: I plan to submit the driver upstream :-)
After more than a year of development, the Linux UVC driver is now stable
enough to be included in the kernel. There is a show stopper though: V4L2.
The UVC specification defines a set of standard controls. Most of them are
part of the V4L2 specification as well (brightness, contrast, ...), but some
of them aren't. Those controls are currently exposed through private controls
(which drivers are allowed to expose by V4L2), but I don't want to keep
private controls around for standard controls defined by UVC.
Once V4L2 will be updated (hopefully soon, I keep trying :-)), I will submit
the driver upstream.
Regards,
Laurent Pinchart
On 2/7/07, Akemi Yagi <[email protected]> wrote:
> On Tue, 06 Feb 2007 19:07:50 +0530, Sunil Naidu wrote:
>
> > On 2/5/07, Stefan Seyfried <[email protected]> wrote:
> >> On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
> >> > On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
> >>
> >> Wrong. I abandoned all floppy drives some years ago. I'd actually vote
> >> for removing the floppy driver from the kernel completely.
> >
> > I don't think time has come for that yet, still millions of people do use
> > Floppy on Linux ;-)
>
> So, I am not the only person on earth who still makes sure the floppy gets
> included when building a new custom PC?
Yep, still floppies are useful. Example, when we buy a new device
(driver) with a floppy (sometimes by manufacturer). Plus, from the
customer (not user) POV, what's wrong in spending another $10 for a
FDD in a typical $1000 PC? Makes sense right ;-)
>
> Akemi
~Akula2
On Wed, Feb 07, 2007 at 07:03:26PM +0530, Sunil Naidu wrote:
> Yep, still floppies are useful. Example, when we buy a new device
> (driver) with a floppy (sometimes by manufacturer). Plus, from the
> customer (not user) POV, what's wrong in spending another $10 for a
> FDD in a typical $1000 PC? Makes sense right ;-)
Well certainly anyone with windows that needed a driver for their sata
controller better have a floppy drive (well apparenly vista now knows
about these amazing things called usb and optical drives... :). I also
find them handy as an emergency grub boot method, although I guess most
new machines could boot that from cd if necesary.
Personally I just stick in a $25 floppy and usb memory card reader in
one. Very handy, and doesn't waste space that way.
--
Len Sorensen
Eric Sandeen wrote:
> 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. :)
Be warned. The driver is marked HIGHLY EXPERIMENTAL and it seem to work
only on my machine. Seems to have some problem with LBA48 support.
The datasheet initio posted on the website just contains register
descriptions, which is much better than nothing but I still had to do a
LOT of trial-and-error to make that thing quasi-working. I've tried to
contact them in many ways but couldn't get any response. I'll probably
get back to it in a few weeks.
I can write ATA drivers for most hardware in a few days given 1.
actually useful datasheet 2. hardware at hand 3. an ENGINEER to talk to
when I get stuck. So, sign me up.
It will be nice to have some central web site / wiki / whatever to
monitor progress, arbitrate jobs, provides link to relevant info and
people (probably some of them being open-by-request) and possibly
provide links to bugzilla entries.
--
tejun
On Wed, Feb 07, 2007 at 06:03:58AM -0800, Tejun Heo wrote:
> I can write ATA drivers for most hardware in a few days given 1.
> actually useful datasheet 2. hardware at hand 3. an ENGINEER to talk to
> when I get stuck. So, sign me up.
Thanks, I'll add you to the list.
> It will be nice to have some central web site / wiki / whatever to
> monitor progress, arbitrate jobs, provides link to relevant info and
> people (probably some of them being open-by-request) and possibly
> provide links to bugzilla entries.
So far most of the companies have not really wanted the publicity,
that's why I have not posted anything publically about it. But I do
have a place to make all of this public if it turns out that it is ok to
do so.
thanks,
greg k-h
On Wed, Feb 07, 2007 at 08:12:05AM +0100, Miguel Ojeda wrote:
>
> As I'm not an expert in any kind of device, so I would like to join
> for any device which its type has not been assigned to any person yet
> (wild card?). Also, I would code for small LCDs.
Thanks, I've added you to the list.
I'll be doing a public update soon as people are wondering what is going
on :)
thanks,
greg k-h
On Tue, 6 Feb 2007, Akemi Yagi wrote:
> On Tue, 06 Feb 2007 19:07:50 +0530, Sunil Naidu wrote:
>
>> On 2/5/07, Stefan Seyfried <[email protected]> wrote:
>>> On Wed, Jan 31, 2007 at 03:14:31AM +0100, Adrian Bunk wrote:
>>>> On Tue, Jan 30, 2007 at 05:24:28PM -0800, Greg KH wrote:
>>>
>>> Wrong. I abandoned all floppy drives some years ago. I'd actually vote
>>> for removing the floppy driver from the kernel completely.
>>
>> I don't think time has come for that yet, still millions of people do use
>> Floppy on Linux ;-)
>
> So, I am not the only person on earth who still makes sure the floppy gets
> included when building a new custom PC?
No, I've avoided useing vendors that don't offer it as an option.
David Lang
Hi!
> > 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.
So can I treat Shem's code as a spec release, and merge it? :-).
[Okay, so your position is more reasonable than expected, good; but
signed-off process strongly discourages merging some code without
author's cooperation.]
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html