From: Mike F. <va...@ge...> - 2009-02-20 17:56:57
|
Rather than hard coding the subdirs to search for ioctls, discover them dynamically with newer kernel trees by working off of the exported header mechanism. If the kernel does not have this mechanism, we fall back to the old method of hard coding the list. This fixes issues where the current hard coded list does not contain all headers which get exported to userspace (like the mtd ioctls). Signed-off-by: Mike Frysinger <va...@ge...> --- linux/ioctlent.sh | 14 +++++++++++++- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/linux/ioctlent.sh b/linux/ioctlent.sh index cff6145..479eed4 100644 --- a/linux/ioctlent.sh +++ b/linux/ioctlent.sh @@ -68,7 +68,19 @@ lookup_ioctls '7[12]' linux/videotext.h lookup_ioctls 89 $asm/sockios.h linux/sockios.h lookup_ioctls 8B linux/wireless.h -files="linux/* $asm/* scsi/* sound/*" +if [ -e $dir/Kbuild ] ; then + # kernel has exported user space headers, so query only them + files=$( + cd $dir + find . -mindepth 2 -name Kbuild | \ + sed -e 's:^\./::' -e 's:/Kbuild:/*:' | \ + grep -v '^asm-' + echo "$asm/* asm-generic/*" + ) +else + # older kernel so just assume some headers + files="linux/* $asm/* scsi/* sound/*" +fi # Build the list of all ioctls regexp='^[[:space:]]*#[[:space:]]*define[[:space:]]\+[A-Z][A-Z0-9_]*[[:space:]]\+_S\?\(IO\|IOW\|IOR\|IOWR\)\>' -- 1.6.1.3 |
From: Denys V. <dvl...@re...> - 2009-02-22 02:59:26
|
Hi Mike, On Fri, 2009-02-20 at 12:56 -0500, Mike Frysinger wrote: > Rather than hard coding the subdirs to search for ioctls, discover them > dynamically with newer kernel trees by working off of the exported header > mechanism. If the kernel does not have this mechanism, we fall back to > the old method of hard coding the list. > > This fixes issues where the current hard coded list does not contain all > headers which get exported to userspace (like the mtd ioctls). I searched the tree and apparently there is no documentation whatsoever on what ioctlent.sh is and how to use it. I assume it is used to refresh ioctldefs.h from time to time. However, I only _assume_, and you apparently actually used it recently. Can you write up a little explanation/HOWTO about it? I intend to add it to the cvs. I also will use it to validate future patches for ioctlent.sh. -- vda |
From: Mike F. <va...@ge...> - 2009-02-22 04:18:39
|
On Saturday 21 February 2009 21:59:18 Denys Vlasenko wrote: > On Fri, 2009-02-20 at 12:56 -0500, Mike Frysinger wrote: > > Rather than hard coding the subdirs to search for ioctls, discover them > > dynamically with newer kernel trees by working off of the exported header > > mechanism. If the kernel does not have this mechanism, we fall back to > > the old method of hard coding the list. > > > > This fixes issues where the current hard coded list does not contain all > > headers which get exported to userspace (like the mtd ioctls). > > I searched the tree and apparently there is no documentation > whatsoever on what ioctlent.sh is and how to use it. if there is docs, i wish i knew about them ;). it took me a while to figure out how to use those things. in general strace seems to be lacking docs, so to get started requires reading a lot of source and mucking with stuff. but this seems to be par for the course with anything ptrace related. > I assume it is used to refresh ioctldefs.h from time to time. > > However, I only _assume_, and you apparently actually used it recently. each of the .sh scripts in the tree is used to generate/update the related list > Can you write up a little explanation/HOWTO about it? > I intend to add it to the cvs. np -mike |
From: Denys V. <dvl...@re...> - 2009-02-23 13:24:29
|
On Fri, 2009-02-20 at 12:56 -0500, Mike Frysinger wrote: > Rather than hard coding the subdirs to search for ioctls, discover them > dynamically with newer kernel trees by working off of the exported header > mechanism. If the kernel does not have this mechanism, we fall back to > the old method of hard coding the list. > > This fixes issues where the current hard coded list does not contain all > headers which get exported to userspace (like the mtd ioctls). Thanks to your HACKING-scripts, I could test it and confirm that this is an improvement. Committed all three patches to cvs. Added HACKING-scripts too. Did some editing after apply, please test current cvs. Thanks! -- vda |
From: Mike F. <va...@ge...> - 2009-02-23 17:37:19
|
On Monday 23 February 2009 08:24:19 Denys Vlasenko wrote: > On Fri, 2009-02-20 at 12:56 -0500, Mike Frysinger wrote: > > Rather than hard coding the subdirs to search for ioctls, discover them > > dynamically with newer kernel trees by working off of the exported header > > mechanism. If the kernel does not have this mechanism, we fall back to > > the old method of hard coding the list. > > > > This fixes issues where the current hard coded list does not contain all > > headers which get exported to userspace (like the mtd ioctls). > > Thanks to your HACKING-scripts, I could test it and confirm that this is > an improvement. > > Committed all three patches to cvs. Added HACKING-scripts too. > Did some editing after apply, please test current cvs. other than the helper comments in the *ent.sh scripts pointing people to the HACKING-scripts file ... at least for me, when i want to do know what something does, i tend to do: - run it with help options ... script doesnt accept help or sits there waiting for input ... - read the file ... script doesnt have any useful information in it ... - start grepping the tree looking for hints ... generated files show up as well as HACKING-scripts ... that's why i found the simple comment in each script useful ... -mike |