Mike Smith wrote:
> > On Mon, Jun 19, 2000 at 05:01:46PM -0600, Warner Losh wrote:
> > > In message <[EMAIL PROTECTED]> "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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
