> I've put together some of my initial thoughts on the design for link
> layer discovery at http://www.opensolaris.org/os/project/lld/design
>
> I'd like any feedback, advice, etc. on how to further improve and
> refine things before I get too deep into writing any code.
I took a quick look at this last night and I think this is heading in a
good direction. Some initial thoughts:
* It's worth exploring how best to align the subcommands with the way other
subcommands work in dladm. For instance, existing subcommands are
verb-noun where "noun" is either the type of the link or the class of
the link. Accordingly, it might be more fitting to have a flag to
show-link that gives the discovered info for that link. Similarly,
maybe something like `discover-link' would be a better fit for
performing discovery? (As an aside, Clearview, Brussels and Crossbow
are all working on a number of new subcommands so combined with this,
dladm's subcommand list is getting hefty.)
* The show-peer -v option output is an interesting solution to the
80-column output problem. If we went with that approach, it should be
available uniformly across the show-* subcommands and we should figure
out how it interacts with parseable-output mode. Also, in general
we've avoided multi-word field names because they complicate parsing
of the output and require quoting with -o <field>.
* WRT your question about SMF: yes, I think implicit enabling is the way
to go; connect-wifi currently does this for wpad when using WPA.
* A nit: s/[dev]/[link] or [name]/ throughout.
--
meem
_______________________________________________
networking-discuss mailing list
[email protected]
