Ben Greear wrote:
Donald Becker wrote:
"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
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
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
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.