> > Would the properties still end up in the show-linkprop output? If so, > > even well-behaved admins are still subjected to a mountain of properties > > that they shouldn't even be using, which seems bad. Or are you proposing > > some way to hide these properties? (I'm nervous about that as well.) If > > we're sure this stuff will be off the beaten path, maybe we could reduce > > the number of properties to just `cap', `advcap', and `lpadvcap' (or > > somesuch) with a commas-separated list of values? > > What we really need is a simple UI for managing the "common" tunables > (and maybe exposing them as "properties" isn't the best way to handle > this! see for example the way we handle WIFI "properties" for SSID... > they have their own subcommands)
Right, that was the thinking behind that breakdown. But I think most of the tunables we've been discussing *aren't* that common -- at least, I was kind of hoping most customers aren't mucking with fixed speed and duplex settings. Jumbograms are in a bit of gray area, but if we had a boolean jumbograms property as you suggest, I think that'd be adminstratively decent. I'm curious why you think having three properties (ala cap, advcap and lpadvcap) wouldn't be a reasonable tradeoff? > Actually, the plethora of different jumbo frame sizes that various NICs > support is *another* annoyance. I think we should just pick a standard > Solaris value that is typical... say 9000 bytes or somesuch, and then > abandon the attempts to support other less common "jumbo sizes". The > infinite tunability here is more likely to cause problems for customers > than to help them.) I'm inclined to agree, but I'm not familiar with what causes a customer to choose a given value. -- meem
