Re: oskit driver for i8042 keyboard controller
On Thu, Nov 07, 2002 at 01:43:28PM -0500, Roland McGrath wrote: > > Confirmed. What is the non-bus-walk name of these devices (just curious)? > > What do you mean? Devices don't have flat names. The names like "eth0" > and so forth are compatibility hacks in bus_walk_from_compat_string. I thought the bus walk was to find a leaf in a hierarchy of devices, where the bus is a top node of the devices on the bus. Ie, like "i8042:kbd" etc. But that might be pure fiction, I never really groked the way devices are organized in oskit. > > Ah, which reminds me that I still use device_read and not > > device_read_inband, in my kbd driver. > > Well that's just silly. But they should both work. Yeah, I just c&p'ed that line from some other place. > > Writing of the bytes doesn't seem to work properly, I set up streamio > > (cat'ing from that works fine), and then I tried > > > > echo $'\xED\x07' > kbd > > The examples/x86/i8042 test program does just that, and it works (lights go > on). So this must be a problem interacting with oskit-mach. Ok, I will go into the debugging. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/ ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
arbitrary IDs with available UID 0?
Hi, The doc says that you are allowed to create auth objects associated with any IDs if you have euid 0, and the code actually allows it even if only auid 0. (Because isroot() uses isuid() and isuid() allows both). Is the code wrong or the documentation? I think we should fix the code. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/ ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: oskit driver for i8042 keyboard controller
> I thought the bus walk was to find a leaf in a hierarchy of devices, where > the bus is a top node of the devices on the bus. Ie, like "i8042:kbd" etc. > But that might be pure fiction, I never really groked the way devices are > organized in oskit. That is right, it's a tree where the non-leaf nodes are called busses. Stick a call to oskit_dump_devices(); in after the probe in an oskit kernel, and it will show you the whole tree. Some of the example kernels do this. In oskit-mach, we only probe on demand in device lookup, so you'd have to insert an early oskit_bus_probe (osenv_rootbus_getbus ()); call to see anything from oskit_dump_devices. The probe happens in oskit_bus_walk_lookup (or bus_walk_from_compat_string), the first time device_open is done on something other than "console", "kmsg", "time", or "mem". The silly "bus device" interface in oskit/ds_bus.c lets you do the dump yourself from the Hurd, e.g. "storecat -Tdevice @" to see the root bus. That produces a silly syntax that is reasonably understandable from looking at it, and should be trivially machine-parseable. >From there you can see each of the busses (pci, ide or scsi controllers, etc) and with "storecat -Tdevice @pci" or whatever you can follow each node and walk the tree yourself. Once you look at the tree, and read oskit/unsupported/bus_walk_lookup.c for the big comment at the start about the bus-walk syntax, I think it will all make sense. I added the ds_bus.c hack as a minimal kludge interface for the kernel to report device information that could be used to write a user-level device manager thingie as a translator for a virtual filesystem or whatever you like. For user-level drivers, such a program would be the central server for managing hardware io resources and such. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: arbitrary IDs with available UID 0?
> The doc says that you are allowed to create auth objects associated with any > IDs if you have euid 0, and the code actually allows it even if only auid 0. > > (Because isroot() uses isuid() and isuid() allows both). I think it needs to be fixed. In POSIX.1, seteuid(123) should not work if your euid!=0 and your ruid==0 (and 123 is some unrelated uid). ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: oskit driver for i8042 keyboard controller
Roland McGrath <[EMAIL PROTECTED]> writes: > In oskit-mach, we only probe on demand in device lookup, so you'd have to > insert an early oskit_bus_probe (osenv_rootbus_getbus ()); call to see > anything from oskit_dump_devices. This is an interesting strategy. Long ago, I recall there being devices on a Vax that you couldn't reliably probe this way, because the bus could hang for several seconds during the probe for various reasons. It also prevents the auto-detection of interrupt number, doesn't it? You'd have to turn off all other interrupts, and tickle the device. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: arbitrary IDs with available UID 0?
Marcus Brinkmann <[EMAIL PROTECTED]> writes: > The doc says that you are allowed to create auth objects associated with any > IDs if you have euid 0, and the code actually allows it even if only auid 0. > > (Because isroot() uses isuid() and isuid() allows both). > > Is the code wrong or the documentation? I think we should fix the code. It seems to me that it's much cleaner to fix the code, so that auids are really *not* used for anything. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: oskit driver for i8042 keyboard controller
> This is an interesting strategy. Long ago, I recall there being > devices on a Vax that you couldn't reliably probe this way, because > the bus could hang for several seconds during the probe for various > reasons. In practice, the probe always happens very early. The first time a device_open is done for the root disk, that probes the root bus and that recurses on the busses for controllers it finds and so forth. Anyway, this kind of question is for the device manager thingie to worry about in the long run. Conceptually, the kernel should not be thinking about peripheral hardware, and the device interfaces in oskit-mach are just a makeshift solution putting in the kernel what only works in the kernel right now, and a Hurdish user-level layer should cover the ugly innards. > It also prevents the auto-detection of interrupt number, doesn't it? > You'd have to turn off all other interrupts, and tickle the device. This is the business of the driver to figure out, in the oskit interfaces. It doesn't really have to turn off all interrupts, it can just install its special probe interrupt handler on all the canditate irqs that are not already taken by other devices that won't share. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: oskit driver for i8042 keyboard controller
On Thu, Nov 07, 2002 at 01:43:28PM -0500, Roland McGrath wrote: > > Writing of the bytes doesn't seem to work properly, I set up streamio > > (cat'ing from that works fine), and then I tried > > > > echo $'\xED\x07' > kbd > > The examples/x86/i8042 test program does just that, and it works (lights go > on). So this must be a problem interacting with oskit-mach. Ok, it works just after boot. But then reading doesn't work. The reason is a reference leak somewhere in the glue code. There are three additional references to the device in whatever open mode you used the first time when looking it up. Subsequent opens will try the cache lookup first, but if it's not the same open mode, it won't succeed. Then it tries to reopen it with the new open modes, but this fails of course, because kbd/aux can only be opened once. it won't be a problem in my console, as I am opening it once with read/write permission. But of course it needs to be fixed. I don't know where the three references come from. They are not increased by subsequent open/close, so they might come from the code that creates and enters the device, not sure. I would need to do more debugging if it isn't something obvious to you. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/ ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: oskit driver for i8042 keyboard controller
> it won't be a problem in my console, as I am opening it once with read/write > permission. But of course it needs to be fixed. I don't know where the > three references come from. They are not increased by subsequent > open/close, so they might come from the code that creates and enters the > device, not sure. I would need to do more debugging if it isn't something > obvious to you. Hmm, that's not obvious to me off hand. I would have to go debug it myself to get a handle on it. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: oskit driver for i8042 keyboard controller
On Fri, Nov 08, 2002 at 06:26:09PM -0500, Roland McGrath wrote:
> > it won't be a problem in my console, as I am opening it once with read/write
> > permission. But of course it needs to be fixed. I don't know where the
> > three references come from. They are not increased by subsequent
> > open/close, so they might come from the code that creates and enters the
> > device, not sure. I would need to do more debugging if it isn't something
> > obvious to you.
>
> Hmm, that's not obvious to me off hand. I would have to go debug it myself
> to get a handle on it.
Ok, I can try to find out where the references come from.
We have some good and some bad news. The good news is that I now have a
hacked pc kbd driver for scancode set 2, and also implemented the kbd led
thingie. Because the console already supported this, everything works now,
not only local state like caps lock and num lock, but also external state like
scroll lock (which is per VC). So that was quite easy. I now have to clean
up the code to not rely on the big #ifdef, and maybe I will also add a
feature to set kbd rate/delay while I am at it. That would make it quite
usable already.
The bad news is that there are bugs ;)
Right now what I am doing is to read from kbd byte by byte. I will change
it to read many bytes at once (as much as the internal buffer is), and then
process the local buffer first, before reading more. However, reading byte
by byte should also work I would think. The bug I am seeing is that one
byte gets stuck:
I just released a key (let's say "p"), but I only read F0. When I press the
next key ("q") down, the scancode for "p" is read. The next read does probably
not return anything (hard to say because of key repeat) until I release the
key, then I can read two bytes, the scancode for the key I pressed ("q") and
the "F0" of releasing the "q". The "q" for the release is only read with
the next key press etc. It works before I press CAPS but not afterwards.
Roland, is there a problem with writing to the device while the user presses
keys? maybe there is some race there.
Another serious bug is that my I/O permission stuff is not working properly.
There seems to be a race of some sort. Sometimes I just get SIGILL when
writing to VGA ports. The VGA ports are higher than the speaker ports.
When and where this happens is entirely random. I guess I have to set up a
break point in the kernels SIGILL handler or so, and check out the processor
state. Of course it could be something very subtle like the need to flush
or update something after installing the IO ports at a task switch. Or
maybe it's just that I am not pausing (I am using out, not out_p, but I
think that should work, and not cause a SIGKILL anyway).
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED]
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de/
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: oskit driver for i8042 keyboard controller
> Ok, I can try to find out where the references come from. Please do. > Right now what I am doing is to read from kbd byte by byte. I will change > it to read many bytes at once (as much as the internal buffer is), and then > process the local buffer first, before reading more. However, reading byte > by byte should also work I would think. Yes, it should. The only issue should be if you aren't keeping up with draining the internal buffer. > I just released a key (let's say "p"), but I only read F0. I tried to reproduce this with the examples/x86/i8042.c test program and tweaks of it, but could not in the few minutes I spent trying. I have appended the hacked version of the test program, which cycles the LED state frequently (tweak foo in gdb to adjust how fast) so you can try to type at the same time and see if they interfere. It is entirely possible there is a bug in the driver with this. When you do a write, the driver puts that in its tiny output queue (8 bytes), and sends it out the port. Then it watches the input bytes to notice 0xfa or 0xfe, which are the device ACK/NAK of each command byte, and eats the 0xfa or 0xfe bytes until it has ACKs for all the bytes it sent (output queue is drained). As it is now, it delivers the final 0xfa byte as data, which tells you your full command was received by the keyboard; you will read one 0xfa for each oskit_stream_write you did, but actually in oskit-mach the code in oskit/ds_asyncio.c will pause in the middle of your device_write buffer and do another oskit_stream_write when the queue drains, so if there are multiple asynchronous device_writes going on you are really getting an 0xfa for each time the output buffer filled + 1. I think probably I should just make it eat the final 0xfa as well. Change to "break;" to "continue;" in "case KBC_DEVCMD_ACK:" to make that happen. It would be ideal if you could find a way to tweak this test program and a pattern of using it that produces a problem. That stuff I can debug right now. If not, it might actually be an interaction with the oskit-mach glue code. If working oskit-mach and hurd are required to debug it, I won't get to it as soon. > Another serious bug is that my I/O permission stuff is not working properly. > There seems to be a race of some sort. In that case you really want to put a bkpt at i386_exception or suchlike and find exactly what is happening. > Of course it could be something very subtle like the need to flush or > update something after installing the IO ports at a task switch. It looks to me like the switching code does the very same thing I see in the Linux sources. > Or maybe it's just that I am not pausing (I am using out, not out_p, but > I think that should work, and not cause a SIGKILL anyway). Figure out what machine trap is happening and all the available machine state at the time before speculating more. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: oskit driver for i8042 keyboard controller
Roland McGrath <[EMAIL PROTECTED]> writes: > Anyway, this kind of question is for the device manager thingie to worry > about in the long run. Conceptually, the kernel should not be thinking > about peripheral hardware, and the device interfaces in oskit-mach are just > a makeshift solution putting in the kernel what only works in the kernel > right now, and a Hurdish user-level layer should cover the ugly innards. Of course it belongs not in the kernel. The interesting problems happen regardless of which piece of software is doing the task, however. > > It also prevents the auto-detection of interrupt number, doesn't it? > > You'd have to turn off all other interrupts, and tickle the device. > > This is the business of the driver to figure out, in the oskit interfaces. > It doesn't really have to turn off all interrupts, it can just install its > special probe interrupt handler on all the canditate irqs that are not > already taken by other devices that won't share. Well, on a Vax at least, you could usually jumper any device to interrupt on any IRQ you liked. On a Microvax typical devices had a smaller but still fairly configurable range. On a PC, it's usually much more limited, but sharing is *very* important. So how do you handle that? It seems like you still will have to turn off any device that might conflict. It won't be the whole bus like a Vax, but it will still be something. > In practice, the probe always happens very early. The first time a > device_open is done for the root disk, that probes the root bus and that > recurses on the busses for controllers it finds and so forth. Hrm. Sure, that's fine for the main hard disk. But what about some occasionally-used peripheral? The first time I open the CD writer which lives on its own IDE controller: I don't want that to cause the whole system to pause for a second. And worse yet, I fear, is when you try to open a device that isn't there, but you don't get I/O errors when you poke at at: then you have to time out waiting for the interrupt. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
