[Suspend-devel] Whitelisting no-pm-quirks

[Holger Macht]

On Thu 03. May - 21:55:14, Danny Kukawka wrote:
> On Donnerstag, 3. Mai 2007, David Zeuthen wrote:
> > On Thu, 2007-05-03 at 10:40 +0200, Danny Kukawka wrote:
> > > The point is not using s2ram or that s2ram would break. The point is that
> > > removing the quirk would break resume if you suspend via init=/bin/bash
> > > (the testcase) or console. This change only work under X. All this has
> > > nothing to do with s2ram, only with the suspend itself.
> >
> > I'll rephrase my questions
> >
> >  1. Is it correct than s2ram has it's own list of quirks?
> 
> Currently yes

To be a little bit pernickety, actually HAL is using its own list no one
else is using AFAIK ;-) Every distro I know of currently uses the s2ram
internal one.

[...]

> IIRC the s2ram developers already think about adding support for the HAL 
> quirks, maybe in some kind of mixed mode (if there are no HAL info's use the 
> own whitelist). I add the devel mailinglist to CC, I think they can tell 
> more.

Still, what we definitely want is _one single_ architecture independent
whitelist. And there is where hal-info comes in which is easy to update
for distributions etc. IMHO. I'm seeing this difficulty with the two
different lists for quite some time know and thought about possible
solutions. AFAICS, the main reason for heaving s2ram internal whitelist is
that s2ram can be used completely without any trace of hal on some
system. So best would be to maintain the whitelist in one place and having
a converter.

I already started to write a XML parser for the hal-info xml whitelist to
convert it to the whitelist.c file, but had to recognize that it wouldn't
be easy and had to give up. It would be possible, yes, but it will get
very complicated and wouldn't be worth the trouble. The fdi files use some
strange way of nesting xml tags which is not easy to parse if you need to
know which closing tag belongs to which opening one, and especially to
keep track of the information contained. Additionally, when the initially
conversion from s2ram's whitelist to hal-info was done, there already were
information/detail loss. To convert back and forth would just result in
more and more information loss because fdi files and the whitelist.c will
always have different capabilities of matching against machine
information.

Maintaining two whitelists is definitely not the way to go.
But let's wait for the suspend developer to comment...

Regards,
	Holger