Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Kamil Rytarowski
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 IOCOTH

Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Mouse
> 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

Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Kamil Rytarowski
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 s

Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Mouse
>>> $ 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 nu

Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Christos Zoulas
> 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

Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Kamil Rytarowski
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 c

Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Kamil Rytarowski
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

Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Mouse
> $ 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 part

Re: New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Christos Zoulas
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

New tools proposal: ioctlname and ioctldecode

2020-04-01 Thread Kamil Rytarowski
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