Re: SIOCADDMULTI for unicast broken

[Jeff Garzik <jgarzik@pobox.com>]

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