Peter Memishian wrote:
>  > 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.

>       * I'm a bit surprised by the "endpoint" terminology; it seems more
>         like a "peer" link to me.  Or do we not require that two links
>         have symmetric endpoints?  (e.g., if link A has endpoint B, must
>         link B have endpoint A?  If so, I think "peer" would be a more
>         descriptive term.)

Yes, peer link is better. I will change it in the doc.

>       * 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.

>       * 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.

>       * 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.

Rishi
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to