Selective removal mode for udev

PATCH In review Hannes Reinecke 3 participants 7 messages Feb 11, 2005 – Feb 18, 2005

lore

Share & tools

lore

Hannes Reinecke

author

2005-02-11 09:18 UTC #0 lore raw

PATCH 1/1 Selective removal mode for udev

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.

Cheers,

Hannes

Signature · 4 lines

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

===== udev.8.in 1.77 vs edited =====

udev.8.in +15 -0

@@ -59,6 +59,21 @@
 The switch to enable/disable logging of udev information
 The default value is
 .IR yes .
+.TP
+.B udev_remove
+Configure the behaviour for remove events. Possible values are
+.IR all ,
+.IR symlinks_only ,
+.IR none .
+When set to
+.IR all ,
+udev will remove all device information (this is the default). When
+set to
+.IR symlinks_only ,
+udev will remove all symlinks but leave the device node
+intact. When set to
+.IR none ,
+udev will not remove any device information.
 .P
 .RI "A sample " udev.conf " file might look like this:
 .sp

===== udev_config.c 1.31 vs edited =====

udev_config.c +12 -0

@@ -48,6 +48,7 @@
 int udev_log;
 int udev_dev_d;
 int udev_hotplug_d;
+int udev_remove_mode = UDEV_REMOVE_ALL;
 
 
 static int string_is_true(const char *str)

@@ -164,6 +165,17 @@
 
 		if (strcasecmp(variable, "udev_log") == 0) {
 			udev_log = string_is_true(value);
+			continue;
+		}
+
+		if (strcasecmp(variable, "udev_remove") == 0) {
+			if (strcasecmp(value,"all") == 0) {
+				udev_remove_mode=UDEV_REMOVE_ALL;
+			} else if (strcasecmp(value,"symlinks_only") == 0) {
+				udev_remove_mode=UDEV_REMOVE_SYMLINKS;
+			} else if (strcasecmp(value,"none")) {
+				udev_remove_mode=UDEV_REMOVE_NONE;
+			}
 			continue;
 		}
 	}

===== udev_db.c 1.41 vs edited =====

udev_db.c +5 -0

@@ -165,6 +165,11 @@
 	get_db_filename(udev, filename, SYSFS_PATH_MAX);
 	unlink(filename);
 
+	if (udev_remove_mode == UDEV_REMOVE_SYMLINKS) {
+		memset(udev->symlink, 0, NAME_SIZE);
+		udev_db_add_device(udev);
+	}
+
 	return 0;
 }

===== udev.h 1.84 vs edited =====

udev.h +6 -0

@@ -48,6 +48,11 @@
 
 #define DEFAULT_PARTITIONS_COUNT	15
 
+/* Removal modes to keep whiners happy */
+#define UDEV_REMOVE_ALL			0
+#define UDEV_REMOVE_SYMLINKS		1
+#define UDEV_REMOVE_NONE		2
+
 struct udevice {
 	char devpath[DEVPATH_SIZE];
 	char subsystem[SUBSYSTEM_SIZE];

@@ -89,5 +94,6 @@
 extern int udev_log;
 extern int udev_dev_d;
 extern int udev_hotplug_d;
+extern int udev_remove_mode;
 
 #endif

===== udev_remove.c 1.45 vs edited =====

udev_remove.c +11 -0

@@ -80,6 +80,11 @@
 	snprintf(filename, NAME_SIZE, "%s/%s", udev_root, udev->name);
 	filename[NAME_SIZE-1] = '\0';
 
+	if (udev_remove_mode == UDEV_REMOVE_SYMLINKS) {
+		dbg("remove device nodes for '%s' requested to be ignored by config", udev->name);
+		goto remove_symlinks;
+	}
+
 	info("removing device node '%s'", filename);
 	retval = unlink_secure(filename);
 	if (retval)

@@ -104,6 +109,7 @@
 	if (strchr(udev->name, '/'))
 		delete_path(filename);
 
+ remove_symlinks:
 	foreach_strpart(udev->symlink, " ", pos, len) {
 		char linkname[NAME_SIZE];

@@ -152,6 +158,11 @@
 
 	if (udev->ignore_remove) {
 		dbg("remove event for '%s' requested to be ignored by rule", udev->name);
+		return 0;
+	}
+
+	if (udev_remove_mode == UDEV_REMOVE_NONE) {
+		dbg("remove event for '%s' requested to be ignored by config", udev->name);
 		return 0;
 	}

Kay Sievers

2005-02-11 09:52 UTC #1 lore raw

Quoted 11 lines · Hannes Reinecke

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.

Quoted 6 lines

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.

How does that sound?

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_id396&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Christian Zoz

2005-02-11 10:15 UTC #2 lore raw

In reply to Hannes Reinecke

Quoted 16 lines · Kay Sievers

Quoted 10 lines · Hannes Reinecke
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?

Quoted 5 lines

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.

Signature · 14 lines

ciao, christian

睡眠不足はいい仕事の敵だ。


-------------------------------------------------------
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_id396&op�k
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Kay Sievers

2005-02-11 11:39 UTC #3 lore raw

In reply to Hannes Reinecke

Quoted 20 lines · Christian Zoz

Quoted 19 lines · Kay Sievers
Quoted 10 lines · Hannes Reinecke
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.

Quoted 6 lines

Quoted 2 lines
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

Hannes Reinecke

author

2005-02-11 13:51 UTC #4 lore raw

In reply to Hannes Reinecke

Quoted 2 lines · Kay Sievers

Quoted 1 line · Christian Zoz
On Fri, Feb 11, Kay Sievers wrote:

[ .. ]

Quoted 15 lines

Quoted 4 lines
Quoted 4 lines
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?
Quoted 8 lines
Quoted 5 lines
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. :)

Quoted 9 lines

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

Signature · 15 lines

Dr. Hannes Reinecke			[email protected]
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_id396&op�k
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Kay Sievers

2005-02-13 21:24 UTC #5 lore raw

In reply to Hannes Reinecke

Quoted 23 lines · Kay Sievers

Quoted 11 lines · Hannes Reinecke
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.
Quoted 6 lines
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?

Quoted 5 lines

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/[email protected][email protected]

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

Hannes Reinecke

author

2005-02-18 17:43 UTC #6 lore raw

In reply to Hannes Reinecke

Quoted 36 lines · Kay Sievers

Quoted 24 lines · Kay Sievers
Quoted 11 lines · Hannes Reinecke
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.
Quoted 6 lines
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?
Quoted 5 lines
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/[email protected][email protected]

Quoted 9 lines

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