Re: [Patch] Selective removal mode for udev

[Hannes Reinecke <hare@suse.de>]

Kay Sievers wrote:
> 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?
> 
For chickens.

There are some which consider removing of device nodes a bad idea.

This is basically meant to keep them happy whilst others have the choice 
of doing the right thing.
This sort of thing tended to occur during re-partitioning, as the remove 
events in general were far quicker processed than the 'add' events.
Should be resolved with using udev, but arguing with them tends to be 
pointless. Hence this options.

Cheers,

Hannes


-------------------------------------------------------
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