From owner-freebsd-hackers Mon Aug 21 22:22:07 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id WAA03309 for hackers-outgoing; Mon, 21 Aug 1995 22:22:07 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id WAA03283 ; Mon, 21 Aug 1995 22:22:01 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA24531; Tue, 22 Aug 1995 15:20:31 +1000 Date: Tue, 22 Aug 1995 15:20:31 +1000 From: Bruce Evans Message-Id: <199508220520.PAA24531@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@cs.weber.edu Subject: Re: Clock interrupts during probes? Cc: gibbs@freefall.FreeBSD.org, hackers@freefall.FreeBSD.org Sender: hackers-owner@FreeBSD.org Precedence: bulk >> >> if (p) { >> >> ... >> >> pstats = p->p_stats; >> >> ... >> >> if (timerrisset(&pstats->p_timer[ITIMER_PROF].it_value) ... >> >> } >> ... >0 isn't a real process. The 'if (p) {' code implies that a NULL process >is possible -- any place other than boot where this would be the case? Not in the boot code, which carefully and bogusly sets curproc to non-NULL. A NULL process is normal while the system is idle. The clock code handles that case fine, although I would write it differently so that there is always a process state to scribble on - this saves time when the system isn't idle. [Interrupts] >The question is then whether you trap them all to you when you enable >them, or whether on probe succes, ownership is assumed by a NULL >handler and the interrupt-with-no-handler case is the probe coming true. I meant `traps' to mean only synchronous traps, not interrupts. >I'd actually vote for the second: The PCI case of shared interrupts >argues for not trapping ownership. That would let ISA nad EISA non >shared instances assume ownership. This implies the probe-true state >is kept seperately, not derived from the fact that it has an interrupt >hooked (which is better than every device having their own null routine >anyway). Something like that. Autoconfig of shared interrupts is going to be even harder when devices are probed at modload time. Another device may be using the interrupt that you're trying to detect. >> >In the issue of SPL's, the spl0 is set in the forked processes prior to >> >them going into their tight loop. I can see no reasonable benefit from >> >this, specificall in vmdaemon(). >> >> I think it is a no-op. >Yeah, me too. I wanted an opinion from the author, though. I think he doesn't read the hackers list, having no time to read too-long discussions like this :-). >> Each coroutine instance would provide a sleeper. >Hmmm. This complicates the probe a bit, but not unreasonably so. It would >actually help in the case of where you are trying to get the interrupts >up early and probe the clock first. It's probably the right way to clean >it up. It buys you simultaneous attach for long delay devices, if the >interrupt stuff is handled correctly. 8-). Yes, and interrupt the interrupt stuff needs to be handled correctly for probe/attach to work at modload time. Bruce