Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!ns.saard.net!news.adelaide.on.net!yarrina.connect.com.au!news.mel.connect.com.au!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!news.sprintlink.net!helena.MT.net!nate From: nate@trout.sri.MT.net (Nate Williams) Newsgroups: comp.os.linux.development.system,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc,comp.os.linux.advocacy Subject: Re: Historic Opportunity facing Free Unix (was Re: The Lai/Baker paper, benchmarks, and the world of free UNIX) Date: 15 Apr 1996 15:44:17 GMT Organization: SRI Intl. - Montana Operations Lines: 99 Message-ID: <4ktqsh$iu4@helena.MT.net> References: <4ki055$60l@Radon.Stanford.EDU> <jdd.829261293@cdf.toronto.edu> <yfglok14n5r.fsf@time.cdrom.com> <31702487.420C2193@lambert.org> Reply-To: "Nate Williams" <nate@sneezy.sri.com> NNTP-Posting-Host: trout.sri.mt.net Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:21356 comp.unix.bsd.386bsd.misc:585 comp.unix.bsd.bsdi.misc:3191 comp.unix.bsd.netbsd.misc:2998 comp.unix.bsd.freebsd.misc:17321 comp.os.linux.advocacy:45403 In article <31702487.420C2193@lambert.org>, Terry Lambert <terry@lambert.org> wrote: >] and how to get the user from point A (a CDROM in one hand and >] a PC on the desk) to point B (a fancy graphical interface >] complete with "click here to start" button). > >This one is easier; it is completely technical, and I have >tried to push it in a large number of comercial organizations, >including Novell USG (the former USL) without success: > >1) Move the DDX code for per-card drivers into the > kernel. Augh.... This is evil, and causes the kernel to bloat excessively. Even in WNT, the pig that it is doesn't do this. >2) Implement "fallback drivers". Such a driver is a > standard driver implemented on BIOS calls. For > video, this is INT 10. This will be sufficient > to put the screen in 640x480 graphic mode for the > 95% majority of PC hardware capable of running a > protected mode OS. Needs VM86, and can un-necessarily de-stabilize the system with buggy BIOS implementations. See below. >3) Implement a full VM86(). Because the fallback > drivers must operate from protected mode, you > will need virtual machine technology to make BIOS > calls from protected mode to implement them. This work is happening now. :) >4) Either discard the concept of memory overcommit > altogether, or allow it to be selected off. Never. ;) >5) Enable more explicit processor detection. This > is necessary to implement APM for systems without > APM BIOS capability. APM BIOS capability should > be ignored. As someone who has most recently looked into APM, it's virtually impossible to implement APM without support from the BIOS. The APM BIOS is the only 'standard' way of determining the hardware status (battery status, docked/undocked, 'real' disk time-out), and doing things like controlling hardware in a portable manner. Without APM, we'd have to do all of this on a per-platform basis, which means it would never get done. We're having a hard-enough time trying to get the machine/processor independant APM support working well enough, can you imagine trying to get this down for each and every laptop made? Finally, I'm surprised you don't want APM BIOS capability but like other BIOS capabilities. One of the biggest problems I've been having with the APM support is buggy APM BIOS implementations. >6) Build your "magic install image". > >Now let's talk about "magic install images". Such an image is >a non-memory-overcommit (fd's are not strictly recoverable for >executables) APM save image of a sytem "just about to be >installed". It doesn't work that way. Doing an APM restore image *requires* that the machine no be powered down completely *AND* that the image size be the same size as the actual memory in the machine. I've had lots of problems with memory mis-matches and power downs when the machine was completely powered down on my older ThinkPad. (I can't try it on my NEC since it doesn't even support 'saving the current state to disk'.) In short, this won't work on anything but certain brand of laptops, and in my experience it won't work for installs. >The hardest part is writing the standalone APM restore code >program, to be run as a boot or as a DOS executable. Actually, the hardest part is writing new APM code for every laptop since it doesn't work on most. And, I suspect APM will be going away pretty soon now as Intel/M$ have a new 'power-management' scheme that will be useful for desktops and laptops. Unfortunately, it is completely different (if you're in marketing you'd call it 'better') than any of the current power management standards. If you are going argue, at least argue for things that have a chance of being implemented in this lifetime. Nate -- nate@sneezy.sri.com | Research Engineer, SRI Intl. - Montana Operations nate@trout.sri.MT.net | Loving life in God's country, the great state of work #: (406) 449-7662 | Montana. home #: (406) 443-7063 | A fly pole and a 4x4 Chevy truck = Heaven on Earth