device id version _string_?
Hello, Keith.
I was wondering what you think of the idea of having a
short version string for a device ID structure rather than a version number. The advantage of this is that it allows modified kernels to ensure that an incompatible version of depmod will complain about an unknown version string without requiring central coordination to hand out version numbers or determine an order to them. It could also make the naming more mnemonic.
For example, let's say Yellow Dog decides to ship an
enhanced version of (future) FireWire ID's. They might set their firewire_device_id version string to string to "yellow1" to ensure that people use a depmod that supports their kernel (or at least get a warning about it so they can expect firewire hot plugging not to work). Later, if that format is rolled into the standard kernel or you want to support it from the stock modutils, you could integrate the code that handles that particular version string value.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104 [email protected] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · Adam J. Richter
I was wondering what you think of the idea of having a
short version string for a device ID structure rather than a version number. The advantage of this is that it allows modified kernels to ensure that an incompatible version of depmod will complain about an unknown version string without requiring central coordination to hand out version numbers or determine an order to them. It could also make the naming more mnemonic.
I hate the idea of distributors or third party developers shipping anything that changes kernel ABI's. The downstream dependencies and side effects are just too messy, especially when users upgrade their user space utilities and lose the patched support. Modutils only supports the standard kernel ABI, as defined by Linus plus work in progress on the official development lists.
There is no good reason for anybody to ship a modified format for any hotplug table without first discussing it on the hotplug list and getting agreement about the new format and its implications on existing code. Kernel ABI's must only be changed by the group that maintains them.
I cannot stop anybody going off on their own and effectively forking hotplug. But they will have to create a new table name instead of corrupting an existing table format, ship their own version of modutils with a different name, ship their own scripts to handle the new table and they will be completely responsible for maintaining all their forked code.
Bottom line, I do not want any questions or problems caused by people who fork a kernel ABI. You fork it, you handle _all_ the problems, I am not going to support you (generic "you").
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Hi Adam,
Would you mind clearly stating what it is in Kieth's patch that doesn't work for you? Then Kieth and others can address your concerns. If I'm not mistaken, your current concerns have only to do with the fact that Kieth's patch has been accepted by Linus. That seems like a poor reason to redesign the system.
Did I just miss the place where you told Kieth that his patch was fundamentally flawed?
Thanks,
Miles
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel