On Thu, 2009-06-18 at 06:30 -0700, Peter Memishian wrote: > Some background here: the original draft proposal for this case was for a > set of read-only link properties, which Sowmini and I (and perhaps others) > commented on. I asked Ted/Venki to instead build a show-ib subcommand > because (a) it follows what we've already done with other media and (b) it > seemed more convenient given that none of the things being modeled as > properties could be administratively controlled. (I never saw the updated > materials with the proposed output from show-ib; I agree with Seb's > suggestion for the new output format.) > > Regarding also having administrative link properties: I see limited value > in exposing inherently read-only things as link properties, as they > clutter up the show-linkprop output and cannot be operated on by any of > the other linkprop subcommands -- and the set of possible values is likely > something better explained in a manpage. This is why the dladm/wifi case > that introduced link properties had both a show-wifi subcommand and a > smaller set of link properties that could be configured. (Note that there > are still cases when a property may be read-only -- e.g., it may be that > the property can only be set by some subset of drivers, or only if other > bits of configuration are set a certain way.) I will concede that there > are already some inherently read-only properties in dladm (grr).
Okay, and I was evidently misled by Ted's acknowledgment of my previous mail message suggesting both show-linkprop and show-ib output. For the record, the proposal is for a show-ib subcommand only, and no link properties, right? Can the project team supply an updated proposal which clarifies some of the confusion and brings the output format up to date with what was discussed? Thanks, -Seb
