James Carlson wrote:
[EMAIL PROTECTED] 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
_______________________________________________
networking-discuss mailing list
[email protected]
