Subject: Re: SIOCADDMULTI for unicast broken

From: Jeff Garzik <[email-masked]>
Date: Fri, 03 Jan 2003 20:52:13 -0500

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