Re: [PATCH] udev+ifrename integration

[Kay Sievers <kay.sievers@vrfy.org>]

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