Re: ioctl(2) vs sys/ioctl.h
In article <20474.1292802...@splode.eterna.com.au>, matthew green 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
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. this changes the ABI on LP64BE if i am not mistaken. .mrg.
Re: ioctl(2) vs sys/ioctl.h
In article <20101219200631.gc14...@falu.nl>, Rhialto 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
> 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
On Sun, Dec 19, 2010 at 09:06:31PM +0100, Rhialto wrote: > > Easier: the aforementioned constant FLUSHR (and all others) can be > defined as ((void *)1234) (for appropriate values of 1234). FLUSHR (and FLUSHW) have to be numbers - they are bit patterns and can be or'ed together. > However, we don't have streams, so no streams ioctls, which makes the > point moot, at least for the given example. Historically (and outside netbsd) integer args are more common (and the 'cmd' can be 32 bits). David -- David Laight: da...@l8s.co.uk
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
On Sat, Dec 18, 2010 at 04:06:15PM -0800, Paul Goyette wrote: > Is there some reason why there is a discrepancy in the definition of > ioctl()? > > >From man page ioctl(2) ... >ioctl(int d, unsigned long request, void *argp); > Yet, from sys/ioctl.h we have ... > int ioctl(int, unsigned long, ...); As mentioned by others, historically the 3rd arg to ioctl was either a pointer or a constant. Pre ANSI-C this didn't matter. There is a bigger problem, the 'int' and 'void *' arguments might be passed in different ways then '...' is specified. For a userspace varargs function this isn't a problem - it is taken care of by va_arg(), but for a sycall stub this isn't true since the type of the argument isn't known early enough. 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)) We only get away with it on our 64 bit archs because they all pass the first 3 arguments in registers. David -- David Laight: da...@l8s.co.uk
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, Christos Zoulas wrote: In article , Paul Goyette wrote: Is there some reason why there is a discrepancy in the definition of ioctl()? From man page ioctl(2) SYNOPSIS #include 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 Sat, 18 Dec 2010, der Mouse wrote: > >>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? it seems to be a flag > I'm just brainstorming possible ways to avoid inflicting a varargs > declaration on all users of ioctl. they already have it, see and http://pubs.opengroup.org/onlinepubs/009695399/functions/ioctl.html iain
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
Re: ioctl(2) vs sys/ioctl.h
In article , Paul Goyette wrote: >Is there some reason why there is a discrepancy in the definition of >ioctl()? > >From man page ioctl(2) > > SYNOPSIS >#include > >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. 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 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 | -
