linux-kernel - Re: [PATCH] linux-2.6.32-directemp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100206085518.GA4680@suse.de>
Date:	Sat, 6 Feb 2010 00:55:18 -0800
From:	Greg KH <gregkh@...e.de>
To:	Chris Verges <chrisv@...erswitching.com>
Cc:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Rob Owings <rowings@...rmistor.com>
Subject: Re: [PATCH] linux-2.6.32-directemp

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