Re: Nested suspends; messages vs. states

Patrick Mochel
2005-03-24T02:40:42Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1151 bytes --]

On Wed, 23 Mar 2005, Pavel Machek wrote:

> Hi!
>
> > > There are many drivers that do not fit your idea of "driver". Like
> > > mtrrs. Some drivers only ever do work on resume, etc. Forcing driver
> > > to think how to split it into class->stop, bus->save_state and
> > > bus->enter state is bad idea. [Notice that almost no drivers need
> > > ->save_state operation...]
> >
> > I don't think MTRRs should be counted as drivers. Rather, they should be
> > counted as part of the CPU state(s), to be saved and restored when CPU
> > context is saved and restored. Treating them as drivers leads to races
> > :>
>
> Okay, I'll need to make cpu hotplug deal with them. But MTRR are not
> the only strange device. Think timer, for example.

That's a system device (like the current MTRR). In the name of sanity,
please don't make exceptions to the model based on them or platform
devices. Both of those models are FITH and need to be re-done.

Tangentially, if anyone has decent ideas on how to better represent those
types of devices, I'm very intersted in knowing. I'd like to see them
fixed up and cleaned up in the next few months..

Thanks,

Pat