From: md@Linux.IT (Marco d'Itri)
To: linux-hotplug@vger.kernel.org
Subject: Re: new version of udev has different cd/dvd devices
Date: Thu, 05 Jan 2006 12:27:11 +0000 [thread overview]
Message-ID: <20060105122711.GA8137@wonderland.linux.it> (raw)
In-Reply-To: <43B313ED.40402@bl.com>
[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]
On Jan 04, Patrick Mansfield <patmans@us.ibm.com> wrote:
> > - there is no other component which
> ?
Debian lacks something like /sbin/hwup of SuSE, so I need a lightweight
self-contained solution.
> A simple script that generates rules to create /dev's under (perhaps)
> /dev/user that are the same as the current kernel name based on a match
> with ID_SERIAL (of course handling name collisions and more) would be
> useful. Users could then edit the rule file to create "nicer" names.
We already have stable names in /dev/disk/ and I do not think we need
more. What I need is a solution for the /dev/cdrom* symlinks.
> - allow selection of policies, so for example, you can have by-id,
> by-path, or user-named. So we don't always create by-id, by-path or
> user-named.
Why not?
> How do you know if an attribute (mainly the id / serial number) for the
> device is useful as a persistent attribute? Do you assume all are invalid,
> valid, or what?
You can't, each SUBSYSTEM needs to be special-cased.
> Should or how do you integrate this into the installer? It is bad to *not*
No (at least for Debian), because the installer does not need these
devices and I have to support upgrades and new devices added after the
initial installation.
--
ciao,
Marco
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2006-01-05 12:27 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-28 22:38 new version of udev has different cd/dvd devices Moshe Yudkowsky
2005-12-28 22:50 ` Marco d'Itri
2005-12-28 23:29 ` Kay Sievers
2005-12-29 0:10 ` Moshe Yudkowsky
2005-12-29 0:22 ` Marco d'Itri
2005-12-29 0:44 ` Moshe Yudkowsky
2005-12-29 13:20 ` Phil Howard
2005-12-29 13:36 ` Marco d'Itri
2005-12-29 15:18 ` Phil Howard
2005-12-29 16:57 ` Kay Sievers
2005-12-30 7:46 ` Greg KH
2005-12-30 13:45 ` Phil Howard
2005-12-30 18:09 ` Marco d'Itri
2005-12-30 18:16 ` Darren Salt
2005-12-30 18:49 ` Kay Sievers
2005-12-30 18:56 ` Kay Sievers
2005-12-30 19:12 ` Darren Salt
2005-12-30 19:16 ` Kay Sievers
2005-12-30 19:47 ` Darren Salt
2005-12-30 20:34 ` Kay Sievers
2005-12-30 21:00 ` Darren Salt
2005-12-30 21:45 ` Kay Sievers
2005-12-30 21:58 ` Kay Sievers
2005-12-30 22:51 ` Darren Salt
2005-12-30 23:02 ` Darren Salt
2005-12-30 23:47 ` Marco d'Itri
2005-12-31 0:04 ` Kay Sievers
2005-12-31 0:20 ` Darren Salt
2005-12-31 0:39 ` Marco d'Itri
2006-01-02 10:35 ` Martin Schwenke
2006-01-04 18:48 ` Patrick Mansfield
2006-01-04 21:23 ` Darren Salt
2006-01-05 12:27 ` Marco d'Itri [this message]
2006-01-05 17:03 ` Greg KH
2006-01-05 17:52 ` Greg KH
2006-01-05 18:50 ` patman
2006-01-06 0:50 ` Greg KH
2006-01-06 3:40 ` patman
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=20060105122711.GA8137@wonderland.linux.it \
--to=md@linux.it \
--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).