From owner-freebsd-hackers Fri Oct 13 12:57:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10652 for hackers-outgoing; Fri, 13 Oct 1995 12:57:06 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA10647 for ; Fri, 13 Oct 1995 12:56:58 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA17995; Fri, 13 Oct 1995 11:51:07 -0700 From: Terry Lambert Message-Id: <199510131851.LAA17995@phaeton.artisoft.com> Subject: Re: IPX now available To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Fri, 13 Oct 1995 11:51:07 -0700 (MST) Cc: terry@lambert.org, julian@ref.tfs.com, jhay@mikom.csir.co.za, hackers@FreeBSD.ORG In-Reply-To: <1369.813577339@critter.tfs.com> from "Poul-Henning Kamp" at Oct 13, 95 10:42:19 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5012 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > > 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.