From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: [Patch] Selective removal mode for udev
Date: Sun, 13 Feb 2005 21:24:38 +0000 [thread overview]
Message-ID: <20050213212438.GA24179@vrfy.org> (raw)
In-Reply-To: <420C787E.7080407@suse.de>
On Fri, Feb 11, 2005 at 10:52:28AM +0100, Kay Sievers wrote:
> On Fri, 2005-02-11 at 10:18 +0100, Hannes Reinecke wrote:
> >Because we are chicken ...
> >
> >This patch adds a 'removal' mode for udev, with three possible choices:
> >
> >- all: default behaviour; remove all nodes and symlinks
> >- symlink_only: only remove symlinks, but keep device nodes
> >- none: do not remove nodes nor symlinks.
> >
> >The latter is equivalent with the existing 'ignore_remove' rule
> >statement, but implemented as a global switch.
> >
> >Properly documented in the man-page etc.
> >
> >This is basically for those worrying about 'my device node may be
> >vanishing and ooh everything will stop working'.
> >
> >Comments etc welcome.
>
> Hmm, wouldn't it be nicer to be able to set these things along with the
> rules, so we still have only one source of policy. And we are able to
> match against SUBSYSTEMS, DRIVERS and such things?
>
> Something like an OPTIONS="..." key, which may contain a list of keys
> and we can also move the no_partitions key into that.
>
> This way we can specify the "remove-policy" with an "option" only rule
> globally or only for a certain subsystem.
I've added something to my tree:
http://vrfy.bkbits.net:8080/udev/patch@1.1143?nav=cset@1.1143
We have options-only rules now:
BUS="scsi", SUBSYSTEM="block", SYSFS{removable}="1", OPTIONS="all_partitions"
will create all partitions for all block devices which are known to have removable
media.
It does not implement your remove-only-the-symlinks option. For what was it meant
to be used?
Thanks,
Kay
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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 prev parent reply other threads:[~2005-02-13 21:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-11 9:18 [Patch] Selective removal mode for udev Hannes Reinecke
2005-02-11 9:52 ` Kay Sievers
2005-02-11 10:15 ` Christian Zoz
2005-02-11 11:39 ` Kay Sievers
2005-02-11 13:51 ` Hannes Reinecke
2005-02-13 21:24 ` Kay Sievers [this message]
2005-02-18 17:43 ` Hannes Reinecke
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=20050213212438.GA24179@vrfy.org \
--to=kay.sievers@vrfy.org \
--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).