Specifying names for tap interfaces

[Roger Pau Monne]

Hello,

New Xen versions will ship with upstream Qemu, which means we have to
get ready to support new Qemu features not present in the previous
versions of Qemu used by Xen. This also means that Xen developers are
not allowing to post Qemu-xen specific changes, so all changes should be
first committed and approved to regular Qemu and then backported to the
Qemu Xen repository.

So far we are doing quite good, and new Qemu upstream seems to be
working fine with Xen under NetBSD. The only remaining issue is with tap
interfaces, so we can at least have a working basic HVM guest. New Qemu
does not longer support the deprecated "bridge" parameter that NetBSD
was using to attach the created tap interface to a given bridge.

Linux does this by passing the name of the tap interface Qemu has to
create, so when the interface is created its name is known and can be
used outside of Qemu.

From what I see, NetBSD has the option to fetch the name of the
interface created, using the TAPGIFNAME ioctl, but this is not really
helpful because we create the interface from Qemu, but the scripts that
attach the network interface are launched from the toolstack (xl).

Will it be possible to provide a TAPSIFNAME ioctl to set the name of the
created interface? I will start looking into this, but I would also like
some feedback.

Thanks, Roger.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Linux does this by passing the name of the tap interface Qemu has to
create, so when the interface is created its name is known and can be
used outside of Qemu.

From what I see, NetBSD has the option to fetch the name of the
interface created, using the TAPGIFNAME ioctl, but this is not really
helpful because we create the interface from Qemu, but the scripts
that attach the network interface are launched from the toolstack
(xl).

Will it be possible to provide a TAPSIFNAME ioctl to set the name of
the created interface? I will start looking into this, but I would
also like some feedback.

So you basically want to have

in dom0, have xl tell qemu to make an interface for the guest, and to
name it /dev/tap-NNN where xl chooses that

have qemu create a tap and arrange the name

have xl in the dom0 bridge tapNNN to whatever

and the problem with just using what tap picks is that there's no
communication path from qemu create back to xl?

Does qemu use /dev/tap, which picks a name, or by finding a /dev/tapN to
open and then using create?

Or is the problem that you need arbitrary names, rather than just to
have xl be able to pick something?


A few thoughts, not particularly coherent:

qemu could be given a name and then create a symlink from that name to
whatever tap chooses. or use mknod to make the name actually be the
special file.

TAPSIFNAME seems tricky, because it seems to be about controlling the
whole name, whereas tap seems to be tapN for some (printed
representation of) number N, correpsonding to character special file
(169,N). So is this just about choosing N, or choosing the rest of
the interface name?

Or is it that choosing N is sufficient, but you'd like to be able to
do TAPSIFNAME on /dev/tap? That seems awkward, because as I read the
code the interface is created on open, so it would have to swap the
softc, essentially closing the current tap and opening a new one.


Overall, it seems easiest to teach qemu to use 'ifconfig tapN create' as
an alternative to clone/set-name.

[Matthew Mondor]

On Mon, 18 Jun 2012 08:55:26 -0400

Post by Greg Troxel
in dom0, have xl tell qemu to make an interface for the guest, and to
name it /dev/tap-NNN where xl chooses that
have qemu create a tap and arrange the name
have xl in the dom0 bridge tapNNN to whatever

[...]

Post by Greg Troxel
qemu could be given a name and then create a symlink from that name to
whatever tap chooses. or use mknod to make the name actually be the
special file.

Roger, please correct me as necessary,

If I understand (from a previous discussion we had on #netbsd), the
goal is not to open the device using another name (symlink or alternate
mknod-created file), but to have ifconfig show another name than
tap<n>. This is where an eventual TAPSIFNAME might allow one to say,
open the cloning device /dev/tap and have ifconfig report it as
"foobar" instead of "tap<n>", and have bridge accept to add "foobar".

I guess that another possibility would be to allow ifconfig and
interfaces to generically support name aliases, such that one could add
an alias "foobar" to "tap14" or such...

I however didn't understand exactly why the feature needed, because an
address is generally assigned to an interface, and that should show up
and possibly resolve using DNS, which can also allow to easily identify
the interfaces apart (i.e. ifconfig -aN). I assume it's a
user-friendlyness issue.

Thanks,

[Roger Pau Monne]

Post by Roger Pau Monne
Linux does this by passing the name of the tap interface Qemu has to
create, so when the interface is created its name is known and can be
used outside of Qemu.
From what I see, NetBSD has the option to fetch the name of the
interface created, using the TAPGIFNAME ioctl, but this is not really
helpful because we create the interface from Qemu, but the scripts
that attach the network interface are launched from the toolstack
(xl).
Will it be possible to provide a TAPSIFNAME ioctl to set the name of
the created interface? I will start looking into this, but I would
also like some feedback.
So you basically want to have
in dom0, have xl tell qemu to make an interface for the guest, and to
name it /dev/tap-NNN where xl chooses that

Well in Linux you can give any name to tap interfaces so Xen is
currently using vif2.0-emu for Linux specific reasons.

Anything that we can control, like tap-%domid.%devid would be good
though. It doesn't have to follow any specific nomenclature, but it will
be good to be able to specify two integers, one that corresponds to the
domain id, and another one that identifies the specific network card
inside that domain.

Post by Roger Pau Monne
have qemu create a tap and arrange the name

Yes, basically to have a ioctl to be able to specify the name.

Post by Roger Pau Monne
have xl in the dom0 bridge tapNNN to whatever

Yes, hotplug scripts are launched directly from xl in new versions, so
xl decides the name and passes it to both Qemu and hotplug scripts.

Post by Roger Pau Monne
and the problem with just using what tap picks is that there's no
communication path from qemu create back to xl?

No, not really. Another option is to try to fetch the name from Qemu and
pass it to the hotplug script. But this will require changes on both the
Qemu and the xl side, and I think it will be more complicated. Apart
from the fact than having this functionality might be interesting to
other users.

Post by Roger Pau Monne
Does qemu use /dev/tap, which picks a name, or by finding a /dev/tapN to
open and then using create?

Qemu opens /dev/tap and creates a new /dev/tapX, then fetches the name
of this interface using the TAPGIFNAME. In the past, Qemu had a
parameter that you could use to set the bridge Qemu has to pass to the
hotplug script, but this is no longer present, and the script Qemu calls
after creating the interface only knows the name of the newly created
interface, which is not really helpful, and it's not used in Linux
because all hotplug scripts are launched from xl.

Post by Roger Pau Monne
Or is the problem that you need arbitrary names, rather than just to
have xl be able to pick something?

Not really arbitrary, as explained before, something like tap-%d.%d
should be ok.

Post by Roger Pau Monne
qemu could be given a name and then create a symlink from that name to
whatever tap chooses. or use mknod to make the name actually be the
special file.

Yes, but the interface name will still be tap%d, and brconfig will fail
to add that interface.

Post by Roger Pau Monne
TAPSIFNAME seems tricky, because it seems to be about controlling the
whole name, whereas tap seems to be tapN for some (printed
representation of) number N, correpsonding to character special file
(169,N). So is this just about choosing N, or choosing the rest of
the interface name?

I think that one way or another we need to be able to choose a tap name
at creation, either the whole name, or just a number appended to tap-.
Wouldn't it be possible to create a network interface with a random
name, that still points to (169,N), even if N is not part of the name?

Post by Roger Pau Monne
Or is it that choosing N is sufficient, but you'd like to be able to
do TAPSIFNAME on /dev/tap? That seems awkward, because as I read the
code the interface is created on open, so it would have to swap the
softc, essentially closing the current tap and opening a new one.
Overall, it seems easiest to teach qemu to use 'ifconfig tapN create' as
an alternative to clone/set-name.

I'm not really sure using an external command is better than performing
a set of ioctls, it's much more trickier to catch errors, and I would
say that overall I doubt Qemu developers would ever agree to switching
from using /dev/tap to ifconfig.

Thanks for the thoughts, Roger.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by Roger Pau Monne
Well in Linux you can give any name to tap interfaces

And other interfaces, IIRC.

This is something I've never liked about Linux, though I'm not entirely
sure why.

Post by Roger Pau Monne
Qemu opens /dev/tap and creates a new /dev/tapX, then fetches the
name of this interface using the TAPGIFNAME. In the past, Qemu had a
parameter that you could use to set the bridge Qemu has to pass to
the hotplug script, but this is no longer present, and the script
Qemu calls after creating the interface only knows the name of the
newly created interface, which is not really helpful, [...]

So, the problem is that the tap unit is not known until Qemu starts,
and Qemu provides no way to associate that interface with other
attributes of the particular Qemu instance that created it, and under
Linux this is addressed by hiding that information in the interface
name. This strikes me as horrible design, abusing the interface name,
of all things, to pass information through Qemu; it would be much
cleaner to give Qemu arguments which it passes verbatim to the script.

Hm, it occurs to me that in a sense that's what the design is now. Is
there any reason the `interface name' has to actually be an interface
name? Could we let Qemu think it's an interface name but have it
actually have nothing to do with any interface name?

Post by Roger Pau Monne
Wouldn't it be possible to create a network interface with a random
name, that still points to (169,N), even if N is not part of the name?

Well, that (169,N) points to - for the most part the pointer goes the
other way.

Post by Roger Pau Monne

Post by Greg Troxel
Overall, it seems easiest to teach qemu to use 'ifconfig tapN
create' as an alternative to clone/set-name.

I'm not really sure using an external command is better than
performing a set of ioctls, it's much more trickier to catch errors,

It is, however, immensely more flexible.

Post by Roger Pau Monne
and I would say that overall I doubt Qemu developers would ever agree
to switching from using /dev/tap to ifconfig.

I don't know Qemu developers at all, but are they interested in a clean
design that is reasonably portable, or do they think Linux is all they
care to bother with and if it happens to work on something else that's
fine but of no particular value to them? If they're closer to the
former end of that spectrum, surely we can work out something that's
not too gross for both us and Linux. (And if they're more towards the
latter, then we'll probably have to have private patches anyway.)

Actually, part of the problem is that inteface names are a separate
namespace unto themselves. It occurs to me that what we want here is,
loosely put, a symlink for an interface name - but symlinks are
filesystem objects, and interface names have nothing to do with the
filesystem.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roger Pau Monne]

Post by Mouse

Post by Roger Pau Monne
Well in Linux you can give any name to tap interfaces

And other interfaces, IIRC.
This is something I've never liked about Linux, though I'm not entirely
sure why.

Post by Roger Pau Monne
Qemu opens /dev/tap and creates a new /dev/tapX, then fetches the
name of this interface using the TAPGIFNAME. In the past, Qemu had a
parameter that you could use to set the bridge Qemu has to pass to
the hotplug script, but this is no longer present, and the script
Qemu calls after creating the interface only knows the name of the
newly created interface, which is not really helpful, [...]

So, the problem is that the tap unit is not known until Qemu starts,
and Qemu provides no way to associate that interface with other
attributes of the particular Qemu instance that created it, and under
Linux this is addressed by hiding that information in the interface
name.

Yes, under Linux the name of the interface to be created is passed to
Qemu, so it is decided and known before the interface is created.

Post by Mouse
This strikes me as horrible design, abusing the interface name,
of all things, to pass information through Qemu; it would be much
cleaner to give Qemu arguments which it passes verbatim to the script.

Passing a set of arguments to append to the script to call upon creating
the network interface doesn't seem like a better idea to me, for
instance error checking of the execution of that script becomes much
more difficult, and if we can control the execution of that script
directly, that gives us the flexibility of choosing how to recover from
errors.

Post by Mouse
Hm, it occurs to me that in a sense that's what the design is now. Is
there any reason the `interface name' has to actually be an interface
name? Could we let Qemu think it's an interface name but have it
actually have nothing to do with any interface name?

Well, Qemu creates that interface, and it needs it in order to inject
and read traffic to and from the guest. So it needs to be a real tap
interface, which will be used by the guest.

Post by Mouse

Post by Roger Pau Monne
Wouldn't it be possible to create a network interface with a random
name, that still points to (169,N), even if N is not part of the name?

Well, that (169,N) points to - for the most part the pointer goes the
other way.

Post by Roger Pau Monne

Post by Greg Troxel
Overall, it seems easiest to teach qemu to use 'ifconfig tapN
create' as an alternative to clone/set-name.

I'm not really sure using an external command is better than
performing a set of ioctls, it's much more trickier to catch errors,

It is, however, immensely more flexible.

Yes, but you need all the fork machinery, to be able to fork a process,
wait for it for finish or kill it if stuck and check the return value.
Also it requires many more resources than a simple ioctl and is more
prone to errors and bugs.

Post by Mouse

Post by Roger Pau Monne
and I would say that overall I doubt Qemu developers would ever agree
to switching from using /dev/tap to ifconfig.

I don't know Qemu developers at all, but are they interested in a clean
design that is reasonably portable, or do they think Linux is all they
care to bother with and if it happens to work on something else that's
fine but of no particular value to them? If they're closer to the
former end of that spectrum, surely we can work out something that's
not too gross for both us and Linux. (And if they're more towards the
latter, then we'll probably have to have private patches anyway.)

We already have a separate file for tap device creation (tap-bsd.c),
which we share with Open and Free, so I don't think they will put much
objections on changing that to something more suitable if a strong
argument is made.

Post by Mouse
Actually, part of the problem is that inteface names are a separate
namespace unto themselves. It occurs to me that what we want here is,
loosely put, a symlink for an interface name - but symlinks are
filesystem objects, and interface names have nothing to do with the
filesystem.

Yes, that will be good, being able to create interface name "symlinks"
(unless we start polluting /dev/ with a forest of symlinks). Should this
be a global thing for all network interfaces?

I've found some information about a remote interface (QMP) that allows
fetching information from Qemu instances, theoretically we should be
able to fetch the "tap" device name from there, but it seems like the
required command to fetch network interfaces information was never
added. I've sent and email to qemu-devel, asking about this missing
command, since it seems it was about to be commited a long time ago:

http://wiki.qemu.org/Google_Summer_of_Code_2010/QMP#query-netdev

Anyway, I'm open to suggestions about how we should tackle this problem.

Thanks, Roger.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roger Pau Monne]

Roger> Anything that we can control, like tap-%domid.%devid would be
Roger> good though. It doesn't have to follow any specific
Roger> nomenclature, but it will be good to be able to specify two
Roger> integers, one that corresponds to the domain id, and another
Roger> one that identifies the specific network card inside that
Roger> domain.
But that, really, Admins hate having %domid in the device name because
it screws up useful things like SNMP/mrtg on those devices.

I don't really understand this, why does the name of the interface
matters regarding SNMP or mrtg? Is this a privacy related issue?

So the admin really wants to specify a consistent name in the XEN
configuration file... something which I think XEN does not yet support.

It supports being able to specify interface names in Linux (on the
domain config file), for both vif (PV) and tap (HVM), and it has been
like this for a long time I think (xend also had this functionality).

See the "vifname" section of this file for more information:

http://xenbits.xensource.com/hg/xen-unstable.hg/file/32034d1914a6/docs/misc/xl-network-configuration.markdown

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roger Pau Monne]

Post by Manuel Bouyer

Post by Roger Pau Monne

Roger> Anything that we can control, like tap-%domid.%devid would be
Roger> good though. It doesn't have to follow any specific
Roger> nomenclature, but it will be good to be able to specify two
Roger> integers, one that corresponds to the domain id, and another
Roger> one that identifies the specific network card inside that
Roger> domain.
But that, really, Admins hate having %domid in the device name because
it screws up useful things like SNMP/mrtg on those devices.

I don't really understand this, why does the name of the interface
matters regarding SNMP or mrtg? Is this a privacy related issue?

Because everywhere an interface name appears (ipf.conf, altq.conf,
mrtg graphs, ...) you have to change it when a domU is restarted.

Yes, I get it, if the name is persistent, then the graphs/statistics can
be fetched much more easily, the interface name never changes.

What Linux guys do (I think) is rename it using the ip command:

ip link set <old_name> name <new_name>

Or specifying the name of the desired interface during creation:

http://www.kernel.org/doc/Documentation/networking/tuntap.txt

But we should look into doing this with the ifconfig command I guess.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthew Mondor]

On Tue, 19 Jun 2012 10:46:40 +0100

Post by Roger Pau Monne
http://www.kernel.org/doc/Documentation/networking/tuntap.txt

When looking at the Linux code it seems that the TUNSETIFF ioctl(2) is
mandatory to have the interface created/attached, and that in the case
of a supplied IFNAMSIZ sized string it'll apply the name at interface
creation, not rename it after creating it automatically at open(2)
time. Thus avoiding the possible race condition I mentionned IRT a
system that'd track interface creation.

[Mouse]

Post by Mouse

Post by Roger Pau Monne
I'm not really sure using an external command is better than
performing a set of ioctls,

It is, however, immensely more flexible.

Yes, but you need all the [infrastructure]

True. I'm not competent to hold an opinion on which way that tradeoff
goes, though if Qemu is already capable of running scripts then it must
have most of that machinery in place - though the point about handling
errors is still a good one.

Yes, that will be good, being able to create interface name
"symlinks" (unless we start polluting /dev/ with a forest of
symlinks).

Well, interface names do not, in general, appear in the filesystem
anywhere, /dev or otherwise, so what I was loosely calling interface
name symlinks would not clutter /dev.

Should this be a global thing for all network interfaces?

Well, if you `symlink' vif7.1 to tap4, then it's as global as any other
interface name, or at least it would be under the paradigm I was
imagining.

I've found some information about a remote interface (QMP) that
allows fetching information from Qemu instances, theoretically we
should be able to fetch the "tap" device name from there, but it
seems like the required command to fetch network interfaces
information was never added.

Ooh, yeah, that sounds like an even better approach.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Anything that we can control, like tap-%domid.%devid would be good
though. It doesn't have to follow any specific nomenclature, but it
will be good to be able to specify two integers, one that corresponds
to the domain id, and another one that identifies the specific network
card inside that domain.

So there's no need to change the /dev/tapN, or the device number, but
just the name of the interface. As far as I know that's just a string
in the struct ifnet, and it's compared when one searches by name, so it
should be changeable. I had thought setting the interface name would
change more and be more intrusive, but maybe it's not so bad.
(It does make sense to require it to start with 'tap' to avoid
collisions.)

It seems easy enough to add the ioctl and see if things blow up...

[Thor Lancelot Simon]

Post by Greg Troxel
It seems easy enough to add the ioctl and see if things blow up...

You can be pretty sure ipf, pf, and npf will blow up.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Thor Lancelot Simon

Post by Greg Troxel
It seems easy enough to add the ioctl and see if things blow up...

You can be pretty sure ipf, pf, and npf will blow up.

Because they watch interface creation and keep matching state? Or do
you just mean that rules written for tap3 will no longer match?

[Thor Lancelot Simon]

Post by Greg Troxel

Post by Thor Lancelot Simon

Post by Greg Troxel
It seems easy enough to add the ioctl and see if things blow up...

You can be pretty sure ipf, pf, and npf will blow up.

Because they watch interface creation and keep matching state? Or do
you just mean that rules written for tap3 will no longer match?

Rename the interface. Now watch what happens when you try to load new
rules. Now tell ipfilter, for example, to "resynchronize the interface
list" (ipf -y). Imagine the fun possible if interfaces change names,
old interfaces, with rules affixed, still exist but the names no longer
match, etc...

I think a lot of fun is possible, and likely.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roger Pau Monne]

Post by Thor Lancelot Simon

Post by Greg Troxel

Post by Thor Lancelot Simon

Post by Greg Troxel
It seems easy enough to add the ioctl and see if things blow up...

You can be pretty sure ipf, pf, and npf will blow up.

Because they watch interface creation and keep matching state? Or do
you just mean that rules written for tap3 will no longer match?

Rename the interface. Now watch what happens when you try to load new
rules. Now tell ipfilter, for example, to "resynchronize the interface
list" (ipf -y). Imagine the fun possible if interfaces change names,
old interfaces, with rules affixed, still exist but the names no longer
match, etc...

Changing the if_xname directly with an ioctl call yells the following
when doing an ifconfig -a:

ifconfig: status: getifinfo: Device not configured

Post by Thor Lancelot Simon
I think a lot of fun is possible, and likely.

I don't know if there's interest in giving tap interfaces different
names (apart from my case), if so I can follow this path and try to add
a correct way to change a device name, but I just don't want to waste
time following a path that is not going to give us a desirable solution.

Roger.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthew Mondor]

On Mon, 18 Jun 2012 12:21:17 -0400

Post by Thor Lancelot Simon

Post by Greg Troxel

Post by Thor Lancelot Simon

Post by Greg Troxel
It seems easy enough to add the ioctl and see if things blow up...

You can be pretty sure ipf, pf, and npf will blow up.

Because they watch interface creation and keep matching state? Or do
you just mean that rules written for tap3 will no longer match?

Rename the interface. Now watch what happens when you try to load new
rules. Now tell ipfilter, for example, to "resynchronize the interface
list" (ipf -y). Imagine the fun possible if interfaces change names,
old interfaces, with rules affixed, still exist but the names no longer
match, etc...
I think a lot of fun is possible, and likely.

Firewall rules can use interface names rather than device IDs as they
can be loaded before interfaces get configured?

In the case of cloned pseudo-devices such as tap(4), new firewall rules
generally have to be dynamically added after the new interface name/id
is known however, similar to with routes.

If TAPSIFNAME was allowed, possibly that it should be restricted to
cloning pseudo-interfaces, and only allow to be used once per
instance. I still see some possible race condition issue if another
subsystem monitors newly created interfaces; it's unlikely that they
expect a special message about an interface name change.

It would be nicer if it was possible to specify the name before the
interface was created, such that they atomically be created with the
target name, but I'm not sure how to provide this without breaking
backwards compatibility, as I think that cloning tap(4) devices are
implicitely created (before one has the opportunity to set its
name)... Unless of course we had yet another tap(4) cloning device
node, behaving slightly differently.

[Matthew Mondor]

On Mon, 18 Jun 2012 12:49:03 -0400

Post by Matthew Mondor
It would be nicer if it was possible to specify the name before the
interface was created, such that they atomically be created with the
target name, but I'm not sure how to provide this without breaking
backwards compatibility, as I think that cloning tap(4) devices are
implicitely created (before one has the opportunity to set its
name)... Unless of course we had yet another tap(4) cloning device
node, behaving slightly differently.

Or perhaps an open(2) flag, which if set, causes the interface creation
to be delayed for the user to explicitely use TAPSIFNAME then
SIOCIFCREATE, with TAPSIFNAME not allowed afterwards?

[Darren Reed]

Post by Roger Pau Monne
Anything that we can control, like tap-%domid.%devid would be good
though. It doesn't have to follow any specific nomenclature, but it
will be good to be able to specify two integers, one that corresponds
to the domain id, and another one that identifies the specific network
card inside that domain.
So there's no need to change the /dev/tapN, or the device number, but
just the name of the interface. As far as I know that's just a string
in the struct ifnet, and it's compared when one searches by name, so it
should be changeable. I had thought setting the interface name would
change more and be more intrusive, but maybe it's not so bad.
(It does make sense to require it to start with 'tap' to avoid
collisions.)
It seems easy enough to add the ioctl and see if things blow up...

This should be done differently.

Rather than just change the name of the interface, create a layer
that maps a real device name to a network interface name.

Otherwise if you rename "tap0" to "bge3", how do you easily
determine that "bge3" is actually a tap device and not a bge?

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jean-Yves Migeon]

Post by Roger Pau Monne

Post by Darren Reed
This should be done differently.
Rather than just change the name of the interface, create a layer
that maps a real device name to a network interface name.
Otherwise if you rename "tap0" to "bge3", how do you easily
determine that "bge3" is actually a tap device and not a bge?

I would like to add this functionality to the kernel, but can someone
provide a little bit more of technical information/steps about how to do it?

(these are suggestions, there are countless ways to do that of course)

This needs some thought regarding the cleanliness of the API, but I
would do it through properties, just for reusability (instead of rolling
out your own API).

When a device gets created properties get attached to it (a proplib(3)
container). You can query those anytime for a device, see drvctl(8) code
for examples.

When attaching a new tap, you can keep the device information:

# drvctl -p tap0
Properties for device `tap0':
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>device-driver</key>
<string>tap</string>
<key>device-unit</key>
<integer>0x0</integer>
</dict>
</plist>

There, you see that the device-driver for a tap0 is "tap" (obviously).

You could add a member in this structure (string?) that would specify
the if_xname from struct ifnet, therefore pointing to the associated
interface name. Have a look to prop_dictionary_set(9) for an API to add
custom members to a property container.

Also, see sys/dev/pci/if_bnx.c, especially the prop_dictionary_set()
parts in bnx_attach. I used properties to move values between the PHY
and the NIC driver "safely." All credits for this idea goes to Izumi
Tsutsui.


Another possibility would be to add properties to ifnet structures, but
this would be redundant. I would expect interfaces and device names to
always match, so adding properties for ifnet structures is... kind of
useless (from my PoV).

[Martin Husemann]

Post by Jean-Yves Migeon
This needs some thought regarding the cleanliness of the API, but I
would do it through properties, just for reusability (instead of rolling
out your own API).

I disagree - wether there should be an api to set interface names to arbitrary
strings, or give interface names an arbitrary alias, or have a mapping layer
that refers via arbitrary names to network devices, is completely orthogonal
to the issue at hand. This needs *a lot* more design work.

However, there already is a perfectly working api to create tap interfaces
at will with a consistent number: ioctl(SIOCIFCREATE,...) and then open
the corresponding /dev/tapN. There is no need to fork ifconfig or anything
fancy.

Xen should just use this and create reliable/persistent mappings of
domUs to tapNs.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roger Pau Monne]

Post by Jean-Yves Migeon

Post by Roger Pau Monne

Post by Darren Reed
This should be done differently.
Rather than just change the name of the interface, create a layer
that maps a real device name to a network interface name.
Otherwise if you rename "tap0" to "bge3", how do you easily
determine that "bge3" is actually a tap device and not a bge?

I would like to add this functionality to the kernel, but can someone
provide a little bit more of technical information/steps about how to do it?

(these are suggestions, there are countless ways to do that of course)
This needs some thought regarding the cleanliness of the API, but I
would do it through properties, just for reusability (instead of rolling
out your own API).
When a device gets created properties get attached to it (a proplib(3)
container). You can query those anytime for a device, see drvctl(8) code
for examples.
# drvctl -p tap0
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>device-driver</key>
<string>tap</string>
<key>device-unit</key>
<integer>0x0</integer>
</dict>
</plist>
There, you see that the device-driver for a tap0 is "tap" (obviously).
You could add a member in this structure (string?) that would specify
the if_xname from struct ifnet, therefore pointing to the associated
interface name. Have a look to prop_dictionary_set(9) for an API to add
custom members to a property container.
Also, see sys/dev/pci/if_bnx.c, especially the prop_dictionary_set()
parts in bnx_attach. I used properties to move values between the PHY
and the NIC driver "safely." All credits for this idea goes to Izumi
Tsutsui.
Another possibility would be to add properties to ifnet structures, but
this would be redundant. I would expect interfaces and device names to
always match, so adding properties for ifnet structures is... kind of
useless (from my PoV).

Thanks for the input, I had no idea about this properties thing. I was
going to try to mimic what FreeBSD does:

http://fxr.watson.org/fxr/source/net/if.c#L2194

It creates a new ioctl called SIOCSIFNAME which basically detaches the
interface, changes the name (if_xname) and attaches the interface again.

I think that you are suggesting to do something similar, but your change
implies that all users of net interfaces should read the name from the
property list instead of reading it from the ifnet struct? So if_xname
remains the same, but the callers should instead read the name from this
property list?

Or the name cannot be changed directly in the ifnet struct because it
represents the type of network interface, so changing tapX to foobar
will make the system think it's an unknown interface?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Roger Pau Monne
Thanks for the input, I had no idea about this properties thing. I was
http://fxr.watson.org/fxr/source/net/if.c#L2194
It creates a new ioctl called SIOCSIFNAME which basically detaches the
interface, changes the name (if_xname) and attaches the interface again.

That seems doable, and I think there's merit to being similar to
FreeBSD. I suspect the interfaces for removal/addition will be
different, but what if_tap.c does can just be adapted. This scheme
feels icky, but it doesn't seem wrong and it may be the lowest-pain path
to getting xen/hvm working.

Post by Roger Pau Monne
I think that you are suggesting to do something similar, but your
change implies that all users of net interfaces should read the name
from the property list instead of reading it from the ifnet struct? So
if_xname remains the same, but the callers should instead read the
name from this property list?

I think the properties suggestion was simpler - just have a way to add a
name, and have the program that wants to use extraname=foo look over
the interfaces to see which has the extraname property set to foo and
then just use that one. Don't change anything else.

Post by Roger Pau Monne
Or the name cannot be changed directly in the ifnet struct because it
represents the type of network interface, so changing tapX to foobar
will make the system think it's an unknown interface?

There are two issues:

the name in struct ifnet gets used in various other places, so
changing it safely is hard (but remove/attach might be ok). This is
the real issue.

changing tapX to foobar means that you can't tell what kind of device
it is by the name, but it's easy enough to require that the prefix not
be changed and then be followed by a number, or some similar rule.

[Thor Lancelot Simon]

Post by Roger Pau Monne
I think that you are suggesting to do something similar, but your
change implies that all users of net interfaces should read the name
from the property list instead of reading it from the ifnet struct?

If that's what is actually being suggested -- ewww.

At some point we have to stop tarting up the entire guts of the kernel
with XML. Sometimes a simple field in a C datastructure is good enough!

Proplib might be a good hammer, but not every problem is a nail.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Robert Elz]

While all of you people are working out how to solve the problem
presented (an issue upon which I have no particular opinion), I'd
like to make one request of the eventual solution...

That is, in all (NetBSD) guest OS's, I'd very much prefer if
the network interfaces have the exact same names - what those
names are matters almost not at all, but each guest should have
the same interface names (assuming they have the same networking
configuration of course).

That makes sharing management scripts, etc, much much easier,
no need to make changes to what works in one guest before
copying it to all of the others.

So, whatever the eventual solution, please at least make
this possible (ie: inside the guest, don't have domain
identifiers as part of the interface names!)

kre

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roger Pau Monne]

Post by Robert Elz
While all of you people are working out how to solve the problem
presented (an issue upon which I have no particular opinion), I'd
like to make one request of the eventual solution...
That is, in all (NetBSD) guest OS's, I'd very much prefer if
the network interfaces have the exact same names - what those
names are matters almost not at all, but each guest should have
the same interface names (assuming they have the same networking
configuration of course).

I'm speaking about Dom0 here, guests (DomUs) should always have the same
interface name since it doesn't depend on the name the interface has on
the Dom0.

Post by Robert Elz
That makes sharing management scripts, etc, much much easier,
no need to make changes to what works in one guest before
copying it to all of the others.
So, whatever the eventual solution, please at least make
this possible (ie: inside the guest, don't have domain
identifiers as part of the interface names!)
kre

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Greg Troxel

Post by Roger Pau Monne
Thanks for the input, I had no idea about this properties thing. I was
http://fxr.watson.org/fxr/source/net/if.c#L2194
It creates a new ioctl called SIOCSIFNAME which basically detaches the
interface, changes the name (if_xname) and attaches the interface again.

That seems doable, and I think there's merit to being similar to
FreeBSD. I suspect the interfaces for removal/addition will be
different, but what if_tap.c does can just be adapted. This scheme
feels icky, but it doesn't seem wrong and it may be the lowest-pain path
to getting xen/hvm working.

Yes, and I think it can be made more general than just tap and Xen
(whenever this should be another string in struct ifnet, or a XML
property of the device is another debate - lets talk about the functionality
we want first).

I think we could have both a device name and a device name alias for an
interface (lets call them xname and xalias for now). The xname would still
be as it is righ now (i.e. bge0 or tap3, bridge1, ...)
xalias is a user-settable string (ifconfig should probably be able to set it)
with the only constraint that it's unique in a system (and probably
lenght-limited). Consumer could refer to an interface by xname or by xalias,
with some way to differenciate xname and xalias (this could via a specific
syntax, e.g. alias:<string>).

Being able to refer to an interface by a user-settable name has more uses
than for Xen (Xen use cases have already been mentionned, I won't repeat
them). For example, on a system with a bnx0, for whatever reason,
the interface is remplaced with a wm(4). I have to change every place
listing interface names (ipf, altq, routing daemons, log analysers, mrtg, ....).
If I could give the interface a custom xalias and use it instead of xname,
the change would be almost transparent (only ifconfig.bnx0 to rename to
ifconfig.wm0).

I think this is more general and less trouble than the destroy/recreate with
a different name (the struct ifnet doesn't change). Changing the xalias on a
running system shouldn't cause more problem than e.g. xvif1-0 being destroyed
and xvif2-0 being created (it should actually be less trouble, because
struct ifnet doesn't change). ipf -y will rescan the ifnet list for new
xnames and xaliases. If you actually change an interface's xalias and forget
to update ipf.conf; well, that's a user error :)

[Edgar Fuß]

Post by Manuel Bouyer
I think we could have both a device name and a device name alias for an
interface (lets call them xname and xalias for now). The xname would still
be as it is righ now (i.e. bge0 or tap3, bridge1, ...)

I like that idea, but one may have to think very carefully about
some details.

Suppose you have bge0 aliased as en0 and wm0 as en1.

Should the output of ifconfig bge0 (or -a) show something like
name-alias: en0
?

What should ifconfig en0 do? Give an error or behave like ifconfig bge0?

What should ifconfig -l output? bge0 and wm0 or en0 and en1 or both?

How should "block all on bge0; pass all on en0" behave?

This is the usual problem of "take x" and "enumerate and pick x" potentially
behaving differently (like "ls CamelCase" and "ls | grep CamelCase" on a
case-preserving file system).

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Edgar Fuß

Post by Manuel Bouyer
I think we could have both a device name and a device name alias for an
interface (lets call them xname and xalias for now). The xname would still
be as it is righ now (i.e. bge0 or tap3, bridge1, ...)

I like that idea, but one may have to think very carefully about
some details.
Suppose you have bge0 aliased as en0 and wm0 as en1.
Should the output of ifconfig bge0 (or -a) show something like
name-alias: en0

Yes, I think ifconfig should show it, of course.

Post by Edgar Fuß
?
What should ifconfig en0 do? Give an error or behave like ifconfig bge0?

Give an error. If you want to use bge0's alias, use 'ifconfig alias:en0'
(or whatever - you get the idea: if you want to use the alias instead of
the name, explicitely say it is an alias).

Post by Edgar Fuß
What should ifconfig -l output? bge0 and wm0 or en0 and en1 or both?

Good question, I didn't think of this case. At first glance, I'd say
ifconfig -l should show only bge0 and wm0, and another option lists
aliases. Or maybe we don't need to have a list of aliases at all ...

Post by Edgar Fuß
How should "block all on bge0; pass all on en0" behave?

That would be:
block all on bge0
pass all on alias:en0

well, it would be identical to
block all on bge0
pass all on bge0

the last matching rule wins

Post by Edgar Fuß
This is the usual problem of "take x" and "enumerate and pick x" potentially
behaving differently (like "ls CamelCase" and "ls | grep CamelCase" on a
case-preserving file system).

Sure. I think that most of this can be avoided if we make clear what is
a name and what is an alias, so you can't use one for the other.
This is different namespaces, so you have to tell which one you want
to use (or list).

[Jean-Yves Migeon]

Post by Thor Lancelot Simon

Post by Roger Pau Monne
I think that you are suggesting to do something similar, but your
change implies that all users of net interfaces should read the name
from the property list instead of reading it from the ifnet struct?

If that's what is actually being suggested -- ewww.

No.

Post by Thor Lancelot Simon
At some point we have to stop tarting up the entire guts of the kernel
with XML. Sometimes a simple field in a C datastructure is good enough!
Proplib might be a good hammer, but not every problem is a nail.

And sometimes inventing new tools is not the way to go :)

[Robert Elz]

Date: Wed, 20 Jun 2012 14:20:20 +0100
From: Roger Pau Monne <***@citrix.com>
Message-ID: <***@citrix.com>

| I'm speaking about Dom0 here,

OK, great. Thanks for the clarification.

kre

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Roger Pau Monne

Post by Darren Reed

Post by Roger Pau Monne
Anything that we can control, like tap-%domid.%devid would be good
though. It doesn't have to follow any specific nomenclature, but it
will be good to be able to specify two integers, one that corresponds
to the domain id, and another one that identifies the specific network
card inside that domain.
So there's no need to change the /dev/tapN, or the device number, but
just the name of the interface. As far as I know that's just a string
in the struct ifnet, and it's compared when one searches by name, so it
should be changeable. I had thought setting the interface name would
change more and be more intrusive, but maybe it's not so bad.
(It does make sense to require it to start with 'tap' to avoid
collisions.)
It seems easy enough to add the ioctl and see if things blow up...

This should be done differently.
Rather than just change the name of the interface, create a layer
that maps a real device name to a network interface name.
Otherwise if you rename "tap0" to "fxp3", how do you easily
determine that "fxp3" is actually a tap device and not a fxp?

I would like to add this functionality to the kernel, but can someone
provide a little bit more of technical information/steps about how to do it?

The first issue that you face that for all intents and purposes, you
cannot change "struct ifnet" because it is in too many places and
change will likely have a huge waterfall effect. So that can't be
changed.

What can be changed is where "struct ifnet" gets its name from.

For network interfaces, what's required here is another data
structure that connects a "struct ifnet" with the device itself.
This structure needs to remain an internal implementation detail
and any interfacing to it via ioctls should be done via proplists.
A new CLI tool is required to manage this interface, maybe call
it nicctl. For now, all that it would do is display what NICs are
present in the system, their device name, instance number and the
name to be used in "struct ifnet".

This CLI tool also needs to be able to add and remove device name
mappings. So, for example, it needs to let me assign the name
"fxp0" to "fxp,3" or some such. This naming information also needs
to be stored in a file somewhere so that when the system boots,
it can use that information to instruct the kernel. Obviously this
needs to be invoked early in rc, i.e. before ifconfig is used to
set the interface IP addresses. What format that file takes is up
to the person doing the implementation. It could be straight text,
maybe it is XML. Whatever.

When a device driver calls if_initname(), if_initname() needs to
see if the new device that is being named should go by another
name. To do this it would be looking at the information stored
in the kernel mentioned above. If so, that name gets copied into
if_xname, else if_xname is composed from <name,unit>.

At some point, network interface initialisation needs to handle
a failure if one device attempts to attach to the system with a
name that is already in use. Similarly, the rename needs to also
be able to fail if the user tries to rename fxp0 to fxp1 when
fxp0 already exists.

The CLI tool used to do interface renaming might also want to
be aware of whether or not the interface is a cloning device
or not. The reason for this is that a cloning device is not
going to be present when the system boots, so any renaming
operation needs to be thought of as being transient and thus
it may not warrant being stored permanently.

For example, I might want to change the name of "ppp0" to
"internet0" after PPP on an ADSL modem link. The ppp0 will
not exist at boot and it is not unreasonable to expect that
there will be another ppp device, so "internet0" may not
always be "ppp0" - some days it may be "ppp1" - so there
is questionable benefit from having a permanent renaming
operation stored for ppp0 -> internet0. Further to this,
it may be worthwhile having changes to pppd to allow the
name to be changed as the interface is created, so that
ppp# is never created, rather orange0 is always created
or some such.

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Darren Reed

Post by Roger Pau Monne
I would like to add this functionality to the kernel, but can someone
provide a little bit more of technical information/steps about how to do it?

The first issue that you face that for all intents and purposes, you
cannot change "struct ifnet" because it is in too many places and
change will likely have a huge waterfall effect. So that can't be
changed.
What can be changed is where "struct ifnet" gets its name from.
For network interfaces, what's required here is another data
structure that connects a "struct ifnet" with the device itself.
This structure needs to remain an internal implementation detail
and any interfacing to it via ioctls should be done via proplists.
A new CLI tool is required to manage this interface, maybe call
it nicctl. For now, all that it would do is display what NICs are
present in the system, their device name, instance number and the
name to be used in "struct ifnet".
This CLI tool also needs to be able to add and remove device name
mappings. So, for example, it needs to let me assign the name
"fxp0" to "fxp,3" or some such. This naming information also needs
to be stored in a file somewhere so that when the system boots,
it can use that information to instruct the kernel. Obviously this
needs to be invoked early in rc, i.e. before ifconfig is used to
set the interface IP addresses. What format that file takes is up
to the person doing the implementation. It could be straight text,
maybe it is XML. Whatever.

I think that basically I agree with Darren. You need a driver
entity (some softc-having thing) and a logical network entity (an
ifnet-having thing) and some correspondence between them that is
set by properties of the driver such as MAC, serial number, its PCI
bus/device/function number. The driver entity has a name written
in NetBSDese (e.g., wmhw0), the logical entity takes either a
default name (e.g., wm0) or the name supplied by the operator (e.g.,
lan19 or wan0 or customer7).

I believe that NetBSD should use autoconf(9) to create the
correspondence. Extend drvctl (or *something*) to let us load/unload
new device->driver correspondences. I've written more about this at
<http://mail-index.netbsd.org/tech-net/2011/05/11/msg002614.html>.

Provide a convenience utility, nicctl, to set up the correspondences for
network interfaces specifically.

I believe that NetBSD should treat disks the same way: split them into
hardware entity and logical disk, set up correspondences between them
using properties of the disk (model, capacity, serial number, whatever)
and/or properties of its partitions (GUID, offset, size, human-readable
name). If we look at them a bit askew, wedges are a step in that
direction. Let the logical disks take a default name (dk0) or else the
operator's name if there is one (backup0).

I think that if you rearrange things in this way, a number of problems
in the kernel shake out. For example, power-management for NICs gets
less hairy. Interesting opportunities come up if you let a logical
driver's device_t (and probably its softc, too) hang around even if
its underlying hardware has disappeared: in that way, the logical
name for a hardware device will persist for at least as long as the
system is up, and the kernel has in the logical driver a place to hang
network configuration or unwritten disk buffers in the event of an
accidental/emergency device detachment.

Dave

[Manuel Bouyer]

Post by Darren Reed
[...]
The first issue that you face that for all intents and purposes, you
cannot change "struct ifnet" because it is in too many places and
change will likely have a huge waterfall effect. So that can't be
changed.

that's not true. struct ifnet can and has been changed, the last
time was 2011/10/19.
But this will likely cause ABI issues; if this has to be pulled up to netbsd-6
and/or netbsd-5, this needs to be carefully examinated.

[Manuel Bouyer]

Post by David Young

Post by Darren Reed

Post by Roger Pau Monne
I would like to add this functionality to the kernel, but can someone
provide a little bit more of technical information/steps about how to do it?

The first issue that you face that for all intents and purposes, you
cannot change "struct ifnet" because it is in too many places and
change will likely have a huge waterfall effect. So that can't be
changed.
What can be changed is where "struct ifnet" gets its name from.
For network interfaces, what's required here is another data
structure that connects a "struct ifnet" with the device itself.
This structure needs to remain an internal implementation detail
and any interfacing to it via ioctls should be done via proplists.
A new CLI tool is required to manage this interface, maybe call
it nicctl. For now, all that it would do is display what NICs are
present in the system, their device name, instance number and the
name to be used in "struct ifnet".
This CLI tool also needs to be able to add and remove device name
mappings. So, for example, it needs to let me assign the name
"fxp0" to "fxp,3" or some such. This naming information also needs
to be stored in a file somewhere so that when the system boots,
it can use that information to instruct the kernel. Obviously this
needs to be invoked early in rc, i.e. before ifconfig is used to
set the interface IP addresses. What format that file takes is up
to the person doing the implementation. It could be straight text,
maybe it is XML. Whatever.

I think that basically I agree with Darren. You need a driver
entity (some softc-having thing) and a logical network entity (an
ifnet-having thing) and some correspondence between them that is
set by properties of the driver such as MAC, serial number, its PCI
bus/device/function number. The driver entity has a name written
in NetBSDese (e.g., wmhw0), the logical entity takes either a
default name (e.g., wm0) or the name supplied by the operator (e.g.,
lan19 or wan0 or customer7).
I believe that NetBSD should use autoconf(9) to create the
correspondence. Extend drvctl (or *something*) to let us load/unload
new device->driver correspondences. I've written more about this at
<http://mail-index.netbsd.org/tech-net/2011/05/11/msg002614.html>.
Provide a convenience utility, nicctl, to set up the correspondences for
network interfaces specifically.
I believe that NetBSD should treat disks the same way: split them into
hardware entity and logical disk, set up correspondences between them
using properties of the disk (model, capacity, serial number, whatever)
and/or properties of its partitions (GUID, offset, size, human-readable
name). If we look at them a bit askew, wedges are a step in that
direction. Let the logical disks take a default name (dk0) or else the
operator's name if there is one (backup0).
I think that if you rearrange things in this way, a number of problems
in the kernel shake out. For example, power-management for NICs gets
less hairy. Interesting opportunities come up if you let a logical
driver's device_t (and probably its softc, too) hang around even if
its underlying hardware has disappeared: in that way, the logical
name for a hardware device will persist for at least as long as the
system is up, and the kernel has in the logical driver a place to hang
network configuration or unwritten disk buffers in the event of an
accidental/emergency device detachment.

I like the idea, but I think we don't want to restrict this to
disk and network device. I can't see why you'd want it for low-level
devices (like e.g. ahcisata or atabus or uhci), but I definitively want it
for anything that is exposted (as a device) to userland (disk, network if,
serial ports, kbd/mouse and other hid, video, printers, ...).

This is a big project ...

[Roger Pau Monne]

Post by Manuel Bouyer

Post by Darren Reed
[...]
The first issue that you face that for all intents and purposes, you
cannot change "struct ifnet" because it is in too many places and
change will likely have a huge waterfall effect. So that can't be
changed.

that's not true. struct ifnet can and has been changed, the last
time was 2011/10/19.
But this will likely cause ABI issues; if this has to be pulled up to netbsd-6
and/or netbsd-5, this needs to be carefully examinated.

There has been a lot of chat here, but I think the general idea is that
the FreeBSD way of changing interface names is not acceptable on NetBSD.
I was halfway on doing that change to NetBSD.

So, we would like to be able to create interface alias, here is what I
think should be doable (from my PoV):

Adding a field to ifnet to contain that alias, something like if_xalias,
then being able to set that name with an ioctl (something like
SIOCSIFALIAS) and to fetch if with an ioctl also (SIOCGIFALIAS). I think
this can be done using the already present ifreq struct, and
getting/setting the alias from the ifr_name field.

What I'm not sure is how to propagate that change to every tool that
interacts with network interfaces, we should of course change ifconfig
to be able to set/get this aliases, but then changes will also be
required to brconfig, pf...?

Also, when the user specifies something like ifconfig alias:foo up, how
do we know to what is alias:foo mapped to? Querying all possible network
interfaces to find it's aliases? Querying all interfaces to get it's
aliases it's a very big overhead.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mouse]

Post by Roger Pau Monne
So, we would like to be able to create interface alias, here is what

Here are some thoughts that come to mind. I'm not sure they're all
points worth worrying about.

Post by Roger Pau Monne
Adding a field to ifnet to contain that alias, something like
if_xalias, then being able to set that name with an ioctl [...]

Is a maximum of one alias per interface sufficient? I once saw it said
that "the number two is ludicrous" - having one of something is fine,
but as soon as you have two, why not an unlimited number? In this
case, the "something" is names per interface.

Why draw a distinction between the name and the alias? (I actually can
see some potential answers to this; I mention it more to provoke
thought than because I think it's a serious issue.)

Post by Roger Pau Monne
What I'm not sure is how to propagate that change to every tool that
interacts with network interfaces, we should of course change
ifconfig to be able to set/get this aliases, but then changes will
also be required to brconfig, pf...?

I see no need for all tools to be aware of aliases. Many (most?) tools
just use names to refer to interfaces and don't care about the finer
points of it. So as long as the names are valid for the purposes the
tools are using them for, I see no reason for, eg, brconfig to care
whether an interface it's trying to add is an alias or not.

Post by Roger Pau Monne
Also, when the user specifies something like ifconfig alias:foo up,
how do we know to what is alias:foo mapped to?

Who is "we"? I see no reason for ifconfig to care; it just does the
ioctl with "alias:foo" in the interface name field and doesn't care
whether it's an alias, even, much less what it's an alias for. Inside
the kernel, for most purposes, this is entirely hidden within the "look
up an interface given its name" code; as far as I can see, the only
other things that have occasion to care are the specifcally alias-aware
ones, like the code to set and get alias names.

If it turns out there is reason for userland to care - and reason to
draw a distinction between an interface's alias and its real name -
then an interface could be added to return the real name corresponding
to a possibly-aliased name.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roger Pau Monne]

Post by Mouse

Post by Roger Pau Monne
So, we would like to be able to create interface alias, here is what

Here are some thoughts that come to mind. I'm not sure they're all
points worth worrying about.

Thanks for the information, it has been really helpful.

Post by Mouse

Post by Roger Pau Monne
Adding a field to ifnet to contain that alias, something like
if_xalias, then being able to set that name with an ioctl [...]

Is a maximum of one alias per interface sufficient? I once saw it said
that "the number two is ludicrous" - having one of something is fine,
but as soon as you have two, why not an unlimited number? In this
case, the "something" is names per interface.

Well, I think that adding one or more than one is not really a problem.
I will start working on adding one alias per interface, but we can
always extend that code to add more than one.

Post by Mouse
Why draw a distinction between the name and the alias? (I actually can
see some potential answers to this; I mention it more to provoke
thought than because I think it's a serious issue.)

Post by Roger Pau Monne
What I'm not sure is how to propagate that change to every tool that
interacts with network interfaces, we should of course change
ifconfig to be able to set/get this aliases, but then changes will
also be required to brconfig, pf...?

I see no need for all tools to be aware of aliases. Many (most?) tools
just use names to refer to interfaces and don't care about the finer
points of it. So as long as the names are valid for the purposes the
tools are using them for, I see no reason for, eg, brconfig to care
whether an interface it's trying to add is an alias or not.

True.

Post by Mouse

Post by Roger Pau Monne
Also, when the user specifies something like ifconfig alias:foo up,
how do we know to what is alias:foo mapped to?

Who is "we"? I see no reason for ifconfig to care; it just does the
ioctl with "alias:foo" in the interface name field and doesn't care
whether it's an alias, even, much less what it's an alias for. Inside
the kernel, for most purposes, this is entirely hidden within the "look
up an interface given its name" code; as far as I can see, the only
other things that have occasion to care are the specifcally alias-aware
ones, like the code to set and get alias names.

Yes.

Post by Mouse
If it turns out there is reason for userland to care - and reason to
draw a distinction between an interface's alias and its real name -
then an interface could be added to return the real name corresponding
to a possibly-aliased name.

Well, now I have a clearer idea of what should be done, I will start
working on this tomorrow morning, let's see if I can get it ready for a
backport to 6.0.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Roger Pau Monne

Post by Manuel Bouyer

Post by Darren Reed
[...]
The first issue that you face that for all intents and purposes, you
cannot change "struct ifnet" because it is in too many places and
change will likely have a huge waterfall effect. So that can't be
changed.

that's not true. struct ifnet can and has been changed, the last
time was 2011/10/19.
But this will likely cause ABI issues; if this has to be pulled up to netbsd-6
and/or netbsd-5, this needs to be carefully examinated.

There has been a lot of chat here, but I think the general idea is
that the FreeBSD way of changing interface names is not acceptable
on NetBSD. I was halfway on doing that change to NetBSD.
So, we would like to be able to create interface alias, here is what
Adding a field to ifnet to contain that alias, something like
if_xalias, then being able to set that name with an ioctl (something
like SIOCSIFALIAS) and to fetch if with an ioctl also
(SIOCGIFALIAS). I think this can be done using the already present
ifreq struct, and getting/setting the alias from the ifr_name field.
What I'm not sure is how to propagate that change to every tool that
interacts with network interfaces, we should of course change
ifconfig to be able to set/get this aliases, but then changes will
also be required to brconfig, pf...?

I would do it at the kernel level: name and aliases are different namespace,
if we embed the namespace information in the string (e.g. alias:foo vs foo),
then you just use the same SIOCGIFADDR() with the same 'struct ifreq'
and the kernel does the job. I suspect most tools won't need to be changed
(ifconfig probably will, though)

Post by Roger Pau Monne
Also, when the user specifies something like ifconfig alias:foo up,
how do we know to what is alias:foo mapped to? Querying all possible
network interfaces to find it's aliases? Querying all interfaces to
get it's aliases it's a very big overhead.

See above.

[Darren Reed]

Post by Manuel Bouyer

Post by Darren Reed
[...]
The first issue that you face that for all intents and purposes, you
cannot change "struct ifnet" because it is in too many places and
change will likely have a huge waterfall effect. So that can't be
changed.

that's not true. struct ifnet can and has been changed, the last
time was 2011/10/19.
But this will likely cause ABI issues; if this has to be pulled up to netbsd-6
and/or netbsd-5, this needs to be carefully examinated.

There has been a lot of chat here, but I think the general idea is that the
FreeBSD way of changing interface names is not acceptable on NetBSD. I was
halfway on doing that change to NetBSD.
So, we would like to be able to create interface alias, here is what I think
Adding a field to ifnet to contain that alias, ..

No, this is not the right approach and I don't think that a short cut
solution like this belongs in NetBSD.

As you noticed, this requires changes to other utilities in order to work.

If your project requires any changes to brconfig, netstat, ifconfig, ipf,
npf, tcpdump, etc, then you've got the wrong solution in hand. Each network
interface should have one name and one name only as far as userland is
concerned. If there are userland programs (aside from device management)
that need to be worried about aliases then you've got the wrong solution.
That sentence just prior should be the litmus test for your design.

I suppose there's one other issue that needs to be resolved and that is
when can an interface be renamed. It might be perfectly acceptable to
say that an interface can only have its name changed whilst it has no
IPv4 addresses assigned to it and only the link-local IPv6 address.
Or maybe it will be ok to allow devices to be renamed when addresses
are present and configured.

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Darren Reed
No, this is not the right approach and I don't think that a short cut
solution like this belongs in NetBSD.
As you noticed, this requires changes to other utilities in order to work.

beside ifconfig, I'm not sure.

Post by Darren Reed
If your project requires any changes to brconfig, netstat, ifconfig, ipf,
npf, tcpdump, etc, then you've got the wrong solution in hand. Each network
interface should have one name and one name only as far as userland is
concerned. If there are userland programs (aside from device management)

I'm not happy with the "one name and one name only". I think some use case
will want the name, some other will want the alias (and you may need both
at the same time).

[Darren Reed]

Post by Manuel Bouyer

Post by Darren Reed
No, this is not the right approach and I don't think that a short cut
solution like this belongs in NetBSD.
As you noticed, this requires changes to other utilities in order to work.

beside ifconfig, I'm not sure.

Post by Darren Reed
If your project requires any changes to brconfig, netstat, ifconfig, ipf,
npf, tcpdump, etc, then you've got the wrong solution in hand. Each network
interface should have one name and one name only as far as userland is
concerned. If there are userland programs (aside from device management)

I'm not happy with the "one name and one name only".

Why aren't you happy?

Post by Manuel Bouyer
I think some use case
will want the name, some other will want the alias (and you may need both
at the same time).

Such as...?

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Mouse

Post by Roger Pau Monne
So, we would like to be able to create interface alias, here is what

Here are some thoughts that come to mind. I'm not sure they're all
points worth worrying about.

Post by Roger Pau Monne
Adding a field to ifnet to contain that alias, something like
if_xalias, then being able to set that name with an ioctl [...]

Is a maximum of one alias per interface sufficient? I once saw it said
that "the number two is ludicrous" - having one of something is fine,
but as soon as you have two, why not an unlimited number? In this
case, the "something" is names per interface.

We can probably make xalias a list instead of a single string. It shouldn't
change much things.

Post by Mouse
Why draw a distinction between the name and the alias? (I actually can
see some potential answers to this; I mention it more to provoke
thought than because I think it's a serious issue.)

I think we want a name that stay attached to the hardware and won't be
arbitrary changed (at last not while you don't swap hardware).

Post by Mouse

Post by Roger Pau Monne
What I'm not sure is how to propagate that change to every tool that
interacts with network interfaces, we should of course change
ifconfig to be able to set/get this aliases, but then changes will
also be required to brconfig, pf...?

I see no need for all tools to be aware of aliases. Many (most?) tools
just use names to refer to interfaces and don't care about the finer
points of it. So as long as the names are valid for the purposes the
tools are using them for, I see no reason for, eg, brconfig to care
whether an interface it's trying to add is an alias or not.

Post by Roger Pau Monne
Also, when the user specifies something like ifconfig alias:foo up,
how do we know to what is alias:foo mapped to?

Who is "we"? I see no reason for ifconfig to care; it just does the
ioctl with "alias:foo" in the interface name field and doesn't care
whether it's an alias, even, much less what it's an alias for. Inside
the kernel, for most purposes, this is entirely hidden within the "look
up an interface given its name" code; as far as I can see, the only
other things that have occasion to care are the specifcally alias-aware
ones, like the code to set and get alias names.

Yes, that's what I have in mind.

[Manuel Bouyer]

Post by Roger Pau Monne

Post by Mouse

Post by Roger Pau Monne
So, we would like to be able to create interface alias, here is what

Here are some thoughts that come to mind. I'm not sure they're all
points worth worrying about.

Thanks for the information, it has been really helpful.

Post by Mouse

Post by Roger Pau Monne
Adding a field to ifnet to contain that alias, something like
if_xalias, then being able to set that name with an ioctl [...]

Is a maximum of one alias per interface sufficient? I once saw it said
that "the number two is ludicrous" - having one of something is fine,
but as soon as you have two, why not an unlimited number? In this
case, the "something" is names per interface.

Well, I think that adding one or more than one is not really a
problem. I will start working on adding one alias per interface, but
we can always extend that code to add more than one.

Post by Mouse
Why draw a distinction between the name and the alias? (I actually can
see some potential answers to this; I mention it more to provoke
thought than because I think it's a serious issue.)

Post by Roger Pau Monne
What I'm not sure is how to propagate that change to every tool that
interacts with network interfaces, we should of course change
ifconfig to be able to set/get this aliases, but then changes will
also be required to brconfig, pf...?

I see no need for all tools to be aware of aliases. Many (most?) tools
just use names to refer to interfaces and don't care about the finer
points of it. So as long as the names are valid for the purposes the
tools are using them for, I see no reason for, eg, brconfig to care
whether an interface it's trying to add is an alias or not.

True.

Post by Mouse

Post by Roger Pau Monne
Also, when the user specifies something like ifconfig alias:foo up,
how do we know to what is alias:foo mapped to?

Who is "we"? I see no reason for ifconfig to care; it just does the
ioctl with "alias:foo" in the interface name field and doesn't care
whether it's an alias, even, much less what it's an alias for. Inside
the kernel, for most purposes, this is entirely hidden within the "look
up an interface given its name" code; as far as I can see, the only
other things that have occasion to care are the specifcally alias-aware
ones, like the code to set and get alias names.

Yes.

Post by Mouse
If it turns out there is reason for userland to care - and reason to
draw a distinction between an interface's alias and its real name -
then an interface could be added to return the real name corresponding
to a possibly-aliased name.

Well, now I have a clearer idea of what should be done, I will start
working on this tomorrow morning, let's see if I can get it ready
for a backport to 6.0.

Don't rush, the discussion is not over.
Also, I think it's too late anyway for 6.0. But it can be in 6.1.

[Manuel Bouyer]

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
No, this is not the right approach and I don't think that a short cut
solution like this belongs in NetBSD.
As you noticed, this requires changes to other utilities in order to work.

beside ifconfig, I'm not sure.

Post by Darren Reed
If your project requires any changes to brconfig, netstat, ifconfig, ipf,
npf, tcpdump, etc, then you've got the wrong solution in hand. Each network
interface should have one name and one name only as far as userland is
concerned. If there are userland programs (aside from device management)

I'm not happy with the "one name and one name only".

Why aren't you happy?

Post by Manuel Bouyer
I think some use case
will want the name, some other will want the alias (and you may need both
at the same time).

Such as...?

I saw some people being unhappy with the idea of interface rename
("once you're renamed it to foobar you don't know anymore if it's a
wm(4) or a tap(4), or possibly a bridge(4)") and I also like being
able to classify interfaces looking at their name,
But I also see a need to be able to refer to them using a different name.
But this is different from a rename.

I really think the feature we want is "alias", not "rename".

[Jean-Yves Migeon]

Post by Manuel Bouyer
I saw some people being unhappy with the idea of interface rename
("once you're renamed it to foobar you don't know anymore if it's a
wm(4) or a tap(4), or possibly a bridge(4)") and I also like being
able to classify interfaces looking at their name,
But I also see a need to be able to refer to them using a different name.
But this is different from a rename.
I really think the feature we want is "alias", not "rename".

In that case, I would avoid the use of "alias". ifconfig(8) uses it
already, but for another purpose.

[Darren Reed]

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
No, this is not the right approach and I don't think that a short cut
solution like this belongs in NetBSD.
As you noticed, this requires changes to other utilities in order to work.

beside ifconfig, I'm not sure.

Post by Darren Reed
If your project requires any changes to brconfig, netstat, ifconfig, ipf,
npf, tcpdump, etc, then you've got the wrong solution in hand. Each network
interface should have one name and one name only as far as userland is
concerned. If there are userland programs (aside from device management)

I'm not happy with the "one name and one name only".

Why aren't you happy?

Post by Manuel Bouyer
I think some use case
will want the name, some other will want the alias (and you may need both
at the same time).

Such as...?

I saw some people being unhappy with the idea of interface rename
("once you're renamed it to foobar you don't know anymore if it's a
wm(4) or a tap(4), or possibly a bridge(4)")

That's simply a matter of observability.

It would be a simple matter to use nicctl or drvctl or some
other tool to display a mapping between hardware devices and
network interface names.

Post by Manuel Bouyer
and I also like being
able to classify interfaces looking at their name,

Right, you like being able to see the driver name.

See above for observability.

Post by Manuel Bouyer
But I also see a need to be able to refer to them using a different name.
But this is different from a rename.
I really think the feature we want is "alias", not "rename".

I'm not so sure.

A network interface name is an entity in the BSD kernel that
has a relationship with a list of addresses. Similarly those
addresses have a relationship with a single interface name.
That's a very simple model that doesn't allow for any
confusion or problems. There is a strict 1 to 1 relationship
between address and interface name.

Aliases break that.

Say I give fxp0 an alias of net0 and I then do
"ifconfig net0 1.2.3.4". Now if I do "ifconfig net0" that
IP address will show up as assigned to it. But if I do
"netstat -nrf inet", net0 is nowhere to be seen. Why?

Who wants to explain to users that NetBSD has two different
classes of network interface names that can be used, one of
which is real and one of which isn't real? Isn't it easier
to just have one?

Yes, aliases are easy to make work but I'm hard pressed to accept
that they have more upsides than downsides, not the least of which
is that they add more complexity to ifconfig and ifconfig's output.

But if enough people are convinced you need alias then go for it.

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roger Pau Monné]

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
No, this is not the right approach and I don't think that a short cut
solution like this belongs in NetBSD.
As you noticed, this requires changes to other utilities in order to work.

beside ifconfig, I'm not sure.

Post by Darren Reed
If your project requires any changes to brconfig, netstat, ifconfig, ipf,
npf, tcpdump, etc, then you've got the wrong solution in hand. Each network
interface should have one name and one name only as far as userland is
concerned. If there are userland programs (aside from device management)

I'm not happy with the "one name and one name only".

Why aren't you happy?

Post by Manuel Bouyer
I think some use case
will want the name, some other will want the alias (and you may need both
at the same time).

Such as...?

I saw some people being unhappy with the idea of interface rename
("once you're renamed it to foobar you don't know anymore if it's a
wm(4) or a tap(4), or possibly a bridge(4)")

That's simply a matter of observability.
It would be a simple matter to use nicctl or drvctl or some
other tool to display a mapping between hardware devices and
network interface names.

Post by Manuel Bouyer
and I also like being
able to classify interfaces looking  at their name,

Right, you like being able to see the driver name.
See above for observability.

Post by Manuel Bouyer
But I also see a need to be able to refer to them using a different name.
But this is different from a rename.
I really think the feature we want is "alias", not "rename".

I'm not so sure.
A network interface name is an entity in the BSD kernel that
has a relationship with a list of addresses. Similarly those
addresses have a relationship with a single interface name.
That's a very simple model that doesn't allow for any
confusion or problems. There is a strict 1 to 1 relationship
between address and interface name.
Aliases break that.
Say I give fxp0 an alias of net0 and I then do
"ifconfig net0 1.2.3.4". Now if I do "ifconfig net0" that
IP address will show up as assigned to it. But if I do
"netstat -nrf inet", net0 is nowhere to be seen. Why?

You will get an error when doing an ifconfig net0, something like
ifconfig <keywork>:net0 should be used, to clearly differentiate
between real interfaces an aliases. So if you use the alias to
configure it you should be aware that it is an alias (or an
alternative name, since alias has other meaning in network
terminology).

Post by Darren Reed
Who wants to explain to users that NetBSD has two different
classes of network interface names that can be used, one of
which is real and one of which isn't real? Isn't it easier
to just have one?
Yes, aliases are easy to make work but I'm hard pressed to accept
that they have more upsides than downsides, not the least of which
is that they add more complexity to ifconfig and ifconfig's output.
But if enough people are convinced you need alias then go for it.
Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Jean-Yves Migeon

Post by Manuel Bouyer
I saw some people being unhappy with the idea of interface rename
("once you're renamed it to foobar you don't know anymore if it's a
wm(4) or a tap(4), or possibly a bridge(4)") and I also like being
able to classify interfaces looking at their name,
But I also see a need to be able to refer to them using a different name.
But this is different from a rename.
I really think the feature we want is "alias", not "rename".

In that case, I would avoid the use of "alias". ifconfig(8) uses it
already, but for another purpose.

Yes, the word alias is confusing. That's why I invended 'xalias' a previous
mail, by lack of a better word.

[Roger Pau Monné]

Post by Manuel Bouyer

Post by Jean-Yves Migeon
In that case, I would avoid the use of "alias". ifconfig(8) uses it
already, but for another purpose.

Yes, the word alias is confusing. That's why I invended 'xalias' a previous
mail, by lack of a better word.

altname (alternative name) sounds better?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Roger Pau Monné

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
No, this is not the right approach and I don't think that a short cut
solution like this belongs in NetBSD.
As you noticed, this requires changes to other utilities in order to work.

beside ifconfig, I'm not sure.

Post by Darren Reed
If your project requires any changes to brconfig, netstat, ifconfig, ipf,
npf, tcpdump, etc, then you've got the wrong solution in hand. Each network
interface should have one name and one name only as far as userland is
concerned. If there are userland programs (aside from device management)

I'm not happy with the "one name and one name only".

Why aren't you happy?

Post by Manuel Bouyer
I think some use case
will want the name, some other will want the alias (and you may need both
at the same time).

Such as...?

I saw some people being unhappy with the idea of interface rename
("once you're renamed it to foobar you don't know anymore if it's a
wm(4) or a tap(4), or possibly a bridge(4)")

That's simply a matter of observability.
It would be a simple matter to use nicctl or drvctl or some
other tool to display a mapping between hardware devices and
network interface names.

Post by Manuel Bouyer
and I also like being
able to classify interfaces looking at their name,

Right, you like being able to see the driver name.
See above for observability.

Post by Manuel Bouyer
But I also see a need to be able to refer to them using a different name.
But this is different from a rename.
I really think the feature we want is "alias", not "rename".

I'm not so sure.
A network interface name is an entity in the BSD kernel that
has a relationship with a list of addresses. Similarly those
addresses have a relationship with a single interface name.
That's a very simple model that doesn't allow for any
confusion or problems. There is a strict 1 to 1 relationship
between address and interface name.
Aliases break that.
Say I give fxp0 an alias of net0 and I then do
"ifconfig net0 1.2.3.4". Now if I do "ifconfig net0" that
IP address will show up as assigned to it. But if I do
"netstat -nrf inet", net0 is nowhere to be seen. Why?

You will get an error when doing an ifconfig net0, something like
ifconfig <keywork>:net0 should be used, to clearly differentiate
between real interfaces an aliases. So if you use the alias to
configure it you should be aware that it is an alias (or an
alternative name, since alias has other meaning in network
terminology).

If I can't use it with tools like ifconfig then what
is the point of having the alternative name at all?

A name that can be used "some of the time" isn't really
very useful and will create confusion with users.

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roger Pau Monné]

Post by Darren Reed

Post by Roger Pau Monné

Post by Darren Reed
Say I give fxp0 an alias of net0 and I then do
"ifconfig net0 1.2.3.4". Now if I do "ifconfig net0" that
IP address will show up as assigned to it. But if I do
"netstat -nrf inet", net0 is nowhere to be seen. Why?

You will get an error when doing an ifconfig net0, something like
ifconfig <keywork>:net0 should be used, to clearly differentiate
between real interfaces an aliases. So if you use the alias to
configure it you should be aware that it is an alias (or an
alternative name, since alias has other meaning in network
terminology).

If I can't use it with tools like ifconfig then what
is the point of having the alternative name at all?

You can use it with all the tools, but you need to know it's an
alternative name, so a keyword must be used to differentiate it from
physical interfaces. I think this prevents confusion, since there's a
clear difference between a real interface, and an "alias" or
"alternative name" of an interface.

Post by Darren Reed
A name that can be used "some of the time" isn't really
very useful and will create confusion with users.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Darren Reed

Post by Manuel Bouyer
it'll be longer anyway, because the point of aliases (beside fixing
xen problems) is to give meaningfull names. typing 'team-foo-dmz' will
always be longer than 'wm0'. prefixing it with keywork: isn't a big
deal.

So you want add a label to a network interface?
Sort of how we can label a disk?

It would be more like a GPT label than a plain disk label, but yes,
that's the idea. With the restriction that multiple interfaces can't have
the same label at the same time in a system. And I want to be able
to lookup interfaces by label instead of by name (BTW, I want to do this
with gpt partitions too, even if right now we can't do that).

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed

Post by Roger Pau Monne
While this is true if you give a name to the interface on the config
file, but how can the toolstack (xl, that launches Qemu) choose an
interface name and pass it to Qemu when no one is specified? Well,
we might be able to search for a free tap device and pass this as the
desired name, but this is a really racy solution, as someone else might
request a tap device while we are launching Qemu, and take our chosen
tap device behind our back, so we will end up failing to create that
domain.
Also, I don't think there's anyway to create vifs interfaces with a
specific name, which I think will also be an interesting feature to
have.

So in that second paragraph you've identified the real problem.

being able to tag an interface with a user-provided string, and
using this string instead of its name for various task. This is not
restricted to xen xvif or tap devices, I have other use cases too
(on a system with lots of interface, having a meaningfull string
for them would be helpfull). But I don't think remplacing the actual
interface name with a user-specified string is the way to go. This
user-specified string should add information, not replace existing
information.

I'm not sure that I follow what you're saying.
Can you please expand on that?

Right now, the unique identifier of an interface is its name, which is
set by the system when the interface is discovered. I don't think we should
change this part, because we are used to the names as they are now, and it
also carry some information (wm0 is an intel adapter, tap0 is a pseudo
interface, xvif5-0 is a Xen PV backend interface connected to the interface
of index 0 in the guest id 5, etc).
But sometimes we'd like to have more, user-defined information easily
available for interfaces, on systems with lots of interfaces.
example 1: xvif5-0 is connected to interface 0 of domU 5. But what is
domU 5 ? I have to use xm list to match the id against a domU's name.
example 2: I have a system with 2 quad-port intel. I know wm6 is
the third port of the second quad-port adapter, but what is it connected to ?

With xaliases (which could also be called label, this is probably the righ
name for that), users could add some informations to interfaces
(either by hand or by some script).
In example 1, the /usr/pkg/etc/xen/scripts/vif-bridge script could
label xvif5-0 with the domU's name followed by interface index in the domU
(say, if by domU's name is proxy, the label would be proxy0).
In example 2, /etc/ifconfig.wm5 could contains (this is just an example of
course):
label team-foo-vlan

Then, ifconfig would display the label as part of interface data,
which can give the information to the admin.

In addition, if we make sure labels are unique in a system, we
could refer to interfaces by label instead of by name (just like
I'd like to use a GPT label in fstab instead of /dev/dkX), we could
use labels in places where names are actually used. If we make the kernel
know that label:X in ifreq is interface's label X and not interface's
name label:X, modifications to network tools should be minimal.

For those who knows nothing aboud xen: a domU is a VM. When a VM is started,
for each network interface in the domU there is a corresponding interface
in the dom0 called xvif<x>-<y>, created when the VM is started and destroyed
when the VM is destroyed. A VM reboot is a destroy/create cycle, so
the domU's id change and a new xvif<x>-<y> is created, with a different x
each time. each time a xvif<x>-<y> is created or destroyed,
/usr/pkg/etc/xen/scripts/vif-bridge is called with parameters.
The domU's name is specified in the Xen VM config file,
/usr/pkg/etc/xen/scripts/vif-bridge has easy access to this information.
This is for PV domUs.
For HVM domUs, there is a a qemu process started for each domU which emulates
disks (a PIIX4 usually) and network controllers (this can be a few different
models, including ne2000 and e1000). just as with plain qemu,
for each emulated network device a tap device is created in the dom0, so
that qemu can do something usefull with data from the emulated device.
Up to now (with the old xm toolstack), qemu creates a tapn device and
calls a script to configure it (connect to a bridge usually).
With the new xl toolstack, the script is called by xl and not by qemu,
and xl has problems to know the name of the tap device created by qemu.

[Darren Reed]

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed

Post by Roger Pau Monne
While this is true if you give a name to the interface on the config
file, but how can the toolstack (xl, that launches Qemu) choose an
interface name and pass it to Qemu when no one is specified? Well,
we might be able to search for a free tap device and pass this as the
desired name, but this is a really racy solution, as someone else might
request a tap device while we are launching Qemu, and take our chosen
tap device behind our back, so we will end up failing to create that
domain.
Also, I don't think there's anyway to create vifs interfaces with a
specific name, which I think will also be an interesting feature to
have.

So in that second paragraph you've identified the real problem.

being able to tag an interface with a user-provided string, and
using this string instead of its name for various task. This is not
restricted to xen xvif or tap devices, I have other use cases too
(on a system with lots of interface, having a meaningfull string
for them would be helpfull). But I don't think remplacing the actual
interface name with a user-specified string is the way to go. This
user-specified string should add information, not replace existing
information.

I'm not sure that I follow what you're saying.
Can you please expand on that?

Right now, the unique identifier of an interface is its name, which is
set by the system when the interface is discovered. I don't think we should
change this part, because we are used to the names as they are now, and it
also carry some information (wm0 is an intel adapter, tap0 is a pseudo
interface, xvif5-0 is a Xen PV backend interface connected to the interface
of index 0 in the guest id 5, etc).

The naming of interfaces is dependent on the driver, not the user.

It currently conveys some information but the real information is
only available in the kernel probing output from when the system
boots.

Personally, I find the "tap" naming for pseudo interfaces obscure
because a "network tap" is traditionally something that is used for
sniffing and that's not NetBSD uses them for. But I digress.

The point here is that the driver based interface name conveys some
coded information that is meaningful to people that know which drivers
use which abbreviations and that's it. That is unless there is some
magical way in which random people equate "wm" with "Intel" (yes I know,
"man wm".) But note that the user or administrator never gets any choice
in whether it is "fxp0" or "wm0", it's decided by programmers that
write the drivers.

To me this screams out for better management of network interfaces.
Something that allows the strings output at bootup to be reported
via the CLI, perhaps including how it is attached (but maybe that
is going just a bit too far.)

Post by Manuel Bouyer
But sometimes we'd like to have more, user-defined information easily
available for interfaces, on systems with lots of interfaces.

Definitely.

Post by Manuel Bouyer
example 1: xvif5-0 is connected to interface 0 of domU 5. But what is
domU 5 ? I have to use xm list to match the id against a domU's name.
example 2: I have a system with 2 quad-port intel. I know wm6 is
the third port of the second quad-port adapter, but what is it connected to ?

There's two of issues here that we can address:
- why can't xvif5-0 be a more meaningful name?
- how do we get meaning out of the name"wm6"?

Post by Manuel Bouyer
With xaliases (which could also be called label, this is probably the righ
name for that), users could add some informations to interfaces
(either by hand or by some script).
In example 1, the /usr/pkg/etc/xen/scripts/vif-bridge script could
label xvif5-0 with the domU's name followed by interface index in the domU
(say, if by domU's name is proxy, the label would be proxy0).
In example 2, /etc/ifconfig.wm5 could contains (this is just an example of
label team-foo-vlan

Wouldn't it be better to dispense with the "xvif5-0" altogether
and just have "proxy0" as the interface name with nothing else?

Do I really need to know that proxy0 is a xvif5-0 when I do
check to see which IP addresses are associated with it, etc?
Do I even care?

The point here is that proxy0 might be xvif1-0 or xvif5-0,
depending on the order in which that domU is started relative
to the other domU's.

In the very least, the way in which network interfaces are created
for Xen is rather primitive as the creation of the domU should be
when the interface is dynamically created and named rather than
depend on a static naming approach.

Post by Manuel Bouyer
Then, ifconfig would display the label as part of interface data,
which can give the information to the admin.
In addition, if we make sure labels are unique in a system, we
could refer to interfaces by label instead of by name (just like
I'd like to use a GPT label in fstab instead of /dev/dkX), we could
use labels in places where names are actually used. If we make the kernel
know that label:X in ifreq is interface's label X and not interface's
name label:X, modifications to network tools should be minimal.

What you're depending on here is the fact that all of the
existing interface names are much shorter than IFNAMSIZ.
That plus the user string being short. The current value
of IFNAMSIZ is 16. So the above string...

team-foo-vlan:tap0

is already too long. So in addition to adding the label string
structure, increasing IF_NAMESIZE (probably double it) is also
required. That might bear some extra thinking about.

On top of that, you'll probably find various parsers will treat
the above string as not being an interface name as colons are
often used to separate parameters.

Another problem that I see with this is that "team-foo-vlan" is
redundant information. Knowing "tap0" is enough to uniquely
identify the network interface, so why would I want to also
use the label? Similarly, if I know that "team-foo-vlan" but
I can't remember which tap interface number, why should I need
to know it?

What this really points toward is we need to support being able
to rename "tap0" to "team-foo-vlan0" and for there to be some
way to identify what "team-foo-vlan0" is (for those that care.)
The means for doing that might also enable more information to
be displayed about things like "wm0" and "lo0" than are typically
easily available today.

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Darren Reed
Not really.
If the type of network interface card changes then the
configuration that specifies the label needs to be updated.

Yes.

Post by Darren Reed
The goal here is to have the system probe cards and assign
them a name that is independent of the card/driver. This
then allows the card to be changed with no action required
by the owner of the system to update the configuration.

And how is the name assigned ?

Post by Darren Reed
Linux's method associates names by driver type (eth0, eth1, etc).

Yes, and it's also associated with the hardware. On a system with a
add-on PCI ethernet called eth0, if you remplace it by another PCI ethernet
(even if it's the same model, as the name is actually attached to the
ethernet address) it'll be called eth1. You have to edit sysconfig files
to have it named eth0 again.

[Darren Reed]

Post by Manuel Bouyer

Post by Darren Reed
Not really.
If the type of network interface card changes then the
configuration that specifies the label needs to be updated.

Yes.

Post by Darren Reed
The goal here is to have the system probe cards and assign
them a name that is independent of the card/driver. This
then allows the card to be changed with no action required
by the owner of the system to update the configuration.

And how is the name assigned ?

You can do it any number of ways.

In the first, you might do it in the kernel, with autoconf.

Another is that you have an application or daemon that is
run when the system boots and applies either a rule or set
of already decided upon naming assignments, such that by
the time the system gets to single user mode, the interfaces
have already picked up their new name.

Another might involve writing device naming state into a
file that is opened and parsed by the kernel at boot.

Post by Manuel Bouyer

Post by Darren Reed
Linux's method associates names by driver type (eth0, eth1, etc).

Yes, and it's also associated with the hardware. On a system with a
add-on PCI ethernet called eth0, if you replace it by another PCI ethernet
(even if it's the same model, as the name is actually attached to the
ethernet address) it'll be called eth1. You have to edit sysconfig files
to have it named eth0 again.

That's an implementation issue.
Or possibly even a naming policy issue.

Solaris 11 doesn't suffer from that.

There's no reason why NetBSD would have to suffer like that.

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
Because it means nothing to the user.
It only means something to the kernel.

It depends of the user. It means something to me.

Yes, but you're a developer.
Not everyone is a developer.

Administrators can understand this too. Users usually don't deal with
interface names directly, they use some high-level tool.

Post by Darren Reed

Post by Manuel Bouyer
Can you give examples ?

For example, "lanscan" from HP-UX.
http://jreypo.wordpress.com/2010/02/09/playing-with-lanadmin-lanscan/

not sure how this would be usefull for me.

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
For example, I would love to see drivers and/or networking
populate a sysctl tree with information about each network
interface. Driver name, instance number, PHY and MII information
might be a good place to start?

I don't think sysctl is a good place for that; I suspect this information
is already available and drvctl can (partially) provide it. drvctl could
be improved for that.

drvctl is doing what it does.
If what you're saying is that more information should be exported
via properties, ok, but the tool to summarise it should be something
else and not drvctl. There's nothing to be gained by putting network
specific things into drvctl.
On the other hand, if you were going to add something to drvctl to
simply output the entire device tree, along with device names
(similar to Solaris's "prtconf"), that would kind of fit in with
drvctl's raison d'etre.

This was what I meant. I misunderstood what you would use sysctl for.
I still think sysctl is the wrong place for what you want, but
it could be part of ifconfig

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
I suppose where I'm coming from is why can't we have something
# ifconfig tap create name proxy0
... where rather creating "tap0" or tap15", the interface gets
created as "proxy0" and "tap" with a number is never seen.

But I want a easy way to know that proxy0 is a tap and not something
else. And we're back to something specific to cloning devices, where
a more general mechanism would be useful.

So on the one hand you want to create proxy0 or some other label
and for people to use that because it is more meaningful but on
the other hand, you don't like abstract names like that because
they don't tell you anything about the driver.

No, I didn't say that. I said that if we go with dynamic names instead of
labels, I want to have the driver name and instance number in ifconfig
output so I can find the information.

Post by Darren Reed
The only way you get that is by having the name be something
like "wm_proxy0" or something like that.
If I have to run a command, such as ifconfig, or something else
to get an understanding of what "proxy0" is then it doesn't matter
if "proxy0" is just a label for wm6 or wm6 renamed.

It's just a matter of what we want to provide as primary information:
proxy0 or wm6. As proxy0 could also be
some_very_long_name_because_there_s_lot_of_interfaces
then I think we should stay with wm6 as the primary information
(or output of things like netstat will be awfull).

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
Rinse and repeat for use with xvif.
Ultimately, doesn't the "xvif" part become just an implementation
detail of what's required to talk to the domU?

It is. But it's a user-visible detail.

Why does a user need to be aware of an implementation detail?
Or why does it need to remain exposed?

Because it's a network interface of the system and we don't have anything
better to display in network tools ?

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
# ifconfig tun0 create
The problem for scripts is that they need to handle errors in case of
tun0 being in use already. It might even be better to allow something
# ifconfig tun create
tun4
where the output of ifconfig is the name of the interface created.
This might be a worthwhile change independent of labels.

I see. It doens't apply to xvif because they're not created with
a userland tool.

So how are the xvif interfaces created?

When a new network backend appears in the domain's tree in the xenstore
(usually network backends are in domain0, but they could be in some
other domains - the Xen architecture allows that - so the interface
is not always created in the domain where xm create was run).

Post by Darren Reed
And why can't it benefit from more dynamic interface creation?

I'm not sure what you mean with "more dynamic"

Post by Darren Reed

Post by Manuel Bouyer
Why ? I can understand that some chars are troubesome in scripts,
but not all of them are.

Because for Un*x the name needs to fit in with applications that
expect a name that refers to a network interface following the
rather generic rule of "name" followed by "number".

By this rule the name can't be "team-foo-vlan". From there, it doesn't
matter much if the tool is not happy with a label prefix, it can't be
used anyway and the tool needs to be fixed.

[Benny Siegert]

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer
it'll be longer anyway, because the point of aliases (beside fixing
xen problems) is to give meaningfull names. typing 'team-foo-dmz' will
always be longer than 'wm0'. prefixing it with keywork: isn't a big
deal.

So you want add a label to a network interface?
Sort of how we can label a disk?

It would be more like a GPT label than a plain disk label, but yes,
that's the idea. With the restriction that multiple interfaces can't have
the same label at the same time in a system. And I want to be able
to lookup interfaces by label instead of by name (BTW, I want to do this
with gpt partitions too, even if right now we can't do that).

Thank you for the detailed explanation. I like the idea of a label, it makes a lot of sense.

--Benny.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Darren Reed

Post by Manuel Bouyer
Right now, the unique identifier of an interface is its name, which is
set by the system when the interface is discovered. I don't think we should
change this part, because we are used to the names as they are now, and it
also carry some information (wm0 is an intel adapter, tap0 is a pseudo
interface, xvif5-0 is a Xen PV backend interface connected to the interface
of index 0 in the guest id 5, etc).

The naming of interfaces is dependent on the driver, not the user.

Yes. I don't see this as a problem.

Post by Darren Reed
It currently conveys some information but the real information is
only available in the kernel probing output from when the system
boots.
Personally, I find the "tap" naming for pseudo interfaces obscure
because a "network tap" is traditionally something that is used for
sniffing and that's not NetBSD uses them for. But I digress.
The point here is that the driver based interface name conveys some
coded information that is meaningful to people that know which drivers
use which abbreviations and that's it. That is unless there is some
magical way in which random people equate "wm" with "Intel" (yes I know,
"man wm".) But note that the user or administrator never gets any choice
in whether it is "fxp0" or "wm0", it's decided by programmers that
write the drivers.

But precisely, 'man wm' is usefull, and a way to associate an interface
name with its driver name is a must have. Actually this is done with
the name. If we allow the name to change at runtime, there has to be
a way to find this information (other than "dmesg |grep name", precisely
because name can change).

Post by Darren Reed
To me this screams out for better management of network interfaces.
Something that allows the strings output at bootup to be reported
via the CLI, perhaps including how it is attached (but maybe that
is going just a bit too far.)

Post by Manuel Bouyer
But sometimes we'd like to have more, user-defined information easily
available for interfaces, on systems with lots of interfaces.

Definitely.

Post by Manuel Bouyer
example 1: xvif5-0 is connected to interface 0 of domU 5. But what is
domU 5 ? I have to use xm list to match the id against a domU's name.
example 2: I have a system with 2 quad-port intel. I know wm6 is
the third port of the second quad-port adapter, but what is it connected to ?

- why can't xvif5-0 be a more meaningful name?

Because the kernel (which creates the interface) doesn't have easy access to
this information.

Post by Darren Reed
- how do we get meaning out of the name"wm6"?

what we get is "this is the 6th instance of the wm driver". We need this
information too.

Post by Darren Reed

Post by Manuel Bouyer
With xaliases (which could also be called label, this is probably the righ
name for that), users could add some informations to interfaces
(either by hand or by some script).
In example 1, the /usr/pkg/etc/xen/scripts/vif-bridge script could
label xvif5-0 with the domU's name followed by interface index in the domU
(say, if by domU's name is proxy, the label would be proxy0).
In example 2, /etc/ifconfig.wm5 could contains (this is just an example of
label team-foo-vlan

Wouldn't it be better to dispense with the "xvif5-0" altogether
and just have "proxy0" as the interface name with nothing else?
Do I really need to know that proxy0 is a xvif5-0 when I do
check to see which IP addresses are associated with it, etc?
Do I even care?

I want to know it's a xvif, at last. Now, proxy0 could be the name and
xvif is another data in ifconfig's output, but this information is needed.
And (sadly) proxy0 can't be created with this name, it has to be changed
later by the configure script.

Post by Darren Reed
The point here is that proxy0 might be xvif1-0 or xvif5-0,
depending on the order in which that domU is started relative
to the other domU's.

Yes, of course. And if you reboot the domU, it'll be something else.
And, in kernel, you'll have a proxy0 with a different struct ifp.

Post by Darren Reed
In the very least, the way in which network interfaces are created
for Xen is rather primitive as the creation of the domU should be
when the interface is dynamically created and named rather than
depend on a static naming approach.

I don't understand what you mean here.

Post by Darren Reed

Post by Manuel Bouyer
Then, ifconfig would display the label as part of interface data,
which can give the information to the admin.
In addition, if we make sure labels are unique in a system, we
could refer to interfaces by label instead of by name (just like
I'd like to use a GPT label in fstab instead of /dev/dkX), we could
use labels in places where names are actually used. If we make the kernel
know that label:X in ifreq is interface's label X and not interface's
name label:X, modifications to network tools should be minimal.

What you're depending on here is the fact that all of the
existing interface names are much shorter than IFNAMSIZ.
That plus the user string being short. The current value
of IFNAMSIZ is 16. So the above string...
team-foo-vlan:tap0
is already too long. So in addition to adding the label string
structure, increasing IF_NAMESIZE (probably double it) is also
required. That might bear some extra thinking about.

You're right, 16 is not enough. But with the rename approach, it's not enough
either (plus, you probably want to keep short name for netstat and other
outputs, while the admin may want to use long name to describe what the
interface is).

Post by Darren Reed
On top of that, you'll probably find various parsers will treat
the above string as not being an interface name as colons are
often used to separate parameters.

another separator can be used (label,team-foo-vlan, or label/team-foo-vlan)

Post by Darren Reed
Another problem that I see with this is that "team-foo-vlan" is
redundant information. Knowing "tap0" is enough to uniquely
identify the network interface, so why would I want to also
use the label? Similarly, if I know that "team-foo-vlan" but
I can't remember which tap interface number, why should I need
to know it?

I think you're mixing both here. In my proposal we can refer to an
interface (reusing you example) as:
tap0
(this is the name) or
label:team-foo-vlan
(this uses the label - the prefix label: is there to instruct the parser
that we're using a label and not a name). You won't use
team-foo-vlan:tap0 because this is, indeed, useless.

Post by Darren Reed
What this really points toward is we need to support being able
to rename "tap0" to "team-foo-vlan0" and for there to be some
way to identify what "team-foo-vlan0" is (for those that care.)
The means for doing that might also enable more information to
be displayed about things like "wm0" and "lo0" than are typically
easily available today.

Yes, that may work too. But I fear some people will want to use a string
that is persistant (at last until the system is rebooted) to refer
to interface, not something that can be changed ...

[Gert Doering]

Hi,

a way to associate an interface name with its driver name is a must have.

I'm not sure I fully understand this argument. Why does the driver name
have to be visible in the name of the interface? I know that "all BSDs
have ever done it that way" - but then, you have it in the kernel boot
messages, for those who really need to know "ah, eth3 is wm, eth4 is em"...

As a sysadmin, I find it actually somewhat annoying that my interface
name changes if I happen to swap a broken network card vs. another one
with a different chip on it, instead of "the first ethernet interface"
reliably being "eth0".

(Of course the Linux way of just iterating eth<n> interfaces is not without
its own set of problems if the initialization sequence of drivers changes
for whatever reason)

gert

[Manuel Bouyer]

Post by Gert Doering
Hi,

a way to associate an interface name with its driver name is a must have.

I'm not sure I fully understand this argument. Why does the driver name
have to be visible in the name of the interface? I know that "all BSDs

I didn't say it has to be encoded in the name. I said there has to
be an easy way to associate an interface name with its driver.
This could be in ifconfig output, for example.

Post by Gert Doering
have ever done it that way" - but then, you have it in the kernel boot
messages, for those who really need to know "ah, eth3 is wm, eth4 is em"...
As a sysadmin, I find it actually somewhat annoying that my interface
name changes if I happen to swap a broken network card vs. another one

This is where label would help :)

Post by Gert Doering
with a different chip on it, instead of "the first ethernet interface"
reliably being "eth0".

The problem is that "the first" interface can change too.

[Darren Reed]

Post by Manuel Bouyer

Post by Gert Doering
Hi,

a way to associate an interface name with its driver name is a must have.

I'm not sure I fully understand this argument. Why does the driver name
have to be visible in the name of the interface? I know that "all BSDs

I didn't say it has to be encoded in the name. I said there has to
be an easy way to associate an interface name with its driver.
This could be in ifconfig output, for example.

Post by Gert Doering
have ever done it that way" - but then, you have it in the kernel boot
messages, for those who really need to know "ah, eth3 is wm, eth4 is em"...
As a sysadmin, I find it actually somewhat annoying that my interface
name changes if I happen to swap a broken network card vs. another one

This is where label would help :)

Not really.

If the type of network interface card changes then the
configuration that specifies the label needs to be updated.

The goal here is to have the system probe cards and assign
them a name that is independent of the card/driver. This
then allows the card to be changed with no action required
by the owner of the system to update the configuration.

Linux's method associates names by driver type (eth0, eth1, etc).
HP-UX uses a similar approach with "lan0", etc.
Solaris (from 11 onwards) uses a more neutral name with "net0"
being the first interface, "net1", etc.

None of the above use labels or create extra complications
in order to deliver user-friendly names,

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jean-Yves Migeon]

Post by Darren Reed
Linux's method associates names by driver type (eth0, eth1, etc).

It's more complicated than that. Nowadays it uses udev to generate
device names, each distros having their own set of rules. Persistence in
setups where the MAC address is randomly allocated (very frequent with
VPS) caused all sort of misconfiguration issues: rebooting the VM moved
eth0 to eth1/2/3, ... causing havoc in network scripts.

Post by Darren Reed
HP-UX uses a similar approach with "lan0", etc.
Solaris (from 11 onwards) uses a more neutral name with "net0"
being the first interface, "net1", etc.
None of the above use labels or create extra complications
in order to deliver user-friendly names,

There's a difference between user-friendly names and useful ones. The
situation described above is one that never happened in NetBSD because
autoconf created the interfaces in the same order they appeared in XenStore.

If we ever have to go down that route, NetBSD would have to make
autoconf machinery more dynamic and have a userland subsystem (maybe
like udev/devfs) react to locators, and name the devices accordingly. No
small feat, and even that has its own share of problems too.

[Darren Reed]

Post by Jean-Yves Migeon

Post by Darren Reed
Linux's method associates names by driver type (eth0, eth1, etc).

It's more complicated than that. Nowadays it uses udev to generate
device names, each distros having their own set of rules. Persistence in
setups where the MAC address is randomly allocated (very frequent with
VPS) caused all sort of misconfiguration issues: rebooting the VM moved
eth0 to eth1/2/3, ... causing havoc in network scripts.

I was unaware that Linux had this bug. I don't believe that
either HP-UX or Solaris 11 do.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jean-Yves Migeon]

Post by Darren Reed

Post by Jean-Yves Migeon

Post by Darren Reed
Linux's method associates names by driver type (eth0, eth1, etc).

It's more complicated than that. Nowadays it uses udev to generate
device names, each distros having their own set of rules. Persistence in
setups where the MAC address is randomly allocated (very frequent with
VPS) caused all sort of misconfiguration issues: rebooting the VM moved
eth0 to eth1/2/3, ... causing havoc in network scripts.

I was unaware that Linux had this bug. I don't believe that
either HP-UX or Solaris 11 do.

It's not a "bug" per see. It also uses hardware information to identify
interfaces, so when you have a random MAC, you get different IDs.

Sometimes it makes sense (you do not expect the MAC to change without
notice for real NICs), sometimes it does not (interfaces created
dynamically, like virtual NICS and taps...).

[Darren Reed]

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer
Right now, the unique identifier of an interface is its name, which is
set by the system when the interface is discovered. I don't think we should
change this part, because we are used to the names as they are now, and it
also carry some information (wm0 is an intel adapter, tap0 is a pseudo
interface, xvif5-0 is a Xen PV backend interface connected to the interface
of index 0 in the guest id 5, etc).

The naming of interfaces is dependent on the driver, not the user.

Yes. I don't see this as a problem.

Because it means nothing to the user.
It only means something to the kernel.

Post by Manuel Bouyer

Post by Darren Reed
The point here is that the driver based interface name conveys some
coded information that is meaningful to people that know which drivers
use which abbreviations and that's it. That is unless there is some
magical way in which random people equate "wm" with "Intel" (yes I know,
"man wm".) But note that the user or administrator never gets any choice
in whether it is "fxp0" or "wm0", it's decided by programmers that
write the drivers.

But precisely, 'man wm' is usefull, and a way to associate an interface
name with its driver name is a must have. Actually this is done with
the name. If we allow the name to change at runtime, there has to be
a way to find this information (other than "dmesg |grep name", precisely
because name can change).

Yes and I think that pursuing a way to find that information will
hopefully lead us to developing a tool that delivers more useful
information, not just that "lan0 is wm4".

Post by Manuel Bouyer

Post by Darren Reed
To me this screams out for better management of network interfaces.
Something that allows the strings output at bootup to be reported
via the CLI, perhaps including how it is attached (but maybe that
is going just a bit too far.)

Post by Manuel Bouyer
But sometimes we'd like to have more, user-defined information easily
available for interfaces, on systems with lots of interfaces.

Definitely.

Post by Manuel Bouyer
example 1: xvif5-0 is connected to interface 0 of domU 5. But what is
domU 5 ? I have to use xm list to match the id against a domU's name.
example 2: I have a system with 2 quad-port intel. I know wm6 is
the third port of the second quad-port adapter, but what is it connected to ?

- why can't xvif5-0 be a more meaningful name?

Because the kernel (which creates the interface) doesn't have easy access to
this information.

Yes, this is a fault with the interface cloning interfaces
and perhaps more generally, network interface naming on
NetBSD.

Post by Manuel Bouyer

Post by Darren Reed
- how do we get meaning out of the name"wm6"?

what we get is "this is the 6th instance of the wm driver".
We need this information too.

But that's not nearly as useful as you might think it is.

What's important is meaning as to what port and card/slot
the port is associated with.

For example, I would love to see drivers and/or networking
populate a sysctl tree with information about each network
interface. Driver name, instance number, PHY and MII information
might be a good place to start?

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer
With xaliases (which could also be called label, this is probably the righ
name for that), users could add some informations to interfaces
(either by hand or by some script).
In example 1, the /usr/pkg/etc/xen/scripts/vif-bridge script could
label xvif5-0 with the domU's name followed by interface index in the domU
(say, if by domU's name is proxy, the label would be proxy0).
In example 2, /etc/ifconfig.wm5 could contains (this is just an example of
label team-foo-vlan

Wouldn't it be better to dispense with the "xvif5-0" altogether
and just have "proxy0" as the interface name with nothing else?
Do I really need to know that proxy0 is a xvif5-0 when I do
check to see which IP addresses are associated with it, etc?
Do I even care?

I want to know it's a xvif, at last. Now, proxy0 could be the name and
xvif is another data in ifconfig's output, but this information is needed.
And (sadly) proxy0 can't be created with this name, it has to be changed
later by the configure script.

What can be done here with Xen and qemu to make it better?

I suppose where I'm coming from is why can't we have something
like this:

# ifconfig tap create name proxy0

... where rather creating "tap0" or tap15", the interface gets
created as "proxy0" and "tap" with a number is never seen.

Rinse and repeat for use with xvif.

Ultimately, doesn't the "xvif" part become just an implementation
detail of what's required to talk to the domU?

Post by Manuel Bouyer

Post by Darren Reed
In the very least, the way in which network interfaces are created
for Xen is rather primitive as the creation of the domU should be
when the interface is dynamically created and named rather than
depend on a static naming approach.

I don't understand what you mean here.

See above.

Cloned network interfaces can be created dynamically, which is great,
but unfortunately the entire name needs to be specified and be related
to the name of the driver, e.g.

# ifconfig tun0 create

The problem for scripts is that they need to handle errors in case of
tun0 being in use already. It might even be better to allow something
like this:

# ifconfig tun create
tun4

where the output of ifconfig is the name of the interface created.

This might be a worthwhile change independent of labels.

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer
Then, ifconfig would display the label as part of interface data,
which can give the information to the admin.
In addition, if we make sure labels are unique in a system, we
could refer to interfaces by label instead of by name (just like
I'd like to use a GPT label in fstab instead of /dev/dkX), we could
use labels in places where names are actually used. If we make the kernel
know that label:X in ifreq is interface's label X and not interface's
name label:X, modifications to network tools should be minimal.

What you're depending on here is the fact that all of the
existing interface names are much shorter than IFNAMSIZ.
That plus the user string being short. The current value
of IFNAMSIZ is 16. So the above string...
team-foo-vlan:tap0
is already too long. So in addition to adding the label string
structure, increasing IF_NAMESIZE (probably double it) is also
required. That might bear some extra thinking about.

You're right, 16 is not enough. But with the rename approach, it's not enough
either (plus, you probably want to keep short name for netstat and other
outputs, while the admin may want to use long name to describe what the
interface is).

Well, if I can name the interface with a custom string without the
need for the word label, then there is less pressure on the interface
name length. But if there is a desire for longer interface names such
as "new-project-vlan0", then change is required.

Post by Manuel Bouyer

Post by Darren Reed
On top of that, you'll probably find various parsers will treat
the above string as not being an interface name as colons are
often used to separate parameters.

another separator can be used (label,team-foo-vlan, or label/team-foo-vlan)

The name used for network interfaces should be limited to
[a-z], [A-Z], [0-9] and maybe "-" and/or "_".

Post by Manuel Bouyer
I think you're mixing both here. In my proposal we can refer to an
tap0
(this is the name) or
label:team-foo-vlan

I'm afraid that the alphabet that you want to use for network
interface names (when including the label prefix) is going to
be incompatible with what programs expect/allow.

Post by Manuel Bouyer

Post by Darren Reed
What this really points toward is we need to support being able
to rename "tap0" to "team-foo-vlan0" and for there to be some
way to identify what "team-foo-vlan0" is (for those that care.)
The means for doing that might also enable more information to
be displayed about things like "wm0" and "lo0" than are typically
easily available today.

Yes, that may work too. But I fear some people will want to use a string
that is persistant (at last until the system is rebooted) to refer
to interface, not something that can be changed ...

Well there should be nothing to force people to use meaningful names.

My perspective on this is that if NetBSD is going to support virtual
network stacks then it is likely those stacks will need to have their
own "lo0", even if it would normally be "lo1". When I approach it from
that perspective, NetBSD will need to support the name in the interface
list for the virtual network stack being different from the "physical"
network interface name. The more general solution for that problem
would seem to me to solve the problem you're trying to address with
a label.

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer
Right now, the unique identifier of an interface is its name, which is
set by the system when the interface is discovered. I don't think we should
change this part, because we are used to the names as they are now, and it
also carry some information (wm0 is an intel adapter, tap0 is a pseudo
interface, xvif5-0 is a Xen PV backend interface connected to the interface
of index 0 in the guest id 5, etc).

The naming of interfaces is dependent on the driver, not the user.

Yes. I don't see this as a problem.

Because it means nothing to the user.
It only means something to the kernel.

It depends of the user. It means something to me.

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
The point here is that the driver based interface name conveys some
coded information that is meaningful to people that know which drivers
use which abbreviations and that's it. That is unless there is some
magical way in which random people equate "wm" with "Intel" (yes I know,
"man wm".) But note that the user or administrator never gets any choice
in whether it is "fxp0" or "wm0", it's decided by programmers that
write the drivers.

But precisely, 'man wm' is usefull, and a way to associate an interface
name with its driver name is a must have. Actually this is done with
the name. If we allow the name to change at runtime, there has to be
a way to find this information (other than "dmesg |grep name", precisely
because name can change).

Yes and I think that pursuing a way to find that information will
hopefully lead us to developing a tool that delivers more useful
information, not just that "lan0 is wm4".

Can you give examples ?

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
To me this screams out for better management of network interfaces.
Something that allows the strings output at bootup to be reported
via the CLI, perhaps including how it is attached (but maybe that
is going just a bit too far.)

Post by Manuel Bouyer
But sometimes we'd like to have more, user-defined information easily
available for interfaces, on systems with lots of interfaces.

Definitely.

Post by Manuel Bouyer
example 1: xvif5-0 is connected to interface 0 of domU 5. But what is
domU 5 ? I have to use xm list to match the id against a domU's name.
example 2: I have a system with 2 quad-port intel. I know wm6 is
the third port of the second quad-port adapter, but what is it connected to ?

- why can't xvif5-0 be a more meaningful name?

Because the kernel (which creates the interface) doesn't have easy access to
this information.

Yes, this is a fault with the interface cloning interfaces
and perhaps more generally, network interface naming on
NetBSD.

No. In this specific case it's because of the way Xen works.
A xvif interface is created because an entry is written to the
xenstore for it. We have to work with the informations available in
the xenstore; when the entry for the xvif is written the guest's name
may not be availble yet. We have to live with that.
A cloning interface can create an interface with arbitrary name (there's
no limitation in the kernel other than the name lenght). The limitation
are
- what is available when the kernel creates the interface
- POLA (a user wouldn't expect a tap device to be named anything else
but tapX).

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
- how do we get meaning out of the name"wm6"?

what we get is "this is the 6th instance of the wm driver".
We need this information too.

But that's not nearly as useful as you might think it is.
What's important is meaning as to what port and card/slot
the port is associated with.
For example, I would love to see drivers and/or networking
populate a sysctl tree with information about each network
interface. Driver name, instance number, PHY and MII information
might be a good place to start?

I don't think sysctl is a good place for that; I suspect this information
is already available and drvctl can (partially) provide it. drvctl could
be improved for that.

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer
With xaliases (which could also be called label, this is probably the righ
name for that), users could add some informations to interfaces
(either by hand or by some script).
In example 1, the /usr/pkg/etc/xen/scripts/vif-bridge script could
label xvif5-0 with the domU's name followed by interface index in the domU
(say, if by domU's name is proxy, the label would be proxy0).
In example 2, /etc/ifconfig.wm5 could contains (this is just an example of
label team-foo-vlan

Wouldn't it be better to dispense with the "xvif5-0" altogether
and just have "proxy0" as the interface name with nothing else?
Do I really need to know that proxy0 is a xvif5-0 when I do
check to see which IP addresses are associated with it, etc?
Do I even care?

I want to know it's a xvif, at last. Now, proxy0 could be the name and
xvif is another data in ifconfig's output, but this information is needed.
And (sadly) proxy0 can't be created with this name, it has to be changed
later by the configure script.

What can be done here with Xen and qemu to make it better?

For qemu I don't know (maybe it already have what's needed).
For Xen, we'd have to check in which order informations are
written to the xenstore (for all xen versions we support).

Post by Darren Reed
I suppose where I'm coming from is why can't we have something
# ifconfig tap create name proxy0
... where rather creating "tap0" or tap15", the interface gets
created as "proxy0" and "tap" with a number is never seen.

But I want a easy way to know that proxy0 is a tap and not something
else. And we're back to something specific to cloning devices, where
a more general mechanism would be usefull.

Post by Darren Reed
Rinse and repeat for use with xvif.
Ultimately, doesn't the "xvif" part become just an implementation
detail of what's required to talk to the domU?

It is. But it's a user-visible detail.

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
In the very least, the way in which network interfaces are created
for Xen is rather primitive as the creation of the domU should be
when the interface is dynamically created and named rather than
depend on a static naming approach.

I don't understand what you mean here.

See above.
Cloned network interfaces can be created dynamically, which is great,
but unfortunately the entire name needs to be specified and be related
to the name of the driver, e.g.
# ifconfig tun0 create
The problem for scripts is that they need to handle errors in case of
tun0 being in use already. It might even be better to allow something
# ifconfig tun create
tun4
where the output of ifconfig is the name of the interface created.
This might be a worthwhile change independent of labels.

I see. It doens't apply to xvif because they're not created with
a userland tool.
I agree it would be usefull.

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer
Then, ifconfig would display the label as part of interface data,
which can give the information to the admin.
In addition, if we make sure labels are unique in a system, we
could refer to interfaces by label instead of by name (just like
I'd like to use a GPT label in fstab instead of /dev/dkX), we could
use labels in places where names are actually used. If we make the kernel
know that label:X in ifreq is interface's label X and not interface's
name label:X, modifications to network tools should be minimal.

What you're depending on here is the fact that all of the
existing interface names are much shorter than IFNAMSIZ.
That plus the user string being short. The current value
of IFNAMSIZ is 16. So the above string...
team-foo-vlan:tap0
is already too long. So in addition to adding the label string
structure, increasing IF_NAMESIZE (probably double it) is also
required. That might bear some extra thinking about.

You're right, 16 is not enough. But with the rename approach, it's not enough
either (plus, you probably want to keep short name for netstat and other
outputs, while the admin may want to use long name to describe what the
interface is).

Well, if I can name the interface with a custom string without the
need for the word label, then there is less pressure on the interface
name length. But if there is a desire for longer interface names such
as "new-project-vlan0", then change is required.

I think there is a need for longuer label, yes. With lots of interface,
16 characters won't be enough to give meaningfull label to all of them.
I looked at the vlan descriptions at work, more than half of them have
description (in the cisco world) longer than 16 chars.

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
On top of that, you'll probably find various parsers will treat
the above string as not being an interface name as colons are
often used to separate parameters.

another separator can be used (label,team-foo-vlan, or label/team-foo-vlan)

The name used for network interfaces should be limited to
[a-z], [A-Z], [0-9] and maybe "-" and/or "_".

Why ? I can understand that some chars are troubesome in scripts,
but not all of them are.

Post by Darren Reed

Post by Manuel Bouyer
I think you're mixing both here. In my proposal we can refer to an
tap0
(this is the name) or
label:team-foo-vlan

I'm afraid that the alphabet that you want to use for network
interface names (when including the label prefix) is going to
be incompatible with what programs expect/allow.

This has to be explored I guess

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
What this really points toward is we need to support being able
to rename "tap0" to "team-foo-vlan0" and for there to be some
way to identify what "team-foo-vlan0" is (for those that care.)
The means for doing that might also enable more information to
be displayed about things like "wm0" and "lo0" than are typically
easily available today.

Yes, that may work too. But I fear some people will want to use a string
that is persistant (at last until the system is rebooted) to refer
to interface, not something that can be changed ...

Well there should be nothing to force people to use meaningful names.
My perspective on this is that if NetBSD is going to support virtual
network stacks then it is likely those stacks will need to have their
own "lo0", even if it would normally be "lo1". When I approach it from
that perspective, NetBSD will need to support the name in the interface
list for the virtual network stack being different from the "physical"
network interface name. The more general solution for that problem
would seem to me to solve the problem you're trying to address with
a label.

For this is looks like you want unique interface name in a name domain,
but not accross domains. It looks like a different problem and I'm not
sure how your "more general solution" would fix this

[Iain Hibbert]

Post by Manuel Bouyer

Post by Darren Reed
So you want add a label to a network interface?
Sort of how we can label a disk?

It would be more like a GPT label than a plain disk label, but yes,
that's the idea.

I do support this concept, and I don't see really why this 'label' cannot
be integrated further into the drivers, eg 802.11 interfaces have a SSID
that is visible externally, the label can be used for that directly. It is
similar a bit to Bluetooth controllers, which have an externally visible
name (currently this cannot be used by tools to select the device, but I
would like to make it so)

Post by Manuel Bouyer
With the restriction that multiple interfaces can't have the same label
at the same time in a system.

but I don't see why such a restriction should be required. It may be
useful for something, and if the admin wants to label network interfaces
the same, that is their perogative.. the driver name is still a unique
identifier.

regards,
iain

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Edgar Fuß]

Post by Manuel Bouyer
what we get is "this is the 6th instance of the wm driver".
We need this information too.

I don't know whether it's a reasonable idea, but what came to my mind was
doing it the other way round than giving an interface a label: Let the user
specify the name of the interface but add something like "driver" and
"instance" to the information presented by ifconfig. Plus a syntax to
specify an interface by the unique driver/instance pair.
Does this make sense?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer
Right now, the unique identifier of an interface is its name, which is
set by the system when the interface is discovered. I don't think we should
change this part, because we are used to the names as they are now, and it
also carry some information (wm0 is an intel adapter, tap0 is a pseudo
interface, xvif5-0 is a Xen PV backend interface connected to the interface
of index 0 in the guest id 5, etc).

The naming of interfaces is dependent on the driver, not the user.

Yes. I don't see this as a problem.

Because it means nothing to the user.
It only means something to the kernel.

It depends of the user. It means something to me.

Yes, but you're a developer.
Not everyone is a developer.

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
The point here is that the driver based interface name conveys some
coded information that is meaningful to people that know which drivers
use which abbreviations and that's it. That is unless there is some
magical way in which random people equate "wm" with "Intel" (yes I know,
"man wm".) But note that the user or administrator never gets any choice
in whether it is "fxp0" or "wm0", it's decided by programmers that
write the drivers.

But precisely, 'man wm' is usefull, and a way to associate an interface
name with its driver name is a must have. Actually this is done with
the name. If we allow the name to change at runtime, there has to be
a way to find this information (other than "dmesg |grep name", precisely
because name can change).

Yes and I think that pursuing a way to find that information will
hopefully lead us to developing a tool that delivers more useful
information, not just that "lan0 is wm4".

Can you give examples ?

For example, "lanscan" from HP-UX.

A good example of its output is here:
http://jreypo.wordpress.com/2010/02/09/playing-with-lanadmin-lanscan/

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
To me this screams out for better management of network interfaces.
Something that allows the strings output at bootup to be reported
via the CLI, perhaps including how it is attached (but maybe that
is going just a bit too far.)

Post by Manuel Bouyer
But sometimes we'd like to have more, user-defined information easily
available for interfaces, on systems with lots of interfaces.

Definitely.

Post by Manuel Bouyer
example 1: xvif5-0 is connected to interface 0 of domU 5. But what is
domU 5 ? I have to use xm list to match the id against a domU's name.
example 2: I have a system with 2 quad-port intel. I know wm6 is
the third port of the second quad-port adapter, but what is it connected to ?

- why can't xvif5-0 be a more meaningful name?

Because the kernel (which creates the interface) doesn't have easy access to
this information.

Yes, this is a fault with the interface cloning interfaces
and perhaps more generally, network interface naming on
NetBSD.

No. In this specific case it's because of the way Xen works.
A xvif interface is created because an entry is written to the
xenstore for it. We have to work with the informations available in
the xenstore; when the entry for the xvif is written the guest's name
may not be availble yet. We have to live with that.

I see.

Post by Manuel Bouyer

Post by Darren Reed
For example, I would love to see drivers and/or networking
populate a sysctl tree with information about each network
interface. Driver name, instance number, PHY and MII information
might be a good place to start?

I don't think sysctl is a good place for that; I suspect this information
is already available and drvctl can (partially) provide it. drvctl could
be improved for that.

drvctl is doing what it does.

If what you're saying is that more information should be exported
via properties, ok, but the tool to summarise it should be something
else and not drvctl. There's nothing to be gained by putting network
specific things into drvctl.

On the other hand, if you were going to add something to drvctl to
simply output the entire device tree, along with device names
(similar to Solaris's "prtconf"), that would kind of fit in with
drvctl's raison d'etre.

Post by Manuel Bouyer

Post by Darren Reed
I suppose where I'm coming from is why can't we have something
# ifconfig tap create name proxy0
... where rather creating "tap0" or tap15", the interface gets
created as "proxy0" and "tap" with a number is never seen.

But I want a easy way to know that proxy0 is a tap and not something
else. And we're back to something specific to cloning devices, where
a more general mechanism would be useful.

So on the one hand you want to create proxy0 or some other label
and for people to use that because it is more meaningful but on
the other hand, you don't like abstract names like that because
they don't tell you anything about the driver.

The only way you get that is by having the name be something
like "wm_proxy0" or something like that.

If I have to run a command, such as ifconfig, or something else
to get an understanding of what "proxy0" is then it doesn't matter
if "proxy0" is just a label for wm6 or wm6 renamed.

Post by Manuel Bouyer

Post by Darren Reed
Rinse and repeat for use with xvif.
Ultimately, doesn't the "xvif" part become just an implementation
detail of what's required to talk to the domU?

It is. But it's a user-visible detail.

Why does a user need to be aware of an implementation detail?
Or why does it need to remain exposed?

Post by Manuel Bouyer

Post by Darren Reed
# ifconfig tun0 create
The problem for scripts is that they need to handle errors in case of
tun0 being in use already. It might even be better to allow something
# ifconfig tun create
tun4
where the output of ifconfig is the name of the interface created.
This might be a worthwhile change independent of labels.

I see. It doens't apply to xvif because they're not created with
a userland tool.

So how are the xvif interfaces created?

And why can't it benefit from more dynamic interface creation?

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed
On top of that, you'll probably find various parsers will treat
the above string as not being an interface name as colons are
often used to separate parameters.

another separator can be used (label,team-foo-vlan, or label/team-foo-vlan)

The name used for network interfaces should be limited to
[a-z], [A-Z], [0-9] and maybe "-" and/or "_".

Why ? I can understand that some chars are troubesome in scripts,
but not all of them are.

Because for Un*x the name needs to fit in with applications that
expect a name that refers to a network interface following the
rather generic rule of "name" followed by "number".

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Darren Reed

Post by Roger Pau Monné
ifconfig <keywork>:net0 should be used, to clearly differentiate
between real interfaces an aliases. So if you use the alias to
configure it you should be aware that it is an alias (or an
alternative name, since alias has other meaning in network
terminology).

If I can't use it with tools like ifconfig then what
is the point of having the alternative name at all?

You can use it with ifconfig, or any other tool. Just use
'<keywork>:net0' instead of 'net0' as the name.

Post by Darren Reed
A name that can be used "some of the time" isn't really
very useful and will create confusion with users.

As long as the user created the alias, he should know it's an alias.

[Darren Reed]

Post by Roger Pau Monné

Post by Darren Reed

Post by Roger Pau Monné

Post by Darren Reed
Say I give fxp0 an alias of net0 and I then do
"ifconfig net0 1.2.3.4". Now if I do "ifconfig net0" that
IP address will show up as assigned to it. But if I do
"netstat -nrf inet", net0 is nowhere to be seen. Why?

You will get an error when doing an ifconfig net0, something like
ifconfig <keywork>:net0 should be used, to clearly differentiate
between real interfaces an aliases. So if you use the alias to
configure it you should be aware that it is an alias (or an
alternative name, since alias has other meaning in network
terminology).

If I can't use it with tools like ifconfig then what
is the point of having the alternative name at all?

You can use it with all the tools, but you need to know it's an
alternative name, so a keyword must be used to differentiate it from
physical interfaces. I think this prevents confusion, since there's a
clear difference between a real interface, and an "alias" or
"alternative name" of an interface.

Sorry, you have completely failed to convince me of this idea
because you're introducing more complexity for very questionable
benefit.

Post by Roger Pau Monné
You can use it with ifconfig, or any other tool. Just use
'<keywork>:net0' instead of 'net0' as the name.

Why would I want to ever use the altname when it just makes
the command string for ifconfig longer?

On 21/06/2012 7:43 PM, Martin Husemann wrote:
...

Post by Roger Pau Monné
It sounds to me like xen would have a config file to fire up the domU,
and there could be an entry saying "this domU will use tap14".

And the domU never sees "tap#".

Post by Roger Pau Monné
While this is true if you give a name to the interface on the config
file, but how can the toolstack (xl, that launches Qemu) choose an
interface name and pass it to Qemu when no one is specified? Well,
we might be able to search for a free tap device and pass this as the
desired name, but this is a really racy solution, as someone else might
request a tap device while we are launching Qemu, and take our chosen
tap device behind our back, so we will end up failing to create that
domain.
Also, I don't think there's anyway to create vifs interfaces with a
specific name, which I think will also be an interesting feature to
have.

So in that second paragraph you've identified the real problem.
Solving that doesn't require altname or aliases. Further, using
altnames or aliases doesn't solve the race conditions that you
mention in the first paragraph.

Another question - is there some reason why the name can't be created
in a more dynamic fashion and the name of the created device used as
part of the configuration rather than requiring the name to be a
static part of the configuration? Regardless of device name aliases,
etc, this seems to be the better way to approach the problem from a
perspective of having a network interface name made available that
does not conflict with any existing names.

On 21/06/2012 8:17 PM, Martin Husemann wrote:
...

Post by Roger Pau Monné
Note that I am not objecting to fix the more general problem of
creating aliases or rename support. However, of everything I saw
discussed so far, only the FreeBSD variant has (a) clearly defined
semantics and (b) is very simple to implement. It is so simple, it
wouldn't hurt as a stopgap/intermediate solution.
Everything else, at least from my understanding, needs *a lot* more
thought and design work - which does not mean it is the wrong way to
go in the long term.

I'd rather see time spent on implementing something that will be kept
around for the long term rather than to see time and effort wasted on
code that is for a feature that is regarded as "stop gap" and will be
thrown away.

As well as developer time, it is also harmful for users as they have
to eventually unlearn this stop-gap thing.

There's also the chance that whoever does the work to do it right will
have to create a solution that is more complex in order to be compatible
with this stop gap thing because that has become an established interface.

And of course if the stop-gap gets accepted there there is less
motivation to fix the problem properly because the aggravation is gone.

Do it right and do it once.

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Darren Reed
[...]

Post by Manuel Bouyer
You can use it with ifconfig, or any other tool. Just use
'<keywork>:net0' instead of 'net0' as the name.

Why would I want to ever use the altname when it just makes
the command string for ifconfig longer?

it'll be longer anyway, because the point of aliases (beside fixing
xen problems) is to give meaningfull names. typing 'team-foo-dmz' will
always be longer than 'wm0'. prefixing it with keywork: isn't a big
deal.

Post by Darren Reed
...

Post by Manuel Bouyer
It sounds to me like xen would have a config file to fire up the domU,
and there could be an entry saying "this domU will use tap14".

And the domU never sees "tap#".

No, of course. the problem is in dom0.

Post by Darren Reed

Post by Manuel Bouyer
While this is true if you give a name to the interface on the config
file, but how can the toolstack (xl, that launches Qemu) choose an
interface name and pass it to Qemu when no one is specified? Well,
we might be able to search for a free tap device and pass this as the
desired name, but this is a really racy solution, as someone else might
request a tap device while we are launching Qemu, and take our chosen
tap device behind our back, so we will end up failing to create that
domain.
Also, I don't think there's anyway to create vifs interfaces with a
specific name, which I think will also be an interesting feature to
have.

So in that second paragraph you've identified the real problem.

I dissagree that this is the real problem. There is a desired feature:
being able to tag an interface with a user-provided string, and
using this string instead of its name for various task. This is not
restricted to xen xvif or tap devices, I have other use cases too
(on a system with lots of interface, having a meaningfull string
for them would be helpfull). But I don't think remplacing the actual
interface name with a user-specified string is the way to go. This
user-specified string should add information, not replace existing
information.

Post by Darren Reed
[...]
...

Post by Manuel Bouyer
Note that I am not objecting to fix the more general problem of
creating aliases or rename support. However, of everything I saw
discussed so far, only the FreeBSD variant has (a) clearly defined
semantics and (b) is very simple to implement. It is so simple, it
wouldn't hurt as a stopgap/intermediate solution.
Everything else, at least from my understanding, needs *a lot* more
thought and design work - which does not mean it is the wrong way to
go in the long term.

I'd rather see time spent on implementing something that will be kept
around for the long term rather than to see time and effort wasted on
code that is for a feature that is regarded as "stop gap" and will be
thrown away.

Seconded.

[Darren Reed]

Post by Manuel Bouyer

Post by Darren Reed
[...]

Post by Manuel Bouyer
You can use it with ifconfig, or any other tool. Just use
'<keywork>:net0' instead of 'net0' as the name.

Why would I want to ever use the altname when it just makes
the command string for ifconfig longer?

it'll be longer anyway, because the point of aliases (beside fixing
xen problems) is to give meaningfull names. typing 'team-foo-dmz' will
always be longer than 'wm0'. prefixing it with keywork: isn't a big
deal.

So you want add a label to a network interface?

Sort of how we can label a disk?

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer
While this is true if you give a name to the interface on the config
file, but how can the toolstack (xl, that launches Qemu) choose an
interface name and pass it to Qemu when no one is specified? Well,
we might be able to search for a free tap device and pass this as the
desired name, but this is a really racy solution, as someone else might
request a tap device while we are launching Qemu, and take our chosen
tap device behind our back, so we will end up failing to create that
domain.
Also, I don't think there's anyway to create vifs interfaces with a
specific name, which I think will also be an interesting feature to
have.

So in that second paragraph you've identified the real problem.

being able to tag an interface with a user-provided string, and
using this string instead of its name for various task. This is not
restricted to xen xvif or tap devices, I have other use cases too
(on a system with lots of interface, having a meaningfull string
for them would be helpfull). But I don't think remplacing the actual
interface name with a user-specified string is the way to go. This
user-specified string should add information, not replace existing
information.

I'm not sure that I follow what you're saying.

Can you please expand on that?

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Manuel Bouyer

Post by David Young

Post by Darren Reed

Post by Roger Pau Monne
I would like to add this functionality to the kernel, but can someone
provide a little bit more of technical information/steps about how to do it?

The first issue that you face that for all intents and purposes, you
cannot change "struct ifnet" because it is in too many places and
change will likely have a huge waterfall effect. So that can't be
changed.
What can be changed is where "struct ifnet" gets its name from.
For network interfaces, what's required here is another data
structure that connects a "struct ifnet" with the device itself.
This structure needs to remain an internal implementation detail
and any interfacing to it via ioctls should be done via proplists.
A new CLI tool is required to manage this interface, maybe call
it nicctl. For now, all that it would do is display what NICs are
present in the system, their device name, instance number and the
name to be used in "struct ifnet".
This CLI tool also needs to be able to add and remove device name
mappings. So, for example, it needs to let me assign the name
"fxp0" to "fxp,3" or some such. This naming information also needs
to be stored in a file somewhere so that when the system boots,
it can use that information to instruct the kernel. Obviously this
needs to be invoked early in rc, i.e. before ifconfig is used to
set the interface IP addresses. What format that file takes is up
to the person doing the implementation. It could be straight text,
maybe it is XML. Whatever.

I think that basically I agree with Darren. You need a driver
entity (some softc-having thing) and a logical network entity (an
ifnet-having thing) and some correspondence between them that is
set by properties of the driver such as MAC, serial number, its PCI
bus/device/function number. The driver entity has a name written
in NetBSDese (e.g., wmhw0), the logical entity takes either a
default name (e.g., wm0) or the name supplied by the operator (e.g.,
lan19 or wan0 or customer7).
I believe that NetBSD should use autoconf(9) to create the
correspondence. Extend drvctl (or *something*) to let us load/unload
new device->driver correspondences. I've written more about this at
<http://mail-index.netbsd.org/tech-net/2011/05/11/msg002614.html>.
Provide a convenience utility, nicctl, to set up the correspondences for
network interfaces specifically.
I believe that NetBSD should treat disks the same way: split them into
hardware entity and logical disk, set up correspondences between them
using properties of the disk (model, capacity, serial number, whatever)
and/or properties of its partitions (GUID, offset, size, human-readable
name). If we look at them a bit askew, wedges are a step in that
direction. Let the logical disks take a default name (dk0) or else the
operator's name if there is one (backup0).
I think that if you rearrange things in this way, a number of problems
in the kernel shake out. For example, power-management for NICs gets
less hairy. Interesting opportunities come up if you let a logical
driver's device_t (and probably its softc, too) hang around even if
its underlying hardware has disappeared: in that way, the logical
name for a hardware device will persist for at least as long as the
system is up, and the kernel has in the logical driver a place to hang
network configuration or unwritten disk buffers in the event of an
accidental/emergency device detachment.

I like the idea, but I think we don't want to restrict this to
disk and network device. I can't see why you'd want it for low-level
devices (like e.g. ahcisata or atabus or uhci), but I definitively want it
for anything that is exposted (as a device) to userland (disk, network if,
serial ports, kbd/mouse and other hid, video, printers, ...).

I hadn't thought about using it for disk, but if you do .. hmmm ..

This should probably be listed under the "Virtualisation Projects"
for NetBSD as device renaming would go a long way to enabling various
devices to be renamed upon export into a chroot/jails-like environment.

Post by Manuel Bouyer
This is a big project ...

Yes... and it might be a project where you start in one small area,
such as networking, and try to get that right before trying to fix
everything.

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jean-Yves Migeon]

Post by Martin Husemann

Post by Jean-Yves Migeon
This needs some thought regarding the cleanliness of the API, but I
would do it through properties, just for reusability (instead of rolling
out your own API).

I disagree - wether there should be an api to set interface names to arbitrary
strings, or give interface names an arbitrary alias, or have a mapping layer
that refers via arbitrary names to network devices, is completely orthogonal
to the issue at hand. This needs *a lot* more design work.

It is not completely orthogonal. The problem is passing data back between:
- a process that creates a tap and which is the only one able to know
its real name (Qemu),
- tools that will use the tap's name to attach to something like a
bridge, but cannot know it in advance before Qemu creates it.

So we need an API/subsystem that somehow allows passing this tiny bit of
information between these two. Properties is one, adding an extra member
to ifnet is another one too.

Post by Martin Husemann
However, there already is a perfectly working api to create tap interfaces
at will with a consistent number: ioctl(SIOCIFCREATE,...) and then open
the corresponding /dev/tapN. There is no need to fork ifconfig or anything
fancy.
Xen should just use this and create reliable/persistent mappings of
domUs to tapNs.

"Xen" is not really concerned by this problem, only the xl toolstack and
Qemu are.

Speaking of which, another way of passing/storing this sort of data is
Xenstore. However, the script approach makes it hard to manage errors,
so it would have to be done "natively" inside Qemu.

BTW, what is the problem with symlinks like Mouse suggested? Pass down
the /dev/tap-foobar to Qemu, use SIOCIFCREATE and if successful, symlink
/dev/tap-foobar to /dev/tapN from Qemu? This avoids playing with ifnet
and kernel.

That would not be the first time symlinks are used for this, LVM comes
to mind.

[Sverre Froyen]

Post by Manuel Bouyer

Post by Roger Pau Monne

Post by Martin Husemann

Post by Roger Pau Monne
Then we end up with the same problem, since xl needs to know the name
of the created device (to launch the appropriate hotplug scripts), and
there's not way to fetch that from Qemu.

I thought I saw command line options to invoke qemu that pass the tap
ifname, or even open a fd and just pass the number?
qemu -net tap,ifname=tap14
or
qemu -net tap,fd=4
and you could pass the name to the script vie environment vars.

As I said on a previous email, how can you guarantee that the name
you chose and pass to Qemu will not be taken by someone else while
you are calling Qemu?
You might even be launching several guests at the same time, which
will lead you to a race.

- xl opens /dev/tap, which creates the tap device (so xl knows the name)
and a file descriptor (which I'll call n)
- fork and exec qemu with: -net tap,vlan=0,fd=n
- the xl parent process closes n.
in this setup, qemu reuses the already-existing tape device and doesn't
create a new one, so no race condition possible here.
This should fix the problem.

Could you not specify the ethernet address, pass it to qemu and use it to
identify the interface? In other words, use the ethernet address as an
interface alias/label.

Apologies if this has already been suggested and rejected.

Regards,
Sverre

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Sverre Froyen
Could you not specify the ethernet address, pass it to qemu and use it to
identify the interface? In other words, use the ethernet address as an
interface alias/label.

The ethernet address is not guaranteed to be unique.

[Sverre Froyen]

Post by Manuel Bouyer

Post by Sverre Froyen
Could you not specify the ethernet address, pass it to qemu and use it to
identify the interface? In other words, use the ethernet address as an
interface alias/label.

The ethernet address is not guaranteed to be unique.

But you can *choose* to make them unique, can you not? Seems to me this is
just like any other label.

In some ways it surprises me that the label issue first(?) comes up for
network interfaces, since these already have multiple "labels": ethernet
address, IP address, etc. I have had more trouble identifying disk and com
devices that show up at random places.

Regards,
Sverre

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Sverre Froyen

Post by Manuel Bouyer
The ethernet address is not guaranteed to be unique.

But you can *choose* to make them unique, can you not? Seems to me this is
just like any other label.

No, see vlan(4) for example.

[Roger Pau Monné]

On Wed, Jun 20, 2012 at 9:59 PM, Jean-Yves Migeon

Post by Jean-Yves Migeon

Post by Martin Husemann

Post by Jean-Yves Migeon
This needs some thought regarding the cleanliness of the API, but I
would do it through properties, just for reusability (instead of rolling
out your own API).

I disagree - wether there should be an api to set interface names to arbitrary
strings, or give interface names an arbitrary alias, or have a mapping layer
that refers via arbitrary names to network devices, is completely orthogonal
to the issue at hand. This needs *a lot* more design work.

- a process that creates a tap and which is the only one able to know
its real name (Qemu),
- tools that will use the tap's name to attach to something like a
bridge, but cannot know it in advance before Qemu creates it.
So we need an API/subsystem that somehow allows passing this tiny bit of
information between these two. Properties is one, adding an extra member
to ifnet is another one too.

Post by Martin Husemann
However, there already is a perfectly working api to create tap interfaces
at will with a consistent number: ioctl(SIOCIFCREATE,...) and then open
the corresponding /dev/tapN. There is no need to fork ifconfig or anything
fancy.
Xen should just use this and create reliable/persistent mappings of
domUs to tapNs.

"Xen" is not really concerned by this problem, only the xl toolstack and
Qemu are.
Speaking of which, another way of passing/storing this sort of data is
Xenstore. However, the script approach makes it hard to manage errors,
so it would have to be done "natively" inside Qemu.
BTW, what is the problem with symlinks like Mouse suggested? Pass down
the /dev/tap-foobar to Qemu, use SIOCIFCREATE and if successful, symlink
/dev/tap-foobar to /dev/tapN from Qemu? This avoids playing with ifnet
and kernel.

But then when the hotplug script tries to do a `brconfig bridge0 add
tap-foobar` it will fail.

Also, as someone already suggested it will be interesting to be able
to give interfaces associated with guests a permanent name, which this
approach doesn't solve. The solution should be at least applicable to
both tap and vif interfaces, but since we are there, why not make it
work for all network interfaces? I think other users might benefit
from this feature (like not having to rewrite firewall rules when
changing network cards).

Post by Jean-Yves Migeon
That would not be the first time symlinks are used for this, LVM comes
to mind.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jean-Yves Migeon]

Post by Roger Pau Monné

Post by Jean-Yves Migeon
BTW, what is the problem with symlinks like Mouse suggested? Pass down
the /dev/tap-foobar to Qemu, use SIOCIFCREATE and if successful, symlink
/dev/tap-foobar to /dev/tapN from Qemu? This avoids playing with ifnet
and kernel.

But then when the hotplug script tries to do a `brconfig bridge0 add
tap-foobar` it will fail.

Fair point. Do a readlink + basename first :o

Yeah, everything is a file... except interfaces.

Post by Roger Pau Monné
Also, as someone already suggested it will be interesting to be able
to give interfaces associated with guests a permanent name, which this
approach doesn't solve. The solution should be at least applicable to
both tap and vif interfaces, but since we are there, why not make it
work for all network interfaces? I think other users might benefit
from this feature (like not having to rewrite firewall rules when
changing network cards).

IMHO this is not the right place to fix this. First, most firewalls out
there support variables, like macros in pf.conf. IMHO adding more
complexity to kernel for this is questionable.

Instead of renaming your interface inside the config files, you alias it
in kernel. Which is anyway a dubious construct because it will not
survive a reboot... except if you edit a config file that sets up this
aliasing for you. Ewww. Back to square one.

[Roger Pau Monné]

On Wed, Jun 20, 2012 at 11:00 PM, Jean-Yves Migeon

Post by Jean-Yves Migeon
IMHO this is not the right place to fix this. First, most firewalls out
there support variables, like macros in pf.conf. IMHO adding more
complexity to kernel for this is questionable.

Well this might be ok with firewalls, but it's not applicable to guest
interfaces, there's still the problem with persistent interfaces for
DomUs, which this doesn't solve.

Post by Jean-Yves Migeon
Instead of renaming your interface inside the config files, you alias it
in kernel. Which is anyway a dubious construct because it will not
survive a reboot... except if you edit a config file that sets up this
aliasing for you. Ewww. Back to square one.

I don't think it will be so difficult/awkward to create an init config
file, like the ones that already exist for bridged/vlan interfaces,
that would set up the alternative name at boot time like
<ifconfig.altname.foo> or even <ifconfig.foo>.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Roger Pau Monne
While this is true if you give a name to the interface on the config
file, but how can the toolstack (xl, that launches Qemu) choose an
interface name and pass it to Qemu when no one is specified?

Well, I would call that admin error and do:

if (name is specified)
try to create and use that
if (that fails || none was specified)
open the cloning /dev/tap and query the interface name

(where "that fails" obviously includes name collisions with existing
tap instances). This could give you an option usefull for NetBSD 6.0.

Note that I am not objecting to fix the more general problem of
creating aliases or rename support. However, of everything I saw
discussed so far, only the FreeBSD variant has (a) clearly defined
semantics and (b) is very simple to implement. It is so simple, it wouldn't
hurt as a stopgap/intermediate solution.

Everything else, at least from my understanding, needs *a lot* more thought
and design work - which does not mean it is the wrong way to go in the long
term.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roger Pau Monne]

Post by Martin Husemann

Post by Roger Pau Monne
While this is true if you give a name to the interface on the config
file, but how can the toolstack (xl, that launches Qemu) choose an
interface name and pass it to Qemu when no one is specified?

if (name is specified)
try to create and use that
if (that fails || none was specified)
open the cloning /dev/tap and query the interface name

Then we end up with the same problem, since xl needs to know the name of
the created device (to launch the appropriate hotplug scripts), and
there's not way to fetch that from Qemu.

Post by Martin Husemann
(where "that fails" obviously includes name collisions with existing
tap instances). This could give you an option usefull for NetBSD 6.0.
Note that I am not objecting to fix the more general problem of
creating aliases or rename support. However, of everything I saw
discussed so far, only the FreeBSD variant has (a) clearly defined
semantics and (b) is very simple to implement. It is so simple, it wouldn't
hurt as a stopgap/intermediate solution.

I'm not completely sure the FreeBSD solution is easier to implement than
the alias one, but at this point this shouldn't be our primary concern.

Post by Martin Husemann
Everything else, at least from my understanding, needs *a lot* more thought
and design work - which does not mean it is the wrong way to go in the long
term.
Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Roger Pau Monné
Well this might be ok with firewalls, but it's not applicable to guest
interfaces, there's still the problem with persistent interfaces for
DomUs, which this doesn't solve.

I have never administered a dom0, so I clearly lack understanding here.
Can you please explain why this needs kernel help at all (maybe again,
I didn't get it earlier)?

It sounds to me like xen would have a config file to fire up the domU,
and there could be an entry saying "this domU will use tap14".
So assumming we know what tap device we want upfront, there is already
a simple API to create it, without renaming it later.

What am I missing?

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roger Pau Monne]

Post by Martin Husemann

Post by Roger Pau Monné
Well this might be ok with firewalls, but it's not applicable to guest
interfaces, there's still the problem with persistent interfaces for
DomUs, which this doesn't solve.

I have never administered a dom0, so I clearly lack understanding here.
Can you please explain why this needs kernel help at all (maybe again,
I didn't get it earlier)?
It sounds to me like xen would have a config file to fire up the domU,
and there could be an entry saying "this domU will use tap14".
So assumming we know what tap device we want upfront, there is already
a simple API to create it, without renaming it later.
What am I missing?

While this is true if you give a name to the interface on the config
file, but how can the toolstack (xl, that launches Qemu) choose an
interface name and pass it to Qemu when no one is specified? Well, we
might be able to search for a free tap device and pass this as the
desired name, but this is a really racy solution, as someone else might
request a tap device while we are launching Qemu, and take our chosen
tap device behind our back, so we will end up failing to create that domain.

Also, I don't think there's anyway to create vifs interfaces with an
specific name, which I think will also be an interesting feature to have.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Roger Pau Monne
Then we end up with the same problem, since xl needs to know the name of
the created device (to launch the appropriate hotplug scripts), and
there's not way to fetch that from Qemu.

I thought I saw command line options to invoke qemu that pass the tap
ifname, or even open a fd and just pass the number?

Something like:

qemu -net tap,ifname=tap14
or
qemu -net tap,fd=4

and you could pass the name to the script vie environment vars.

Marin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Roger Pau Monne
I'm not completely sure the FreeBSD solution is easier to implement than
the alias one, but at this point this shouldn't be our primary concern.

But the "alias" one has not (yet) well defined semantics.
For example: if you do a snmp traffic graph, which of the N alias names
defined for tap14 do you use?

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roger Pau Monne]

Post by Martin Husemann

Post by Roger Pau Monne
Then we end up with the same problem, since xl needs to know the name of
the created device (to launch the appropriate hotplug scripts), and
there's not way to fetch that from Qemu.

I thought I saw command line options to invoke qemu that pass the tap
ifname, or even open a fd and just pass the number?
qemu -net tap,ifname=tap14
or
qemu -net tap,fd=4
and you could pass the name to the script vie environment vars.

As I said on a previous email, how can you guarantee that the name you
chose and pass to Qemu will not be taken by someone else while you are
calling Qemu?

You might even be launching several guests at the same time, which will
lead you to a race.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Brian Buhrow]

Hello. I know nothing here either, but I have a couple of questions.
Who is it that's launching the guests? Can't who ever it is, have a
locking protocol that says, I'm now fetching a network interface, please
don't fetch one until I'm certain my client is up or dead? Then we know we
won't have a race for the interface name, and we're done.
I'm a little with Darren on the issue of alias names in that an interface
should be known by one name during the life of its existence. It seems to
me the issue here is who controls the name of an interface and how does
that knowledge get passed around? So far I've not seen anything that makes
me feel comfortable with the proposed solutions. If I'm writing firewall
rules, I need to know the name of the interface I'm using well before Qemu
gets into the picture and as long as that's true, I fail to understand the
problem we face. I think it would be helpful,even though it may seem
extremely elementary to those that know, if someone who understands both
how hvm hosts used to get their interface names and what changed.
-thanks
-Brian

On Jun 21, 12:16pm, Roger Pau Monne wrote:
} Subject: Re: Specifying names for tap interfaces
} Martin Husemann wrote:
} > On Thu, Jun 21, 2012 at 11:24:37AM +0100, Roger Pau Monne wrote:
} >> Then we end up with the same problem, since xl needs to know the name of
} >> the created device (to launch the appropriate hotplug scripts), and
} >> there's not way to fetch that from Qemu.
} >
} > I thought I saw command line options to invoke qemu that pass the tap
} > ifname, or even open a fd and just pass the number?
} >
} > Something like:
} >
} > qemu -net tap,ifname=tap14
} > or
} > qemu -net tap,fd=4
} >
} > and you could pass the name to the script vie environment vars.
}
} As I said on a previous email, how can you guarantee that the name you
} chose and pass to Qemu will not be taken by someone else while you are
} calling Qemu?
}
} You might even be launching several guests at the same time, which will
} lead you to a race.
}

-- End of excerpt from Roger Pau Monne

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roger Pau Monne]

Post by Martin Husemann

Post by Roger Pau Monne
I'm not completely sure the FreeBSD solution is easier to implement than
the alias one, but at this point this shouldn't be our primary concern.

But the "alias" one has not (yet) well defined semantics.
For example: if you do a snmp traffic graph, which of the N alias names
defined for tap14 do you use?

You can use the one you prefer, I don't see the problem there. Any calls
to "altname:name" (or "alias:name") will get redirected to the physical
interface that is behind that alias.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Jean-Yves Migeon

Post by Roger Pau Monné
Also, as someone already suggested it will be interesting to be able
to give interfaces associated with guests a permanent name, which this
approach doesn't solve. The solution should be at least applicable to
both tap and vif interfaces, but since we are there, why not make it
work for all network interfaces? I think other users might benefit
from this feature (like not having to rewrite firewall rules when
changing network cards).

IMHO this is not the right place to fix this. First, most firewalls out
there support variables, like macros in pf.conf. IMHO adding more
complexity to kernel for this is questionable.

it's not only firewalls. It's everything that uses interface names.
There is firewall rules of course, but also mrtg scripts, nagios
scripts, network daemons, and so on.

Post by Jean-Yves Migeon
Instead of renaming your interface inside the config files, you alias it
in kernel. Which is anyway a dubious construct because it will not
survive a reboot... except if you edit a config file that sets up this
aliasing for you. Ewww. Back to square one.

No: you only have to rename /etc/ifconfig.foo to ifconfig.bar. As this is where
the alias will be set, everything will follow.

[Manuel Bouyer]

Post by Roger Pau Monne

Post by Martin Husemann

Post by Roger Pau Monne
Then we end up with the same problem, since xl needs to know the name of
the created device (to launch the appropriate hotplug scripts), and
there's not way to fetch that from Qemu.

I thought I saw command line options to invoke qemu that pass the tap
ifname, or even open a fd and just pass the number?
qemu -net tap,ifname=tap14
or
qemu -net tap,fd=4
and you could pass the name to the script vie environment vars.

As I said on a previous email, how can you guarantee that the name
you chose and pass to Qemu will not be taken by someone else while
you are calling Qemu?
You might even be launching several guests at the same time, which
will lead you to a race.

This is a problem with name, but not if you use the fd-type setup:
- xl opens /dev/tap, which creates the tap device (so xl knows the name) and
a file descriptor (which I'll call n)
- fork and exec qemu with: -net tap,vlan=0,fd=n
- the xl parent process closes n.

in this setup, qemu reuses the already-existing tape device and doesn't
create a new one, so no race condition possible here.
This should fix the problem.

[Jean-Yves Migeon]

Post by Manuel Bouyer

Post by Roger Pau Monne
As I said on a previous email, how can you guarantee that the name
you chose and pass to Qemu will not be taken by someone else while
you are calling Qemu?
You might even be launching several guests at the same time, which
will lead you to a race.

- xl opens /dev/tap, which creates the tap device (so xl knows the name) and
a file descriptor (which I'll call n)
- fork and exec qemu with: -net tap,vlan=0,fd=n
- the xl parent process closes n.
in this setup, qemu reuses the already-existing tape device and doesn't
create a new one, so no race condition possible here.
This should fix the problem.

I like this idea, I did not know we could pass down a fdes to Qemu.

I would recommend this if it works. That gives us some time to think
about interfaces/devices xaliases instead of rushing it for
Qemu-upstream support.

[David Young]

Post by Manuel Bouyer

Post by David Young

Post by Darren Reed

Post by Roger Pau Monne
I would like to add this functionality to the kernel, but can someone
provide a little bit more of technical information/steps about how to do it?

The first issue that you face that for all intents and purposes, you
cannot change "struct ifnet" because it is in too many places and
change will likely have a huge waterfall effect. So that can't be
changed.
What can be changed is where "struct ifnet" gets its name from.
For network interfaces, what's required here is another data
structure that connects a "struct ifnet" with the device itself.
This structure needs to remain an internal implementation detail
and any interfacing to it via ioctls should be done via proplists.
A new CLI tool is required to manage this interface, maybe call
it nicctl. For now, all that it would do is display what NICs are
present in the system, their device name, instance number and the
name to be used in "struct ifnet".
This CLI tool also needs to be able to add and remove device name
mappings. So, for example, it needs to let me assign the name
"fxp0" to "fxp,3" or some such. This naming information also needs
to be stored in a file somewhere so that when the system boots,
it can use that information to instruct the kernel. Obviously this
needs to be invoked early in rc, i.e. before ifconfig is used to
set the interface IP addresses. What format that file takes is up
to the person doing the implementation. It could be straight text,
maybe it is XML. Whatever.

I think that basically I agree with Darren. You need a driver
entity (some softc-having thing) and a logical network entity (an
ifnet-having thing) and some correspondence between them that is
set by properties of the driver such as MAC, serial number, its PCI
bus/device/function number. The driver entity has a name written
in NetBSDese (e.g., wmhw0), the logical entity takes either a
default name (e.g., wm0) or the name supplied by the operator (e.g.,
lan19 or wan0 or customer7).
I believe that NetBSD should use autoconf(9) to create the
correspondence. Extend drvctl (or *something*) to let us load/unload
new device->driver correspondences. I've written more about this at
<http://mail-index.netbsd.org/tech-net/2011/05/11/msg002614.html>.
Provide a convenience utility, nicctl, to set up the correspondences for
network interfaces specifically.
I believe that NetBSD should treat disks the same way: split them into
hardware entity and logical disk, set up correspondences between them
using properties of the disk (model, capacity, serial number, whatever)
and/or properties of its partitions (GUID, offset, size, human-readable
name). If we look at them a bit askew, wedges are a step in that
direction. Let the logical disks take a default name (dk0) or else the
operator's name if there is one (backup0).
I think that if you rearrange things in this way, a number of problems
in the kernel shake out. For example, power-management for NICs gets
less hairy. Interesting opportunities come up if you let a logical
driver's device_t (and probably its softc, too) hang around even if
its underlying hardware has disappeared: in that way, the logical
name for a hardware device will persist for at least as long as the
system is up, and the kernel has in the logical driver a place to hang
network configuration or unwritten disk buffers in the event of an
accidental/emergency device detachment.

I like the idea, but I think we don't want to restrict this to
disk and network device. I can't see why you'd want it for low-level
devices (like e.g. ahcisata or atabus or uhci), but I definitively want it
for anything that is exposted (as a device) to userland (disk, network if,
serial ports, kbd/mouse and other hid, video, printers, ...).

Yeah, I don't think that we would want it for low-level devices, either.
Mainly just for those device-tree "leaves" that, as you say, exposed to
userland.

Post by Manuel Bouyer
This is a big project ...

It is. There can be no doubt about that. And it is blocked up, I
think, because nobody has finished the work on autoconf(9) that makes
it more dynamic and that provides richer locators. We must acknowledge
that there have been some smart starts on this work, they're stalled,
but maybe they can be unstuck. I would sure like to see the Foundation
make this a priority for funding.

Dave

[Roger Pau Monne]

Post by Darren Reed

Post by Roger Pau Monne
Anything that we can control, like tap-%domid.%devid would be good
though. It doesn't have to follow any specific nomenclature, but it
will be good to be able to specify two integers, one that corresponds
to the domain id, and another one that identifies the specific network
card inside that domain.
So there's no need to change the /dev/tapN, or the device number, but
just the name of the interface. As far as I know that's just a string
in the struct ifnet, and it's compared when one searches by name, so it
should be changeable. I had thought setting the interface name would
change more and be more intrusive, but maybe it's not so bad.
(It does make sense to require it to start with 'tap' to avoid
collisions.)
It seems easy enough to add the ioctl and see if things blow up...

This should be done differently.
Rather than just change the name of the interface, create a layer
that maps a real device name to a network interface name.
Otherwise if you rename "tap0" to "bge3", how do you easily
determine that "bge3" is actually a tap device and not a bge?

I would like to add this functionality to the kernel, but can someone
provide a little bit more of technical information/steps about how to do it?

Thanks, Roger.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael Richardson]

Roger> Anything that we can control, like tap-%domid.%devid would be
Roger> good though. It doesn't have to follow any specific
Roger> nomenclature, but it will be good to be able to specify two
Roger> integers, one that corresponds to the domain id, and another
Roger> one that identifies the specific network card inside that
Roger> domain.

But that, really, Admins hate having %domid in the device name
because it screws up useful things like SNMP/mrtg on those
devices.

Roger> I don't really understand this, why does the name of the
Roger> interface matters regarding SNMP or mrtg? Is this a privacy
Roger> related issue?

Because, the *mrtg* graph is generally for interface "FOO" (usually
associated with virtual machine "FOO", but naturally machines can have
multiple interfaces).

There are other ways of specifying the interface, but they are generally
not stable across reboots, or restarts of the virtual machine. In
particular, ifIndex (which shows up in th4e OID) is definitely not
stable (nor should it be).

Roger> It supports being able to specify interface names in Linux
Roger> (on the domain config file), for both vif (PV) and tap (HVM),
Roger> and it has been like this for a long time I think (xend also
Roger> had this functionality).

I knew it was coming, I just wasn't sure if it had happened yet.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] ***@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video

then sign the petition.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael Richardson]

Roger> Anything that we can control, like tap-%domid.%devid would be
Roger> good though. It doesn't have to follow any specific
Roger> nomenclature, but it will be good to be able to specify two
Roger> integers, one that corresponds to the domain id, and another
Roger> one that identifies the specific network card inside that
Roger> domain.

But that, really, Admins hate having %domid in the device name because
it screws up useful things like SNMP/mrtg on those devices.

So the admin really wants to specify a consistent name in the XEN
configuration file... something which I think XEN does not yet support.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] ***@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video http://youtu.be/kzx1ycLXQSE
then sign the petition.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Michael Richardson
Roger> Anything that we can control, like tap-%domid.%devid would be
Roger> good though. It doesn't have to follow any specific
Roger> nomenclature, but it will be good to be able to specify two
Roger> integers, one that corresponds to the domain id, and another
Roger> one that identifies the specific network card inside that
Roger> domain.
But that, really, Admins hate having %domid in the device name because
it screws up useful things like SNMP/mrtg on those devices.
So the admin really wants to specify a consistent name in the XEN
configuration file... something which I think XEN does not yet support.

Seconded, having persistent interface name would be a great improvement.

[Manuel Bouyer]

Post by Roger Pau Monne

Roger> Anything that we can control, like tap-%domid.%devid would be
Roger> good though. It doesn't have to follow any specific
Roger> nomenclature, but it will be good to be able to specify two
Roger> integers, one that corresponds to the domain id, and another
Roger> one that identifies the specific network card inside that
Roger> domain.
But that, really, Admins hate having %domid in the device name because
it screws up useful things like SNMP/mrtg on those devices.

I don't really understand this, why does the name of the interface
matters regarding SNMP or mrtg? Is this a privacy related issue?

Because everywhere an interface name appears (ipf.conf, altq.conf,
mrtg graphs, ...) you have to change it when a domU is restarted.