LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Wolfgang Beiter <w.beiter@aon.at>
To: Greg KH <gregkh@suse.de>
Cc: Randy Dunlap <rdunlap@xenotime.net>,
Shawn Bohrer <shawn.bohrer@gmail.com>,
David Schleef <ds@schleef.org>,
Frank Mori Hess <fmhess@users.sourceforge.net>,
Ian Abbott <abbotti@mev.co.uk>,
linux-kernel@vger.kernel.org, Wolfgang Beiter <w.beiter@aon.at>
Subject: Re: staging: me4000 and relation to other data acquisition devices
Date: Wed, 29 Oct 2008 16:12:02 +0100 [thread overview]
Message-ID: <20081029151202.GB2190@localhost.localdomain> (raw)
In-Reply-To: <20081028181402.GB4873@suse.de>
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
next prev parent reply other threads:[~2008-10-29 15:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-28 15:49 Shawn Bohrer
2008-10-28 16:34 ` Greg KH
2008-10-28 17:33 ` Randy Dunlap
2008-10-28 18:14 ` Greg KH
2008-10-29 15:12 ` Wolfgang Beiter [this message]
2008-10-30 0:02 ` Greg KH
2008-10-29 18:57 ` Moritz Muehlenhoff
2008-10-30 0:37 ` J.R. Mauro
2008-10-30 0:46 ` Richard Holden
2008-10-30 1:42 ` Greg KH
2008-10-30 14:25 ` J.R. Mauro
2008-10-30 15:23 ` Greg KH
2008-10-30 15:42 ` J.R. Mauro
2008-10-31 15:00 ` Greg KH
2008-10-31 15:10 ` J.R. Mauro
2008-10-30 1:43 ` Greg KH
2008-10-29 17:37 ` Shawn Bohrer
2008-10-30 0:04 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081029151202.GB2190@localhost.localdomain \
--to=w.beiter@aon.at \
--cc=abbotti@mev.co.uk \
--cc=ds@schleef.org \
--cc=fmhess@users.sourceforge.net \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.net \
--cc=shawn.bohrer@gmail.com \
--subject='Re: staging: me4000 and relation to other data acquisition devices' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).