Date: Thu, 15 May 1997 10:21:51 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: csubl@csv.warwick.ac.uk (Mr M P Searle) Cc: msmith@atrad.adelaide.edu.au, karpen@ocean.campus.luth.se, hackers@FreeBSD.ORG Subject: Re: 2.2 Splashkit Message-ID: <199705151721.KAA15108@phaeton.artisoft.com> In-Reply-To: <7018.199705151355@finnan.csv.warwick.ac.uk> from "Mr M P Searle" at May 15, 97 02:55:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > Color cycling should happen at an even pace, if possible. > > > > > > > > It's already been explained that it can't. > > > > > > Umm... No. It was said that there was a timer interupt, but that > > > it was not available during probing, and so you (ie "syscons") > > > would have to wait for driver output and possibly do something > > > at the same time as you output that. So every time you get a > > > call from a driver, you should be able to cycle the colors. > > > What you will want to do, however, is not cycle too often. So > > > you save the value of the hardware clock, or something, each > > > time you cycle. > > > > Er, have you ever heard of anything called "hardware abstraction" or > > "layering"? [ ... ] > > Bruce will probably correct me, but I don't think that the kernel time > > code is running during the hardware probe phase. Well, that would be because it's not correctly layered. 8-). > Well, I don't know much about the kernel probes, but most of the time is > spent in delay loops, right? And although the timing of some of these may > be important, if a loop is waiting for 2 seconds, it isn't going to matter > if it delays for 2.1 seconds instead. So, the delay loop could be replaced > by one which (if the delay is longer than, say, 50ms) is split into > a number of short delay loops, with a call to the splash-screen routine > in between. (Cycling the colours at the end of every device probe only > wouldn't do much - on my machine at least the only devices that delay for > a significant amount of time are the floppy, SCSI disk and SCSI CD.) Better to use a real timer in the probes. This will get rid of the manifest "magic" values which are responsible for how long the thing buzzes waiting. What is really needed (and has been since 1993, when I first suggested it, and then implemented it on UnixWare) is a high resoloution timer system based on reschedulable one-shots. Then if you used the timer in the probes instead of delay loops, you could do neat things like probe hardware with known different interrupts (PnP, PCMCIA, EISA, PCI -- basically everything but ISA [Die, ISA, Die!]) *simultaneously*. It'd make the system a bit more zippy on boot anyway. So you bring the console code up first thing (you have to anyway to report boot progress) and make the splash code sonsume the console code and the timer code (bring the timer up second thing). I just had a discussion about the necessary timer code with Peter Wemm, actually, and we both agree that it would be difficult to write. But that's the way you want to approach it, and you get neat wins out of it anyway, like being able to move the ft driver into the kernel and not spend 60% of your time while it's running buzzing on the FDC. It also buys you concurrency speedups in PIO delay loops. Too much work for me, right now, though. Regards, 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?199705151721.KAA15108>