> 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. I don't care where they go --
> >drivers/net/pci_ids [per directory ids?], drivers/net/3c59x.meta,
> >whereever. Anywhere but the C source code. It's quite silly to require
> >a driver rebuild just to add a single PCI id, and further, embedding
> >metadata in C source is rarely a good idea in the long term. [reference
> >some of Linus's counter-arguments when it was mentioned that Donald
> >Becker's method of including Config.{in,help} data in C source might be
> >useful]
>
>
> 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.
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.
It should be noted that David Hinds' pcmcia-cs package stores id in an
external database. There are both positive and negative lessons that
have been learned from that experience (WRT external id tables only!
:):)) too.
> Not to say I would not want to see this changed to allow this to happen,
> I'm very tired of telling USB Palm users to get a new kernel version
> just because a single device id was added which their new device has.
Indeed :/ There are also issues like vendors who want to GPG-sign
drivers, and updating the PCI id table makes the GnuPG signature and the
certification that goes along with it invalid, requiring a vendor update.
Jeff
-
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/