> Typical issue of not including "conf/std".  Yamamoto-san, I think it
> should be better to have config(1) automatically include it, otherwise
> we'll have reports like this any time we add something there.

it's what i proposed in the first place.  (as "default-options")
so i'm not against it.

> So, as you have guessed now, your problem is that you don't have any
> bufq strategy compiled into your kernel.  Now, the kernel should panic
> instead of segfaulting (what happens is that it ends up with
> bufq_strat_dummy and tries to call its init function, which is NULL).

as bufq_strat_dummy is skipped in the loop, i think bsp is NULL.

> To sum up, we have 3 bugs:
> 
>  1.  Segfault instead of panic.  Easy enough to solve, we should test
>      after the loop if we got bufq_strat_dummy, and panic.  Or even
>      make the #ifdef DEBUG block permanent and replace the printf with
>      a panic().
> 
>  2.  fdc/fd doesn't depend on BUFQ_DISKSORT in the config files.  Should
>      be easy enough to fix.

it isn't a bug.  "fallback to an existing strategy" is
an intended behaviour when i wrote the code.

>  3.  Users don't know about conf/std and what to do with it.  Proper way
>      to fix that is left as an exercise to the reader.  Even though I
>      tend to agree with Yamamoto-san's point on having conf/std
>      automatically included, users who know how config(1) works will
>      still have a choice, while those who aren't always looking at
>      source-changes (can't really blame them) won't be bitten in such
>      ways that easily.

users should read UPDATING. :-)

YAMAMOTO Takashi