Date: Mon, 18 Aug 1997 12:29:39 +0930 From: Greg Lehey <grog@lemis.com> To: =?iso-8859-1?Q?S=F8ren_Schmidt?= <sos@sos.freebsd.dk> Cc: jkh@time.cdrom.com, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: reset screen hardware? Message-ID: <19970818122939.30413@lemis.com> In-Reply-To: =?iso-8859-1?Q?=3C199708170951=2ELAA00412=40sos=2Efreebsd=2Edk=3E=3B_fro?= =?iso-8859-1?Q?m_S=F8ren_Schmidt_on_Sun=2C_Aug_17=2C_1997_at_11=3A51=3A1?= =?iso-8859-1?Q?9AM_%2B0200?= References: <19970817163116.16698@lemis.com> <199708170951.LAA00412@sos.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 17, 1997 at 11:51:19AM +0200, Søren Schmidt wrote: > In reply to Greg Lehey who wrote: >>> >>> Funny, my bigget rant has to do with people going "Why doesn't FreeBSD >>> have feature XXX?!" rather than "Here are my diffs to support feature >>> XXX, please integrate them." >> >> And would you? If I had come along with the diffs for doing it this >> way, you'd have said (with some justification) "Go away, we don't want >> all this crap in the kernel". I was, in fact, considering doing the >> implementation, but I see that it's not the way to go. > > Come on here, what at least I have been advocating for, is that > we need that functionality, but we need it done RIGHT. We allready > have so many kludges/hacks in the kernel, we don't need another one. I think you're missing the point. That's what I said. Note the "(with some justification)". > If Joe random hacker cannot graps the bigger picture, and get his > hacks in the right direction, well, I'm sorry it won't be commited. > On the other hand, if Joe mature hacker comes around, and wants to > help do the hard work along the guidelines that the responsible > person(s) have laid out (and belive me, for the most part things > has been thought long and seriously about), he will be welcommed > with open arms. Sure. No debate. > So to get concrete in this matter, we need: > > 1. Being able to call realmode code from the kernel. > > 2. Being able to run BIOS functions, that is we need to keep > track of the BIOS's workspace, most often in low memory. > > 3. Then write the code to call the right BIOS functions to > be able to talk to the video HW. > > So, if someone is SERIOUS about getting this to work, pick one > of the above, come back to me so we can get technical about > the details, and them submit the diffs. Then I'm certain it will > be committed, and the author will get his fair share of applause.. > > But gimme a break on just demanding XXX functionality, sometimes > with badly (if at all) designed hacks.... Wait a while, there was no design at all at this point. We had Mike saying that it wasn't possible, and me suggesting a possible approach. My statement was that the kernel probe routines seemed the obvious place to put such code. I stand by that statement. The question was how to find out the parameters, and the fact that the code is so voluminous makes the approach impractical. But that doesn't make the approach a hack. There is, BTW, a potential problem with the "call the BIOS" approach (which I consider marginally more of a hack, since the driver doesn't know what's going on): what if the driver has set a different mode for the board, like 50 line or some such? That would have to be redone after the BIOS call. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970818122939.30413>