[PATCH 1/2] Update errno and ioctl definitions for newer Linux

[Mike Frysinger]

On Tuesday 23 October 2012 19:58:46 Dmitry V. Levin wrote:
> On Tue, Oct 23, 2012 at 05:36:58PM +0100, Steve McIntyre wrote:
> > --- a/linux/ioctlent.h.in
> > +++ b/linux/ioctlent.h.in
> > @@ -2,6 +2,7 @@
> > 
> >  	{"linux/fs.h",	"FIBMAP",	0x0001},
> >  	{"linux/fs.h",	"FIGETBSZ",	0x0002},
> >  	{"linux/fd.h",	"FDGETPRM",	0x0204},
> > +	{"linux/fd.h",	"FDGETPRM32",	0x0204},
> 
> I'm not sure such entries are worth adding.  I know we have these
> redundant "*32" entries in linux/ioctlent.h.in already, maybe it's time
> to strip them instead of adding new ones.

if the # is the same as the non-32 version, then yeah, we should omit it.  
otherwise the output is generally useless:
	ioctl(1, FDGETPRM or FDGETPRM32, {...}) = 0

the decoder would need to know more info in order to tell which one exactly is 
being used (based on the active ELF).  but we don't have that, so we should 
filter it.

i'm guessing Steve just ran the script in the tree to generate this and didn't 
hand update it.  which means we should update the script to be smarter.

> > +	{"asm-generic/ioctls.h",	"TCGETS",	0x5401},
> 
> We were adding asm-generic entries to arch-specific ioctlent files before.
> I'm not sure whether we'd rather move all these entries to the common
> ioctlent file as indirectly proposed by this patch.
> Any ideas why we might want to continue the old practice?

asm-generic is sucky because it's the generic code, unless there are 
exceptions.  if there are ioctls that are the same for all targets, we should 
def put in the common header.  not sure how easy it is to detect this ... 
maybe we'd have to update ioctlent.sh to run cpp for all the targets by 
manually setting the required -D flags ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20121023/b0ac2024/attachment.bin>