Re: [PATCH 1/1] PCI: Dynids - passing driver data

[Brian King <brking@us.ibm.com>]

Adam Belay wrote:
> On Mon, Feb 07, 2005 at 02:18:20PM -0800, Greg KH wrote:
> 
>>On Mon, Feb 07, 2005 at 04:00:27PM -0600, brking@us.ibm.com wrote:
>>
>>>Currently, code exists in the pci layer to allow userspace to specify
>>>driver data when adding a pci dynamic id from sysfs. However, this data
>>>is never used and there exists no way in the existing code to use it.
>>
>>Which is a good thing, right?  "driver_data" is usually a pointer to
>>somewhere.  Having userspace specify it would not be a good thing.
> 
> 
> Yeah, I don't think it's safe to use "driver_data".  Although it can be a
> set of flags, it's also often used as an index in an array, or as a
> pointer.  An invalid value could result in an oops.
> 
> Most drivers don't use "driver_data".  For those that do, it might be
> helpful to have the capability of setting a few static configuration values
> before probing the device. Currently "driver_data" fills this role.
> Perhaps we need a new mechanism that would be more useable with sysfs?
> The current code is limiting because the configuration options in
> "driver_data" are not well defined.  Any ideas?

Unfortunately, from what I have gathered so far, driver_data is pretty 
unique for different drivers, especially when comparing the usage in the 
pci serial driver to a scsi hba driver like ipr.

Certainly, a driver that uses driver_data as a pointer cannot allow it 
to be passed in from userspace. But a device driver that uses it as an 
index into an array can easily allow it to be passed in and do some 
simple range checking on it to verify it is a valid value before 
indexing into the array.


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center