On Fri, Nov 22, 2024 at 09:11:25PM -0700, Theo de Raadt wrote:
> Andrew Hewus Fresh <andrew@afresh1.com> wrote:
> 
> > Index: patterns.c
> > ===================================================================
> > RCS file: /cvs/src/usr.sbin/fw_update/patterns.c,v
> > diff -u -p -r1.16 patterns.c
> > --- patterns.c	30 Oct 2024 00:04:46 -0000	1.16
> > +++ patterns.c	23 Nov 2024 03:39:19 -0000
> > @@ -43,6 +43,18 @@
> >  
> >  #define nitems(_a)	(sizeof((_a)) / sizeof((_a)[0]))
> >  
> > +/*
> > + * Testing changes:
> > + *
> > + * For testing, fw_update(8) has a special case for when it is named
> > + * "fw_update.sh" and "firmware_patterns" exists in the current
> > + * directory.  It uses those patterns instead of the default.  If
> > + * there is also a file called "dmesg" it will use that instead.
> > + *
> > + * `make firmware_patterns          && ksh ./fw_update.sh`
> > + * `scp other-host:/var/run/dmesg . && ksh ./fw_update.sh`
> > + */
> 
> I dislike this intensely.
> 
> Should we do the same in ls, for testing?
> 
> How about for bgpd?  Or some other random program?  I don't need to list
> 50 programs we could do this for, and it is all just complicated churn
> which will eventually have a a bug.
> 
> It's the wrong thing.  This is a developer group. You install, then you test.
> There may be only one person who wants this, and it's you.  Noone else wants
> this fragility.
 
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.