OK, then it sounds like vanity naming *IS* supported for PPPoE, and
this text can just be removed.
Okay, will do.
As long as that works, we're in sync, and everything's fine. There's
no reason to allow a user to rename "foobar0:pppoed" into "blah" -- in
fact, that'd rather severely break the existing design and would have
no possible administrative use.
Agreed.
Instead, if a distinction must be made, I'd rather see it be made as
an option. E.g., use "-f" to mean "force." So, if the user does
"delete-phys" and there are still references, it fails. If the user
does "delete-phys -f", the references are torched as well.
Using "discard" to mean "delete with extreme prejudice" seems harder
to remember and explain. I'm not sure I can come up with another case
in which that design pattern was used.
Just for usability (if nothing else), I think it'd be nice to have
"delete-<X>" be the pattern everywhere.
The "delete-phys -f" approach seems nice. I will talk to the team about it.
That does point out a bit of strangeness in the existing command set,
but I sort of doubt that it's fixable now as S10 has left the barn.
It would have been nicer to have a simple "create" command with some
sort of option to specify what type of link you want to create, and
then have a single "delete" command that doesn't *need* to know a
thing about type.
As it is, this current design means that the user can't just say
"please delete this thing." The user must reassert the "type" of the
thing in order to delete it, even though the "type" may well be
irrelevant to the user, and the system certainly knows full well what
the type is when given just the name. There isn't a separate name
space for aggregations versus VLANs or physical links.
Thus, "delete-aggr somevlan0" will fail and say something like "you
gave me a VLAN, but all I want to do is kill aggregations; type your
command again in frustration." Sort of like the "we cannot complete
your call as dialed; please dial '1' for toll calls" error message.
I fully agree all of the above.
I suppose I can live with separate "delete-<X>" commands. It'd sort
of be nice, though, to consider having a single "delete" that can
eventually take over.
... and a single "create" to create each type of link by specifying
different options? I will think about it.
I think this needs a big readme entry, blogs, comp.unix.solaris
postings, and any other advertisements we can think of.
Agreed.
It also needs to be pointed out as soon as possible in ARC review. I
wouldn't be surprised to find that you run into resistance on this (it
seems to me to break the model of that interface), so getting it over
with early -- before more design and coding uses it -- would be good.
Okay. Thank you very much for reminding.
How can it be done even lower than the softmac if we cannot change the
underlying driver?
You're planning to change those drivers anyway to support VLAN MAC
overhead properly, right? That's your big chance, _if_ it's something
necessary and valuable to do. I'm somewhat less sure that it is.
Frankly, I'd rather see the effort expended on porting those older
drivers over to Nemo than tweaking their performance.
Okay.
When does the wificonfig->dladm transition occur?
Meem already answered this, and yes, if this component goes in before
the wificonfig/dladm transition, we willl have to update wificonfig.
Thanks
- Cathy
_______________________________________________
networking-discuss mailing list
[email protected]
