James Carlson wrote:
> 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.
>
One quick note on this theory. I do not want to leave them "where they
are" (if that is in ndd), if that means that old device drivers have to
retain all the crufty ndd logic _in addition_ to implementing the new
Brussels API.
HOWEVER, I like the idea that some of these "legacy" parameters that we
don't particularly want to encourage might not be available/advertised
via the new dladm API. Maybe what Brussels needs is a way to say
"expose this property via NDD only". (In fact, I think I suggested just
such a thing in my detailed design suggestion, that I think nobody else
read. :-)
Eventually, hopefully we'll be able to remove this legacy cruft and
replace them with a better framework. But, at the moment, for some of
these (like the bcopy/dma/buffer management issues), this requires
substantial new effort that management has yet to express a real
interest in. (Yes, I've been campaigning for this project ... to the
point that I want to do it myself under the guise of a Nemo II or
somesuch. Folks with managerial influence are encouraged to voice their
opinions in this regard. :-)
-- Garrett
