Date: Tue, 2 Apr 1996 13:00:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: Brett_Glass@ccgate.infoworld.com, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Hacked kernel with option to disable "green" mode Message-ID: <199604022000.NAA16874@phaeton.artisoft.com> In-Reply-To: <199604020723.RAA01028@godzilla.zeta.org.au> from "Bruce Evans" at Apr 2, 96 05:23:05 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Note that long waits (> 10 usec) usually only occur in initialization and > panic dump code when it can't even use timeouts. Most waits occur at > interrupt time when it can't use tsleep. Hence my suggestion to event schedule. It would have to be coupled with a queue abstraction of interrupt handling; specifically, a SVR4/WindowsNT style top/bottom handler division, where the point of the service routine is to queu the interrupt as an event and allow further interrupts. This has the negative side effective of increasing latency, and the positive side effect of increasing concurrency (ie: it can be set to take another interrupt from the same device right after the event has be queued instead of at service time). FreeBSD's interrupt code is close to this anyway, especially with some of the recent changes. The timer interrupt is an event trigger. For long duration events which can take place "after so much time has elapsed" instead of "when so much time has elapsed", hooking the standard timer interrupt with a function callback is perfectly acceptable. > >Of course, pausing 30 seconds in the kernel could be catastrophic for some > >applications, > > Perhaps more importantly, pausing 30 seconds outside the kernel may be > catastrophic :-). There is probably little difference where the wait > occurs except on multi-disk-controller systems where the IDE controller > is little used. This is not an issue if the quantum period times the number of ready-to-run processes does not exceed the maximum allowable delay period (which is why the timer is unacceptable for moving "ft" functionality into the floppy tape driver in the kernel). > >so implementing some of those proprietary commands is still > >useful. The modification I sent in covers Seagate's. > > It can't be used in the standard driver because its operation is unknown. > It might format the drives... Yes, I agree. It should be a standalone command using the wdcontrol() interface that the user must specify, with knowledge of the potential consequences, instead of a config option that a user might say "this looks like what I need -- I'll try it". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604022000.NAA16874>