> The contents of this database can be exposed through procfs or a similar
> mechanism. The driver-model core would only use the first two fields for
> matching entries; a new entry that matches an existing entry in the driver
> name and device ID fields would overwrite it. Each device driver would be
> able to iterate over all the entries which match its name, and
> interpretating of the device ID and data fields would be entirely up to
> the driver. Since the data can be an arbitrary character string, there is
> great flexibility for encoding and storing information.
That is a problem not an advantage.
> (An important point is that this information doesn't really belong in
> sysfs, because there needs to be entries for drivers that aren't currently
> loaded in the kernel. That's the only way to guarantee that when the
> driver _is_ loaded the information will be available.)
>
> (Another somewhat tangential point: We might want to include whitelist
> information too, in the sense that the hotplug system ought to be able to
> cause a driver to be probed for a particular device even if the normal
> matching criterion fails. Among the entries in the database could be
> items that tell a bus driver to match a particular device to a particular
> device driver.)
Can be done entirely in user space.
> Presumably the hotplug system would be used to populate this resident
> database, based on a large set of known entries stored in a file. The
> system would useable even in the absence of hotplug support, however. All
> that's needed is a utility that at some early stage during the boot
> process would copy into the resident database a short file containing the
> entries for devices currently attached to the system.
Then you absolutely need an initrd.
[..]
> This mechanism should be useable by almost any sort of driver. And by
> moving the majority of the database out of the kernel it should provide a
> great improvement in memory utilization and maintainability.
>
> Comments? Would this be a good sort of thing for 2.7?
It seems to me that you would be in for a lot of pain.
That "data" field is completely unstructured, so you end up keeping
device quirk description formats in sync.
Introducing new interfaces to user space is not an unqualified good thing.
Regards
Oliver
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
