There's "testing new features" (the implication being that they
probably work, but maybe not) and there's the Bill Jolitz philosophy
of "This is reasearch. We don't care if it works for you."
When we're doing the former, I'm all for it - excepting a few key
binaries like netscape, I switched my entire system over to ELF.
It didn't quite work, so I needed to change the kernel and modular
code I'm debugging back to a.out, but that's OK since it looked
like it would work. When you want to do the later, the changes belong in
#ifdef'd notyet code or comments indicating that this is the future direction
of things to come, any one else have implementation suggestions?
Since (perhaps this changed in the last few days; I'm going to rebuild
my GDB with HJ's newest patch and see what happens) cursory tests show
that the user tools don't work, ELF core dumps fall into the later
category, and should NOT be the default (even if it is an ELF
kernel).
>How is one supposed to test it out if we have to wait "until we're
>positive"?
Ok, I over stated this. However, if there are obvious bugs in the interaction
of user level tools (specifically GDB) and the current implementation of ELF
core dumps, they should not be the default in any one's kernels but the people
actively working on that problem.
If you want to implement the Jolitz philosophy more fully, we can all
send in our favorite development tree changes
Other developer:
"The SCSI system just broke"
Eric, Michael, or I:
"That's OK, it's just there for testing purposes..."
and have a kernel it is not possible to develop under.