Re: Generic ioctl and ether_ioctl don't agree
- From: Yar Tikhiy <yar@xxxxxxxxxxxxxxxx>
- Date: Thu, 15 Mar 2007 14:14:00 +0300
On Wed, Mar 14, 2007 at 12:50:12PM +0000, Bruce M. Simpson wrote:
Yar Tikhiy wrote:
Hi folks,This is one of those annoying things which breaks compatibility with
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.
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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: <sys/queue.h> bikeshed proposal
- Next by Date: Multithreaded qsort(3)
- Previous by thread: <sys/queue.h> bikeshed proposal
- Next by thread: Multithreaded qsort(3)
- Index(es):
Relevant Pages
|
|
