On Fri, 19 Jun 2015, Johnny Billquist wrote: > On 2015-06-19 11:45, Edgar Fu?? wrote: > > > "Runs on kernel stack in kernel space" is not the same thing as the Linux > > > concept of bottom half. :-) > > I don't know what the Linux (or VMS or Windows) concept of "nottom half" is. > > I thought I knew what the BSD concept of kernel halves is. > > I can't comment on Windows - I have no idea. > VMS uses a very different solution, so it don't make much sense to talk about > that here (or at least the parts that I know, which might be outdated). > > If I remember Linux right, they have a fixed list of registered bottom half > handlers (which of course ran out of space a long time ago), and then through > some tricks extended it to be more general, but in essence the bottom half is > the part of the device driver that runs after an interrupt to complete an I/O > request. The top half being also running in the kernel, but in the context of > a process that does the I/O, and the top half blocks until the I/O completes. > And the bottom half is the part the unblocks the top half again. And each > driver has its own bottom and top halves. One major point of the bottom halves > is that when running the bottom half, interrupts are not blocked. A device > driver normally do only a minimal amount of work in the interrupt handler > itself, and then defer the rest of the work to the bottom half code, which > will run at some later time. > > Of course, I could be remembering this all wrong, and it might be outdated as > well. So take what I write with a grain of salt. Or rather, read up on it in a > Linux book instead. > > I would say the bottom half concept in Linux is close to the softint stuff in > NetBSD. But I might be wrong on that one, as I don't remember all the details > of that either right now.
From what I remember the BSD book talks about the "top half" and "bottom half" of the driver, not just interrupt dispatch the way linux does. On linux, the top half of the interrupt handler runs in interrupt context, either preempting a kernel thread on the kernel stack or on a separate interrupt stack depending on the particular architecture. The bottom half of an interrupt handler is basically a softint that runs on a kernel stack. In general, you register a top half handler to acknowledge the interrupt. If the interrupt has any notable amount of processing to do or needs to fiddle with locks, the top half schedules a bottom half interrupt to do that. In addition to that you can have code that runs in a kernel thread, and you can have code that runs in the kernel in process context as the result of a system call. It's been a while since I fiddled with interrupts on NetBSD, but ISTR we now schedule an interrupt thread to do all of the processing so there is no equivalent of the linux interrupt top half and interrupt bottom half. Or is that Solaris? I forget. Eduardo