I'm not sure what the reference to PPPoE "devices" in section 3.1.1
means.
I thought that when sppptun plumbs an interface, it gives the interface
the name in the form of <devname>.pppoe(d)?
In the future, sppptun will be able to plumb the sppptun device using
its link name. But the PPPoE interface name will still in the form of
<linkname>.pppoe(d), and that will not be changed by the vanity naming
component.
I continue to believe that the MAC naming conventions from Nemo are a
bit weird. It just doesn't strike me as correct to have a naming
structure where one element is always exactly zero -- either bgeX/0 or
aggr0/X, but never fooX/Y. I realize that it corresponds to something
obscure buried in the implementation and that there are rumors that
some physical interface someday may possibly have multiple "ports"
(though what those might represent has never been adequately
explained), but, despite the extended hallway discussions I've had
with meem about this, it still doesn't feel right. (Perhaps nothing
you can fix here, but it makes me queasy anyway.)
Seb already has this change in his binary compatibility mac_t wad. The
format for MAC names will be <drvname>N.
I do not think that changing "create-aggr -d" to "create-aggr -l" is
necessarily warranted. I recognize that you're trying to enforce the
notion that this feature takes *link* names rather than *device*
names, but the fact that one letter or another was chosen is, I
believe, moot. At best, you could introduce "-l" as an alias for
"-d," but I can see no good case to be made for obsoleting and
removing "-d." If it were my project, though, I would not bother to
do even that. I'd just note in the man page that the argument for
"-d" is a link name, and move on. There's no reason that the letter
"d" must mean "device" here and that "device" must mean "no vanity
naming allowed." Users just don't think that way and are unlikely to
care much about the distinction.
I discussed this within our I-team. We think that as "-l" is used in
other sub-commands to represent a link, (for example, create-vlan), it's
very important to be consistent.
Why is the subcommand named "discard-phys"? It looks to me like this
discards the configuration of a _link_, not a physical device,
By our definition, "phys" is a type of link, just like other link types
such as "vlan" and "aggr".
though
it is the physical device that was removed. (Maybe I'm just confused
about the distinction between the verbs "discard" and "delete," as
both seem to be used for the same thing.)
Yes, "discard" roughly equals to "delete", except that unlike
"delete-aggr" or "delete-vlan", "discard-phys" will not only delete the
physical link itself but also remove the specific physical link from all
associated link configurations (for example, delete all associated
VLANs). If you think that "delete-phys" itself is clear enough to imply
that difference, sure, we will think about that. In fact, we are still
working with UI experts of the UI design, what we proposed here might
change later.
Or, if what you are suggesting is something like "delete-link", which
deletes (discard) links based on the type of the link the administrator
specifies, and replaces delete-aggr, delete-vlan and discard-phys, I may
not agree. It seems more natural to me to have delete-aggr if we have
create-aggr to create the aggregation.
Of all of the changes in the document, I think 3.1.6 is on the
shakiest ground. It doesn't make sense to me to assert here that
device names and interface names are unrelated and that applications
that were relying on this can be broken with impunity. Not only does
ifconfig obviously do this with "-a plumb", but others may well have
relied on it as we provide no other usable interface to find the
network interfaces.
http://search.cpan.org/src/DAGOBERT/Solaris-DeviceTree-0.02/lib/Solaris/DeviceTree/Libdevinfo.pm
I agree it is a big risk. But as long as link names can be different
from device names, applications will *not* be able to get the correct
link names directly using libdevinfo. I think we have to accept this and
warn users that vanity naming may cause problems for applications using
libdevinfo. We will certainly update ON gate to use the new interfaces
to enumelate links. For third-party applications, we can also work with
them to update their code.
5.1: while you're there, could you just move libmacadm into libdladm?
Do we really need a separate library to house one function?
Sure.
Why does softmac attempt to coalesce messages from the lower stream?
This doesn't sound like a win to to me -- if coalescing is to be done
at all, shouldn't it be done at the lowest possible level? Has any
measurement been done to see the positive (presumably lower CPU cycle
usage) and negative (latency and jitter) impact of this?
How can it be done even lower than the softmac if we cannot change the
underlying driver? If what you are suggesting is to evaluate the
performance impact first, sure we will do that.
What about wificonfig updates to support vanity link names? Any
changes required here?
AFAIK, the current plan is to replace wificonfig with dladm.
When does SunTrunking get EOF'd and replaced with the softmac support?
Why does this new project introduce a feature that overlaps an
existing product but does *not* explicitly announce a transition for
the older product?
Sure, I will talk to the SunTrunking owner about this.
Thank you very much for all your comments.
- Cathy
_______________________________________________
networking-discuss mailing list
[email protected]
