Sowmini.Varadhan at Sun.COM writes: > One of the features that makes ndd very popular is that it allows > the setting of these debug/workaround knobs "on the fly", i.e., no reboot > required (as in /etc/system), and the driver can actually re-adjust > its state based on the setting requested (mdb cannot trigger state > re-adjustment in the driver by itself).
Yep; understood. > Providing a way to do this on-the-fly debug/workaround setting was > one of the motivations for private properties. I agree that there is a > danger of abuse here, and maybe we can think of ways to control > the danger (by controlling documentation, perhaps?), but I see a benefit > in having private props for the short term, at least. It's exactly that abuse that I'm worried about. One of the reasons for doing Brussels is that driver parameters have historically been the Old West for configuration. How do we make sure that Brussels itself doesn't become just a new dumping ground? > Actually, I myself felt that bcopy/dma threshold, as well as > some of the ipg properties that have been suggested as public property > candidates, also fell in the "Advanced Usage" bucket.. Ick. I'd put it in the class of things that, if we were producing solid designs, would just never need to be touched at all. There's a line here between allowing configuration for special purposes (disabling autonegotiation, perhaps) and asking our customers to do our design work for us (by figuring out the "optimal" way to move data). This is one that I think walks over the line. We need a better answer. > > Would it be good for us to retain them somehow in early phase of Brussel, > > like by ways of keep it as "private" properties? For backward compatibility > > reason, some customers might rely on those private properties in their > > production env. Before we provide enough tuning in framework, they will > > lose nothing. > > I like Raymond's proposal.. I'd rather see those things left behind whereever they are -- ndd, driver.conf -- and left out of Brussels user interfaces, with bugs filed to have them removed completely over time. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
