Generic ioctl and ether_ioctl don't agree

[Yar Tikhiy]

On Wed, Mar 14, 2007 at 12:50:12PM +0000, Bruce M. Simpson wrote:
> Yar Tikhiy wrote:
> >Hi folks,
> >
> >Quite a while ago I noticed that our ioctl handlers get the ioctl
> >command via u_long, but ether_ioctl()'s command argument is int.
> >This disarray dates back to 1998, when ioctl functions started to
> >take u_long as the command, but ether_ioctl() was never fixed.
> >Fortunately, our ioctl command coding still fits in 32 bits, or
> >else we would've got problems on 64-bit arch'es already.  I'd like
> >to fix this long-standing bug some day after RELENG_7 is branched.
> >Of course, this will break ABI to network modules on all 64-bit
> >arch'es.  BTW, the same applies to other L2 layers, such as firewire,
> >which seems to have been cloned from if_ethersubr.c.
> >  
> This is one of those annoying things which breaks compatibility with 
> external modules.
> 
> I'm not sure about this, though. I was getting sign extension warnings 
> on amd64 last week when I was testing the IGMPv3 aware mtest(8). Perhaps 
> if we're fixing these ABIs, we should commit to an explicit C99 type 
> with known bit width, i.e. uint32_t.
> 
> I would be much happier if we began using C99 types in the code.

This is a point to discuss in -arch as it's closely related to the
generic ioctl interface.  Let's move this thread to -arch.

It's been a vague issue to me whether to use a fixed-width type or
a basic type in particular kernel code.  Of course, it's better to
use a fixed-width type when it comes to network packets or hardware
registers.  OTOH, errno is int.   But not all cases are that simple.
Do we have a guideline for that?

-- 
Yar