Re: ioctl(2) vs sys/ioctl.h
On Sun, 19 Dec 2010, Christos Zoulas wrote: In article pine.neb.4.64.1012181604050.27...@quicky.whooppee.com, Paul Goyette p...@whooppee.com wrote: Is there some reason why there is a discrepancy in the definition of ioctl()? From man page ioctl(2) SYNOPSIS #include sys/ioctl.h int ioctl(int d, unsigned long request, void *argp); Yet, from sys/ioctl.h we have __BEGIN_DECLS int ioctl(int, unsigned long, ...); __END_DECLS Most of our ioctl's take pointer arguments. Some streams ioctls though take int arguments (ioctl(fd, I_FLUSH, FLUSHR) for example) and using void * as the argument would not compile cleanly. I think that we should not have void * in the man page either. Should the man page be updated to match reality? - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: ioctl(2) vs sys/ioctl.h
On Dec 19, 8:00am, p...@whooppee.com (Paul Goyette) wrote: -- Subject: Re: ioctl(2) vs sys/ioctl.h | Should the man page be updated to match reality? I just did. christos
Re: ioctl(2) vs sys/ioctl.h
On Sun 19 Dec 2010 at 19:32:49 +, David Laight wrote: I suspect the only form that will work is soemthing like: int ioctl(int, unsigned long, void *); #define ioctl(fd, cmd, arg) ioctl(fd, cmd, (void *)(intptr_t)(arg)) Easier: the aforementioned constant FLUSHR (and all others) can be defined as ((void *)1234) (for appropriate values of 1234). However, we don't have streams, so no streams ioctls, which makes the point moot, at least for the given example. David -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: ioctl(2) vs sys/ioctl.h
There is a bigger problem, the 'int' and 'void *' arguments might be passed in different ways then '...' is specified. True, but it is not inherently a problem; it just complicates the implementation of ioctl(), since it then has to not just pass down a data pointer, but pass down enough information for the particular ioctl's implementation to find whatever type the actual argument is. (As it is, the implementation already depends on a nonportability, basically that all pointer types are the same. It would explode badly on a machine where some but not all pointer types are larger than a machine word/register.) We only get away with it on our 64 bit archs because they all pass the first 3 arguments in registers. ...and are all byte-addressed. If some pointers were 64 bits and others were 128 (or, worse, 72 or 96 or some such), it would fall over rather hard. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: ioctl(2) vs sys/ioctl.h
In article 20101219200631.gc14...@falu.nl, Rhialto rhia...@falu.nl wrote: On Sun 19 Dec 2010 at 19:32:49 +, David Laight wrote: I suspect the only form that will work is soemthing like: int ioctl(int, unsigned long, void *); #define ioctl(fd, cmd, arg) ioctl(fd, cmd, (void *)(intptr_t)(arg)) Easier: the aforementioned constant FLUSHR (and all others) can be defined as ((void *)1234) (for appropriate values of 1234). However, we don't have streams, so no streams ioctls, which makes the point moot, at least for the given example. Ok, how about *all* the examples in ioctl(2)? :-) christos
Re: ioctl(2) vs sys/ioctl.h
In article 20474.1292802...@splode.eterna.com.au, matthew green m...@eterna.com.au wrote: On Sun 19 Dec 2010 at 19:32:49 +, David Laight wrote: I suspect the only form that will work is soemthing like: int ioctl(int, unsigned long, void *); #define ioctl(fd, cmd, arg) ioctl(fd, cmd, (void *)(intptr_t)(arg)) Easier: the aforementioned constant FLUSHR (and all others) can be defined as ((void *)1234) (for appropriate values of 1234). However, we don't have streams, so no streams ioctls, which makes the point moot, at least for the given example. this changes the ABI on LP64BE if i am not mistaken. That would change the ABI on _LP64 systems that don't pass the first 3 arguments in registers. We don't have any yet. On the other hand we are not planning to change ioctl like this for no good reason (and we would break standards compliance). I just changed the man pages to be consistent with the implementation. christos
ioctl(2) vs sys/ioctl.h
Is there some reason why there is a discrepancy in the definition of ioctl()? From man page ioctl(2) SYNOPSIS #include sys/ioctl.h int ioctl(int d, unsigned long request, void *argp); Yet, from sys/ioctl.h we have __BEGIN_DECLS int ioctl(int, unsigned long, ...); __END_DECLS - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: ioctl(2) vs sys/ioctl.h
int ioctl(int, unsigned long, ...); Most of our ioctl's take pointer arguments. Some streams ioctls though take int arguments (ioctl(fd, I_FLUSH, FLUSHR) for example) and using void * as the argument would not compile cleanly. Must FLUSHR (to continue your example) be defined as an int value? Obviously there can be ABI issues, but they can be worked around the same way you work around other compat ABI issues - or ignored, on arches where ints and void *s are passed sufficiently compatibly. Or perhaps ioctl could turn into something else after #including the file that defines I_FLUSH and/or FLUSHR? I'm just brainstorming possible ways to avoid inflicting a varargs declaration on all users of ioctl. I don't know whether there are any issues which might break the above ideas - assuming anyone besides me cares, that is. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
