Re: Looks like the kyua zfs tests likely are not used on aarch64 or other contexts with unsigned char
- Reply: Mark Millard : "Re: Looks like the kyua zfs tests likely are not used on aarch64 or other contexts with unsigned char"
- In reply to: Mark Millard : "Re: Looks like the kyua zfs tests likely are not used on aarch64 or other contexts with unsigned char"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 10 Sep 2023 18:21:16 UTC
On Sun, Sep 10, 2023, 11:10 AM Mark Millard <marklmi@yahoo.com> wrote: > On Sep 10, 2023, at 00:31, Mark Millard <marklmi@yahoo.com> wrote: > > > kyua tests that use the: > > > > /usr/tests/sys/cddl/zfs/bin/mkfile > > > > program like so (for example): > > > > mkfile 500M /testpool.1861/bigfile.0 > > > > (which should be valid) end up with mkfile > > instead reporting: > > > > Standard error: > > Usage: mkfile [-nv] <size>[e|p|t|g|m|k|b] <filename> ... > > > > which prevent the kyua test involved from working. > > > > Turns out this is from expecting char to be always > > signed (so a -1 vs. 255 distinction, here in an > > aarch64 context): > > > > . . . > > (gdb) list > > 179 /* Options. */ > > 180 while ((ch = getopt(argc, argv, "nv")) != -1) { > > 181 switch (ch) { > > 182 case 'n': > > 183 nofill = 1; > > 184 break; > > 185 case 'v': > > (gdb) print ch > > $16 = 255 '\377' > > (gdb) print/x -1 > > $17 = 0xffffffff > > (gdb) print/x ch > > $18 = 0xff > > . . . > > > > With the mix of unsigned and signed it ends up > > being a 0xffu != 0xffffffffu test, which is > > always true. > > > > So the switch is reached as if a "-" prefix was > > present (that is not). Then the "option" is classified > > as invalid and the usage message is produced. > > > > Apparently no one had noticed. That, in turn, suggests a > > lack of inspected testing on aarch64, powerpc64, > > powerpc64le, armv7, powerpc, and powerpcspe. That, in > > turn, suggests that kyua test inspection for the likes > > of aarch64 is not historically a part of the release > > process for openzfs or for operating systems that include > > openzfs. > > > > Looks like the mkfile.c traces back to a former port > sysutils/mkfile that was unfetchable as of 2019. And, > looking around, it seems the kyua zfs tests may be a > FreeBSD only thing, not adopted in openzfs. > > So various implicit assumptions when I wrote the note > do not actually hold. > > FreeBSD would have to do additional testing via kyua, > beyond what openzfs does for testing, to discover the > unsigned char related mis-behavior in the mkfile that > FreeBSD's kyua tests use. Only FreeBSD variants are > likely to have a similar status, not general openzfs > including operating systems. > I wonder how hard ot would be to look for the char = getopt() pattern with coccinelle Warner === > Mark Millard > marklmi at yahoo.com > > >