Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Oct 1995 11:51:07 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        phk@critter.tfs.com (Poul-Henning Kamp)
Cc:        terry@lambert.org, julian@ref.tfs.com, jhay@mikom.csir.co.za, hackers@FreeBSD.ORG
Subject:   Re: IPX now available
Message-ID:  <199510131851.LAA17995@phaeton.artisoft.com>
In-Reply-To: <1369.813577339@critter.tfs.com> from "Poul-Henning Kamp" at Oct 13, 95 10:42:19 am

next in thread | previous in thread | raw e-mail | index | archive | help
> > > > We want a registration mechanism for LLC's, another for protocol
> > > > families, etc..
> > 
> > OK, I just sent off a message a bit ago to Serge Vakulenko (vak@cronyx.msk.su
> )
> > [And off Terry went...]

8-).

> I think we are on to a very important issue here, and before anybody jump
> to conclusions or through hoops, let me say that we need to get all the
> pieces of the puzzle on the table before we design away.

I agree.  That's why we need 5000' views on potential designs, and people
not afraid to criticize them without the original proposers getting their
shorts in an uproar.

> Is anybody willing to serve as editor on a 
> 	"FreeBSD future kernel architecture"
> document ?

I vote for Poul-Henning Kamp.  8-).

> You need to be good at writing, and you need to understand the issues too.
> 
> PS:
> Terry forgot Power Management:

I didn't forget it, I only talked about devices.  In the detach routine,
I discussed power conservation modes in the hardware.

There is an implication here that power management entry points must be
part of a physical device driver.  Certainly a generic card services
capability would require such a thing.

I didn't talk about ENPIC's, either.  There are 6 common PCMCIA
interface chipsets, of which we support 3 (only because two are pin
compatible with the Intel part).

I would suggest that card services must be *TOTALLY* seperate from the
idea of what device is being serviced.  Actually, some great strides
have been made in this direction already (very recently).

The PReP spec has a lot of interesting stuff to say about power
management.  I recommend getting a copy -- it is available online
from www.motorolla.com as a postscript document.

> 	The "PM" module can inform the kernel that:
> 		"CPU-slowed down"
> 		"CPU-speed up"
> 		"suspend imminent"
> 		"revive complete"

Power management at this level is a connundrum.  To be able to support
suspend/resume is greatly dependent on hardware capabilities at the
processor level, and in general the use of undocumented instructions
(like ICEBP) on a per CPU type basis.

In BIOS implementations, power management assumes the CPU (just as most
machines shipping with older Cyrix/TI parts enabled the cache with CPU
specific knowledge in the POST routines during boot).


A second level to this connundrum is that there is typically insufficient
swap on a running system (because of memory overcommit) to be able to
fully recover the machine state.


I've long held the opinion that the "correct" way to install an OS is
to have a CDROM image of a "suspended" system at the point of accepting
the defaults on an install, and then to "resume" it on a different
machine.  The 30 second install, so to speak.


The third level to such a connundrum is state maintenance in the hardware
but not in the driver.  This is aparticular problem for the console
driver, since the hardware state is altered without the knowledge of
the console driver.  A "resume" is not possible in this situation because
of this.  This has long been one of my "hot buttons", and usually it has
manifested as repeated suggestions that the DDX code be moved into the
console driver itself.

It turns out that the same issue prevents the use of the kernel debugger
in the event of a panic while running X.  This is a wholly dissatisfactory
situation.

> 	The kernel can tell the PM module to:
> 		"slow down the CPU"
> 		"speed up the CPU"
> 		"suspend"
> 		"revive"
> 
> 	The PM can tell a driver:
> 		"device powered down"
> 		"device sleeping"
> 		"device online"
> 
> 	A driver can tell the PM:
> 		"power off device"
> 		"sleep device"
> 		"online device"
> 
> possibly more.

I don't necessarily understand the need for the driver to be able to
make requests of the power manager, since that seems to violate the
layering.

I can possibly see it in the case of PCMCIA, though they have their own
standards and algorithms already defined (and available for purchase
from the PCMCIA SIG).

I think the idea of a power manager is actually a subtopic in a more
general issue: configuration management (what Win95 calls "the resource
manger" and proceeds to implement horribly).

Much of my recent FS changes have actually been geared toward the idea
of asking a file system if it wants to mount a logical device, rather
than specifying the device mounts by file system type in an FS TAB.
This is part of the general picture, but it is only a *tiny* part.


I think the issues involved are extremely complicated.  We have two
working examples (PCMCIA and PReP) and one almost-but-not-quite-working
example (Win95) to guide us.  PHK is correct that we must look before
we leap.


Suggested reading:

	PCMCIA standard
	PReP spec
	PnP.doc (Win95 DDK, MS Level II developer kit)
	ISA Plug N Play documentation at ftp.microsoft.com
	PCI/NuBUS Plug N Play documentation at ftp.apple.com


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510131851.LAA17995>