I'd like to see the rest of this thread ;)
> > > > We could add it to suspend scripts, but wouldn't mtrrs fit into the
> > > > driver model idea? Would you say the same thing about implementing S3
> > > > support?
> > >
> > > I think going through the driver model is the right thing to
> > > do.
> >
> > It's useless bloat.
What exactly is useless bloat? Based on the level of indentation, I'd
assume that Richard said that...care to elaborate?
> > > Userspace should not need to know about mtrrs,
> >
> > It's a swsuspend helper daemon, not some random application. There
> > *should* be a helper daemon, if not, the design is flawed.
Care to elaborate on that one, too? What does a userland daemon add to
make it a sane design?
> There's no helper daemon, nor I plan to make one. Notice that mtrr
> stuff is shared between S3 (== suspend to ram) and swsusp. Both S3 and
> swsusp can be used to do some pretty important stuff (machine
> overheats or battery critically low -> suspend somewhere), so I do not
> think userland daemon is good idea.
>
> It can be dependend on CONFIG_PM; if you still think that's too much
> bloat, it could be dependend on CONFIG_SLEEP which could be only
> compiled when S3 or swsusp is selected (but I feel that would be
> overdesign).
Yes, that's too much.
MTRRs are one interface to an x86 CPU. CPUs are already represented in the
device tree. The proper thing to do would be to have the CPU suspend/
resume methods save and restore the MTRRs. It still requires an #ifdef in
the CPU code, but with a little work, could be massaged down a ways.
-pat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Apr 15 2003 - 22:00:36 EST