Re: RFC: Plan for new "hwmatch" command

[Colin Watson <cjwatson@ubuntu.com>]

On Thu, Nov 18, 2010 at 12:32:20PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 11/18/2010 05:58 AM, Evan Broder wrote:
> > 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.

I hadn't been expecting to have both a whitelist and blacklist in
existence at once.  That said, thinking about it, I can imagine that we
might want to say something like "all Intel cards, except for these
particular devices".

> 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.

I agree with you to some extent that a new command seems rather ad-hoc.
On the other hand, I suspect that the configuration might grow rather
large, and I'm concerned about performance; it doesn't seem to me that
implementing this entirely in code would be likely to be very fast.  If
I were doing this in a POSIX shell script, I wouldn't use a giant case
statement.

Maybe it would be worth having a 'grep' command?  You could probably
implement this as a fairly large regex assuming that you didn't mind the
wildcards being a little inflexible (you'd only be able to use a
wildcard for an entire field, not for substrings).  Then you'd have a
logic file plus a data file that it searches, and you wouldn't have to
put lengthy strings of data in the logic file.

It might be worth prototyping this in POSIX shell with fairly minimal
utilities, to see which utilities we would need to add to GRUB to make
this possible.

(Of course, there's still the option of carrying this as an Ubuntu
patch, and advertising it as having an unstable interface.  I'd rather
avoid that if we can figure out a good upstream design for this,
though.)

-- 
Colin Watson                                       [cjwatson@ubuntu.com]