public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Chris Verges <chrisv@cyberswitching.com>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Rob Owings <rowings@thermistor.com>
Subject: Re: [PATCH] linux-2.6.32-directemp
Date: Sat, 6 Feb 2010 00:55:18 -0800	[thread overview]
Message-ID: <20100206085518.GA4680@suse.de> (raw)
In-Reply-To: <68FBE0F3CE97264395875AC1C468F22C24A633@mail03.cyberswitching.local>

On Fri, Feb 05, 2010 at 04:26:42PM -0800, Chris Verges wrote:
> > Sorry, but no, this driver will not be accepted, as it can be done
> just
> > fine from userspace instead of a kernel driver, as discussed before.
> 
> Hi Greg,
> 
> Sounds good.  I'll still be sending out an updated patch for anyone who
> is interested in a kernel driver.  They're welcome to patch in the
> driver themselves.

That's great.

> I may be missing some key piece of information about libusb and usbfs,
> but it seems like it pushes a lot of the protocol communication off to
> the user app.  So if there are several user apps that want to use the
> same USB device, they either need a userland library or to re-implement
> functionality; is that correct?

Yes, that is true.

> What I may be missing is the rationale behind pushing these drivers into
> userland libraries and having yet another entity in the FOSS world that
> is responsible for managing them.  The kernel seems like an obvious
> clearinghouse for software/hardware interactions.  Yes, there may be
> lots of drivers, but at least everyone knows where to go for them.  But
> like I said before, I may be missing something.

No, you are correct.  We want a driver in the kernel when it provides a
common interface to a class of devices (network, tty, video, etc.)  For
devices like yours, there is no specific class in the kernel (well,
there is for hardware monitoring devices, but not for generic
thermometers.)  So for that, you are going to write a custom userspace
program anyway to be reading the temp value from sysfs, so you might as
well just either use a library to talk to your device, or put it within
the application itself.

Hope this helps explain things,

greg k-h

  reply	other threads:[~2010-02-06  8:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-05  4:47 [PATCH] linux-2.6.32-directemp Chris Verges
2010-02-05 15:45 ` Alan Stern
2010-02-05 17:16 ` Greg KH
2010-02-05 17:32   ` Chris Verges
2010-02-05 20:40 ` Andrew Morton
2010-02-05 21:32   ` Chris Verges
2010-02-05 21:46     ` Andrew Morton
2010-02-05 23:58       ` Greg KH
2010-02-06  0:26         ` Chris Verges
2010-02-06  8:55           ` Greg KH [this message]
2010-02-06  9:42 ` Bruno Prémont
     [not found]   ` <68FBE0F3CE97264395875AC1C468F22C2445C2@mail03.cyberswitching.local>
2010-02-06 18:01     ` [lm-sensors] " Jean Delvare

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=20100206085518.GA4680@suse.de \
    --to=gregkh@suse.de \
    --cc=chrisv@cyberswitching.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rowings@thermistor.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox