Date: Tue, 20 Jun 2000 10:27:08 +0300 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Mike Smith <msmith@FreeBSD.org> Cc: Andrew Reilly <areilly@nsw.bigpond.net.au>, freebsd-current@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: ACPI project progress report Message-ID: <394F1CCC.45B8A2C3@FreeBSD.org> References: <200006200040.RAA10386@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote: > > On Mon, Jun 19, 2000 at 05:01:46PM -0600, Warner Losh wrote: > > > In message <20000620085531.A38839@gurney.reilly.home> "Andrew Reilly" writes: > > > : That sounds way too hard. Why not restrict suspend activity to > > > : user-level processes and bring the kernel/drivers back up through > > > : a regular boot process? At least that way the hardware and drivers > > > : will know what they are all up to, even if some of it has changed > > > : in the mean time. > > > > > > Takes too long... That's shutdown, not S4. > > > > Yes. But what is the difference, really? As far as the > > hardware is concerned, it's being booted. If that process can > > be sped up by using the "S4" mechanisms, why can't they be > > applied to a regular boot process too? [I'm thinking about a > > kernel equivelant of the "clean shutdown" flag on file systems.] > > > > Fundamentally, is there no way to get the kernel and drivers to > > go through a full boot phase in a small fraction of the time > > that it takes to repopulate 64M of RAM from disk? (*) > > The real issue here is persistent system state across the S4 suspend; ie. > leaving applications open, etc. IMO this isn't really something worth a > lot of effort to us, and it has a lot of additional complications for a > "server-class" operating system in that you have to worry about network > connections from other systems, not just _to_ other systems. Why then brand commercial vendors have such capability in their "server-class" operating system for a long time? Particularly HP's PA-RISC servers does have it, at least I remember such feature in the old 30MHz systems which I managed several years ago (the systems was shipped with small internal battery, which in the case of power failure was used to dump system to the disk). -Maxim. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?394F1CCC.45B8A2C3>