staging: me4000 and relation to other data acquisition devices - Kernel

This is a discussion on staging: me4000 and relation to other data acquisition devices - Kernel ; 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 ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: staging: me4000 and relation to other data acquisition devices

  1. staging: me4000 and relation to other data acquisition devices

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

  2. Re: staging: me4000 and relation to other data acquisition devices

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

  3. Re: staging: me4000 and relation to other data acquisition devices

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

  4. Re: staging: me4000 and relation to other data acquisition devices

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

  5. Re: staging: me4000 and relation to other data acquisition devices

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



















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

  6. Re: staging: me4000 and relation to other data acquisition devices

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

  7. Re: staging: me4000 and relation to other data acquisition devices

    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....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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: staging: me4000 and relation to other data acquisition devices

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

  9. Re: staging: me4000 and relation to other data acquisition devices

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

  10. Re: staging: me4000 and relation to other data acquisition devices

    On Wed, Oct 29, 2008 at 2:57 PM, 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):
    >
    > 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....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 majordomo@vger.kernel.org
    > 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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: staging: me4000 and relation to other data acquisition devices


    On Oct 29, 2008, at 6:37 PM, J.R. Mauro wrote:

    > On Wed, Oct 29, 2008 at 2:57 PM, 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):
    >>
    >> 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 majordomo@vger.kernel.org
    >> 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 majordomo@vger.kernel.org
    > 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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: staging: me4000 and relation to other data acquisition devices

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

  13. Re: staging: me4000 and relation to other data acquisition devices

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

  14. Re: staging: me4000 and relation to other data acquisition devices

    On Wed, Oct 29, 2008 at 9:42 PM, Greg KH 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 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....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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: staging: me4000 and relation to other data acquisition devices

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

  16. Re: staging: me4000 and relation to other data acquisition devices

    On Thu, Oct 30, 2008 at 11:23 AM, Greg KH 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
    >

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

  17. Re: staging: me4000 and relation to other data acquisition devices

    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 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/tw...tOfTreeDrivers

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

  18. Re: staging: me4000 and relation to other data acquisition devices

    On Fri, Oct 31, 2008 at 11:00 AM, Greg KH 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 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/tw...tOfTreeDrivers
    >
    > 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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread