Date: Sun, 20 Jul 1997 10:46:36 -0700 (PDT) From: Chris Timmons <skynyrd@opus.cts.cwu.edu> To: freebsd-hackers@freebsd.org Subject: suggested enhancement: linux_ioctl.c diagnostic output Message-ID: <Pine.BSF.3.95.970720102920.26163B-100000@opus.cts.cwu.edu>
next in thread | raw e-mail | index | archive | help
I tried to get some comments about this from -emulation but perhaps the
subject line wasn't to the point enough.
If you read down to the end I've sketched out a proposed change to
linux_ioctl.c. I'd like to know:
1. Overall is this a worthwile change?
2. Is the long comment which documents linux ioctl encoding
inappropriate for this source file?
3. I see from style(9) that I should have spaces between the
operands to the bitwise and operator. What about the
style of the nested conditional? I guess there might also be
some unnecessary parens in the printf argument list.
-Chris
---------- Forwarded message ----------
Date: Fri, 11 Jul 1997 16:44:56 -0700 (PDT)
From: Chris Timmons <skynyrd@opus.cts.cwu.edu>
To: freebsd-emulation@freebsd.org
Subject: Linux StreamWorks player; diagnostic output suggestion
While running down an emulation problem with the Linux/Elf StreamWorks
Audio player, I've done some thinking about the way in which our
diagnostic output for unimplemented ioctls is formatted by linux_ioctl.c
in the linux emulator source. Please comment on what I've got below; if
no-one strenuously objects I will send-pr it as a patch.
The problem with StreamWorks Audio Player is that it wants to use ioctl
commands not present in our VoxWare 3.0 sound driver system. The calls in
question are available in the VoxWare v3.5-alpha5 driver which I am
running on my 2.2-STABLE system courtesy work done by Amancio Hasty and
Brian Litzinger (and probably others whom I am unaware of but thank
nonetheless.) I am going to ask around on the -multimedia list if I can
be of help integrating VoxWare v3.5-alpha5 into -current so that I can
then prepare and submit the appropriate emulation mappings in
linux_ioctl.c.
linux_ioctl.c DIAGNOSTIC OUTPUT
-------------------------------
I think the goal of the diagnostic output should be to give the end user
something meaningful to put into a send-pr. Here is what I was seeing
from the StreamWorks player.:
LINUX: 'ioctl' fd=8, typ=0xc50(P), num=0x12 not implemented
This contains good information, but to run this down you really have to
use ktrace and have an understanding of linux ioctl encoding to get enough
information to be able to start digging in the linux sources. You can't
tell the mode of the request, only get a nibble of the parameter size, and
aren't left with something that resembles an ioctl definition.
I've modified the uprintf call to do a little bit more formatting, so that
the output is now formatted like this:
LINUX: unimplemented ioctl: fd=8, cmd=0x800c5012 (IOR, 'P', 18, 12)
We now see the full command word, the mode and also the size parameter
presented in more or less the way it would appear in the source which
defines the ioctl itself. See the comment in my code about non-printing
characters.
In evaluating this change I would say that a drawback is more execution
time if you're caught in a tight loop featuring an unimplemented ioctl,
and also a more complex printf featuring the cryptic conditional operator.
In the case of the former, probably the extra overhead is negligible,
particularly because if you're executing it at all you have bigger
problems :)
I respect the fact that comments in the code are sparse because the code
is self documenting. Would this comment be inappropriate? Presumably
someone like I will have another emulation problem someday and come
looking for clues - this will save time downloading the linux kernel
sources, at least :)
Proposed code snippet for the 'unimplemented ioctl' section of
linux_ioctl.c:
/*
* Linux i386 IOCTL commands are 32 bits total, and at the source
* level are encoded with the familiar _IO, _IOR, _IOW, and _IOWR
* macros. The Linux binary encoding of the upper 16 bits differs
* from that used by FreeBSD as follows: Like FreeBSD the lower 16
* bits contain the command while the higher 16 bits store the mode
* and size of any parameter structures. FreeBSD's encoding scheme
* is found in <sys/ioccom.h>.
*
* In Linux binary encoding, the highest two bits of the most
* significant 16 correspond to mode:
*
* 00 _IO (no parameters)
* 01 _IOW (copy in parameters)
* 10 _IOR (copy out parameters)
* 11 _IOWR (copy in/copy out parameters)
*
* The remaining 14 bits of this word store the size of any
* parameter structures.
*
* Many of the IOCTL codes found in the upper 8 bits of the lower 16
* conveniently correspond to ascii characters and are actually
* represented that way by convention in source code. We print them
* that way below, but there are codes that map to non-printing
* characters.
* Printing undefined characters in diagnostic output isn't a very nice
* thing to do, but the alternative is either to omit entirely or be
* much more complex than is appropriate. The non-printing codes can
* still be seen in the cmd= output that shows all 32 bits.
*
*/
uprintf("LINUX: unimplemented ioctl: fd=%d, cmd=0x%lx (%s, '%c', %lu,
%lu)\n",
args->fd, args->cmd,
(args->cmd&0xc0000000)
? (args->cmd&0xc0000000) == 0x80000000
? "IOR"
: (args->cmd&0xc0000000) == 0x40000000
? "IOW"
: "IOWR"
: "IO",
/* ick - risk printing the unprintable */
(char)((args->cmd&0x0000ff00)>>8),
args->cmd&0xff,
(args->cmd&0x3fff0000) >> 16);
return EINVAL;
}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970720102920.26163B-100000>