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 {
classid=$1
vendorid=$2
deviceid=$3
if [ x$classid != x<CLASS> ]; then
continue
fi
case x$vendorid
<VEN1>) .... ;;
<VEN2>) .... ;;
esac
}
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]
> https://blueprints.launchpad.net/ubuntu/+spec/packageselection-foundations-n-grub2-boot-framebuffer
> [2] https://code.launchpad.net/~broder/+junk/grub2-extras-lua-enum-pci
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
> -- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
