> >> The third option I see is to completely ditch this, stating that > >> although We obviously CAN set the non-volatile memory we CAN'T do it > >> with the regular API, and to move into doing this via some > >> proprietary API such as debugfs. > > > Why go to debugfs rather than gracefully extending the ethtool stuff > > to explicitly support what you need? > > Gracefully extend it to where? > > The most I can learn from this is that some adapters are in need of additional > metadata for doing this sort of stuff. > The state-machine itself is propriety and I don't think anyone would gain from > trying to formalize anything else from it. > If by 'graceful extension' of ethtool API you mean adding an additional field > or > two for metadata - sure, I can do that, I just don't think of it as graceful. > ;-) > > And if this is actually the way we want to take this, I would still [don't > get upset > ;-)] argue in favor of overloading the 'magic' field for this purpose, as > bnx2x and > bnxt are already doing. > Basically if the 'magic' would also contain metadata that could be verified as > appropriate [I.e., by having valid ranges], it would still fit as a safety > measure for > guaranteeing the correctness of the write request.
Hi Dave, I'll probably send V2 [relatively] shortly, and it looks like I'll drop this one out as I don't yet understand the expected direction through which to solve this. I'd appreciate any suggested pointers here. Thanks, Yuval
