On 11/7/07, Peter Memishian <[EMAIL PROTECTED]> 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'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.)
I wasn't too happy with the name choices myself, but wanted something as a starting point. I'd definitely like more discussion around this. 'discover-link' is a definite possibility, though my only thought is that it might imply initating some sort of active probing of the line instead of the more passive 'show me what's been seen on this link' (at least for displaying the data; obviously broadcasting the server's info is such an active process). As silly as it may sound, I've been in places where merely having such implications due to naming would put undue restrictions on use. > > * 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>. My thoughts here were that the protocol(s) could return more information than could be displayed in 80 columns, but I wanted some way for an admin to be able to view the data. With parseable-output mode, I suspect that all the values could be output. IIRC, I don't think parseable-output has any restrictions on column length since it's designed for scripts, and not terminals. Do any of the other subcommands have similar issues with potentially more data than what can fit in 80 columns? If so, it would make sense to try to follow the same convention. I pretty much only use show-dev and show-link in practice (at least to date, not sure how it will change yet when some of the other projects putback), so I'm not very familiar with what the other subcommands output. > > * 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. > That's what I was thinking, but my only concern was since this listens on a link, I was concerned about implicit enabling. I haven't looked at wpad yet, does it actually listen on the wireless interface, or just communicate using a door? Just wondering if there are differences that might factor into the decision. > * A nit: s/[dev]/[link] or [name]/ throughout. Fixed > > -- > meem > _______________________________________________ networking-discuss mailing list [email protected]
