> > > On behalf of the RBridges team I am requesting feedback > > > from the community on our plan to introduce support for > > > simulated links in OpenSolaris. The document included > > > in-line below introduces simlinks and is in the form of > > > a PSARC fast-track document. > > > > I like this proposal; it seems very clean and fits in well with the dladm > > architecture. A few questions: > > > > * I see this case is Committed, so I presume we planning to > > document this construct in dladm(1M)? Or do we feel that's > > not worthwhile? > > I feel it should be left out of dladm man page until we gain more > experience with simlinks. I can create a page on opensolaris that could > list the commands and private properties.
The Interface Taxonomy document has this to say about Committed: We publish the specification of these interfaces, typically as manual pages or other product documentation. I guess what you propose above could be "other product documentation", but it feels a bit loose. > > * Related to the previous question: must the other endpoint be a > > simlink? > > Yes it must be simlink. It is possible to remove this restriction > to meet a testing need in future. Would this also remove the requirement that peers be symmetric? Or would e.g., a phys link with a peer of a simlink be able to pull packets both from the peer simlink and the wire? > > * Just a nit, but when I hear the word "simlink" I instantly think > > of "symlink". Also, none of our other link classes have "link" > > in the name. > > Agreed though the geeky name might work here given the use case. OK. > > * It seems like some of the stuff shown by show-simlink is only > > due to deficiences with show-link. In particular, it's hard > > to understand why show-link doesn't include the hardware address > > and it should probably also have the media type. > > True but given that we already have show-* commands for other link classes > I felt it would be expected there be a show-simlink command. To be clear, my issue wasn't with show-simlink, just that ultimately the various show-* commands focused on displaying information that was unique to their domain rather than being forced into displaying general information because of deficiencies in other show-* commands (see 6802707 for more on this). To that end, I'd expect we'd revise this whenever someone fixes up show-link to be more complete. -- meem _______________________________________________ networking-discuss mailing list [email protected]
