From: Kevan Rehm <kfr@sgi.com>
To: linux-hotplug@vger.kernel.org
Subject: shouldn't device names be "standardized"?
Date: Sun, 07 Nov 2004 16:56:26 +0000 [thread overview]
Message-ID: <418E53BA.1030501@sgi.com> (raw)
Greetings,
Something that confuses me about udev.rules is the tremendous
flexibility possible in producing device names. It seems more of a
curse than a blessing to me, so I must be missing something. Could
someone please provide some insight?
On our brand-new SLES9 machine, I was writing a udev rule to produce
tape device pathnames that have the same persistent format as the device
names our software app already uses on SGI IRIX systems, so that the app
could use common code for both systems. When I went to add the rule, I
discovered that there was a /sbin/udev.get_persistent_device_name.sh
rule already in place that generates persistent disk and tape device
names using both hardware paths and vendor/product/serialno paths.
These names are incompatible with the names that we currently use.
Other machines I have logged into don't appear to have this
udev.get_persistent_device_name.sh installed.
Which got me to thinking. If I add my rule to make my application work,
then what other applications am I breaking who depend upon the rule
already in place, or who depend upon having no rule in place at all,
e.g.who expect traditional. /dev/st0 names?
How does one write a software application that will run correctly on 2.6
Linux kernels everywhere when different machines will have different
udev.rules pathname conventions in place? The only thing I could think
of was to parse the sysfs tree to find the devices I want, then
recursively scan /dev looking for devices with matching major/minor
values in order to come up with the correct device names to use. That
seems like a lot of work!
Then I thought that maybe udev processes ALL matching rules, and so it
would produce names for each inserted rule plus the default rule and
then everyone would be happy, but this doesn't appear to be the case
(unless I misunderstand). Besides, there could still be collisions
between the names generated by different rules.
So it seems to me that it would be better to have some sort of standard
name for devices, sort of like the Linux Filesystem Hierarchy Standard,
where there are names that an application could trust would be present
on any Linux box it would care to run on.
Obviously you-all have already thought of this, so could someone
enlighten me? What am I missing?
Thanks very much,
Kevan Rehm
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id\x12065&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next reply other threads:[~2004-11-07 16:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-07 16:56 Kevan Rehm [this message]
2004-11-07 17:20 ` shouldn't device names be "standardized"? Marco d'Itri
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=418E53BA.1030501@sgi.com \
--to=kfr@sgi.com \
--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).