device id version _string_?

device id version _string_?

[Adam J. Richter]

	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
adam@yggdrasil.com     \ /                  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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: device id version _string_?

[Keith Owens]

On Sat, 20 Jan 2001 19:29:37 -0800, 
"Adam J. Richter" <adam@yggdrasil.com> wrote:
>	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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: device id version _string_?

[Miles Lane]

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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel