This does the same config file parse that -c/-C do, but only
that (hence no raidframe device is needed, or accepted).
Any syntax errors in the config file will be reported, nothing
else happens.
First, and what got me started on this set of cleanups, the queue
length in the "queue" section (START queue) is limited to what will
fit in a char without losing accuracy (I tried setting it to 200,
rather than the more common (universal?) 100 and found that the
value configured into the array was -56 instead.
Why the value needs to be passed through a char variable I have no
idea (it is an int in the filesystem raidframe headers) - but that's
the way it is done, and changing it would be an ABI change I believe
(and so need versioning to alter) and that isn't worth it for this
(or not now, IMO).
Instead check that the value in the char is the same value as was
read from the config file, and complain if not. Those of you with
unsigned chars will be able to have queue lengths up to 255, the
rest of us are limited to 127.
While looking at that, I noticed some code that obviously fails to
understand that scanf("%s") will never return a string containing
spaces, and proceeded to attempt to remove trailing spaces from the
result ... amusingly, after having used the result for its intended
purpose (non existent trailing spaces unremoved), after which that
buffer was never used again. That code is now gone (but for now,
just #if 0'd rather than actually deleted - it should be cleaned up
sometime).
Then I saw some other issues with how the config was parsed - a
simple (unbounded) scanf("%s") into a buffer, which hypothetically
might not be large enough (not a security issue really, raidctl has
no special privs, and it isn't likely that root could easily be
tricked into running it on a bogus config file - or not without
looking first anyway, and a huge long string would rather stand
out). Bound the string length to something reasonable, and
assert() that the buffer is big enough to contain it.
Lastly, in the event of one particular detected error in the
config file, the code would write a warning, but then just go
ahead and use the bad data (or nothing perhaps) anyway - a
failure of logic flow (unlikely to have ever happened, everyone
seems to simply copy the sample config from the man page, and
make minor adjustments as needed).
If any of these changes make any difference to anyone (except
me with my attempt to make longer queues - for no particularly
well thought out reason), I'd be very surprised.
the following comment appeared:
/*
* After NetBSD 9, convert this to not output the numRow's value,
* which is no longer required or ever used.
*/
We are after NetBSD 9 (well after). The change requested in that
comment is made here, and the comment is thus removed.
A couple of places in rf_configure.c where a value for the "rows"
parameter was output in an error message (always simply as the
constant 0) have also been updated (those messages will no longer
include "row 0", which they always said previously). One of them
was also slightly reworded to be clearer what problem it was
experiencing (when it said 'unable to get device file' it meant
it was unable to locate the name for the device in the config file,
not that it was found, and there was some other problem with it).
Determining the location where the error occurred is now done by
ParseVErrorInternal. This frees the remaining code from keeping the
filename and the line number together. It also makes Parse_Error short
enough that it might be worth providing a separate function for each of
the 3 log levels.
No functional change.
in case a clock interrupt is deffered while we're switching lwp.
Fix a (rare) panic:
panic: kernel diagnostic assertion "p != NULL" failed: file "/usr/src/sys/kern/kern_clock.c", line 438
seen when xen_timer_handler() is called from the splx() at the end of
mi_switch()
msaitoh