[Pm-utils] Migrating suspend quirks away from hal

[Dan Nicholson]

On Wed, Nov 25, 2009 at 6:43 AM, Victor Lowther
<victor.lowther at gmail.com> wrote:
> On Wed, Nov 25, 2009 at 6:10 AM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
>>
>> Hello Victor,
>>
>> sorry for the late response; conference and all that..
>>
>> Victor Lowther [2009-11-15 21:59 -0600]:
>> > And now, a version that actaully works.  With a bit of glue code, this
>> > can replace auto quirk and smart kernel driver handling in pm-utils.
>>
>> I just tried your script, but AFAIK it just figures out the quirks
>> that are necessary on the _current_ system by parsing the .fdi
>> directly, right?
>
> No, it translates the .fdi files that are currently on the system into a
> native format that uses bash-style extended regular expressions instead of
> the .fdi ad-hoc pattern matching scheme..  The translation is fairly
> simplistic right now (and could certainly do with being rewritten, in a
> language that acctually understands xml) but it only reads the .fdi files to
> translate them, and it only does that if they are newer than the native
> format files.  If there are no .fdi files, or they are older than the native
> ones, it just uses the native format files.
>
> Take a look at maybe_update_native(), translate_xml() and their callers in
> the script for more details.
>
>>
>> What I actually had in mind was that we should do a static conversion
>> to produce a simple-to-parse text file map which can then be put into,
>> and maintained within (well, it's not going to change often any more),
>> pm-utils itself, so that we can get rid of hal/hal-info completely.
>>
>> Would you want to change your script accordingly, or want me to work
>> on such a static conversion script?
>
> No need, I already do that in the current script for convienence.  Once we
> actually decide that this is the way forward, moving the XML translation
> into its own script or rewriting it in a language that actually understands
> XML will be pretty easy.
>
>>
>> I thought about having one file per vendor, such as
>>
>>  /usr/share/pm-utils/video-quirks/ibm
>
> I already do this.
>
>>
>> and each file would have a list of (dmi property:value)* → quirks map like
>>
>>  product_name:.*X31;bios-version:INET17WW      s3_bios s3_mode
>>
>> which can then be matched against /sys/class/dmi/id/* with grep.
>
> I tried that, it is hideously expensive -- you end up having to parse each
> line in the file in the shell, and then run grep on the specific DMI
> property you are looking at with the bits you parse out, which ends up
> running grep several hundred times. Since bash already knows about regular
> expressions, I cut out the middleman, and keeping the current treeish
> structure makes it easier to save a little time by not comparing the bits
> you do not actually care about.

I think if this is really the way to go, then shell is not the right
tool for the job at runtime. You could write a trivial C program to
parse that out and spit out the quirks on stdout for pm-utils to use.
Bash is great, but it is not the right tool for all jobs.

--
Dan