All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: linux-hotplug@vger.kernel.org
Subject: Re: [Patch] Selective removal mode for udev
Date: Fri, 11 Feb 2005 13:51:14 +0000	[thread overview]
Message-ID: <420CB852.9060204@suse.de> (raw)
In-Reply-To: <420C787E.7080407@suse.de>

Kay Sievers wrote:
> On Fri, 2005-02-11 at 11:15 +0100, Christian Zoz wrote:
>>On Fri, Feb 11, Kay Sievers wrote:
[ .. ]
>>>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.
> 
Yes, this sounds reasonable.

Proposed format:

OPTIONS=<optargs>
<optargs> := "<arg>(,<arg>)*"
<arg> := ignore_scripts|remove_none|remove_symlinks

No, since we're having several options I consider it quite a waste to 
store every option with one line in the database. Can't we just use a 
bitmap for it? Would simplify handling quite a lot ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de


-------------------------------------------------------
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Ãk
_______________________________________________
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:[~2005-02-11 13:51 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 [this message]
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=420CB852.9060204@suse.de \
    --to=hare@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.