[PATCH] udev+ifrename integration

[PATCH] udev+ifrename integration

[Jean Tourrilhes]

	Hi,

	Integration of ifrename into udev has been a thorn in the side
of some major distro (Unbuntu, Debian...).
	There is a set of users that are hooked to ifrename for
renaming interfaces. Ifrename has various power user feature that
allow you to shoot yourself in the foot pretty nicely, and those users
can't live without that. They are integrating ifrename into udev in
various ad-hoc ways and everything "seems" to work.
	Then, the distro maintainers point out that they can't do that
because in reality it breaks udev (and HAL, and NetworkManager, and so
on).

	One of the solution is to migrate all apps using Hotplug
events to use 'ifindex' instead of 'ifname'. This is needed anyway to
fix the netif remove/add race condition. But this require kernel
support (which I just sent to Kay) and won't happen overnight.

	The other solution is to offer a clean integration of ifrename
into udev. This has other benefits as well.
	The attached patch for udev-105 does just that. The first
thing to notice is that the changes are minimal. Also, none of the
changes are specific to ifrename, and those could be used by any
network renaming program/script and solutions based on 'nameif' of
'iproute2'.
	Another point is that this integration will mostly work with
older version of ifrename but only version 29-pre14 or later will
fully work.

	Finally, the udev rules would look like :
----------------------------------------------------
ENV{UDEVTEST}="yes", SUBSYSTEM="net", PROGRAM="/usr/local/sbin/ifrename -D -V -i %k", NAME:="%c", OPTIONS+="skip_netrename", OPTIONS+="last_rule"
SUBSYSTEM="net", PROGRAM="/usr/local/sbin/ifrename -i %k", NAME:="%c", OPTIONS+="skip_netrename", OPTIONS+="last_rule"
----------------------------------------------------

	Have fun...

	Jean

P.S. : Marco, bug 363598. Non voglio aggiungere niente a questo bug ;-)

-----------------------------------------------------------
diff -u -p udev-105-pristine/udev.7 udev-105/udev.7
--- udev-105-pristine/udev.7	2007-02-02 16:24:48.000000000 -0800
+++ udev-105/udev.7	2007-02-28 17:48:37.000000000 -0800
@@ -146,7 +146,7 @@ keys can be specified per rule. Dependin
 .PP
 \fBPROGRAM\fR
 .RS 4
-Execute external program. The key is true, if the program returns without exit code zero. The whole event environment is available to the executed program. The program's output printed to stdout is available for the RESULT key.
+Execute external program. The key is true, if the program returns with exit code zero. The whole event environment is available to the executed program. The program's output printed to stdout is available for the RESULT key.
 .RE
 .PP
 \fBRESULT\fR
diff -u -p udev-105-pristine/udev.h udev-105/udev.h
--- udev-105-pristine/udev.h	2007-02-02 16:24:48.000000000 -0800
+++ udev-105/udev.h	2007-02-28 17:26:03.000000000 -0800
@@ -85,6 +85,7 @@ struct udevice {
 	int partitions;
 	int ignore_device;
 	int ignore_remove;
+	int skip_netrename;
 	char program_result[PATH_SIZE];
 	int test_run;
 };
diff -u -p udev-105-pristine/udev_device.c udev-105/udev_device.c
--- udev-105-pristine/udev_device.c	2007-02-02 16:24:48.000000000 -0800
+++ udev-105/udev_device.c	2007-02-28 17:26:54.000000000 -0800
@@ -213,10 +213,12 @@ int udev_device_event(struct udev_rules 
 		if (strcmp(udev->name, udev->dev->kernel) != 0) {
 			char *pos;
 
-			retval = rename_netif(udev);
-			if (retval != 0)
-				goto exit;
-			info("renamed netif to '%s'", udev->name);
+			if(!udev->skip_netrename) {
+				retval = rename_netif(udev);
+				if (retval != 0)
+					goto exit;
+				info("renamed netif to '%s'", udev->name);
+			}
 
 			/* export old name */
 			setenv("INTERFACE_OLD", udev->dev->kernel, 1);
diff -u -p udev-105-pristine/udev_rules.c udev-105/udev_rules.c
--- udev-105-pristine/udev_rules.c	2007-02-02 16:24:48.000000000 -0800
+++ udev-105/udev_rules.c	2007-02-28 17:26:45.000000000 -0800
@@ -901,6 +901,8 @@ int udev_rules_get_name(struct udev_rule
 				udev->ignore_remove = 1;
 				dbg("remove event should be ignored");
 			}
+			if (rule->skip_netrename)
+				udev->skip_netrename = 1;
 			/* apply all_partitions option only at a main block device */
 			if (rule->partitions &&
 			    strcmp(udev->dev->subsystem, "block") = 0 && udev->dev->kernel_number[0] = '\0') {
diff -u -p udev-105-pristine/udev_rules.h udev-105/udev_rules.h
--- udev-105-pristine/udev_rules.h	2007-02-02 16:24:48.000000000 -0800
+++ udev-105/udev_rules.h	2007-02-28 17:17:36.000000000 -0800
@@ -90,7 +90,8 @@ struct udev_rule {
 	unsigned int partitions;
 	unsigned int last_rule:1,
 		     ignore_device:1,
-		     ignore_remove:1;
+		     ignore_remove:1,
+		     skip_netrename:1;
 
 	size_t bufsize;
 	char buf[];
diff -u -p udev-105-pristine/udev_rules_parse.c udev-105/udev_rules_parse.c
--- udev-105-pristine/udev_rules_parse.c	2007-02-02 16:24:48.000000000 -0800
+++ udev-105/udev_rules_parse.c	2007-02-28 17:36:10.000000000 -0800
@@ -569,6 +569,10 @@ static int add_to_rules(struct udev_rule
 				dbg("creation of partition nodes requested");
 				rule->partitions = DEFAULT_PARTITIONS_COUNT;
 			}
+			if (strstr(value, "skip_netrename") != NULL) {
+				dbg("skipping net rename");
+				rule->skip_netrename = 1;
+			}
 			valid = 1;
 			continue;
 		}
diff -u -p udev-105-pristine/udevtest.c udev-105/udevtest.c
--- udev-105-pristine/udevtest.c	2007-02-02 16:24:48.000000000 -0800
+++ udev-105/udevtest.c	2007-02-28 16:53:29.000000000 -0800
@@ -110,6 +110,8 @@ int main(int argc, char *argv[], char *e
 	setenv("DEVPATH", udev->dev->devpath, 1);
 	setenv("SUBSYSTEM", udev->dev->subsystem, 1);
 	setenv("ACTION", "add", 1);
+	/* Allow rules to know it's debugging time */
+	setenv("UDEVTEST", "yes", 1);
 
 	printf("This program is for debugging only, it does not create any node,\n"
 	       "or run any program specified by a RUN key. It may show incorrect results,\n"

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Kay Sievers]

On Wed, 2007-03-07 at 11:44 -0800, Jean Tourrilhes wrote:
> 	Integration of ifrename into udev has been a thorn in the side
> of some major distro (Unbuntu, Debian...).

That's all because it's just not needed. Udev ships a full-featured
solution for persistent network names, and that's what these distros
use.

> 	There is a set of users that are hooked to ifrename for
> renaming interfaces. Ifrename has various power user feature that
> allow you to shoot yourself in the foot pretty nicely, and those users
> can't live without that. They are integrating ifrename into udev in
> various ad-hoc ways and everything "seems" to work.
> 	Then, the distro maintainers point out that they can't do that
> because in reality it breaks udev (and HAL, and NetworkManager, and so
> on).
> 
> 	One of the solution is to migrate all apps using Hotplug
> events to use 'ifindex' instead of 'ifname'. This is needed anyway to
> fix the netif remove/add race condition. But this require kernel
> support (which I just sent to Kay) and won't happen overnight.

There is no known add/remove race since we killed the /sbin/hotplug
fork-bomb. Care to explain what you mean?

> 	The other solution is to offer a clean integration of ifrename
> into udev. This has other benefits as well.
> 	The attached patch for udev-105 does just that. The first
> thing to notice is that the changes are minimal. Also, none of the
> changes are specific to ifrename, and those could be used by any
> network renaming program/script and solutions based on 'nameif' of
> 'iproute2'.
> 	Another point is that this integration will mostly work with
> older version of ifrename but only version 29-pre14 or later will
> fully work.
> 
> 	Finally, the udev rules would look like :
> ----------------------------------------------------
> ENV{UDEVTEST}="yes", SUBSYSTEM="net", PROGRAM="/usr/local/sbin/ifrename -D -V -i %k", NAME:="%c", OPTIONS+="skip_netrename", OPTIONS+="last_rule"
> SUBSYSTEM="net", PROGRAM="/usr/local/sbin/ifrename -i %k", NAME:="%c", OPTIONS+="skip_netrename", OPTIONS+="last_rule"
> ----------------------------------------------------

You can almost never use "last_rule", that will break a lot of stuff
that wants to see event from udev, including HAL.

> --- udev-105-pristine/udev.h	2007-02-02 16:24:48.000000000 -0800
> +++ udev-105/udev.h	2007-02-28 17:26:03.000000000 -0800
> @@ -85,6 +85,7 @@ struct udevice {
>  	int partitions;
>  	int ignore_device;
>  	int ignore_remove;
> +	int skip_netrename;

You ask udev to rename a netif, but want to skip that part, but use the
rest of the logic in NAME=, huh?
Why not just instruct your external tool, not to actually rename the
interface (dry run), but return the name, and udev will do the rename?

> --- udev-105-pristine/udevtest.c	2007-02-02 16:24:48.000000000 -0800
> +++ udev-105/udevtest.c	2007-02-28 16:53:29.000000000 -0800
> @@ -110,6 +110,8 @@ int main(int argc, char *argv[], char *e
>  	setenv("DEVPATH", udev->dev->devpath, 1);
>  	setenv("SUBSYSTEM", udev->dev->subsystem, 1);
>  	setenv("ACTION", "add", 1);
> +	/* Allow rules to know it's debugging time */
> +	setenv("UDEVTEST", "yes", 1);

There is no real need for that, just match on UDEV_LOG, if you want to
add debugging rules. Udevtest has at least LOG_INFO, the udev default is
LOG_ERR. 
Also the udevtest program doesn't really work today, and is kind of
useless, because we match on all the kernel supplied variables which are
not available.

Kay


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Jean Tourrilhes]

On Wed, Mar 07, 2007 at 09:35:18PM +0100, Kay Sievers wrote:
> On Wed, 2007-03-07 at 11:44 -0800, Jean Tourrilhes wrote:
> > 	Integration of ifrename into udev has been a thorn in the side
> > of some major distro (Unbuntu, Debian...).
> 
> That's all because it's just not needed. Udev ships a full-featured
> solution for persistent network names, and that's what these distros
> use.

	When it comes to renaming network interfaces, I would not call
udev full featured. It has basic renaming, that work for 99% of users,
but there are plenty of things that udev doesn't know how to do. And
that's ok, because we can use ifrename in those cases. And it's
probably a good idea to keep udev small and tiny and push the bloat in
ifrename, because ifrename is optional.

> There is no known add/remove race since we killed the /sbin/hotplug
> fork-bomb. Care to explain what you mean?

	Let's keep this issue in its own separate thread.

> > 	Finally, the udev rules would look like :
> > ----------------------------------------------------
> > ENV{UDEVTEST}="yes", SUBSYSTEM="net", PROGRAM="/usr/local/sbin/ifrename -D -V -i %k", NAME:="%c", OPTIONS+="skip_netrename", OPTIONS+="last_rule"
> > SUBSYSTEM="net", PROGRAM="/usr/local/sbin/ifrename -i %k", NAME:="%c", OPTIONS+="skip_netrename", OPTIONS+="last_rule"
> > ----------------------------------------------------
> 
> You can almost never use "last_rule", that will break a lot of stuff
> that wants to see event from udev, including HAL.

	Good to know. I was not sure, and I can drop it.

> > --- udev-105-pristine/udev.h	2007-02-02 16:24:48.000000000 -0800
> > +++ udev-105/udev.h	2007-02-28 17:26:03.000000000 -0800
> > @@ -85,6 +85,7 @@ struct udevice {
> >  	int partitions;
> >  	int ignore_device;
> >  	int ignore_remove;
> > +	int skip_netrename;
> 
> You ask udev to rename a netif, but want to skip that part, but use the
> rest of the logic in NAME=, huh?
> Why not just instruct your external tool, not to actually rename the
> interface (dry run), but return the name, and udev will do the rename?

	Because you would loose the following features of ifrename :
		o wildcard renaming
		o takeover
	There is also another feature that I have not yet implemented
in ifrename that you could not implement with that, which is alternate
renaming. And I have other more nebulous ideas.

> > --- udev-105-pristine/udevtest.c	2007-02-02 16:24:48.000000000 -0800
> > +++ udev-105/udevtest.c	2007-02-28 16:53:29.000000000 -0800
> > @@ -110,6 +110,8 @@ int main(int argc, char *argv[], char *e
> >  	setenv("DEVPATH", udev->dev->devpath, 1);
> >  	setenv("SUBSYSTEM", udev->dev->subsystem, 1);
> >  	setenv("ACTION", "add", 1);
> > +	/* Allow rules to know it's debugging time */
> > +	setenv("UDEVTEST", "yes", 1);
> 
> There is no real need for that, just match on UDEV_LOG, if you want to
> add debugging rules. Udevtest has at least LOG_INFO, the udev default is
> LOG_ERR. 

	Good to know.

> Also the udevtest program doesn't really work today, and is kind of
> useless, because we match on all the kernel supplied variables which are
> not available.

	So, what is its replacement ?

> Kay

	Have fun...

	Jean

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Scott James Remnant]

[-- Attachment #1.1: Type: text/plain, Size: 508 bytes --]

On Wed, 2007-03-07 at 13:11 -0800, Jean Tourrilhes wrote:

> 	Because you would loose the following features of ifrename :
> 		o wildcard renaming
> 		o takeover
> 	There is also another feature that I have not yet implemented
> in ifrename that you could not implement with that, which is alternate
> renaming. And I have other more nebulous ideas.
> 
These things are both implemented in the Ubuntu patch for udev.

Scott
-- 
Scott James Remnant
Ubuntu Development Manager
scott@ubuntu.com

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Jean Tourrilhes]

On Thu, Mar 08, 2007 at 11:24:16AM +0000, Scott James Remnant wrote:
> On Wed, 2007-03-07 at 13:11 -0800, Jean Tourrilhes wrote:
> 
> > 	Because you would loose the following features of ifrename :
> > 		o wildcard renaming
> > 		o takeover
> > 	There is also another feature that I have not yet implemented
> > in ifrename that you could not implement with that, which is alternate
> > renaming. And I have other more nebulous ideas.
> > 
> These things are both implemented in the Ubuntu patch for udev.
> 
> Scott

	Yes, but your patch does not seem to be in the upstream
udev. Why is that ?
	And does you patch support all features of ifrename, or just a
select few ?

	I see my patch as having the following advantages :
		o no bloat in udev.
		o no extra maintainance effort for udev.
		o you get the real ifrename, with 100% features.
		o not ifrename specific, you can use this extension
for any other tool that you may wish to use or create. I would never
claim that ifrename is everything to all users.
	For example, every time a new feature is added in ifrename,
you automatically get it without having to lift a finger. How cool it
that ? It looks to me like a win-win situation.

	My other points was that it's not only about features existing
currently in ifrename, but about features that may be implemented in
the future. Having as much flexibility as possible in the design open
the door to inovation.

	Have fun...

	Jean

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Scott James Remnant]

[-- Attachment #1.1: Type: text/plain, Size: 1529 bytes --]

On Thu, 2007-03-08 at 10:15 -0800, Jean Tourrilhes wrote:

> On Thu, Mar 08, 2007 at 11:24:16AM +0000, Scott James Remnant wrote:
> > On Wed, 2007-03-07 at 13:11 -0800, Jean Tourrilhes wrote:
> > 
> > > 	Because you would loose the following features of ifrename :
> > > 		o wildcard renaming
> > > 		o takeover
> > > 	There is also another feature that I have not yet implemented
> > > in ifrename that you could not implement with that, which is alternate
> > > renaming. And I have other more nebulous ideas.
> > > 
> > These things are both implemented in the Ubuntu patch for udev.
> > 
> Yes, but your patch does not seem to be in the upstream
> udev. Why is that ?
> 
It's been submitted upstream, but not accepted; Kay tends towards
conservatism until things are proved to be needed.

> And does you patch support all features of ifrename, or just a
> select few ?
> 
Select few.

We explicitly do not want to support all of the features of ifrename,
because it caused us nothing but headaches in the past.

All we want is for interface names to be consistent across reboots, and
for there to be no race conditions between the interface being added and
renamed; the patch we use is sufficient to do that.

When we used to call-out ifrename from hotplug, we had incredible
numbers of problems due to ifrename mis-features and race conditions
inherent with not controlling the interface renaming ourselves.

Scott
-- 
Scott James Remnant
Ubuntu Development Manager
scott@ubuntu.com

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Kay Sievers]

On Wed, 2007-03-07 at 13:11 -0800, Jean Tourrilhes wrote:
> On Wed, Mar 07, 2007 at 09:35:18PM +0100, Kay Sievers wrote:
> > On Wed, 2007-03-07 at 11:44 -0800, Jean Tourrilhes wrote:
> > > 	Integration of ifrename into udev has been a thorn in the side
> > > of some major distro (Unbuntu, Debian...).
> > 
> > That's all because it's just not needed. Udev ships a full-featured
> > solution for persistent network names, and that's what these distros
> > use.
> 
> 	When it comes to renaming network interfaces, I would not call
> udev full featured. It has basic renaming, that work for 99% of users,
> but there are plenty of things that udev doesn't know how to do.

Sure, I said "full featured persistent names", not full of crazy
features for renaming. :)

> And
> that's ok, because we can use ifrename in those cases. And it's
> probably a good idea to keep udev small and tiny and push the bloat in
> ifrename, because ifrename is optional.


> > > --- udev-105-pristine/udev.h	2007-02-02 16:24:48.000000000 -0800
> > > +++ udev-105/udev.h	2007-02-28 17:26:03.000000000 -0800
> > > @@ -85,6 +85,7 @@ struct udevice {
> > >  	int partitions;
> > >  	int ignore_device;
> > >  	int ignore_remove;
> > > +	int skip_netrename;
> > 
> > You ask udev to rename a netif, but want to skip that part, but use the
> > rest of the logic in NAME=, huh?
> > Why not just instruct your external tool, not to actually rename the
> > interface (dry run), but return the name, and udev will do the rename?
> 
> 	Because you would loose the following features of ifrename :
> 		o wildcard renaming
> 		o takeover
> 	There is also another feature that I have not yet implemented
> in ifrename that you could not implement with that, which is alternate
> renaming. And I have other more nebulous ideas.

Takeover probably works, and we didn't see a real use-case for wildcards
as the main goal is persistence, and not transforming from one random
namespace into another random namespace.

Anyway, how about you add a "hotplug" option to ifrename to output all
useful information in env-key format after its work, like:
  $ifrename --hotplug-use -i %k
  DEVPATH=/sys/class/net/renamed3
  INTERFACE=renamed3
  INTERFACE_OLD=eth1

and whatever information may be useful for the stuff that runs after the
renaming, I'm sure you will find something more to export. :)

Integration into udev would happen with the IMPORT= key. I would change
udev to update all internal variables that carry the name, if DEVPATH is
overwritten from an IMPORT action. How does that sound to you?

> > Also the udevtest program doesn't really work today, and is kind of
> > useless, because we match on all the kernel supplied variables which are
> > not available.
> 
> 	So, what is its replacement ?

There is no real replacement, because we don't have the kernel variables
available for a test run. You can run udevd with debug and console
output and trigger real events.

Thanks,
Kay


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Jean Tourrilhes]

On Fri, Mar 09, 2007 at 11:57:49AM +0000, Scott James Remnant wrote:
> On Thu, 2007-03-08 at 10:15 -0800, Jean Tourrilhes wrote:
> > 
> > Yes, but your patch does not seem to be in the upstream
> > udev. Why is that ?
> > 
> It's been submitted upstream, but not accepted; Kay tends towards
> conservatism until things are proved to be needed.

	And my personal bias is modularity. All users should not have
to bear the cost of a selected few, but the selected few should be
able to do it.

> > And does you patch support all features of ifrename, or just a
> > select few ?
> > 
> Select few.
> 
> We explicitly do not want to support all of the features of ifrename,
> because it caused us nothing but headaches in the past.
> 
> All we want is for interface names to be consistent across reboots, and
> for there to be no race conditions between the interface being added and
> renamed; the patch we use is sufficient to do that.

	Actually, udev does a much better job at that than ifrename,
as ifrename does not autogenerate persistent rules.

> When we used to call-out ifrename from hotplug, we had incredible
> numbers of problems due to ifrename mis-features and race conditions
> inherent with not controlling the interface renaming ourselves.

	That was more a hotplug issue than a ifrename issue. And
actually, the other big culprit there was ifupdown and its stupid
locking strategy (thank god this is now fixed).

> Scott

	Jean

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Jean Tourrilhes]

On Fri, Mar 09, 2007 at 02:59:25PM +0100, Kay Sievers wrote:
> On Wed, 2007-03-07 at 13:11 -0800, Jean Tourrilhes wrote:
> > On Wed, Mar 07, 2007 at 09:35:18PM +0100, Kay Sievers wrote:
> > > On Wed, 2007-03-07 at 11:44 -0800, Jean Tourrilhes wrote:
> > > > 	Integration of ifrename into udev has been a thorn in the side
> > > > of some major distro (Unbuntu, Debian...).
> > > 
> > > That's all because it's just not needed. Udev ships a full-featured
> > > solution for persistent network names, and that's what these distros
> > > use.
> > 
> > 	When it comes to renaming network interfaces, I would not call
> > udev full featured. It has basic renaming, that work for 99% of users,
> > but there are plenty of things that udev doesn't know how to do.
> 
> Sure, I said "full featured persistent names", not full of crazy
> features for renaming. :)

	By the way, you may want to add to your documentation that
using the MAC address does not work with some driver and that people
should use something else, such as bus-id.

> Takeover probably works,

	Actually, I hate it, but people keep asking for it.

> and we didn't see a real use-case for wildcards
> as the main goal is persistence, and not transforming from one random
> namespace into another random namespace.

	I perfectly understand, we are not targeting the same users.

> Anyway, how about you add a "hotplug" option to ifrename to output all
> useful information in env-key format after its work, like:
>   $ifrename --hotplug-use -i %k
>   DEVPATH=/sys/class/net/renamed3
>   INTERFACE=renamed3
>   INTERFACE_OLD=eth1

	Yep, trivial.

> and whatever information may be useful for the stuff that runs after the
> renaming, I'm sure you will find something more to export. :)

	Not really at this point. I'm taking suggestions.

> Integration into udev would happen with the IMPORT= key. I would change
> udev to update all internal variables that carry the name, if DEVPATH is
> overwritten from an IMPORT action. How does that sound to you?

	That's exactly what I wanted to hear from you. Let's go for it.
	I'm afraid that I don't fully understand the udev part, so
I'll defer to you.

> There is no real replacement, because we don't have the kernel variables
> available for a test run. You can run udevd with debug and console
> output and trigger real events.

	That's too bad. I like udevtest ;-)

> Thanks,
> Kay

	Thanks a lot.

	Jean

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Jean Tourrilhes]

On Fri, Mar 09, 2007 at 02:59:25PM +0100, Kay Sievers wrote:
> On Wed, 2007-03-07 at 13:11 -0800, Jean Tourrilhes wrote:
> 
> Anyway, how about you add a "hotplug" option to ifrename to output all
> useful information in env-key format after its work, like:
>   $ifrename --hotplug-use -i %k
>   DEVPATH=/sys/class/net/renamed3
>   INTERFACE=renamed3
>   INTERFACE_OLD=eth1
> 
> and whatever information may be useful for the stuff that runs after the
> renaming, I'm sure you will find something more to export. :)
> 
> Integration into udev would happen with the IMPORT= key. I would change
> udev to update all internal variables that carry the name, if DEVPATH is
> overwritten from an IMPORT action. How does that sound to you?

	Ok, I've just looked into doing that. I've implemented the
ifrename part in version 29.pre16.
	The "proof of concept" patch for udev is attached. I've not
yet tested that patch, because I'm not sure this is the right
implementation and it makes me wonder if this is the right
solution. It's definitely more messy than the previous patch I sent.

	Have fun...

	Jean

--------------------------------------------------------------

diff -u -p udev-106/udev.j1.h udev-106/udev.h
--- udev-106/udev.j1.h	2007-03-09 17:26:45.000000000 -0800
+++ udev-106/udev.h	2007-03-09 17:27:30.000000000 -0800
@@ -85,6 +85,7 @@ struct udevice {
 	int partitions;
 	int ignore_device;
 	int ignore_remove;
+	int update_devpath;
 	char program_result[PATH_SIZE];
 	int test_run;
 };
diff -u -p udev-106/udev_rules.j1.c udev-106/udev_rules.c
--- udev-106/udev_rules.j1.c	2007-03-09 14:48:19.000000000 -0800
+++ udev-106/udev_rules.c	2007-03-09 17:40:13.000000000 -0800
@@ -188,6 +188,8 @@ static int import_keys_into_env(struct u
 			dbg("import '%s=%s'", variable, value);
 			name_list_key_add(&udev->env_list, variable, value);
 			setenv(variable, value, 1);
+			if(!strcmp(variable, "INTERFACE"))
+				udev->update_devpath = 1;
 		}
 	}
 
@@ -903,6 +905,25 @@ int udev_rules_get_name(struct udev_rule
 				udev->ignore_remove = 1;
 				dbg("remove event should be ignored");
 			}
+			if (udev->update_devpath = 1) {
+				char *env;
+				char *pos;
+				env = getenv("INTERFACE");
+				if (env && strcmp(env, udev->dev->kernel)) {
+					/* Update internal variables */
+					strcpy(udev->name, env);
+					strcpy(udev->dev->kernel, env);
+					/* now fake the devpath, because the kernel name changed silently */
+					pos = strrchr(udev->dev->devpath, '/');
+					if (pos != NULL) {
+						pos[1] = '\0';
+						strlcat(udev->dev->devpath, udev->name, sizeof(udev->dev->devpath));
+						strlcpy(udev->dev->kernel, udev->name, sizeof(udev->dev->kernel));
+					}
+					/* No more renaming, we are done */
+					name_set = 1;
+				}
+			}
 			/* apply all_partitions option only at a main block device */
 			if (rule->partitions &&
 			    strcmp(udev->dev->subsystem, "block") = 0 && udev->dev->kernel_number[0] = '\0') {

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Kay Sievers]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

On Fri, 2007-03-09 at 17:50 -0800, Jean Tourrilhes wrote:
> On Fri, Mar 09, 2007 at 02:59:25PM +0100, Kay Sievers wrote:
> > On Wed, 2007-03-07 at 13:11 -0800, Jean Tourrilhes wrote:
> > 
> > Anyway, how about you add a "hotplug" option to ifrename to output all
> > useful information in env-key format after its work, like:
> >   $ifrename --hotplug-use -i %k
> >   DEVPATH=/sys/class/net/renamed3
> >   INTERFACE=renamed3
> >   INTERFACE_OLD=eth1
> > 
> > and whatever information may be useful for the stuff that runs after the
> > renaming, I'm sure you will find something more to export. :)
> > 
> > Integration into udev would happen with the IMPORT= key. I would change
> > udev to update all internal variables that carry the name, if DEVPATH is
> > overwritten from an IMPORT action. How does that sound to you?
> 
> 	Ok, I've just looked into doing that. I've implemented the
> ifrename part in version 29.pre16.
> 	The "proof of concept" patch for udev is attached. I've not
> yet tested that patch, because I'm not sure this is the right
> implementation and it makes me wonder if this is the right
> solution. It's definitely more messy than the previous patch I sent.

Oh, I think we should just match on a DEVPATH variable to import. Any
external tool, not limited to the INTERFACE variable, that causes the
kernel to change the devpath, would just need to pass the new value for
udev to update all internal values like %k %n %p.

Thanks,
Kay

[-- Attachment #2: import-devpath.patch --]
[-- Type: text/x-patch, Size: 705 bytes --]

diff --git a/udev_rules.c b/udev_rules.c
index 200b4e7..7ab3bba 100644
--- a/udev_rules.c
+++ b/udev_rules.c
@@ -186,7 +186,13 @@ static int import_keys_into_env(struct u
 		linepos = line;
 		if (get_key(&linepos, &variable, &value) == 0) {
 			dbg("import '%s=%s'", variable, value);
-			name_list_key_add(&udev->env_list, variable, value);
+
+			/* handle device, renamed by external tool, returning new path */
+			if (strcmp(variable, "DEVPATH") == 0) {
+				info("updating devpath from '%s' to '%s'", udev->dev->devpath, value);
+				sysfs_device_set_values(udev->dev, value, NULL, NULL);
+			} else
+				name_list_key_add(&udev->env_list, variable, value);
 			setenv(variable, value, 1);
 		}
 	}

[-- Attachment #3: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 226 bytes --]

_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Jean Tourrilhes]

On Sat, Mar 10, 2007 at 02:28:13PM +0100, Kay Sievers wrote:
> 
> Oh, I think we should just match on a DEVPATH variable to import. Any
> external tool, not limited to the INTERFACE variable, that causes the
> kernel to change the devpath, would just need to pass the new value for
> udev to update all internal values like %k %n %p.

	I'm sorry, but I don't get it.
	First, I don't see how the other internal variables are
updated. Maybe a sample of rules would help me.
	Second, I don't see how this would prevent subsequent naming
rules to apply.

> Thanks,
> Kay

	Thanks...

	Jean

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Kay Sievers]

On Mon, 2007-03-12 at 09:07 -0700, Jean Tourrilhes wrote:
> On Sat, Mar 10, 2007 at 02:28:13PM +0100, Kay Sievers wrote:
> > 
> > Oh, I think we should just match on a DEVPATH variable to import. Any
> > external tool, not limited to the INTERFACE variable, that causes the
> > kernel to change the devpath, would just need to pass the new value for
> > udev to update all internal values like %k %n %p.
> 
> 	I'm sorry, but I don't get it.
> 	First, I don't see how the other internal variables are
> updated.

sysfs_device_set_values(udev->dev, value, NULL, NULL);
will do this with the value of DEVPATH passed by the tool.

The tool called by IMPORT= will return:
  DEVPATH=/...
and whatever it "thinks" is useful here, like the new INTERFACE name.
If udev finds DEVPATH, it will update %p %k %n. All other variables just
set or replace the current event environment.

> Maybe a sample of rules would help me.

SUBSYSTEM="net", ACTION="add", IMPORT="/sbin/ifrename --export -i %k"

> 	Second, I don't see how this would prevent subsequent naming
> rules to apply.

We can make NAME="" work, to prevent other NAME rules from matching. For
now NAME="%k" may already work.

Kay


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Jean Tourrilhes]

On Mon, Mar 12, 2007 at 05:51:04PM +0100, Kay Sievers wrote:
> On Mon, 2007-03-12 at 09:07 -0700, Jean Tourrilhes wrote:
> 
> > Maybe a sample of rules would help me.
> 
> SUBSYSTEM="net", ACTION="add", IMPORT="/sbin/ifrename --export -i %k"
> 
> > 	Second, I don't see how this would prevent subsequent naming
> > rules to apply.
> 
> We can make NAME="" work, to prevent other NAME rules from matching. For
> now NAME="%k" may already work.

	Thanks for the help, I'm still learning about udev. It all
make sense now.
	I've tested udev with your patch (see below) and the following
udev rule and confirm that it works properly.

---------------------------------
SUBSYSTEM="net", ACTION="add", IMPORT="/sbin/ifrename -u -i %k", NAME:="%k"
---------------------------------

	If the interface is specified in /etc/iftab, the renaming is
done and further rules ignored. If the interface is not in /etc/iftab,
or if /etc/iftab does not exist, no renaming is done and further rule
do apply. And it works properly at boot time. This allow smooth
integration.
	I've released a new version of ifrename that fixes some
devpath bugs.

	Also, with the additional fix in the attached patch, you can
use udevtest like this :

---------------------------------
ENV{UDEV_LOG}="6", SUBSYSTEM="net", ACTION="add", IMPORT="/sbin/ifrename -D -V -u -i %k", NAME:="%k"
---------------------------------

> Kay

	Thanks a lot !

	Jean

------------------------------------------------------------------

diff -u -p udev-106/udev_rules.j1.c udev-106/udev_rules.c
--- udev-106/udev_rules.j1.c	2007-03-15 10:07:51.000000000 -0700
+++ udev-106/udev_rules.c	2007-03-15 10:09:50.000000000 -0700
@@ -186,7 +186,16 @@ static int import_keys_into_env(struct u
 		linepos = line;
 		if (get_key(&linepos, &variable, &value) = 0) {
 			dbg("import '%s=%s'", variable, value);
-			name_list_key_add(&udev->env_list, variable, value);
+			/* handle device, renamed by external tool,
+			 * returning new path */
+			if (strcmp(variable, "DEVPATH") = 0) {
+				info("updating devpath from '%s' to '%s'",
+				     udev->dev->devpath, value);
+				sysfs_device_set_values(udev->dev, value,
+							NULL, NULL);
+			} else
+				name_list_key_add(&udev->env_list,
+						  variable, value);
 			setenv(variable, value, 1);
 		}
 	}
diff -u -p udev-106/udevtest.j1.c udev-106/udevtest.c
--- udev-106/udevtest.j1.c	2007-03-15 10:39:16.000000000 -0700
+++ udev-106/udevtest.c	2007-03-15 10:42:09.000000000 -0700
@@ -59,8 +59,13 @@ int main(int argc, char *argv[], char *e
 
 	info("version %s", UDEV_VERSION);
 	udev_config_init();
-	if (udev_log_priority < LOG_INFO)
+	if (udev_log_priority < LOG_INFO) {
+		char priority[32];
+
 		udev_log_priority = LOG_INFO;
+		sprintf(priority, "%i", udev_log_priority);
+		setenv("UDEV_LOG", priority, 1);
+	}
 
 	for (i = 1 ; i < argc; i++) {
 		char *arg = argv[i];

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Kay Sievers]

On Thu, 2007-03-15 at 16:27 -0700, Jean Tourrilhes wrote:
> On Mon, Mar 12, 2007 at 05:51:04PM +0100, Kay Sievers wrote:
> > On Mon, 2007-03-12 at 09:07 -0700, Jean Tourrilhes wrote:
> > 
> > > Maybe a sample of rules would help me.
> > 
> > SUBSYSTEM="net", ACTION="add", IMPORT="/sbin/ifrename --export -i %k"
> > 
> > > 	Second, I don't see how this would prevent subsequent naming
> > > rules to apply.
> > 
> > We can make NAME="" work, to prevent other NAME rules from matching. For
> > now NAME="%k" may already work.
> 
> 	Thanks for the help, I'm still learning about udev. It all
> make sense now.
> 	I've tested udev with your patch (see below) and the following
> udev rule and confirm that it works properly.

Nice!

> ---------------------------------
> SUBSYSTEM="net", ACTION="add", IMPORT="/sbin/ifrename -u -i %k", NAME:="%k"
> ---------------------------------

Current udev git should also prevent any later naming rule to match,
with NAME="" now.

> 	If the interface is specified in /etc/iftab, the renaming is
> done and further rules ignored. If the interface is not in /etc/iftab,
> or if /etc/iftab does not exist, no renaming is done and further rule
> do apply. And it works properly at boot time. This allow smooth
> integration.
> 	I've released a new version of ifrename that fixes some
> devpath bugs.

Sounds good.

> 	Also, with the additional fix in the attached patch, you can
> use udevtest like this :
> 
> ---------------------------------
> ENV{UDEV_LOG}="6", SUBSYSTEM="net", ACTION="add", IMPORT="/sbin/ifrename -D -V -u -i %k", NAME:="%k"
> ---------------------------------

I've applied the udevtest part, the other part I already committed
yesterday.

Thanks,
Kay


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Jean Tourrilhes]

On Fri, Mar 16, 2007 at 01:14:22AM +0100, Kay Sievers wrote:
> On Thu, 2007-03-15 at 16:27 -0700, Jean Tourrilhes wrote:
> 
> > ---------------------------------
> > SUBSYSTEM="net", ACTION="add", IMPORT="/sbin/ifrename -u -i %k", NAME:="%k"
> > ---------------------------------
> 
> Current udev git should also prevent any later naming rule to match,
> with NAME="" now.

	I don't know, the current syntax is more "interesting", but I
agree that it may spook the casual user.

> I've applied the udevtest part, the other part I already committed
> yesterday.

	Thanks, that's great ! I'll wait impatiently for the next release ;-)

> Thanks,
> Kay

	Jean

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Kay Sievers]

On Fri, 2007-03-09 at 14:59 +0100, Kay Sievers wrote:
> On Wed, 2007-03-07 at 13:11 -0800, Jean Tourrilhes wrote:
> > On Wed, Mar 07, 2007 at 09:35:18PM +0100, Kay Sievers wrote:

> > > Also the udevtest program doesn't really work today, and is kind of
> > > useless, because we match on all the kernel supplied variables which are
> > > not available.
> > 
> > 	So, what is its replacement ?
> 
> There is no real replacement, because we don't have the kernel variables
> available for a test run. You can run udevd with debug and console
> output and trigger real events.

Jean,
I said udevtest is broken, you said you like to use it.
So it may work now as expected with the new kernel and a recent udev. :)
  http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h\x16574dccd8f62dc1b585325f8a6a0aab10047ed8
  http://git.kernel.org/git/?p=linux/hotplug/udev.git;a=commitdiff;hhd4af11cae0af3a8e06770228b16613700b363e

Btw, does the ifrename integration work fine for you now?

Kay



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
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

Re: [PATCH] udev+ifrename integration

[Jean Tourrilhes]

On Mon, Apr 30, 2007 at 12:02:00PM +0200, Kay Sievers wrote:
> On Fri, 2007-03-09 at 14:59 +0100, Kay Sievers wrote:
> 
> Jean,
> I said udevtest is broken, you said you like to use it.
> So it may work now as expected with the new kernel and a recent udev. :)
>   http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h\x16574dccd8f62dc1b585325f8a6a0aab10047ed8
>   http://git.kernel.org/git/?p=linux/hotplug/udev.git;a=commitdiff;hhd4af11cae0af3a8e06770228b16613700b363e
> 

	Kay, you are doing a superb job.
	In a lot of my latest designs, I've been going stateless, it's
more overhead, but more robust.
	For udevtest, I just put myself in the shoes of a dumb
users. When things don't work as you expect, you need to have tools to
understand what is happening. Personally, I know how to add printk()
in the kernel as needed.
	One thing that may be missing from 'udevtest' is a clue to
which file is responsible for the rule being applied.

> Btw, does the ifrename integration work fine for you now?

	Working fine on two PCs here (Desktop/Laptop). Well, I don't
reboot them that often. Guus will probably push a Debian package for
this integration in a few weeks, which should bring larger testing.

> Kay

	Thanks !

	Jean

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
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