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:
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.
Th
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
> 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
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
>>> $ 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
> 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
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
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
> $ 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
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
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
12 matches
Mail list logo