Have you actually seen this? Maybe we can steal their concepts..
> subsystem of the kernel. Essentially when you change stuff you go
> into there and say "If you dicked with the buffer cache, run one of
> test X Y or Z, if you changed the locking code in the networking run A
> or B"
My first comment is changed since when? What are we to use as a
reference?
Ok, I'm all for having a suite of test to check the current configuration.
But just how much can you test before you are actually running that
version of the kernel?
I also think that keeping track of what changes there were in the kernel
is futile. I guess this would have to be a diff between the currently
running kernel and the one that was just compiled. What if it was a large
number of kernel revisions? We do, however, need to have some sort of way
to test specific changes like complete TCP or scsi rewrites, for instance.
Or is this not what you mean?
I unfortunately don't know enough about kernel programming, yet.
A few of my concerns:
1. Don't we need a reference point to work from? In other words, are we
planning to work from a 'known good' configuration/kernel? Otherwise, we
would take the bugs as they come?
2. Have we established that we are going to use .config (or /proc?) to
find out what options the kernel has, and have specific tests for each
driver/device? Or each subsystem? Or each protocol etc?
3. Are we to use the existing kernel messaging to report these messages?
If not, are we going to insert new functions to write our reports?
Alan mentioned something before about implementing the POSIX set of tests.
He said it was rather difficult to do. I certainly don't have the
ability (unless its socket programming) to do this, but if there are
known tests out there, shouldn't we start with that?
Thanks,
Dave