Date: Mon, 18 Aug 1997 12:50:55 +0930 From: Greg Lehey <grog@lemis.com> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: hackers@freebsd.org Subject: Re: reset screen hardware? Message-ID: <19970818125054.52750@lemis.com> In-Reply-To: <199708171009.TAA04212@genesis.atrad.adelaide.edu.au>; from Michael Smith on Sun, Aug 17, 1997 at 07:39:40PM %2B0930 References: <199708170311.MAA04998@freebie.lemis.com> <199708171009.TAA04212@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 17, 1997 at 07:39:40PM +0930, Michael Smith wrote: > 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. Can you give me a dump of the parse tree at the point where you abort? >> -- 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." Well, what I read was: Michael Smith writes: > Alfred Perlstein stands accused of saying: >> I'm not familiar with the protection mechanism in freebsd, if i wrote a >> program to reset the text screens by programming the ports what kind of >> skeleton code would it need? > > It wouldn't work. > That's not "this is nasty". You did in an earlier message, which unfortunately I didn't keep. >> 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. Win-32 emulators? I didn't know that. I only knew about wine, and last time I looked it couldn't handle Win-32. I've just taken another look at the emulators ports, and I can't see a second one. > Note that neither of their development teams have the biollion-plus > development budget of the original. Yup, that makes you wonder. Why does it cost Microsoft so much to maintain this particular heap of crap? >>>>> 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. Sure, but we don't need a chipset driver here. All we need here is a way to recognize the chipset. Once you've done that, extracting the registers is relatively trivial (yes, I know, you'll come back again and say that there are tricks and things, but they can be overcome). >>> 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, I disagree. One of the stated purposes of any OS kernel is management of hardware resources. Currently, display boards are about the only exception. The main reason for the problem is that the kernel has not really accepted graphics cards, but that's not really acceptable. > unmaintainable in the kernel environment, and _inevitably_ will lag, > often indefinitely, behind hardware development. These problems apply equally to the X server. I suppose what we're getting to here is more a question of where to put the "platform" software in a system. Ideally, a user program should not be allowed to access hardware--that's the job of the kernel. On the other hand, the X server alone is bigger than the kernel, so just putting the whole thing in the kernel would be impossible. But why shouldn't it be an LKM? No, I'm not advocating doing this, but from a purely conceptual point of view, that's where it belongs. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970818125054.52750>