linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: linux-hotplug@vger.kernel.org
Subject: Re: device id version _string_?
Date: Sun, 21 Jan 2001 03:47:01 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-98004876207646@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-98004776106627@msgid-missing>

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

  reply	other threads:[~2001-01-21  3:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-21  3:29 device id version _string_? Adam J. Richter
2001-01-21  3:47 ` Keith Owens [this message]
2001-01-21  4:33 ` Miles Lane

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-98004876207646@msgid-missing \
    --to=kaos@ocs.com.au \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).