Date: Tue, 22 Aug 1995 15:20:31 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, terry@cs.weber.edu Cc: gibbs@freefall.FreeBSD.org, hackers@freefall.FreeBSD.org Subject: Re: Clock interrupts during probes? Message-ID: <199508220520.PAA24531@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508220520.PAA24531>