Cathy Zhou writes: > http://opensolaris.org/os/community/networking/uv-design.pdf
I'm not sure what the reference to PPPoE "devices" in section 3.1.1 means. Does this mean the 'device' names that sppptun uses to plumb PPPoE streams? The 'interface' names used to name those streams (and used by pppd to refer to them)? Or the "sppp" interfaces created by pppd itself? If it refers to the sppptun interface names, then I don't think that vanity naming needs to do anything here. The existing mechanism ought to do the job fine because sppptun renames the interface as part of setting it up. (That whole "default name" guff could be ripped out.) If it refers to the sppptun device name, then I don't understand why this wouldn't be supported. I think it should be. If it's not, then it sounds to me like vanity naming is just incomplete. Why would this one standard part of Solaris not be supported? Shouldn't it just try "/dev/net/%s" first and then "/dev/%s"? 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.) 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. Why is the subcommand named "discard-phys"? It looks to me like this discards the configuration of a _link_, not a physical device, 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.) 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 5.1: while you're there, could you just move libmacadm into libdladm? Do we really need a separate library to house one function? 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? What about wificonfig updates to support vanity link names? Any changes required here? 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? -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
