Re: New tools proposal: ioctlname and ioctldecode
In article <2096.1585816...@jinx.noi.kre.to>, Robert Elz wrote: >Date:Thu, 2 Apr 2020 04:11:17 +0200 >From:Kamil Rytarowski >Message-ID: > > | This is partially enforceable. As once we generate catchall switch like: > | > | case FOO_OP: > | ... > | case BAR_OP: > | ... > | > | a compiler will report error whenever FOO_OP = BAR_OP. > >That makes it easy to detect, not enforce. Once detected that way, >what happens next? Neither will (or can really) change as they both >have existing applications compiled that use them - in the worse case >the conflicts come from attempting to implement compat mode for someone >else's binaries, and support their existing ioctl's (which we obviously >cannot alter) - and do that for two different systems at once. > >This is the same reason we cannot fix the few duplicates that exist in >our code - we want to retain backward binary compatibility, which means >supporting ancient binaries that happen to use those ioctl values. > >Avoiding conflicts is (always has been) the aim - it allows drivers to >detect attempts to use an ioctl intended for some different device, rather >than believing it was intended for them, but there simply isn't, and can't >really be, any way to enforce that. > >kre > >ps: don't forget all the sockioctl()s which also need decoding. Perhaps >even more than device ioctls. We already have a lot of dups. See the mkioctls script. christos
Re: New tools proposal: ioctlname and ioctldecode
Date:Thu, 2 Apr 2020 04:11:17 +0200 From:Kamil Rytarowski Message-ID: | This is partially enforceable. As once we generate catchall switch like: | | case FOO_OP: | ... | case BAR_OP: | ... | | a compiler will report error whenever FOO_OP = BAR_OP. That makes it easy to detect, not enforce. Once detected that way, what happens next? Neither will (or can really) change as they both have existing applications compiled that use them - in the worse case the conflicts come from attempting to implement compat mode for someone else's binaries, and support their existing ioctl's (which we obviously cannot alter) - and do that for two different systems at once. This is the same reason we cannot fix the few duplicates that exist in our code - we want to retain backward binary compatibility, which means supporting ancient binaries that happen to use those ioctl values. Avoiding conflicts is (always has been) the aim - it allows drivers to detect attempts to use an ioctl intended for some different device, rather than believing it was intended for them, but there simply isn't, and can't really be, any way to enforce that. kre ps: don't forget all the sockioctl()s which also need decoding. Perhaps even more than device ioctls.
Re: New tools proposal: ioctlname and ioctldecode
On 02.04.2020 04:06, Mouse wrote:
>> We should maintain a contract that all new ioctl operations are
>> system wide unique.
>
> That is, unfortunately, unenforceable in the presence of a user base
> that writes and shares code. If I #define IOCNEWTHING _IO('?',7) and
> someone else #defines IOCOTHERTHING _IO('?',7), there really isn't any
> way to prevent that, nor to prevent them from conflicting when - and
> eventually it will happen - someone wants to run a system with both new
> thing and other thing.
>
This is partially enforceable. As once we generate catchall switch like:
case FOO_OP:
...
case BAR_OP:
...
a compiler will report error whenever FOO_OP = BAR_OP.
Re: New tools proposal: ioctlname and ioctldecode
> We should maintain a contract that all new ioctl operations are
> system wide unique.
That is, unfortunately, unenforceable in the presence of a user base
that writes and shares code. If I #define IOCNEWTHING _IO('?',7) and
someone else #defines IOCOTHERTHING _IO('?',7), there really isn't any
way to prevent that, nor to prevent them from conflicting when - and
eventually it will happen - someone wants to run a system with both new
thing and other thing.
/~\ 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: New tools proposal: ioctlname and ioctldecode
On 02.04.2020 03:33, Mouse wrote: $ ioctlname 2148554498 WSKBDIO_COMPLEXBELL >>> Where would you get the mapping between the ioctl value and the >>> name? [...] >> Everything is already done in kdump and reused in other tools like >> ktruss. > > So, the big switch() method. > Yes. We should maintain a contract that all new ioctl operations are system wide unique. >>> What about collisions, two ioctls having the same numeric value? >> There are some collisions, but not that many of them. In these cases >> we try to pick the more interesting device. > > For kdump, that makes some sense. For this tool, I think it would make > the most sense to report them all. (Arguably, kdump should too...) > > Of course, that would mean changing things at least slightly from the > current kdump approach. I'm not sure that would necessarily be a bad > thing, especially if we could somehow (major handwave here) tell which > ioctls go together, in which case kdump could do heuristics along the > lines of "this fd accepted FOO_IOC_A, so we're going to decode this one > as FOO_IOC_B rather than BAR_IOC_C". > This would be ideal... however it's not that simple and I would recommend to go with the path of removing the conflicts entirely for the general benefit. For the time being we just live with conflicts and ignore a subset of operations. From a quick look there are conflicts e.g. due to chio(1) a SCSI charger added in NetBSD 1.3 for and.com. Are there still any users?
Re: New tools proposal: ioctlname and ioctldecode
>>> $ ioctlname 2148554498 >>> WSKBDIO_COMPLEXBELL >> Where would you get the mapping between the ioctl value and the >> name? [...] > Everything is already done in kdump and reused in other tools like > ktruss. So, the big switch() method. >> What about collisions, two ioctls having the same numeric value? > There are some collisions, but not that many of them. In these cases > we try to pick the more interesting device. For kdump, that makes some sense. For this tool, I think it would make the most sense to report them all. (Arguably, kdump should too...) Of course, that would mean changing things at least slightly from the current kdump approach. I'm not sure that would necessarily be a bad thing, especially if we could somehow (major handwave here) tell which ioctls go together, in which case kdump could do heuristics along the lines of "this fd accepted FOO_IOC_A, so we're going to decode this one as FOO_IOC_B rather than BAR_IOC_C". I suppose that's the hazard of catchall interfaces like ioctl(): they are difficult to make usefully discoverable. /~\ 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: New tools proposal: ioctlname and ioctldecode
> On Apr 1, 2020, at 9:27 PM, Kamil Rytarowski wrote:
>
> I've implemented:
>
> ioctlprint [-f format] [-e emul] arg...
>
> $ ./ioctlprint 2148554498 2148554498
> WSKBDIO_COMPLEXBELL _IOW('W',0x2,0x10) 0x80105702
> WSKBDIO_COMPLEXBELL _IOW('W',0x2,0x10) 0x80105702
>
> $ ./ioctlprint -f "%o %d %d %i %x %e %n\n" 2148554498
> 020004053402 2148554498 2148554498 2148554498 0x80105702
> _IOW('W',0x2,0x10) WSKBDIO_COMPLEXBELL
>
> %n - name
> %e - expression
> %x - print HEX number
> %o - print OCT number
> %d %i - print DEC number
>
> http://netbsd.org/~kamil/patch-00245-kdump-ioctlname.3.txt
You are fast! I'd write a man page and commit it.
christos
signature.asc
Description: Message signed with OpenPGP
Re: New tools proposal: ioctlname and ioctldecode
On 02.04.2020 02:14, Christos Zoulas wrote:
> In article <0fd513f7-6f0c-6ed1-2119-6ce5313d4...@gmx.com>,
> Kamil Rytarowski wrote:
>> I propose to add two new tools:
>>
>> - ioctlname
>> - ioctldecode
>
> I would call it ioctlprint and have:
>
> ioctlprint [-f ] || arg
>
> for the input arg can be:
> name = TIOCFOO
> expr = _IO?('x', y, z)
> value = 0xfoobee
>
> The format can be contain %e %n %v which expand to what you
> think and defaults to:
>
> "%n %e %v\n"
>
> christos
>
I've implemented:
ioctlprint [-f format] [-e emul] arg...
$ ./ioctlprint 2148554498 2148554498
WSKBDIO_COMPLEXBELL _IOW('W',0x2,0x10) 0x80105702
WSKBDIO_COMPLEXBELL _IOW('W',0x2,0x10) 0x80105702
$ ./ioctlprint -f "%o %d %d %i %x %e %n\n" 2148554498
020004053402 2148554498 2148554498 2148554498 0x80105702
_IOW('W',0x2,0x10) WSKBDIO_COMPLEXBELL
%n - name
%e - expression
%x - print HEX number
%o - print OCT number
%d %i - print DEC number
http://netbsd.org/~kamil/patch-00245-kdump-ioctlname.3.txt
Re: New tools proposal: ioctlname and ioctldecode
On 02.04.2020 02:56, Mouse wrote:
>> $ ioctldecode 2148554498
>> _IOW('W',0x2,0x10)
>
>> $ ioctlname 2148554498
>> WSKBDIO_COMPLEXBELL
>
> Where would you get the mapping between the ioctl value and the name?
> Would this be just a huge switch statement (or compiled-in table), or
> would it search /usr/include/sys at runtime, or what?
>
> In particular, would any special action need to be taken upon adding a
> new ioctl for it to be recognized?
>
Everything is already done in kdump and reused in other tools like
ktruss. Please check: src/usr.bin/kdump/Makefile.ioctl-c.
> What about collisions, two ioctls having the same numeric value? (I'm
> not aware of any offhand, but I'd be astonished if it never happened.)
>
There are some collisions, but not that many of them. In these cases we
try to pick the more interesting device.
In sanitizers there are around 2000 individual ioctls and 51 collisions.
Some of them are gone as we remove old unmaintained device drivers.
Re: New tools proposal: ioctlname and ioctldecode
> $ ioctldecode 2148554498
> _IOW('W',0x2,0x10)
> $ ioctlname 2148554498
> WSKBDIO_COMPLEXBELL
Where would you get the mapping between the ioctl value and the name?
Would this be just a huge switch statement (or compiled-in table), or
would it search /usr/include/sys at runtime, or what?
In particular, would any special action need to be taken upon adding a
new ioctl for it to be recognized?
What about collisions, two ioctls having the same numeric value? (I'm
not aware of any offhand, but I'd be astonished if it never happened.)
/~\ 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: New tools proposal: ioctlname and ioctldecode
In article <0fd513f7-6f0c-6ed1-2119-6ce5313d4...@gmx.com>,
Kamil Rytarowski wrote:
>I propose to add two new tools:
>
> - ioctlname
> - ioctldecode
I would call it ioctlprint and have:
ioctlprint [-f ] || arg
for the input arg can be:
name = TIOCFOO
expr = _IO?('x', y, z)
value = 0xfoobee
The format can be contain %e %n %v which expand to what you
think and defaults to:
"%n %e %v\n"
christos
New tools proposal: ioctlname and ioctldecode
I propose to add two new tools:
- ioctlname
- ioctldecode
Both of them are a special mode embedded into kdump(1).
>From time to time there is need to decode IOCTL codes and there is no
(as far as I am aware) easy tool to do so.
ioctlname is already invented and it calls the internal function
ioctldecode().
commit f551b480cd03a35cec2a4927270c00cfaa508a27
Author: christos
Date: Mon Apr 13 14:39:23 2009 +
Allow kdump to be used as an ioctl decoder if invoked as ioctlname.
Today the internal/hidden program ioctlname produces something like:
"_IOW('W',0x2,0x10)".
I propose to rename this program to ioctldecode and change ioctlname to
print a descriptive operation name as received by the ioctlname() function.
$ ioctldecode 2148554498
_IOW('W',0x2,0x10)
$ ioctlname 2148554498
WSKBDIO_COMPLEXBELL
I propose to install both programs and add appropriate man-pages.
A functional patch is here:
http://netbsd.org/~kamil/patch-00245-kdump-ioctlname.2.txt
