Date: Sun, 17 Aug 1997 19:39:40 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: grog@lemis.com (Greg Lehey) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: reset screen hardware? Message-ID: <199708171009.TAA04212@genesis.atrad.adelaide.edu.au> In-Reply-To: <199708170311.MAA04998@freebie.lemis.com> from Greg Lehey at "Aug 17, 97 12:41:37 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey stands accused of saying: > >> > >> How about a more positive approach? I know plenty of people who'll > >> tell me in vivid detail why things won't work. > > > > This is like asking for a positive approach to a VMS ABI emulation > > module 8) > > Yes. If people want it. I didn't say it had to be nice. I'm not sure I can parse that. > -- rant mode on -- > > If there's one thing that pisses me off about many FreeBSD hackers, > it's this attitude "Ooh, this is nasty. I don't want to have anything > to do with it". I don't see how this is relevant to the discussion at hand. What is currently being said is "there is a tough problem. The proposed solution sucks both from a practicality and a supportability point of view. In addition, a more general and elegant solution is already being implemented." That's not "this is nasty". > Lots of PC hardware is nasty. Messing around in a 16 > bit BIOS is nasty. IDE is nasty. VGA is nasty. Come to think of it, > what's nice about PC hardware? But FreeBSD's acceptance suffers > significantly because nobody can be bothered to deal with these nasty > things. Where's the Win-32 emulator? ... There are two of them; both accumulating significant support and offering usefully overlapping feature sets. Note that neither of their development teams have the biollion-plus development budget of the original. > >>> We wont have hundreds of K's of code like that in kernel space. > >> > >> That's for sure. But who says it'll be hundreds of Ks? > > > > Have a look at the X server sources someday. > > Must I? I took a look at SuperProbe. The binary is 83 kB, and in the > kernel some of that could go. Sure, that's too much for the kernel, > too, but it's still not hundreds. Turn around, go back. SuperProbe != video chipset drivers. > > Basically, it is not possible to take a snapshot of the state of a > > modern video adapter without uintimate knowledge of the hardware > > involved. Such a snapshot is often useless anyway, as it does not > > contain information about the state transitions prior to the snaphot > > state, which may be very significant to the hardware's current mode of > > operation. > > But we still have the evidence that every X server manages to reset > them most of the time. That's _right_. But it achieves this by knowing, in fact having _been_told_ in advance what the hardware is, and thus having hardware-specific intelligence. The point is that this intelligence is foreign to the kernel, unmaintainable in the kernel environment, and _inevitably_ will lag, often indefinitely, behind hardware development. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708171009.TAA04212>