On Fri, Nov 22, 2024 at 09:19:14PM -0700, Theo de Raadt wrote:
> Andrew Hewus Fresh <andrew@afresh1.com> wrote:
> 
> > It is useful to me, so I will keep the patch around.  I thought perhaps
> > the iteration process for testing against a bsd.rd dmesg was worth the
> > extra complexity, but it's not.  I'll drop it.
> 
> I do not understand the usage pattern.
> 
> On bsd.rd it is not called by that name.
> 
> On a regular install, it is not called by that name either.
> 
> It only happens if you skip "make install", and run it by a special
> name.  Noone does that.

The use case is only for testing changes to patterns.c to make sure they
work, since they are not the most obvious to work with.  Which is why I
added a comment there.

This way you can quickly run `make firmware_patterns && keh
./fw_update.sh -l` in the directory where you are editing the file and
make sure it does what you expect.  An additional `make install` in this
case isn't terribly difficult though and definitely wouldn't be worth
the complexity.

The most useful place I would see would be testing changes to match
things in a dmesg from a bsd.rd.  You could copy the dmesg from the
bsd.rd into the src tree and use `ksh ./fw_update.sh -l` to test whether
your changes will work on that bsd.rd.  The time to get the dmesg from
the other machine is a one-time cost but `make install && reboot` onto
the bsd.rd plus mounting the local filesystems to get the patterns file
is a long testing loop.

You could even copy a dmesg from a mailing list and test whether
patterns match on a machine you don't have.