linux-kernel - Re: [PATCH v3] uio/pdrv

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, 19 Apr 2011 22:37:40 +1000
From:	John Williams <john.williams@...alogix.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Wolfram Sang <w.sang@...gutronix.de>,
	Michal Simek <monstr@...str.eu>,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	hjk@...sjkoch.de, arnd@...db.de
Subject: Re: [PATCH v3] uio/pdrv_genirq: Add OF support

On Tue, Apr 19, 2011 at 4:11 PM, Grant Likely <grant.likely@...retlab.ca> wrote:
> On Tue, Apr 19, 2011 at 11:58:25AM +1000, John Williams wrote:
>> On Tue, Apr 19, 2011 at 2:06 AM, Wolfram Sang <w.sang@...gutronix.de> wrote:
>> > Hi,
>> >
>> >> For example with "uio" compatible string:
>> >> static const struct of_device_id __devinitconst uio_of_genirq_match[] = {
>> >>       { .compatible = "uio", },
>> >>       { /* empty for now */ },
>> >> };
>> >
>> > Please use a proper example with "vendor,device".
>> > (And after that it won't be empty anymore)
>>
>> My vote is, and always has been 'generic-uio' :)
>>
>> Putting some random vendor/device string in there is just nuts. Do you
>> really want a kernel patch every time some one binds their device to
>> it?
>>
>> Or, is there no expectation that anybody would attempt to merge such a
>> pointless patch to begin with?
>>
>> As we discussed at ELC, putting a real vendor/device in there is also
>> broken because all instances in the system wil bind to the generic
>> uio, which is not necessarily what is desired.
>>
>> I know the arguments against the 'generic-uio' tag, but come on, let's
>> look at the lesser of two evils here!  I call BS on this DTS purity.
>
> Call it what you like, but the reasons are well founded.  The alternative
> that has been proposed which I am in agreement with is to investigate
> giving userspace the hook to tell the kernel at runtime which devices
> should be picked up by the uio driver.

OK, so let's talk about this interface.  As I see it, it must be able
to handle bind per-instance, not per compatibility.

For example, we make systems with multiple, identical timers.  One
will be used as the system timer, the others need to be (optionally)
bound to generic UIO.

Therefore, it's not OK to just do

echo "vendor,device" >> /sys/class/something/generic-uio/compatlist

or whatever, as this would bind all instances matching vendor,device.

So, the question I have is, how to handle bind per-instance?

I can accept that the generic-uio idea is permanently blocked, but
please can we have some concrete suggestions on an approach that would
be acceptable?

> In the mean time, explicitly modifying the match table is an okay
> compromise.

My mind is still boggling that in this day and age it could possibly
be preferred to modify code, instead of a data structure.  However,
clearly this is a lost cause!

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