Peter Memishian wrote: [...] > > > * 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.
Given that the intended use is for testing scripts it should be okay or perhaps we should relax the stability level for now. I am open to suggestions. > > > * 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? Interesting question, I don't know what is the right behavior but something for discussion before lifting the restriction. [..] > > > * 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. Okay. Rishi _______________________________________________ networking-discuss mailing list [email protected]
