linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Alexander E. Patrakov" <patrakov@ums.usu.ru>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev - that famouse obsolete %e option
Date: Wed, 02 Aug 2006 12:54:08 +0000	[thread overview]
Message-ID: <44D0A070.2000807@ums.usu.ru> (raw)
In-Reply-To: <d5a13c80607310524o73ae4a68ib58f0311176af6ee@mail.gmail.com>

VMiklos wrote:
> 2006/8/1, Kay Sievers <kay.sievers@vrfy.org>:
>> If you want to work on this, please start with one of the several
>> solutions to name optical drives persistently by writing udev rules. I'm
>> sure at some point we will include one of them in the udev tree.
> 
> here cames my first try:
> 
> http://frugalware.org/~vmiklos/patches/udev-096-optical_gen.diff
> 
> comments? :)

(I have not fully read that, but can still identify missing pieces)

The interaction with the boot scripts must be documented. The problem is
that udev rules that are needed to generate cdrom rules are triggered
when the root filesystem is read-only, and thus the generated rules
cannot be saved without additional efforts.

Debian works around this by saving the generated rules to /dev/shm and
copying them to /etc/udev/rules.d in a separate bootscript. LFS in the
past (until the Debian-based generator was completely dropped due to
cries of some people about too much automation, and because of mails
like
http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2006-May/057166.html) 

did the following:

# /etc/udev/rules.d/81-cdrom.rules: Set CD-ROM permissions and get
device capabilities
ACTION="add", SUBSYSTEM="block", ENV{ID_TYPE}="cd",
IMPORT{program}="cdrom_id --export $tempnode", GROUP="cdrom"

# /etc/udev/rules.d/82-persistent-cd.rules: generated file
ACTION="add", SUBSYSTEM="block", BUS="ide", ID="0.1",
ENV{ID_CDROM}="1", SYMLINK+="cdrom", ENV{GENERATED}="1"

# /etc/udev/rules.d/83-cdrom-symlinks.rules: Determine CD drive capability.

ACTION!="add",          GOTO="cd_aliases_generator_end"
SUBSYSTEM!="block",     GOTO="cd_aliases_generator_end"
ENV{GENERATED}="?*",   GOTO="cd_aliases_generator_end"

# Fail the uevent if the autogenerated rules cannot be saved
ENV{ID_CDROM}="?*", PROGRAM="/bin/grep -c ' / [^[:space:]]* rw'
/proc/mounts",
RESULT!="2", RUN+="/bin/false", GOTO="cd_aliases_generator_end"

ENV{ID_CDROM}="?*", PROGRAM="write_cd_aliases", SYMLINK+="%c"

LABEL="cd_aliases_generator_end"

The idea is that the rule with grep fails the entire uevent when the
root filesystem is read-only. Udev will then add a symlink to the
relevant directory in sysfs to /dev/.udev/failed, and a separate
bootscript will retrigger all failed uevents again after mounting all
filesystems.

-- 
Alexander E. Patrakov


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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

  parent reply	other threads:[~2006-08-02 12:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-31 12:24 udev - that famouse obsolete %e option VMiklos
2006-07-31 12:45 ` Alexander E. Patrakov
2006-07-31 12:51 ` Marco d'Itri
2006-07-31 12:57 ` Alexander E. Patrakov
2006-07-31 14:48 ` Marco d'Itri
2006-07-31 17:40 ` Kay Sievers
2006-07-31 23:45 ` VMiklos
2006-08-01 10:27 ` VMiklos
2006-08-01 12:02 ` Olivier Blin
2006-08-01 12:27 ` Kay Sievers
2006-08-01 16:17 ` VMiklos
2006-08-01 16:35 ` Andrey Borzenkov
2006-08-01 16:46 ` Bryan Kadzban
2006-08-01 16:47 ` Kay Sievers
2006-08-01 18:16 ` VMiklos
2006-08-01 18:28 ` Kay Sievers
2006-08-01 18:57 ` VMiklos
2006-08-02 12:06 ` VMiklos
2006-08-02 12:54 ` Alexander E. Patrakov [this message]
2006-08-02 20:28 ` VMiklos
2006-08-07 10:32 ` VMiklos
2006-08-11 10:18 ` VMiklos

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=44D0A070.2000807@ums.usu.ru \
    --to=patrakov@ums.usu.ru \
    --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).