Ben Greear wrote:
Donald Becker wrote:
It was
"If you need this capability for a RESEARCH PROJECT, you can buy this
specific board and thus not need to modify the kernel or device
driver. "
You can also find a few people that want to receive specific corrupted
packets, change the meaning of LEDs on a NIC, and do many other strange
things. But we don't need a defined kernel interface for each one.
Just out of curiosity, what is the suggested manner for adding such
back-door hacks as this?
SIOCDEVPRIVATE is staying around
> Maybe in a proc file system that the driver
implements?
No! procfs additions are discouraged. sysfs in 2.5.x if you _must_ do
this, but SIOCDEVPRIVATE or just flat out maintaining a kernel patch
against a stable kernel tree would be much preferred, I think.
> It would be neat to see various driver-specific features
like this be implemented, and it would be even nicer if they followed
at least some general guideline for how to interface with the rest of
the world...
Driver-specific features are by definition just that :) If you want a
general guideline, you'll also want a header or helper lib quite often
to eliminate duplication of code and standardize the interface.
Jeff
|