Re: RFC: UIO null parent for __uio_register_device and uio_device_name()

[Earl Chew]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/