From: Matthias Schwarzott <zzam@gentoo.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: Excluding some device types from persistent-net (xen, s390)
Date: Fri, 13 Apr 2007 20:08:19 +0000 [thread overview]
Message-ID: <200704132208.19301.zzam@gentoo.org> (raw)
In-Reply-To: <200704120944.10520.zzam@gentoo.org>
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
next prev parent reply other threads:[~2007-04-13 20:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-12 7:44 Excluding some device types from persistent-net (xen, s390) Matthias Schwarzott
2007-04-12 10:14 ` Kay Sievers
2007-04-12 10:33 ` Matthias Schwarzott
2007-04-12 11:33 ` Cornelia Huck
2007-04-12 12:30 ` Kay Sievers
2007-04-12 13:22 ` Matthias Schwarzott
2007-04-12 13:47 ` Cornelia Huck
2007-04-12 14:12 ` Mike Frysinger
2007-04-13 14:44 ` Cornelia Huck
2007-04-13 14:51 ` Mike Frysinger
2007-04-13 15:05 ` Cornelia Huck
2007-04-13 20:08 ` Matthias Schwarzott [this message]
2007-04-14 11:46 ` Matthias Schwarzott
2007-04-14 12:35 ` Matthias Schwarzott
2007-04-16 8:16 ` Cornelia Huck
2007-04-18 21:00 ` Matthias Schwarzott
2007-04-20 11:27 ` Cornelia Huck
2007-04-21 13:35 ` Matthias Schwarzott
2007-04-23 9:03 ` Cornelia Huck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200704132208.19301.zzam@gentoo.org \
--to=zzam@gentoo.org \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.