From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: [Patch] Selective removal mode for udev
Date: Fri, 11 Feb 2005 11:39:24 +0000 [thread overview]
Message-ID: <1108121964.5397.31.camel@localhost.localdomain> (raw)
In-Reply-To: <420C787E.7080407@suse.de>
On Fri, 2005-02-11 at 11:15 +0100, Christian Zoz wrote:
>On Fri, Feb 11, 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.
>>
>> 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.
>
>For indiviual rules there is ignore_remove. And as a global switch an
>option in udev.conf is much easier. The user needs no knowldege about
>rule writing.
You shouldn't change udev.conf, if you don't know how to write rules. :)
The point is that it's nice to have _all_ policy from one source.
One line with:
OPTIONS="no_remove"
will do the same as the config option. But you can limit its focus with
additional keys to certain devices if needed.
We've removed the default permissions settings from udev.conf for the
same reason.
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-11 11:39 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 [this message]
2005-02-11 13:51 ` Hannes Reinecke
2005-02-13 21:24 ` Kay Sievers
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=1108121964.5397.31.camel@localhost.localdomain \
--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).