[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Plan for new "hwmatch" command

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: RFC: Plan for new "hwmatch" command
Date: Thu, 18 Nov 2010 12:32:20 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101030 Icedove/3.0.10

On 11/18/2010 05:58 AM, Evan Broder wrote:
> Hi -
>    Based on some off-list discussion, I'd like to try a different
> angle for the Lua patches I submitted a week or two ago. For context,
> Ubuntu is interested in setting gfxpayload=keep as often as we can in
> the next release [1]. Since gfxpayload=keep doesn't work with all
> hardware/driver combinations, we need a way to selectively turn it on,
> based on a whitelist or blacklist.
> For my first crack at this [2], I used Lua scripting for comparing
> current hardware against the whitelist/blacklist. However, I've gotten
> feedback that a solution without Lua would be better. Whatever I do,
> I'd like it to be with upstream's approval, and ideally adoption, so I
> want to have a discussion about interfaces before I start coding.
> I'm intentionally opening myself up to bikeshedding, but I'm
> interested in people's opinions on the format of the
> blacklist/whitelist file. I'm also interested in if this is generic
> enough to be a reasonable addition to the GRUB core. And of course I'm
> interested to know if people think I'm going about this all wrong.
> As a strawman, I propose adding the "hwmatch" command:
>   Usage: hwmatch MATCHLIST [BASECLASS]
> MATCHLIST is a file containing a list of hardware identifiers.
> BASECLASS is a PCI base class code. If specified, only PCI devices
> with that base class will be checked. hwmatch returns 0 if any PCI
> device in the system is listed in MATCHLIST, and 1 otherwise.
> MATCHLIST has one device per line with the following space-separated
> fields: base class, subclass, vendor ID, device ID, subsystem vendor
> ID, subsystem device ID. The first two fields are 2 hex digits; the
> other fields are 4 hex digits. Any field can be replaced by a single
> '*' to indicate a wildcard.
This has a problem of multiple matches in both white and black list. To
disambigute such thing you would need some logic. Also having a command
dedicated to this seems ad-hoc. I think something more along the lines
of extending scripting is better. So you'd have something like:
iterate_pci {
   if [ x$classid != x<CLASS> ]; then
   case x$vendorid
      <VEN1>) .... ;;
      <VEN2>) .... ;;
I'd recommend to have this code in a separate hwconfig.cfg for convenience.
We already have the necessary infrastructure to implement iterate_pci
without touching the scripting code. "continue" though will need a bit
of extension to work in iterate_pci. "case" isn't implemented yet but we
already have pattern matching, the main issue is the arrival of new
terminal ";;" and proper handling of it. Some logic with && and || would
come in handy too.
> Thanks in advance,
>  - Evan
> [1] 
> [2]
> _______________________________________________
> Grub-devel mailing list
> address@hidden

Vladimir 'φ-coder/phcoder' Serbinenko

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]