Date: 28 Mar 2005 15:13:52 -0500 From: Lowell Gilbert <freebsd-questions-local@be-well.ilk.org> To: Bahadir Balban <kirmizimantar@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: definition of soft/hard interrupts. Message-ID: <44hdiv34vz.fsf@be-well.ilk.org> In-Reply-To: <b2f65cdb05032706505921e93a@mail.gmail.com> References: <b2f65cdb05032706505921e93a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bahadir Balban <kirmizimantar@gmail.com> writes: > In "The design and implementation of 4.4BSD", the execution of I'm not sure this affects any of your particular questions, but that book is definitely outdated at this point... > workqueues, some timer events and scheduling are referred to as > "software interrupts", as well as system calls. I thought only system > calls would be in "soft interrupt" category as they are initiated with > a software interrupt instruction. A software interrupt actually has its own process context that runs within the lower half of the kernel. Device interrupts are usually handled by packaging the event and passing it to a software interrupt context for handling. I don't think it has to be implemented with a CPU software interrupt instruction. > By my definition, a hardware interrupt is one that is notified by the > interrupt controller, and to my knowledge, timer events are hardware > interrupts. Am I wrong? > > There's also a softclock and hardclock defined. It is as if, an > interrupt handler for an interrupt reported on the controller, is > termed as "hard", but a low-priority workqueue initiated by a later > timer event is called as a "software interrupt" here. The distinction > here mainly being made by their "priority". Would you confirm this? That's correct, but there are a couple of additional details that might make it more clear. Those software interrupts can be scheduled by other device interrupts as well -- the canonical example is a "hard" interrupt servicing a network interface card by setting up the received packet for the software interrupt to handle later, and then re-enabling the card for the next packet. > In my opinion this isn't the way to put it and software interrupts > should only mean interrupts initiated by interrupt instructions. I suspect the usage dates to before the invention of software interrupt opcodes. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44hdiv34vz.fsf>