Dear Grant,
in message <[EMAIL PROTECTED]> you wrote:
>
> However, I have declined (for now) to pick up the defconfigs for those
> boards and instead merged in the config features they require into the
> mpc5200 defconfig. My primary reason for doing so is to increase the
> likelyhood that full featured kernels are built and tested so that
> situations where board ports conflict with each other are caught and
> fixed.
I know what you mean, and I agree with the idea.
Unfortunately I think it's impossible to implement, especially on such
embedded processors with their high level of pin multiplexing.
For example, if you want to include testing of the FEC ethernet
driver, you will probably fail to test the second USB port. I think
it's simply not possible to test all possible options in a single
kernel configuration - first it doesn't work (for example because of
pin multiplexing issues), second you will likely not be able to find
hardware that implements all features at once.
My dream is to have a distributed test environment - a framework
which can be used for automatic testing which includes building and
running the code on a set of systems, and which will then report the
test results to a central location.
We have the same problem (probably to a much higher degree) in
U-Boot; nobody can test all board configurations because nobody has
all the cross-tools installed nor the 500+ boards available.
> ojn has also been complaining about the number of defconfigs he needs
> to build to test all the powerpc configurations without any
> indications about which ones are important and which ones are not.
again, some distributed test tool might help - we would get not only
information abouyt test results, but also which configurations have
been tested how frequently.
> There has been some discussion about having a subdirectory for
> optimized board configs, but nobody has done anything about it yet.
Is this a hint?
> The one part that I have a really strong opinion on is that there
> should be a full featured mpc5200 defconfig for build testing. Beyond
> that (and if ojn can also be appeased) I can probably be convinced. :-)
Maybe my expectations for "full featured' are just too high..
> The LED code just hasn't been picked up. IIRC, it was reworked to
> make it a proper driver in drivers/leds. I need to look at it again,
> but it is a lot of code for a very simple thing and I wasn't sure if I
> should be the one to pick it up because it is in drivers/leds which
> has a different maintainer.
I see. Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
If some day we are defeated, well, war has its fortunes, good and
bad.
-- Commander Kor, "Errand of Mercy", stardate 3201.7
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
