From owner-freebsd-emulation Fri Jul 11 16:45:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA09762 for emulation-outgoing; Fri, 11 Jul 1997 16:45:00 -0700 (PDT) Received: from pahtoh.cwu.edu (root@pahtoh.cwu.edu [198.104.65.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA09757 for ; Fri, 11 Jul 1997 16:44:57 -0700 (PDT) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by pahtoh.cwu.edu (8.8.5/8.8.5) with ESMTP id QAA27171 for ; Fri, 11 Jul 1997 16:44:57 -0700 (PDT) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.6/8.8.5) with SMTP id QAA23567 for ; Fri, 11 Jul 1997 16:44:56 -0700 (PDT) Date: Fri, 11 Jul 1997 16:44:56 -0700 (PDT) From: Chris Timmons Reply-To: Chris Timmons To: freebsd-emulation@freebsd.org Subject: Linux StreamWorks player; diagnostic output suggestion Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 . * * 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; }