On Thu, Nov 26, 2009 at 11:05 AM, Dan Nicholson <dbn.li...@gmail.com> wrote:
> On Wed, Nov 25, 2009 at 6:43 AM, Victor Lowther > <victor.lowt...@gmail.com> wrote: > > On Wed, Nov 25, 2009 at 6:10 AM, Martin Pitt <martin.p...@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. > I think bash works great for this little task. :) > -- > Dan >
_______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
