Date: Tue, 2 Apr 1996 23:58:46 +1000 From: Bruce Evans <bde@zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, terry@lambert.org Cc: freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Hacked kernel with option to disable "green" mode Message-ID: <199604021358.XAA26252@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Easy to do, since there's already an "issue a controller command" function >called wdcommand(). What are the conventions for ioctl numbering, >structs passed to ioctls, etc. in FreeBSD? If you're experienced at >hacking this kernel, it shouldn't take more than 15 minutes of coding to >add the new command. If you're experienced then you will know that only bugs can be added in 15 minutes. wdcommand() only issues the command. The results of the command would be reported at the next interrupt and might confuse the handling of the next command. You can wait for the results using wdwait(), as is done in wdgetctlr(), etc., but busy-waiting is evil. ioctl() can sleep, but this moves the problem to stopping concurrent access to the controller. The DKFL_LABELLING flag is a hack to avoid the problem at first-open time. There used to be calls to wdwsetctlr() for the label-setting ioctls (changing the geometry in the label used to change it in the controller), but concurrent access wasn't handled right for that case. >> I would prefer to have a reschedulable one-shot than to directly use >> the timer interrupt. > ... >> This lets you replace recurrening events with rescheduling the >> oneshot, and replace DELAY() with a one-shot scheduling. >This would certainly work. But the advantage of the timer is that it would >be sharable; the one-shot wouldn't be. You haven't seen Terry's one-shot timers :-). Neither have I, but I expect they would be shareable. E.g., if the next interrupt is scheduled after 75 usec and something wants one after 22 usec, then the timer would be reprogrammed to schedule the next interrupt after 22 usec nsec and again later to schedule the original interrupt. Of course, it might take 5-20 usec to reprogram the timer (20 usec on a 386/20) and another 5-20 usec to switch contexts, not to mention 5-20 usec to accept the interrupt and 5-20 usec to handle it, so one-shots are probably not viable for such small timeouts. I think they will be viable for timeouts a few hundred usec when the system becomes more real-time. See another discussion about bugs that cause clock latencies of > 10000 usec. >In any event, how much would the scheduler and vm modules have to change >-- if at all -- to allow unaffected processes to continue during swapper >I/O? Not at all, I think. Large changes would probably be required to give enough (if any) unaffected processes. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604021358.XAA26252>