*BSD News Article 65922


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