linux-kernel - Re: RFC: Platform data for onboard USB assets

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]

Date:	Tue, 22 Mar 2011 21:56:52 -0700
From:	Greg KH <greg@...ah.com>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	andy.green@...aro.org,
	Jaswinder Singh <jaswinder.singh@...aro.org>,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>, arnd@...db.de,
	broonie@...nsource.wolfsonmicro.com, roger.quadros@...ia.com,
	grant.likely@...retlab.ca
Subject: Re: RFC: Platform data for onboard USB assets

On Wed, Mar 23, 2011 at 12:21:41AM -0400, Nicolas Pitre wrote:
> On Wed, 23 Mar 2011, Benjamin Herrenschmidt wrote:
> > The argument boils down to should we encourage adding an additional
> > in-kernel platform_data based hooks for dynamically probed busses such
> > as USB as well ? or go for a udev based solution for the time being
> > which would probably work as well in practice and focus on getting the
> > device-tree based solution for the long term instead.
> 
> The udev solution has its set of drawbacks.  Using udev is perfect for 
> arbitrary user policies.  But here we're talking about a particular 
> device which happens to be soldered on a particular board, and adding 
> that knowledge to udev which is a separately maintained piece of 
> software from the kernel is rather redundant while the kernel already 
> knows perfectly well on which hardware it is running.  And as Andy 
> pointed out, the kernel's job is to abstract hardware peculiarities, not 
> to force them to user space.

{sigh}

This is the _exact_ same argument that the server manufacturers tried to
do for the naming of the ethernet pci devices and naming of them to
match up with the physical label that is on the back of the machine.

Because of that, please use the same tools that they created to solve
this problem.  It's done in userspace, in a way that works for everyone
and on all distros, even your embedded one.

I do not understand why everyone is so resistant to this solution?  Have
you all tried it out and found problems with it?

thanks,

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/