On Wed, Nov 07, 2007 at 11:50:09PM -0500, Peter Memishian wrote: > > 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 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? [...]
How about 'scan-link'? That would match what scan-wifi does. Is it possible to discover VLANs? Incidentally, I note that the dladm show-link -p and show-wifi -p output formats differ radically. Why? (Change the Subject if responding to this -- it's a different thread :) > * The show-peer -v option output is an interesting solution to the show-peer makes sense for point-to-point links, but an Ethernet NIC is connected to a dumb bridge wouldn't qualify, no? See also the above question about VLAN discovery. > 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>. dladm show-wifi -p output includes BSSID/IBSSID=<ssid> That '/' makes it difficult to use dladm show-wifi -p output in a script! Also, is the ESSID properly quoted? Is it safe to eval dladm show-wifi -p output in a shell? Nico -- _______________________________________________ networking-discuss mailing list [email protected]
