linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

             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).