Re: Nested suspends; messages vs. states

Nigel Cunningham
2005-03-24T03:16:23Z

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

Hi Patrick.

On Thu, 2005-03-24 at 13:40, Patrick Mochel wrote:
> 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..

Just for clarity's sake, what are you thinking should happen to MTRR
support?

Regards,

Nigel
--
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net