From owner-freebsd-hackers Sun Aug 17 03:10:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA20787 for hackers-outgoing; Sun, 17 Aug 1997 03:10:10 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA20713 for ; Sun, 17 Aug 1997 03:09:59 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id TAA04212; Sun, 17 Aug 1997 19:39:41 +0930 (CST) From: Michael Smith Message-Id: <199708171009.TAA04212@genesis.atrad.adelaide.edu.au> Subject: Re: reset screen hardware? In-Reply-To: <199708170311.MAA04998@freebie.lemis.com> from Greg Lehey at "Aug 17, 97 12:41:37 pm" To: grog@lemis.com (Greg Lehey) Date: Sun, 17 Aug 1997 19:39:40 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 [[