Excluding some device types from persistent-net (xen, s390)

Excluding some device types from persistent-net (xen, s390)

[Matthias Schwarzott]

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

Hi there!

I have a change to persistent-net behaviour, to exclude xen-devices, and 
s390-devices.

Can that rule be formatted better?
Does that syntax work: SUBSYSTEMS!="xen|ccwgroup"
I saw the ACTION!="add|change" commit, but does that apply to the SUBSYSTEMS 
list also?

Matthias

-- 
Matthias Schwarzott (zzam)

[-- Attachment #2: udev-108-persistent-net-excludes.diff --]
[-- Type: text/x-diff, Size: 1151 bytes --]

diff --git a/extras/rule_generator/75-persistent-net-generator.rules b/extras/rule_generator/75-persistent-net-generator.rules
index 21eb0c6..72d3412 100644
--- a/extras/rule_generator/75-persistent-net-generator.rules
+++ b/extras/rule_generator/75-persistent-net-generator.rules
@@ -1,6 +1,7 @@
 # these rules generate rules for persistent network device naming
 
-ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*|ath*|wlan*|ra*|sta*" \
+ACTION=="add", SUBSYSTEM=="net", SUBSYSTEMS!="xen", SUBSYSTEMS!="ccwgroup" \
+	KERNEL=="eth*|ath*|wlan*|ra*|sta*" \
 	NAME!="?*", DRIVERS=="?*", GOTO="persistent_net_generator_do"
 
 GOTO="persistent_net_generator_end"
@@ -10,7 +11,6 @@ LABEL="persistent_net_generator_do"
 SUBSYSTEMS=="pci", ENV{COMMENT}="PCI device $attr{vendor}:$attr{device} ($attr{driver})"
 SUBSYSTEMS=="usb", ENV{COMMENT}="USB device 0x$attr{idVendor}:0x$attr{idProduct} ($attr{driver})"
 SUBSYSTEMS=="ieee1394", ENV{COMMENT}="Firewire device $attr{host_id})"
-SUBSYSTEMS=="xen", ENV{COMMENT}="Xen virtual device"
 ENV{COMMENT}=="", ENV{COMMENT}="$env{SUBSYSTEM} device ($attr{driver})"
 
 IMPORT{program}="write_net_rules $attr{address}"

[-- 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: Excluding some device types from persistent-net (xen, s390)

[Kay Sievers]

On 4/12/07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> I have a change to persistent-net behaviour, to exclude xen-devices, and
> s390-devices.

It's not needed, or does not work for xen and s390?

> Can that rule be formatted better?

With the current logic, only one SUBSYSTEMS-key (same for most other
keys) is supported per rule.
(I have a patch pending, that removes the limitation and just creates
a big linear match/action from of the rules, without the limitation on
the count of keys, but that patch is not finished now.)

> Does that syntax work: SUBSYSTEMS!="xen|ccwgroup"
> I saw the ACTION!="add|change" commit, but does that apply to the
> SUBSYSTEMS list also?

It should work for all match-keys, yes.

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: Excluding some device types from persistent-net (xen, s390)

[Matthias Schwarzott]

On Donnerstag, 12. April 2007, you wrote:
> On 4/12/07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> > I have a change to persistent-net behaviour, to exclude xen-devices, and
> > s390-devices.
>
> It's not needed, or does not work for xen and s390?

xen creates random macs per default I think. And s390 does create macs on 
login or similar? Perhaps someone really using a s390 could comment on this.


>
> > Can that rule be formatted better?
>
> With the current logic, only one SUBSYSTEMS-key (same for most other
> keys) is supported per rule.
> (I have a patch pending, that removes the limitation and just creates
> a big linear match/action from of the rules, without the limitation on
> the count of keys, but that patch is not finished now.)
>
> > Does that syntax work: SUBSYSTEMS!="xen|ccwgroup"
> > I saw the ACTION!="add|change" commit, but does that apply to the
> > SUBSYSTEMS list also?
>
> It should work for all match-keys, yes.
>

But that means for now I have to use
SUBSYSTEMS="xen", GOTO="persistent_net_end"
SUBSYSTEMS="ccwgroup", GOTO="persistent_net_end"

or does 
SUBSYSTEMS="xen|ccwgroup", GOTO="persistent_net_end"
or
...., SUBSYSTEMS!="xen|ccwgroup", ...
work, as this IS just one SUBSYSTEMS per line.

Greetings
Matthias

-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
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: Excluding some device types from persistent-net (xen, s390)

[Cornelia Huck]

On Thu, 12 Apr 2007 12:33:12 +0200,
Matthias Schwarzott <zzam@gentoo.org> wrote:

> xen creates random macs per default I think. And s390 does create macs on 
> login or similar? Perhaps someone really using a s390 could comment on this.

There are a few cases where the mac address can be zero (some VM Guest
Lan, iirc), and some ccwgroup devices don't have a mac address (keep in
mind that ccwgroup is just the bus; devices can be fundamentally
different, like qeth and ctc). But these cases should be handled well
during persistent rule generation.

Also, not all s390 network devices are on the ccwgroup bus; however
netiucv device are already excluded since they use iucv* and don't have
mac addresses anyway.

-------------------------------------------------------------------------
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: Excluding some device types from persistent-net (xen, s390)

[Kay Sievers]

On Thu, 2007-04-12 at 12:33 +0200, Matthias Schwarzott wrote:
> On Donnerstag, 12. April 2007, you wrote:
> > On 4/12/07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> > > I have a change to persistent-net behaviour, to exclude xen-devices, and
> > > s390-devices.
> >
> > It's not needed, or does not work for xen and s390?
> 
> xen creates random macs per default I think. And s390 does create macs on 
> login or similar? Perhaps someone really using a s390 could comment on this.
> 
> 
> >
> > > Can that rule be formatted better?
> >
> > With the current logic, only one SUBSYSTEMS-key (same for most other
> > keys) is supported per rule.
> > (I have a patch pending, that removes the limitation and just creates
> > a big linear match/action from of the rules, without the limitation on
> > the count of keys, but that patch is not finished now.)
> >
> > > Does that syntax work: SUBSYSTEMS!="xen|ccwgroup"
> > > I saw the ACTION!="add|change" commit, but does that apply to the
> > > SUBSYSTEMS list also?
> >
> > It should work for all match-keys, yes.
> >
> 
> But that means for now I have to use
> SUBSYSTEMS="xen", GOTO="persistent_net_end"
> SUBSYSTEMS="ccwgroup", GOTO="persistent_net_end"

That should work.

> or does 
> SUBSYSTEMS="xen|ccwgroup", GOTO="persistent_net_end"
> or

That should work too, only the != has the weird behavior.

> ...., SUBSYSTEMS!="xen|ccwgroup", ...
> work, as this IS just one SUBSYSTEMS per line.

This will work with the next udev, today:
  !="a|b"
means:
  (!a) || (!b)
which is pretty useless. :)

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: Excluding some device types from persistent-net (xen, s390)

[Matthias Schwarzott]

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

On Donnerstag, 12. April 2007, Kay Sievers wrote:
> On Thu, 2007-04-12 at 12:33 +0200, Matthias Schwarzott wrote:
> > On Donnerstag, 12. April 2007, you wrote:
> > > On 4/12/07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> > > > I have a change to persistent-net behaviour, to exclude xen-devices,
> > > > and s390-devices.
> > >
> > > It's not needed, or does not work for xen and s390?
> >
> > xen creates random macs per default I think. And s390 does create macs on
> > login or similar? Perhaps someone really using a s390 could comment on
> > this.
> >

>
> > or does
> > SUBSYSTEMS=="xen|ccwgroup", GOTO="persistent_net_end"
> > or
>
> That should work too, only the != has the weird behavior.
>
Updated patch with this variant attached.

Now we can discuss if the rules itself are usfull.

1. xen:
I think for xen the persistence framework itself is not usefull, as the order 
of the devices is every time the same, isn't it. The only known problem is 
caused by the rules itself: When mac is randomly assigned udev counts up 
xen[0-9].

2. s390 / ccwgroup
I have no such machine, but I have this request to re-add (the for s390 
completely removed persistence-net):
http://bugs.gentoo.org/show_bug.cgi?id=173797

 
Cornelia Huck <huckc@de.ibm.com>  (IBM Deutschland Entwicklung GmbH) wrote:
> There are a few cases where the mac address can be zero (some VM Guest
> Lan, iirc), and some ccwgroup devices don't have a mac address (keep in
> mind that ccwgroup is just the bus; devices can be fundamentally
> different, like qeth and ctc). But these cases should be handled well
> during persistent rule generation.
> 
> Also, not all s390 network devices are on the ccwgroup bus; however
> netiucv device are already excluded since they use iucv* and don't have
> mac addresses anyway.

that is part of the used rules: apply persistence only on this condition: 
KERNEL=="eth*|ath*|wlan*|ra*|sta*"

That means qeth and ctc (if that is the device name) should already be 
ignored.

Matthias

-- 
Matthias Schwarzott (zzam)

[-- Attachment #2: udev-108-persistent-net-excludes.diff --]
[-- Type: text/x-diff, Size: 1062 bytes --]

diff --git a/extras/rule_generator/75-persistent-net-generator.rules b/extras/rule_generator/75-persistent-net-generator.rules
index 21eb0c6..eeef4d1 100644
--- a/extras/rule_generator/75-persistent-net-generator.rules
+++ b/extras/rule_generator/75-persistent-net-generator.rules
@@ -1,5 +1,6 @@
 # these rules generate rules for persistent network device naming
 
+SUBSYSTEMS=="xen|ccwgroup", GOTO="persistent_net_generator_end"
 ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*|ath*|wlan*|ra*|sta*" \
 	NAME!="?*", DRIVERS=="?*", GOTO="persistent_net_generator_do"
 
@@ -10,7 +11,6 @@ LABEL="persistent_net_generator_do"
 SUBSYSTEMS=="pci", ENV{COMMENT}="PCI device $attr{vendor}:$attr{device} ($attr{driver})"
 SUBSYSTEMS=="usb", ENV{COMMENT}="USB device 0x$attr{idVendor}:0x$attr{idProduct} ($attr{driver})"
 SUBSYSTEMS=="ieee1394", ENV{COMMENT}="Firewire device $attr{host_id})"
-SUBSYSTEMS=="xen", ENV{COMMENT}="Xen virtual device"
 ENV{COMMENT}=="", ENV{COMMENT}="$env{SUBSYSTEM} device ($attr{driver})"
 
 IMPORT{program}="write_net_rules $attr{address}"

[-- 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: Excluding some device types from persistent-net (xen, s390)

[Cornelia Huck]

On Thu, 12 Apr 2007 15:22:05 +0200,
Matthias Schwarzott <zzam@gentoo.org> wrote:

> 2. s390 / ccwgroup
> I have no such machine, but I have this request to re-add (the for s390 
> completely removed persistence-net):
> http://bugs.gentoo.org/show_bug.cgi?id\x173797
> 
> 
> Cornelia Huck <huckc@de.ibm.com>  (IBM Deutschland Entwicklung GmbH) wrote:
> > There are a few cases where the mac address can be zero (some VM Guest
> > Lan, iirc), and some ccwgroup devices don't have a mac address (keep in
> > mind that ccwgroup is just the bus; devices can be fundamentally
> > different, like qeth and ctc). But these cases should be handled well
> > during persistent rule generation.
> > 
> > Also, not all s390 network devices are on the ccwgroup bus; however
> > netiucv device are already excluded since they use iucv* and don't have
> > mac addresses anyway.
> 
> that is part of the used rules: apply persistence only on this condition: 
> KERNEL="eth*|ath*|wlan*|ra*|sta*"
> 
> That means qeth and ctc (if that is the device name) should already be 
> ignored.

I think you misunderstood me :) qeth and ctc are the names of the
device drivers.

For qeth, you'll usually have run-of-the mill tr* or eth* interfaces,
except for the special hsi* (HiperSockets, this may be where the mac
address is zero) and osn* (special purpose). For eth*, I don't foresee
any trouble, the remainder are ignored anyway.

ctc and claw should be unproblematic as well, as they use special
interface names (as does netiucv).

lcs is the only one I'm not 100% sure about. Interfaces will be tr* or
eth*, macaddress may be zero for ethernet (I don't quite remember).

Were there any problems associated with persistent rules for ccwgroup
devices?

-------------------------------------------------------------------------
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: Excluding some device types from persistent-net (xen, s390)

[Mike Frysinger]

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

On Thursday 12 April 2007, Cornelia Huck wrote:
> Were there any problems associated with persistent rules for ccwgroup
> devices?

yes, that's why we disabled it ... the proposed patch came from OpenSUSE as 
the route we were going before (simply delete the file on s390) is the 
behavior we copied from Debian (which they were doing because the 
persistent-net rules were screwing things up for their users)
-mike

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 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: Excluding some device types from persistent-net (xen, s390)

[Cornelia Huck]

On Thu, 12 Apr 2007 10:12:57 -0400,
Mike Frysinger <vapier@gentoo.org> wrote:

> On Thursday 12 April 2007, Cornelia Huck wrote:
> > Were there any problems associated with persistent rules for ccwgroup
> > devices?
> 
> yes, that's why we disabled it ... the proposed patch came from OpenSUSE as 
> the route we were going before (simply delete the file on s390) is the 
> behavior we copied from Debian (which they were doing because the 
> persistent-net rules were screwing things up for their users)

Could anyone please point me to those problem reports? I have not been
able to google anything (ok, it's Friday) on this but something about
ctcs which are ignored anyway...

-------------------------------------------------------------------------
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: Excluding some device types from persistent-net (xen, s390)

[Mike Frysinger]

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

On Friday 13 April 2007, Cornelia Huck wrote:
> On Thu, 12 Apr 2007 10:12:57 -0400,
>
> Mike Frysinger <vapier@gentoo.org> wrote:
> > On Thursday 12 April 2007, Cornelia Huck wrote:
> > > Were there any problems associated with persistent rules for ccwgroup
> > > devices?
> >
> > yes, that's why we disabled it ... the proposed patch came from OpenSUSE
> > as the route we were going before (simply delete the file on s390) is the
> > behavior we copied from Debian (which they were doing because the
> > persistent-net rules were screwing things up for their users)
>
> Could anyone please point me to those problem reports? I have not been
> able to google anything (ok, it's Friday) on this but something about
> ctcs which are ignored anyway...

Debian is filed under #383303 ... no idea about SuSE, just ripped out of 
some .src.rpm

but thinking about it logically, the MAC is generated on the fly so the 
MAC/iface binding from the previous boot really has no relevance at the next 
boot
-mike

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 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: Excluding some device types from persistent-net (xen, s390)

[Cornelia Huck]

On Fri, 13 Apr 2007 10:51:30 -0400,
Mike Frysinger <vapier@gentoo.org> wrote:

> Debian is filed under #383303 ... no idea about SuSE, just ripped out of 
> some .src.rpm

Ah, ok, I saw that, but coundn't make sense of it.

> 
> but thinking about it logically, the MAC is generated on the fly so the 
> MAC/iface binding from the previous boot really has no relevance at the next 
> boot

If it were generated on the fly, then yes. But the mac really should be
constant afaik, I've never seen it otherwise (though, maybe under
hercules?)

-------------------------------------------------------------------------
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: Excluding some device types from persistent-net (xen, s390)

[Matthias Schwarzott]

On Donnerstag, 12. April 2007, Matthias Schwarzott wrote:
> Hi there!
>
> I have a change to persistent-net behaviour, to exclude xen-devices, and
> s390-devices.
>

I thought even more about the persistent-net framework.

The problems appear in two different cases:
1. Random MAC addresses (as we for now only use by-mac as method)
This will lead to increasing numbers for the device after each reboot with 
different mac.

2. Devices that are ignored and does not add persistent-rules.

This leads to errors as soon as on a system there are devices which we try to 
get persistent, and devices which we ignore (with the same prefix, e.g. 
eth*).
As udev cannot rename the device as soon as the dest name is already occupied.
(ignored devices being eth1, and udev trying to rename eth2 to eth1 will lead 
to eth?_rename devices ...)

Possible solutions for different devices (restricting me to eth, will add new 
mail about wifi stuff):


xen-devices: 
# udevinfo -a -p /sys/class/net/eth0
 
  looking at device '/class/net/eth0':
    KERNEL="eth0"
    SUBSYSTEM="net"
    DRIVER=""
    ATTR{weight}="64"
    ATTR{tx_queue_len}="1000"
    ATTR{flags}="0x1003"
    ATTR{mtu}="1500"
    ATTR{carrier}="1"
    ATTR{broadcast}="ff:ff:ff:ff:ff:ff"
    ATTR{address}="00:16:3e:08:25:1d"
 
  looking at parent device '/devices/xen/vif-0':
    KERNELS="vif-0"
    SUBSYSTEMS="xen"
    DRIVERS="vif"
    ATTRS{devtype}="vif"
    ATTRS{nodename}="device/vif/0"
 
  looking at parent device '/devices/xen':
    KERNELS="xen"
    SUBSYSTEMS=""
    DRIVERS=""

Perhaps the KERNEL(S) attribute of the parent device can be used for 
persistence (even though I don't know how the rule should look like) but 
perhaps just KERNELS="vif-0" will work. As I think the number refers to the 
(n+1)-th network interface declared in xen-conf for this domain. And that 
should be constant, even if mac changes.
Better solutions for xen-devices?


s390: For s390 I don't know the facts, please others discuss if there is 
something special necessary or not.

eth1394: Some users seem to have problems with eth1394, but the people I asked 
seem to have no problems with it (seem to have macs set and constant).

See this thread: "Problems with udev > 106 and multiple network cards"
Perhaps if just one device of this type appears we can persist it with 
ATTR{type}="24" in case no mac exists, ugly :(

Matthias

-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
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: Excluding some device types from persistent-net (xen, s390)

[Matthias Schwarzott]

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

On Freitag, 13. April 2007, Matthias Schwarzott wrote:
> On Donnerstag, 12. April 2007, Matthias Schwarzott wrote:

> xen-devices:
> # udevinfo -a -p /sys/class/net/eth0
>
>   looking at device '/class/net/eth0':
>     KERNEL=="eth0"
>     SUBSYSTEM=="net"
>     DRIVER==""
>     ATTR{weight}=="64"
>     ATTR{tx_queue_len}=="1000"
>     ATTR{flags}=="0x1003"
>     ATTR{mtu}=="1500"
>     ATTR{carrier}=="1"
>     ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
>     ATTR{address}=="00:16:3e:08:25:1d"
>
>   looking at parent device '/devices/xen/vif-0':
>     KERNELS=="vif-0"
>     SUBSYSTEMS=="xen"
>     DRIVERS=="vif"
>     ATTRS{devtype}=="vif"
>     ATTRS{nodename}=="device/vif/0"
>
>   looking at parent device '/devices/xen':
>     KERNELS=="xen"
>     SUBSYSTEMS==""
>     DRIVERS==""
>
> Perhaps the KERNEL(S) attribute of the parent device can be used for
> persistence (even though I don't know how the rule should look like) but
> perhaps just KERNELS=="vif-0" will work. As I think the number refers to
> the (n+1)-th network interface declared in xen-conf for this domain. And
> that should be constant, even if mac changes.
> Better solutions for xen-devices?
>

Attached is an (untested) implementation, that
1. Adds a METHOD setting to write_net_rules
2. Adds methods by-mac and by-xen-vif.
If none specified checking $DEVPATH/device/subsystem - and use by-xen-vif in 
case subsystem is "xen".
3. by-mac does what was default before.
4. by-xen-vif: Look up the name of the device symlink (VIF_NAME) and adding a 
rule with KERNELS=="$VIF_NAME".


For other devices perhaps more such special methods are required.

Matthias
PS: by-path could also be added.

-- 
Matthias Schwarzott (zzam)

[-- Attachment #2: udev-108-persistent-net-xen.diff --]
[-- Type: text/x-diff, Size: 1924 bytes --]

diff --git a/extras/rule_generator/write_net_rules b/extras/rule_generator/write_net_rules
index b709200..47f14cf 100644
--- a/extras/rule_generator/write_net_rules
+++ b/extras/rule_generator/write_net_rules
@@ -85,20 +85,57 @@ if [ -z "$INTERFACE" ]; then
 	exit 1
 fi
 
-if [ "$1" ]; then
-	MAC_ADDR="$1"
+if [ "${1}" != "${1##by-}" ]; then
+	METHOD="${1}"
+	shift
 else
-	MAC_ADDR=$(sysread address)
+	# get subsystem of device
+	SUBSYSTEM=$(sysreadlink device/subsystem)
+	SUBSYSTEM=${SUBSYSTEM##*/}
+	case $SUBSYSTEM in
+		xen)
+		METHOD='by-xen-vif'
+		;;
+		*)
+		METHOD='by-mac'
+		;;
+	esac
 fi
 
-if [ -z "$MAC_ADDR" ]; then
-	echo "No MAC address for $INTERFACE." >&2
-	exit 1
-fi
-if [ "$MAC_ADDR" = "00:00:00:00:00:00" ]; then
-	echo "NULL MAC address for $INTERFACE." >&2
-	exit 1
-fi
+case "$METHOD" in
+	by-mac)
+	if [ "$1" ]; then
+		MAC_ADDR="$1"
+	else
+		MAC_ADDR=$(sysread address)
+	fi
+
+	if [ -z "$MAC_ADDR" ]; then
+		echo "No MAC address for $INTERFACE." >&2
+		exit 1
+	fi
+	if [ "$MAC_ADDR" = "00:00:00:00:00:00" ]; then
+		echo "NULL MAC address for $INTERFACE." >&2
+		exit 1
+	fi
+	RULE="ATTRS{address}==\"$MAC_ADDR\""
+	;;
+
+	by-xen-vif)
+	VIF_NAME="$(sysreadlink device)"
+	VIF_NAME=${VIF_NAME##*/}
+	if [ -z "$VIF_NAME" ]; then
+		echo "No VIF name for $INTERFACE." >&2
+		exit 1
+	fi
+	RULE="KERNELS==\"$VIF_NAME\""
+	;;
+
+        *)
+        echo "Invalid argument (must be either by-mac or by-xen-vif)." >&2
+        exit 1
+        ;;
+esac
 
 # Prevent concurrent processes from modifying the file at the same time.
 lock_rules_file
@@ -117,7 +154,7 @@ if interface_name_taken; then
 fi
 
 # the DRIVERS key is needed to not match bridges and VLAN sub-interfaces
-match="DRIVERS==\"?*\", ATTRS{address}==\"$MAC_ADDR\""
+match="DRIVERS==\"?*\", $RULE"
 if [ $basename = "ath" -o $basename = "wlan" ]; then
 	match="$match, ATTRS{type}==\"1\"" # do not match the wifi* interfaces
 fi

[-- 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: Excluding some device types from persistent-net (xen, s390)

[Matthias Schwarzott]

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

On Samstag, 14. April 2007, Matthias Schwarzott wrote:
> On Freitag, 13. April 2007, Matthias Schwarzott wrote:
> > On Donnerstag, 12. April 2007, Matthias Schwarzott wrote:
> >
> > xen-devices:
> > # udevinfo -a -p /sys/class/net/eth0
> >
> >   looking at device '/class/net/eth0':
> >     KERNEL=="eth0"
> >     SUBSYSTEM=="net"
> >     DRIVER==""
> >     ATTR{weight}=="64"
> >     ATTR{tx_queue_len}=="1000"
> >     ATTR{flags}=="0x1003"
> >     ATTR{mtu}=="1500"
> >     ATTR{carrier}=="1"
> >     ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
> >     ATTR{address}=="00:16:3e:08:25:1d"
> >
> >   looking at parent device '/devices/xen/vif-0':
> >     KERNELS=="vif-0"
> >     SUBSYSTEMS=="xen"
> >     DRIVERS=="vif"
> >     ATTRS{devtype}=="vif"
> >     ATTRS{nodename}=="device/vif/0"
> >
> >   looking at parent device '/devices/xen':
> >     KERNELS=="xen"
> >     SUBSYSTEMS==""
> >     DRIVERS==""
> >
> > Perhaps the KERNEL(S) attribute of the parent device can be used for
> > persistence (even though I don't know how the rule should look like) but
> > perhaps just KERNELS=="vif-0" will work. As I think the number refers to
> > the (n+1)-th network interface declared in xen-conf for this domain. And
> > that should be constant, even if mac changes.
> > Better solutions for xen-devices?
>
> Attached is an (untested) implementation, that
Now checked on one system - and corrected all errors :)
The dest of the device link did not has a subsystem link.
Now checking device/devtype == "vif".

> 1. Adds a METHOD setting to write_net_rules
> 2. Adds methods by-mac and by-xen-vif.
> If none specified checking $DEVPATH/device/subsystem - and use by-xen-vif
> in case subsystem is "xen".
> 3. by-mac does what was default before.
> 4. by-xen-vif: Look up the name of the device symlink (VIF_NAME) and adding
> a rule with KERNELS=="$VIF_NAME".
>
>
> For other devices perhaps more such special methods are required.
>

Matthias

-- 
Matthias Schwarzott (zzam)

[-- Attachment #2: udev-108-persistent-net-xen.diff --]
[-- Type: text/x-diff, Size: 1894 bytes --]

diff --git a/extras/rule_generator/write_net_rules b/extras/rule_generator/write_net_rules
index b709200..dd65407 100644
--- a/extras/rule_generator/write_net_rules
+++ b/extras/rule_generator/write_net_rules
@@ -85,21 +85,55 @@ if [ -z "$INTERFACE" ]; then
 	exit 1
 fi
 
-if [ "$1" ]; then
-	MAC_ADDR="$1"
+if [ "${1}" != "${1##by-}" ]; then
+	METHOD="${1}"
+	shift
 else
-	MAC_ADDR=$(sysread address)
-fi
+	# default method
+	METHOD='by-mac'
 
-if [ -z "$MAC_ADDR" ]; then
-	echo "No MAC address for $INTERFACE." >&2
-	exit 1
-fi
-if [ "$MAC_ADDR" = "00:00:00:00:00:00" ]; then
-	echo "NULL MAC address for $INTERFACE." >&2
-	exit 1
+	# get subsystem of device
+	devtype=$(sysread device/devtype)
+	if [ "$devtype" = "vif" ]; then
+		METHOD='by-xen-vif'
+	fi
 fi
 
+case "$METHOD" in
+	by-mac)
+	if [ "$1" ]; then
+		MAC_ADDR="$1"
+	else
+		MAC_ADDR=$(sysread address)
+	fi
+
+	if [ -z "$MAC_ADDR" ]; then
+		echo "No MAC address for $INTERFACE." >&2
+		exit 1
+	fi
+	if [ "$MAC_ADDR" = "00:00:00:00:00:00" ]; then
+		echo "NULL MAC address for $INTERFACE." >&2
+		exit 1
+	fi
+	RULE="ATTRS{address}==\"$MAC_ADDR\""
+	;;
+
+	by-xen-vif)
+	VIF_NAME="$(sysreadlink device)"
+	VIF_NAME=${VIF_NAME##*/}
+	if [ -z "$VIF_NAME" ]; then
+		echo "No VIF name for $INTERFACE." >&2
+		exit 1
+	fi
+	RULE="KERNELS==\"$VIF_NAME\""
+	;;
+
+        *)
+        echo "Invalid argument (must be either by-mac or by-xen-vif)." >&2
+        exit 1
+        ;;
+esac
+
 # Prevent concurrent processes from modifying the file at the same time.
 lock_rules_file
 
@@ -117,7 +151,7 @@ if interface_name_taken; then
 fi
 
 # the DRIVERS key is needed to not match bridges and VLAN sub-interfaces
-match="DRIVERS==\"?*\", ATTRS{address}==\"$MAC_ADDR\""
+match="DRIVERS==\"?*\", $RULE"
 if [ $basename = "ath" -o $basename = "wlan" ]; then
 	match="$match, ATTRS{type}==\"1\"" # do not match the wifi* interfaces
 fi

[-- 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: Excluding some device types from persistent-net (xen, s390)

[Cornelia Huck]

On Fri, 13 Apr 2007 22:08:19 +0200,
Matthias Schwarzott <zzam@gentoo.org> wrote:

> s390: For s390 I don't know the facts, please others discuss if there is 
> something special necessary or not.

It may be a good idea to use the bus id for ccwgroup devices, something
like eth-0.0.fd00. Reasons:
- Unlike the mac address, it is always there :)
- It is unique. The bus id of the ccwgroup device is the bus id of the
'leading' slave ccw device, and ccw devices have unique ids.

Maybe we should still leave out netiucv (iucv bus) devices, since they
are created by the user writing the id of the remote VM guest...

-------------------------------------------------------------------------
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: Excluding some device types from persistent-net (xen, s390)

[Matthias Schwarzott]

On Montag, 16. April 2007, Cornelia Huck wrote:
> On Fri, 13 Apr 2007 22:08:19 +0200,
>
> Matthias Schwarzott <zzam@gentoo.org> wrote:
> > s390: For s390 I don't know the facts, please others discuss if there is
> > something special necessary or not.
>
> It may be a good idea to use the bus id for ccwgroup devices, something
> like eth-0.0.fd00. Reasons:
> - Unlike the mac address, it is always there :)
> - It is unique. The bus id of the ccwgroup device is the bus id of the
> 'leading' slave ccw device, and ccw devices have unique ids.
>
> Maybe we should still leave out netiucv (iucv bus) devices, since they
> are created by the user writing the id of the remote VM guest...

That sounds like a good idea.
We just need some code:
Some questions for this: 
1. should write_net_rules detect itself what kind of device - or should the 
rules detect this (they already do) and pass this to write_net_rules?
2. How to get the unique identifier of that ccwgroup?
First from a udev-rule and then from write_net_rules?

Matthias
-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
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: Excluding some device types from persistent-net (xen, s390)

[Cornelia Huck]

On Wed, 18 Apr 2007 23:00:11 +0200,
Matthias Schwarzott <zzam@gentoo.org> wrote:

> On Montag, 16. April 2007, Cornelia Huck wrote:
> > On Fri, 13 Apr 2007 22:08:19 +0200,
> >
> > Matthias Schwarzott <zzam@gentoo.org> wrote:
> > > s390: For s390 I don't know the facts, please others discuss if there is
> > > something special necessary or not.
> >
> > It may be a good idea to use the bus id for ccwgroup devices, something
> > like eth-0.0.fd00. Reasons:
> > - Unlike the mac address, it is always there :)
> > - It is unique. The bus id of the ccwgroup device is the bus id of the
> > 'leading' slave ccw device, and ccw devices have unique ids.
> >
> > Maybe we should still leave out netiucv (iucv bus) devices, since they
> > are created by the user writing the id of the remote VM guest...
> 
> That sounds like a good idea.
> We just need some code:
> Some questions for this: 

<Note: I'm not very familiar with the udev rules stuff>

> 1. should write_net_rules detect itself what kind of device - or should the 
> rules detect this (they already do) and pass this to write_net_rules?

This info should already be in SUBSYSTEM and passed on to
write_net_rules, I guess.

> 2. How to get the unique identifier of that ccwgroup?
> First from a udev-rule and then from write_net_rules?

Can't this simply be stripped from DEVPATH (last element)?

-------------------------------------------------------------------------
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: Excluding some device types from persistent-net (xen, s390)

[Matthias Schwarzott]

On Freitag, 20. April 2007, Cornelia Huck wrote:
> On Wed, 18 Apr 2007 23:00:11 +0200,
>
> Matthias Schwarzott <zzam@gentoo.org> wrote:
> > On Montag, 16. April 2007, Cornelia Huck wrote:
> >
> > That sounds like a good idea.
> > We just need some code:
> > Some questions for this:
>
> <Note: I'm not very familiar with the udev rules stuff>
>
> > 1. should write_net_rules detect itself what kind of device - or should
> > the rules detect this (they already do) and pass this to write_net_rules?
>
> This info should already be in SUBSYSTEM and passed on to
> write_net_rules, I guess.
>
> > 2. How to get the unique identifier of that ccwgroup?
> > First from a udev-rule and then from write_net_rules?
>
> Can't this simply be stripped from DEVPATH (last element)?

As I do not know how the DEVPATH for such devices look like, some info like 
udevinfo -a -p /class/net/eth? or file lists in sysfs could help.

Matthias

-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
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: Excluding some device types from persistent-net (xen, s390)

[Cornelia Huck]

On Sat, 21 Apr 2007 15:35:45 +0200,
Matthias Schwarzott <zzam@gentoo.org> wrote:

> > > 2. How to get the unique identifier of that ccwgroup?
> > > First from a udev-rule and then from write_net_rules?
> >
> > Can't this simply be stripped from DEVPATH (last element)?
> 
> As I do not know how the DEVPATH for such devices look like, some info like 
> udevinfo -a -p /class/net/eth? or file lists in sysfs could help.

<btw: it would be nice if you kept me on cc:>

ccwgroup devices sit under a ccw driver specific root device, like

/sys/devices/qeth/0.0.f5f0/

for a qeth device or

/sys/devices/cu3088/0.0.7000/

for a ctc device.

In any case, the network interface is like

/sys/devices/qeth/0.0.f5f0/net/eth0

or

/sys/devices/cu3088/0.0.7000/net/ctc0,

so you should be able to use ID from the parent's parent.

udevinfo -a -p /sys/class/net/ctc0/ says:

  looking at device '/devices/cu3088/0.0.7000/net/ctc0':
    KERNEL="ctc0"
    SUBSYSTEM="net"
    DRIVER=""
    SYSFS{weight}="0"
    SYSFS{tx_queue_len}="100"
    SYSFS{flags}="0x90"
    SYSFS{mtu}="32760"
    SYSFS{operstate}="down"
    SYSFS{broadcast}=""
    SYSFS{address}=""
    SYSFS{link_mode}="0"
    SYSFS{type}="256"
    SYSFS{features}="0x0"
    SYSFS{ifindex}="7"
    SYSFS{iflink}="7"
    SYSFS{addr_len}="0"

  looking at parent device '/devices/cu3088/0.0.7000/net':
    ID="net"
    BUS=""
    DRIVER=""

  looking at parent device '/devices/cu3088/0.0.7000':
    ID="0.0.7000"
    BUS="ccwgroup"
    DRIVER="ctc"
    SYSFS{stats}="0"
    SYSFS{loglevel}="71"
    SYSFS{buffer}="32768"
    SYSFS{type}="CTC/A"
    SYSFS{protocol}="0"
    SYSFS{online}="1"
    SYSFS{uevent}="DRIVER=ctc"

  looking at parent device '/devices/cu3088':
    ID="cu3088"
    BUS=""
    DRIVER=""
    SYSFS{uevent}=""

HTH,
Cornelia.


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