I have some questions about the user-kernel interface of the me4000
driver. From my looking through the code it seems specific to the
me4000 hardware which does concern me since there are hundreds of
different data acquisition devices from many different vendors. In my
opinion it would beneficial if at the very least all of these devices
shared a common device interface.
Additionally there is the out of tree Comedi project:
http://comedi.org
Which supports this hardware, and many more, with a generic device
interface. There may be other reason not to merge Comedi (I know they
have a desire to maintain support of their RT support), but I can't help
but feel that merging the me4000 driver without thinking about the
hundreds of other devices out there is a mistake.
--
Shawn
On Tue, Oct 28, 2008 at 10:49:18AM -0500, Shawn Bohrer wrote:
> I have some questions about the user-kernel interface of the me4000
> driver. From my looking through the code it seems specific to the
> me4000 hardware which does concern me since there are hundreds of
> different data acquisition devices from many different vendors. In my
> opinion it would beneficial if at the very least all of these devices
> shared a common device interface.
I totally agree.
The me4000's user interface is not "set in stone" and needs to be fixed
up in order to move into the main kernel tree.
> Additionally there is the out of tree Comedi project:
>
> http://comedi.org
>
> Which supports this hardware, and many more, with a generic device
> interface. There may be other reason not to merge Comedi (I know they
> have a desire to maintain support of their RT support), but I can't help
> but feel that merging the me4000 driver without thinking about the
> hundreds of other devices out there is a mistake.
I would love to get comedi into the kernel tree. People have talked
about it for years now, is it time for me to just take a snapshot and
place it in drivers/staging/ for everyone to then work on cleaning up
properly?
thanks,
greg k-h
On Tue, 28 Oct 2008 09:34:56 -0700 Greg KH wrote:
> On Tue, Oct 28, 2008 at 10:49:18AM -0500, Shawn Bohrer wrote:
> > I have some questions about the user-kernel interface of the me4000
> > driver. From my looking through the code it seems specific to the
> > me4000 hardware which does concern me since there are hundreds of
> > different data acquisition devices from many different vendors. In my
> > opinion it would beneficial if at the very least all of these devices
> > shared a common device interface.
>
> I totally agree.
>
> The me4000's user interface is not "set in stone" and needs to be fixed
> up in order to move into the main kernel tree.
>
> > Additionally there is the out of tree Comedi project:
> >
> > http://comedi.org
> >
> > Which supports this hardware, and many more, with a generic device
> > interface. There may be other reason not to merge Comedi (I know they
> > have a desire to maintain support of their RT support), but I can't help
> > but feel that merging the me4000 driver without thinking about the
> > hundreds of other devices out there is a mistake.
>
> I would love to get comedi into the kernel tree. People have talked
> about it for years now, is it time for me to just take a snapshot and
> place it in drivers/staging/ for everyone to then work on cleaning up
> properly?
Greg,
Maybe I missed it at the beginning of the staging tree, but would you
explain which drivers you will or will not put into the staging tree?
E.g., what if someone doesn't want their driver merged into mainline?
---
~Randy
On Tue, Oct 28, 2008 at 10:33:37AM -0700, Randy Dunlap wrote:
> On Tue, 28 Oct 2008 09:34:56 -0700 Greg KH wrote:
>
> > On Tue, Oct 28, 2008 at 10:49:18AM -0500, Shawn Bohrer wrote:
> > > I have some questions about the user-kernel interface of the me4000
> > > driver. From my looking through the code it seems specific to the
> > > me4000 hardware which does concern me since there are hundreds of
> > > different data acquisition devices from many different vendors. In my
> > > opinion it would beneficial if at the very least all of these devices
> > > shared a common device interface.
> >
> > I totally agree.
> >
> > The me4000's user interface is not "set in stone" and needs to be fixed
> > up in order to move into the main kernel tree.
> >
> > > Additionally there is the out of tree Comedi project:
> > >
> > > http://comedi.org
> > >
> > > Which supports this hardware, and many more, with a generic device
> > > interface. There may be other reason not to merge Comedi (I know they
> > > have a desire to maintain support of their RT support), but I can't help
> > > but feel that merging the me4000 driver without thinking about the
> > > hundreds of other devices out there is a mistake.
> >
> > I would love to get comedi into the kernel tree. People have talked
> > about it for years now, is it time for me to just take a snapshot and
> > place it in drivers/staging/ for everyone to then work on cleaning up
> > properly?
>
> Greg,
>
> Maybe I missed it at the beginning of the staging tree, but would you
> explain which drivers you will or will not put into the staging tree?
>
> E.g., what if someone doesn't want their driver merged into mainline?
Of course, if someone doesn't want their code in the staging tree, I
will not add it, that's just being "nice".
As for what I will not put into staging, right now I'm sticking with
drivers only, no filesystems (people have asked already). I don't think
we have seen any drivers that I will not put into the staging tree yet.
thanks,
greg k-h
On [28.10.2008 11:14], Greg KH wrote:
> On Tue, Oct 28, 2008 at 10:33:37AM -0700, Randy Dunlap wrote:
> > On Tue, 28 Oct 2008 09:34:56 -0700 Greg KH wrote:
> >
> > > On Tue, Oct 28, 2008 at 10:49:18AM -0500, Shawn Bohrer wrote:
> > > > I have some questions about the user-kernel interface of the me4000
> > > > driver. From my looking through the code it seems specific to the
> > > > me4000 hardware which does concern me since there are hundreds of
> > > > different data acquisition devices from many different vendors. In my
> > > > opinion it would beneficial if at the very least all of these devices
> > > > shared a common device interface.
> > >
> > > I totally agree.
> > >
> > > The me4000's user interface is not "set in stone" and needs to be fixed
> > > up in order to move into the main kernel tree.
> > >
> > > > Additionally there is the out of tree Comedi project:
> > > >
> > > > http://comedi.org
> > > >
> > > > Which supports this hardware, and many more, with a generic device
> > > > interface. There may be other reason not to merge Comedi (I know they
> > > > have a desire to maintain support of their RT support), but I can't help
> > > > but feel that merging the me4000 driver without thinking about the
> > > > hundreds of other devices out there is a mistake.
> > >
> > > I would love to get comedi into the kernel tree. People have talked
> > > about it for years now, is it time for me to just take a snapshot and
> > > place it in drivers/staging/ for everyone to then work on cleaning up
> > > properly?
> >
> > Greg,
> >
> > Maybe I missed it at the beginning of the staging tree, but would you
> > explain which drivers you will or will not put into the staging tree?
> >
> > E.g., what if someone doesn't want their driver merged into mainline?
>
> Of course, if someone doesn't want their code in the staging tree, I
> will not add it, that's just being "nice".
>
> As for what I will not put into staging, right now I'm sticking with
> drivers only, no filesystems (people have asked already). I don't think
> we have seen any drivers that I will not put into the staging tree yet.
>
> thanks,
>
> greg k-h
sorry for causing the disput since the inital point to this may
belong to me.
At the beginning of this year, reading about the LDP (linux driver
project), this encouraged me to write an e-mail to Mr. Kroah-Hartman,
asking for me4000 driver support.
Pointing out that there are still mexxxx driver downloads on
http://www.sourceforge.net, although the drivers are no more supported by the
vendor and wont built with newer linux kernels, I felt it's a good idea.
Linux application developers, who handle with specific
hardware, will probably appreciate all forms of stable und long term
supported drivers.
In the case of a novice (like me), the standard API implemented
by me4000 was the right one due to learn some basics about linux
applications and how they speak to hardware.
There might be other requirements where a more common API is the right
joice and hardware independency is the goal.
thanks,
Wolfgang Beiter
On Tue, Oct 28, 2008 at 09:34:56AM -0700, Greg KH wrote:
> On Tue, Oct 28, 2008 at 10:49:18AM -0500, Shawn Bohrer wrote:
> > I have some questions about the user-kernel interface of the me4000
> > driver. From my looking through the code it seems specific to the
> > me4000 hardware which does concern me since there are hundreds of
> > different data acquisition devices from many different vendors. In my
> > opinion it would beneficial if at the very least all of these devices
> > shared a common device interface.
>
> I totally agree.
>
> The me4000's user interface is not "set in stone" and needs to be fixed
> up in order to move into the main kernel tree.
>
> > Additionally there is the out of tree Comedi project:
> >
> > http://comedi.org
> >
> > Which supports this hardware, and many more, with a generic device
> > interface. There may be other reason not to merge Comedi (I know they
> > have a desire to maintain support of their RT support), but I can't help
> > but feel that merging the me4000 driver without thinking about the
> > hundreds of other devices out there is a mistake.
>
> I would love to get comedi into the kernel tree. People have talked
> about it for years now, is it time for me to just take a snapshot and
> place it in drivers/staging/ for everyone to then work on cleaning up
> properly?
I think that is up to the Comedi maintainers. If the Comedi maintainers
do not want to head in that direction, I'm sure the me4000 driver
currently in drivers/staging/ would benefit from their review.
--
Shawn
Greg KH wrote:
> Of course, if someone doesn't want their code in the staging tree, I
> will not add it, that's just being "nice".
>
> As for what I will not put into staging, right now I'm sticking with
> drivers only, no filesystems (people have asked already). I don't think
> we have seen any drivers that I will not put into the staging tree yet.
Hi Greg,
Great effort with staging, thanks a lot!
I've had a look at the out-of-tree kernel drivers currently present
in Debian, maybe you want to merge some into staging. The Debian
overview pages contain download links (the orig.tar.gz files):
Acer hotkey driver:
http://packages.qa.debian.org/a/acerhk.html
http://www.cakey.de/acerhk/
Synaptics cPad:
http://packages.qa.debian.org/c/cpad-kernel.html
http://www.janerob.com/rob/ts5100/cPad/index.shtml
3Dfx driver:
http://packages.qa.debian.org/d/device3dfx.html
http://glide.sourceforge.net/
et131x Ethernet Controller:
http://packages.qa.debian.org/e/et131x.html
http://sourceforge.net/projects/et131x/
GPIB (IEEE 488) drivers:
http://packages.qa.debian.org/g/gpib.html
http://linux-gpib.sourceforge.net/
LEDs driver of PCEngines ALIX 2/3 boards:
http://packages.qa.debian.org/l/leds-alix.html
https://dev.openwrt.org/
Kernel driver for the back-end scaler on Matrox cards:
http://packages.qa.debian.org/m/mga-vid.html
http://attila.kinali.ch/mga/
ov51x-jpeg driver:
http://packages.qa.debian.org/o/ov51x-jpeg.html
http://www.rastageeks.org/ov51x-jpeg/index.php/Main_Page
tp_smapi kernel modules:
http://packages.qa.debian.org/t/tp-smapi.html
http://tpctl.sourceforge.net/
Voicetronix telephony hardware:
http://packages.qa.debian.org/v/vpb-driver.html
http://www.voicetronix.com.au/
Cheers,
Moritz
On Wed, Oct 29, 2008 at 04:12:02PM +0100, Wolfgang Beiter wrote:
> On [28.10.2008 11:14], Greg KH wrote:
> > On Tue, Oct 28, 2008 at 10:33:37AM -0700, Randy Dunlap wrote:
> > > On Tue, 28 Oct 2008 09:34:56 -0700 Greg KH wrote:
> > >
> > > > On Tue, Oct 28, 2008 at 10:49:18AM -0500, Shawn Bohrer wrote:
> > > > > I have some questions about the user-kernel interface of the me4000
> > > > > driver. From my looking through the code it seems specific to the
> > > > > me4000 hardware which does concern me since there are hundreds of
> > > > > different data acquisition devices from many different vendors. In my
> > > > > opinion it would beneficial if at the very least all of these devices
> > > > > shared a common device interface.
> > > >
> > > > I totally agree.
> > > >
> > > > The me4000's user interface is not "set in stone" and needs to be fixed
> > > > up in order to move into the main kernel tree.
> > > >
> > > > > Additionally there is the out of tree Comedi project:
> > > > >
> > > > > http://comedi.org
> > > > >
> > > > > Which supports this hardware, and many more, with a generic device
> > > > > interface. There may be other reason not to merge Comedi (I know they
> > > > > have a desire to maintain support of their RT support), but I can't help
> > > > > but feel that merging the me4000 driver without thinking about the
> > > > > hundreds of other devices out there is a mistake.
> > > >
> > > > I would love to get comedi into the kernel tree. People have talked
> > > > about it for years now, is it time for me to just take a snapshot and
> > > > place it in drivers/staging/ for everyone to then work on cleaning up
> > > > properly?
> > >
> > > Greg,
> > >
> > > Maybe I missed it at the beginning of the staging tree, but would you
> > > explain which drivers you will or will not put into the staging tree?
> > >
> > > E.g., what if someone doesn't want their driver merged into mainline?
> >
> > Of course, if someone doesn't want their code in the staging tree, I
> > will not add it, that's just being "nice".
> >
> > As for what I will not put into staging, right now I'm sticking with
> > drivers only, no filesystems (people have asked already). I don't think
> > we have seen any drivers that I will not put into the staging tree yet.
> >
> > thanks,
> >
> > greg k-h
>
> sorry for causing the disput since the inital point to this may
> belong to me.
>
> At the beginning of this year, reading about the LDP (linux driver
> project), this encouraged me to write an e-mail to Mr. Kroah-Hartman,
> asking for me4000 driver support.
>
> Pointing out that there are still mexxxx driver downloads on
> http://www.sourceforge.net, although the drivers are no more supported by the
> vendor and wont built with newer linux kernels, I felt it's a good idea.
Yes, it's fine, don't worry about it.
If we can add the comedi code, that would be even better overall, and
provide the common interface we really need for these kinds of devices
in Linux.
thanks,
greg k-h
On Wed, Oct 29, 2008 at 12:37:19PM -0500, Shawn Bohrer wrote:
> On Tue, Oct 28, 2008 at 09:34:56AM -0700, Greg KH wrote:
> > On Tue, Oct 28, 2008 at 10:49:18AM -0500, Shawn Bohrer wrote:
> > > I have some questions about the user-kernel interface of the me4000
> > > driver. From my looking through the code it seems specific to the
> > > me4000 hardware which does concern me since there are hundreds of
> > > different data acquisition devices from many different vendors. In my
> > > opinion it would beneficial if at the very least all of these devices
> > > shared a common device interface.
> >
> > I totally agree.
> >
> > The me4000's user interface is not "set in stone" and needs to be fixed
> > up in order to move into the main kernel tree.
> >
> > > Additionally there is the out of tree Comedi project:
> > >
> > > http://comedi.org
> > >
> > > Which supports this hardware, and many more, with a generic device
> > > interface. There may be other reason not to merge Comedi (I know they
> > > have a desire to maintain support of their RT support), but I can't help
> > > but feel that merging the me4000 driver without thinking about the
> > > hundreds of other devices out there is a mistake.
> >
> > I would love to get comedi into the kernel tree. People have talked
> > about it for years now, is it time for me to just take a snapshot and
> > place it in drivers/staging/ for everyone to then work on cleaning up
> > properly?
>
> I think that is up to the Comedi maintainers. If the Comedi maintainers
> do not want to head in that direction, I'm sure the me4000 driver
> currently in drivers/staging/ would benefit from their review.
Ok, David, Frank, Ian, what do you think?
I can take a snapshot of the development tree right now, put it into
drivers/staging/comedi/ and then work with you all, and the hundreds of
kernel developers to get the code into "mergable" shape to get it merged
into the main kernel tree.
By moving it into the staging tree now, you get the benifit of those
other developers helping out with this effort, and the benifit of the
code being added to all the distros and more users using it, and not
having to build and install their own versions.
I'll be glad to do this, and maintain it if need be. Your codebase is
great, and it provides a much needed standard interface for this type of
device for Linux.
thanks,
greg k-h
On Wed, Oct 29, 2008 at 2:57 PM, Moritz Muehlenhoff <[email protected]> wrote:
> Greg KH wrote:
>> Of course, if someone doesn't want their code in the staging tree, I
>> will not add it, that's just being "nice".
>>
>> As for what I will not put into staging, right now I'm sticking with
>> drivers only, no filesystems (people have asked already). I don't think
>> we have seen any drivers that I will not put into the staging tree yet.
>
> Hi Greg,
> Great effort with staging, thanks a lot!
>
> I've had a look at the out-of-tree kernel drivers currently present
> in Debian, maybe you want to merge some into staging. The Debian
> overview pages contain download links (the orig.tar.gz files):
>
> Acer hotkey driver:
> http://packages.qa.debian.org/a/acerhk.html
> http://www.cakey.de/acerhk/
>
> Synaptics cPad:
> http://packages.qa.debian.org/c/cpad-kernel.html
> http://www.janerob.com/rob/ts5100/cPad/index.shtml
>
> 3Dfx driver:
> http://packages.qa.debian.org/d/device3dfx.html
> http://glide.sourceforge.net/
>
> et131x Ethernet Controller:
> http://packages.qa.debian.org/e/et131x.html
> http://sourceforge.net/projects/et131x/
This driver (or a driver for the same hardware) is in staging already.
>
> GPIB (IEEE 488) drivers:
> http://packages.qa.debian.org/g/gpib.html
> http://linux-gpib.sourceforge.net/
>
> LEDs driver of PCEngines ALIX 2/3 boards:
> http://packages.qa.debian.org/l/leds-alix.html
> https://dev.openwrt.org/
>
> Kernel driver for the back-end scaler on Matrox cards:
> http://packages.qa.debian.org/m/mga-vid.html
> http://attila.kinali.ch/mga/
>
> ov51x-jpeg driver:
> http://packages.qa.debian.org/o/ov51x-jpeg.html
> http://www.rastageeks.org/ov51x-jpeg/index.php/Main_Page
>
> tp_smapi kernel modules:
> http://packages.qa.debian.org/t/tp-smapi.html
> http://tpctl.sourceforge.net/
>
> Voicetronix telephony hardware:
> http://packages.qa.debian.org/v/vpb-driver.html
> http://www.voicetronix.com.au/
>
> Cheers,
> Moritz
>
> --
> 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/
>
Greg,
If you're interested in having the above drivers get into staging and
need someone to email the developers about it, I humbly volunteer.
~J.R.
On Oct 29, 2008, at 6:37 PM, J.R. Mauro wrote:
> On Wed, Oct 29, 2008 at 2:57 PM, Moritz Muehlenhoff <[email protected]>
> wrote:
>> Greg KH wrote:
>>> Of course, if someone doesn't want their code in the staging tree, I
>>> will not add it, that's just being "nice".
>>>
>>> As for what I will not put into staging, right now I'm sticking with
>>> drivers only, no filesystems (people have asked already). I don't
>>> think
>>> we have seen any drivers that I will not put into the staging tree
>>> yet.
>>
>> Hi Greg,
>> Great effort with staging, thanks a lot!
>>
>> I've had a look at the out-of-tree kernel drivers currently present
>> in Debian, maybe you want to merge some into staging. The Debian
>> overview pages contain download links (the orig.tar.gz files):
>>
>> Voicetronix telephony hardware:
>> http://packages.qa.debian.org/v/vpb-driver.html
>> http://www.voicetronix.com.au/
>>
I'm working on the Quicknet IXJ driver currently and I could take this
driver too if it would help.
>> Cheers,
>> Moritz
>>
>> --
>> 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/
>>
>
> Greg,
>
> If you're interested in having the above drivers get into staging and
> need someone to email the developers about it, I humbly volunteer.
>
> ~J.R.
> --
> 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 guess I just volunteered to maintain the telephony drivers, though
I'm still getting used to git. I'll send a Maintainers patch later
today.
-Richard Holden
On Wed, Oct 29, 2008 at 08:37:54PM -0400, J.R. Mauro wrote:
> On Wed, Oct 29, 2008 at 2:57 PM, Moritz Muehlenhoff <[email protected]> wrote:
> > Greg KH wrote:
> >> Of course, if someone doesn't want their code in the staging tree, I
> >> will not add it, that's just being "nice".
> >>
> >> As for what I will not put into staging, right now I'm sticking with
> >> drivers only, no filesystems (people have asked already). I don't think
> >> we have seen any drivers that I will not put into the staging tree yet.
> >
> > Hi Greg,
> > Great effort with staging, thanks a lot!
> >
> > I've had a look at the out-of-tree kernel drivers currently present
> > in Debian, maybe you want to merge some into staging. The Debian
> > overview pages contain download links (the orig.tar.gz files):
> >
> > Acer hotkey driver:
> > http://packages.qa.debian.org/a/acerhk.html
> > http://www.cakey.de/acerhk/
> >
> > Synaptics cPad:
> > http://packages.qa.debian.org/c/cpad-kernel.html
> > http://www.janerob.com/rob/ts5100/cPad/index.shtml
> >
> > 3Dfx driver:
> > http://packages.qa.debian.org/d/device3dfx.html
> > http://glide.sourceforge.net/
> >
> > et131x Ethernet Controller:
> > http://packages.qa.debian.org/e/et131x.html
> > http://sourceforge.net/projects/et131x/
>
> This driver (or a driver for the same hardware) is in staging already.
>
> >
> > GPIB (IEEE 488) drivers:
> > http://packages.qa.debian.org/g/gpib.html
> > http://linux-gpib.sourceforge.net/
> >
> > LEDs driver of PCEngines ALIX 2/3 boards:
> > http://packages.qa.debian.org/l/leds-alix.html
> > https://dev.openwrt.org/
> >
> > Kernel driver for the back-end scaler on Matrox cards:
> > http://packages.qa.debian.org/m/mga-vid.html
> > http://attila.kinali.ch/mga/
> >
> > ov51x-jpeg driver:
> > http://packages.qa.debian.org/o/ov51x-jpeg.html
> > http://www.rastageeks.org/ov51x-jpeg/index.php/Main_Page
> >
> > tp_smapi kernel modules:
> > http://packages.qa.debian.org/t/tp-smapi.html
> > http://tpctl.sourceforge.net/
> >
> > Voicetronix telephony hardware:
> > http://packages.qa.debian.org/v/vpb-driver.html
> > http://www.voicetronix.com.au/
>
> Greg,
>
> If you're interested in having the above drivers get into staging and
> need someone to email the developers about it, I humbly volunteer.
Please do, that would be wonderful.
I'll go add these packages to my big "spreadsheet o' drivers" I'm trying
to use to track all of this mess...
thanks,
greg k-h
On Wed, Oct 29, 2008 at 07:57:19PM +0100, Moritz Muehlenhoff wrote:
> Greg KH wrote:
> > Of course, if someone doesn't want their code in the staging tree, I
> > will not add it, that's just being "nice".
> >
> > As for what I will not put into staging, right now I'm sticking with
> > drivers only, no filesystems (people have asked already). I don't think
> > we have seen any drivers that I will not put into the staging tree yet.
>
> Hi Greg,
> Great effort with staging, thanks a lot!
>
> I've had a look at the out-of-tree kernel drivers currently present
> in Debian, maybe you want to merge some into staging. The Debian
> overview pages contain download links (the orig.tar.gz files):
Thanks for the summary.
(hint, next time, don't drop CC: addresses...)
greg k-h
On Wed, Oct 29, 2008 at 9:42 PM, Greg KH <[email protected]> wrote:
> On Wed, Oct 29, 2008 at 08:37:54PM -0400, J.R. Mauro wrote:
>> On Wed, Oct 29, 2008 at 2:57 PM, Moritz Muehlenhoff <[email protected]> wrote:
>> > Greg KH wrote:
>> >> Of course, if someone doesn't want their code in the staging tree, I
>> >> will not add it, that's just being "nice".
>> >>
>> >> As for what I will not put into staging, right now I'm sticking with
>> >> drivers only, no filesystems (people have asked already). I don't think
>> >> we have seen any drivers that I will not put into the staging tree yet.
>> >
>> > Hi Greg,
>> > Great effort with staging, thanks a lot!
>> >
>> > I've had a look at the out-of-tree kernel drivers currently present
>> > in Debian, maybe you want to merge some into staging. The Debian
>> > overview pages contain download links (the orig.tar.gz files):
>> >
>> > Acer hotkey driver:
>> > http://packages.qa.debian.org/a/acerhk.html
>> > http://www.cakey.de/acerhk/
>> >
>> > Synaptics cPad:
>> > http://packages.qa.debian.org/c/cpad-kernel.html
>> > http://www.janerob.com/rob/ts5100/cPad/index.shtml
>> >
>> > 3Dfx driver:
>> > http://packages.qa.debian.org/d/device3dfx.html
>> > http://glide.sourceforge.net/
>> >
>> > et131x Ethernet Controller:
>> > http://packages.qa.debian.org/e/et131x.html
>> > http://sourceforge.net/projects/et131x/
>>
>> This driver (or a driver for the same hardware) is in staging already.
>>
>> >
>> > GPIB (IEEE 488) drivers:
>> > http://packages.qa.debian.org/g/gpib.html
>> > http://linux-gpib.sourceforge.net/
>> >
>> > LEDs driver of PCEngines ALIX 2/3 boards:
>> > http://packages.qa.debian.org/l/leds-alix.html
>> > https://dev.openwrt.org/
>> >
>> > Kernel driver for the back-end scaler on Matrox cards:
>> > http://packages.qa.debian.org/m/mga-vid.html
>> > http://attila.kinali.ch/mga/
>> >
>> > ov51x-jpeg driver:
>> > http://packages.qa.debian.org/o/ov51x-jpeg.html
>> > http://www.rastageeks.org/ov51x-jpeg/index.php/Main_Page
>> >
>> > tp_smapi kernel modules:
>> > http://packages.qa.debian.org/t/tp-smapi.html
>> > http://tpctl.sourceforge.net/
>> >
>> > Voicetronix telephony hardware:
>> > http://packages.qa.debian.org/v/vpb-driver.html
>> > http://www.voicetronix.com.au/
>>
>> Greg,
>>
>> If you're interested in having the above drivers get into staging and
>> need someone to email the developers about it, I humbly volunteer.
>
> Please do, that would be wonderful.
>
> I'll go add these packages to my big "spreadsheet o' drivers" I'm trying
> to use to track all of this mess...
>
> thanks,
>
> greg k-h
>
Ok. I emailed a few of them. The ones I omitted either didn't have a
clear homepage/maintainer, had already sent a patch to the kernel, or
explicitly stated no intentions of going into mainline.
Maybe you could send me the Spreadsheet O' Drivers if you need more help?
I've also been wondering: should we contact the maintainers of the big
distros and make them aware of staging and have them work with us to
get whatever out-of-tree stuff they have more centralized? I don't
know if it's a good idea, but it could be. And if it is, I have no
idea where to start.
On Thu, Oct 30, 2008 at 10:25:30AM -0400, J.R. Mauro wrote:
> Ok. I emailed a few of them. The ones I omitted either didn't have a
> clear homepage/maintainer, had already sent a patch to the kernel, or
> explicitly stated no intentions of going into mainline.
Which ones were in the last 2 categories?
> Maybe you could send me the Spreadsheet O' Drivers if you need more help?
Yeah, I think I'll move this to a google docs file or somehow merge it
with the information on the linuxdriverproject.org wiki. Give me a few
days.
> I've also been wondering: should we contact the maintainers of the big
> distros and make them aware of staging and have them work with us to
> get whatever out-of-tree stuff they have more centralized? I don't
> know if it's a good idea, but it could be. And if it is, I have no
> idea where to start.
I've already looked at what the following distros include in their
kernel package:
- Fedora
- openSUSE
- Ubuntu
so I have them on my list, and is where I took a number of the existing
staging drivers from.
If you could poke around other distro's kernels (like Mandrake and any
other you can think of) and find out what they include, that would e
great.
thanks,
greg k-h
On Thu, Oct 30, 2008 at 11:23 AM, Greg KH <[email protected]> wrote:
> On Thu, Oct 30, 2008 at 10:25:30AM -0400, J.R. Mauro wrote:
>> Ok. I emailed a few of them. The ones I omitted either didn't have a
>> clear homepage/maintainer, had already sent a patch to the kernel, or
>> explicitly stated no intentions of going into mainline.
>
> Which ones were in the last 2 categories?
The Alix driver seemed to be sent in already: http://lkml.org/lkml/2008/8/19/279
The ov51x-jpeg driver's homepage mentions that there is a driver
already, but it doesn't do jpeg compression, since that kind of
shouldn't be done in the kernel. The out-of-tree driver does do the
compression in the kernel, but the author doesn't think it should go
into mainline. Or something like that.
>
>> Maybe you could send me the Spreadsheet O' Drivers if you need more help?
>
> Yeah, I think I'll move this to a google docs file or somehow merge it
> with the information on the linuxdriverproject.org wiki. Give me a few
> days.
A google spreadsheet would be great for me. Maybe you could do both?
>
>> I've also been wondering: should we contact the maintainers of the big
>> distros and make them aware of staging and have them work with us to
>> get whatever out-of-tree stuff they have more centralized? I don't
>> know if it's a good idea, but it could be. And if it is, I have no
>> idea where to start.
>
> I've already looked at what the following distros include in their
> kernel package:
> - Fedora
> - openSUSE
> - Ubuntu
> so I have them on my list, and is where I took a number of the existing
> staging drivers from.
>
> If you could poke around other distro's kernels (like Mandrake and any
> other you can think of) and find out what they include, that would e
> great.
Ok. I'll talk to distros not mentioned above and hopefully add
anything I find to the forthcoming spreadsheet.
>
> thanks,
>
> greg k-h
>
On Thu, Oct 30, 2008 at 11:42:36AM -0400, J.R. Mauro wrote:
> On Thu, Oct 30, 2008 at 11:23 AM, Greg KH <[email protected]> wrote:
> > On Thu, Oct 30, 2008 at 10:25:30AM -0400, J.R. Mauro wrote:
> >> Ok. I emailed a few of them. The ones I omitted either didn't have a
> >> clear homepage/maintainer, had already sent a patch to the kernel, or
> >> explicitly stated no intentions of going into mainline.
> >
> > Which ones were in the last 2 categories?
>
> The Alix driver seemed to be sent in already: http://lkml.org/lkml/2008/8/19/279
>
> The ov51x-jpeg driver's homepage mentions that there is a driver
> already, but it doesn't do jpeg compression, since that kind of
> shouldn't be done in the kernel. The out-of-tree driver does do the
> compression in the kernel, but the author doesn't think it should go
> into mainline. Or something like that.
>
> >
> >> Maybe you could send me the Spreadsheet O' Drivers if you need more help?
> >
> > Yeah, I think I'll move this to a google docs file or somehow merge it
> > with the information on the linuxdriverproject.org wiki. Give me a few
> > days.
>
> A google spreadsheet would be great for me. Maybe you could do both?
>
> >
> >> I've also been wondering: should we contact the maintainers of the big
> >> distros and make them aware of staging and have them work with us to
> >> get whatever out-of-tree stuff they have more centralized? I don't
> >> know if it's a good idea, but it could be. And if it is, I have no
> >> idea where to start.
> >
> > I've already looked at what the following distros include in their
> > kernel package:
> > - Fedora
> > - openSUSE
> > - Ubuntu
> > so I have them on my list, and is where I took a number of the existing
> > staging drivers from.
> >
> > If you could poke around other distro's kernels (like Mandrake and any
> > other you can think of) and find out what they include, that would e
> > great.
>
> Ok. I'll talk to distros not mentioned above and hopefully add
> anything I find to the forthcoming spreadsheet.
I've gone through the suse, fedora, ubuntu, and gentoo kernels and added
everything that I have found (gentoo had a _lot_ of external kernel
modules in their packaging system) to the wiki at:
http://www.linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
I also dumped all of my spreadsheet information into here as well, as it
didn't make sense to try to categorize it that way.
So, feel free to clean up, and organize that wiki page with whatever
else you have found. Some of it still is not organized (like the huge
list at the end of the page) and there might be duplicates as well.
Thanks a lot for helping out.
greg k-h
On Fri, Oct 31, 2008 at 11:00 AM, Greg KH <[email protected]> wrote:
> On Thu, Oct 30, 2008 at 11:42:36AM -0400, J.R. Mauro wrote:
>> On Thu, Oct 30, 2008 at 11:23 AM, Greg KH <[email protected]> wrote:
>> > On Thu, Oct 30, 2008 at 10:25:30AM -0400, J.R. Mauro wrote:
>> >> Ok. I emailed a few of them. The ones I omitted either didn't have a
>> >> clear homepage/maintainer, had already sent a patch to the kernel, or
>> >> explicitly stated no intentions of going into mainline.
>> >
>> > Which ones were in the last 2 categories?
>>
>> The Alix driver seemed to be sent in already: http://lkml.org/lkml/2008/8/19/279
>>
>> The ov51x-jpeg driver's homepage mentions that there is a driver
>> already, but it doesn't do jpeg compression, since that kind of
>> shouldn't be done in the kernel. The out-of-tree driver does do the
>> compression in the kernel, but the author doesn't think it should go
>> into mainline. Or something like that.
>>
>> >
>> >> Maybe you could send me the Spreadsheet O' Drivers if you need more help?
>> >
>> > Yeah, I think I'll move this to a google docs file or somehow merge it
>> > with the information on the linuxdriverproject.org wiki. Give me a few
>> > days.
>>
>> A google spreadsheet would be great for me. Maybe you could do both?
>>
>> >
>> >> I've also been wondering: should we contact the maintainers of the big
>> >> distros and make them aware of staging and have them work with us to
>> >> get whatever out-of-tree stuff they have more centralized? I don't
>> >> know if it's a good idea, but it could be. And if it is, I have no
>> >> idea where to start.
>> >
>> > I've already looked at what the following distros include in their
>> > kernel package:
>> > - Fedora
>> > - openSUSE
>> > - Ubuntu
>> > so I have them on my list, and is where I took a number of the existing
>> > staging drivers from.
>> >
>> > If you could poke around other distro's kernels (like Mandrake and any
>> > other you can think of) and find out what they include, that would e
>> > great.
>>
>> Ok. I'll talk to distros not mentioned above and hopefully add
>> anything I find to the forthcoming spreadsheet.
>
> I've gone through the suse, fedora, ubuntu, and gentoo kernels and added
> everything that I have found (gentoo had a _lot_ of external kernel
> modules in their packaging system) to the wiki at:
> http://www.linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
>
> I also dumped all of my spreadsheet information into here as well, as it
> didn't make sense to try to categorize it that way.
>
> So, feel free to clean up, and organize that wiki page with whatever
> else you have found. Some of it still is not organized (like the huge
> list at the end of the page) and there might be duplicates as well.
>
> Thanks a lot for helping out.
>
> greg k-h
>
Thanks Greg. I tried to work on this page last night but when I
previewed my changes somehow the whole page was busted. I'll try to
add whatever I've found and GC/categorize the mess at the bottom.