linux-kernel - Re: RFC: UIO null parent for __uio_register_device and uio_device

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: <4D371A35.5000009@ixiacom.com>
Date:	Wed, 19 Jan 2011 09:07:01 -0800
From:	Earl Chew <echew@...acom.com>
To:	Greg KH <greg@...ah.com>
CC:	"Hans J. Koch" <hjk@...sjkoch.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: RFC: UIO  null parent for __uio_register_device and uio_device_name()

On 19/01/2011 8:30 AM, Greg KH wrote:
>> No probing is required in this scenario.
> 
> Great, then create a platform device for your "hardware device" and you
> should be fine, right?

Greg,

I suppose so. I don't understand the need to enforce !parent
since device_create() seems to be fine with a NULL parent.

Would you explain what is to be gained by requiring !parent
at the Linux UIO level ?

>> Working on the implementation of our new system last night I realise
>> that our new configuration runs very lean, and I now do not have the
>> use of udev to populate /dev/uio[0-9].
> 
> Then what populates your other device nodes?

I believe they are fixed in the root file system (ie the major numbers
are fixed). It is also possible that /etc/rcS script does the rest with
judicious mknod invocations.

>> This new configuration runs so lean that I don't have access to sysfs.
> 
> I really find this hard to believe.  Why would you not configure sysfs
> in your system?

The needs of our hardware and application are such that one of the key system
designers told me:

	For the record, sysfs affects interface scalability in two ways: adds a 
	significant memory overhead (IIRC 300-500 bytes per interface) and slows down 
	device registration and de-registration.

>> The result is that I need to figure out the major/minor device number in
>> order to access the Linux UIO device. I will advertise this through /proc/
>> entries specific to the UIO client driver. We can then use this information
>> to mknod /dev/uio[0-9].
> 
> Heh, you have /proc/ but not /sys/?  Someone needs to move out of the
> 90's :)

LOL  Yes, I see your point.

>> I've added uio_device_chrdev() alongside uio_device_name() to allow
>> us to figure out the coordinates of the Linux UIO device.
> 
> Ick, no, please use the sysfs files that are alredy present for such a
> thing, don't reinvent the wheel, I will not accept such a change.

I think you're telling me you won't accept either of:

a. uio_device_name()
b. uio_device_chrdev()

It is not my intention to reinvent the wheel. The problem I have
is that the wheel in question won't fit my application context.

I'm trying to figure out how to get this done without a kernel
change, but I don't have many options left.

I think I can do the following:

o Use device_create() to make a parent before calling uio_register_device.

o Have the application search through /proc/devices to yield the major number
  of the uio driver.

With no sysfs, I cannot think of a way to get hold of the minor number allocated
to this instance of the Linux UIO device, and without that I can't open() the
device driver.

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