Re: RAIDframe nested autoconfiguration

[Jed Davis <jld%panix.com@localhost>]

David Brownlee <abs%NetBSD.org@localhost> writes:

>       I'm probably missing something (and not intending to denigrate
>       the already better situation your patches have introduced :),
>       but if the loop in step 5 was adjusted to encompass 6 as well
>       (so after each configuration it checked for new components
>       and looped back to 2 if any were found), *and* the loop went
>       in strictly ascending raid id order, then the the 'raid1 using
>       a degraded raid0 as a component' should work as expected?

Yes, if I just configure the one with the lowest unit number, then that
use case would work.  I'm a little uneasy about having that kind of
silent dependency on numbering the RAIDs in a postorder-compatible way,
especially when it would manifest only in certain exceptional cases.

Granted, /etc/rc.d/raidframe also imposes that requirement, but it does
so unconditionally, and a shell script is somewhat easier to alter
locally than the kernel autoconfig code.

Alternatively, there's the option of trying to insert missing components
that turn up later; if this can be done without causing spurious
reconstructions, it might be preferable to the mild hackery I have
now[*].  I'd need to learn a bit more about the guts of RAIDframe to see
about that.


[*] Modulo the potential for infinite RAID cycles; but do other systems'
    software RAID drivers attempt to check for that?
-- 
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))