Re: 2.5.47bk2 + current modutils == broken hotplug

David Brownell (david-b@pacbell.net)
Wed, 13 Nov 2002 15:00:05 -0800


Jeff Garzik wrote:
> Greg KH wrote:
>
>> On Wed, Nov 13, 2002 at 03:59:56PM -0500, Jeff Garzik wrote:
>>
>> >(tangent warning!)
>> >Another long term idea I would eventually like to realize is the removal
>> >of device ids from the C source code. ...

Hmm, maybe Linux should use Microsoft's ".inf" file syntax? %-)

That's one thing that it achieves, at the cost of serious chaos
when the files with the device IDs get out of sync with the
drivers they supposedly work with.

>> True, this would be nice, but how would the driver know to bind to a new
>> device, if it isn't rebuilt, and doesn't know about the new id that was
>> just added? In the current scheme of driver matching to devices, I
>> don't see how this could be done.

It'd be good if we had ways that user mode tools can request drivers be
bound and un-bound. "usbfs" has some support for that, not exactly
packaged in the way I'd most like (and "usbfs" is problematic too).

> I think that truly seamless rebinding is doable but would require too
> much additional complexity in the kernel. Rebinding to a new id table
> between unregister() ... register() pairs, or between mod unload and mod
> load, should be enough to be useable for 98% of the cases.

I'd rather not try swapping ID tables ... likely better to keep some
of that information compiled in to the drivers, but also ADD ways that
user mode tools can modify the bindings that the kernel does (or doesn't)
establish. Unless someone wants to get radical and insist that ONLY the
user mode tools can define such policies (after bootstrapping is done).

Of course Greg's example of a Palm could be addressed using current
infrastructure and module parameters, with "wildcard" binding (to
make sure the driver can see if the device matches the parameters).

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/