On 22.08.2008 15:18, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 22.08.2008 08:54, ron minnich wrote:
On Thu, Aug 21, 2008 at 11:24 PM, Stefan Reinauer stepan@coresystems.de wrote:
Actually running the produced stuff through Kconfig is wrong, because it has nothing to do with user configuration. Instead both Kconfig and the tree parser should produce similar output for the data each of them collects.
That's a key point. I agree.
I had something like that in an earlier iteration, but I threw it away. The big problem here are configuration options which are available only for some targets. Look at USBDEBUG:
- Some chipsets simply don't support it, so there's no point in offering
it in Kconfig.
- For the chipsets which support USBDEBUG, we may not want to enable it.
Why would _we_ want to decide, not the user?
To make sure the user is not disappointed if a selectable feature does not work.
- It is conceptually the same as serial console support, so enabling it
unconditionally is bad.
what do you mean with this sentence?
It should be an option the user can set via the config interface.
And now imagine, someone plugs a PCI USB 2.0 card with debug support into the system. Are you saying this user should not get the option of using usb debug, because her onboard chipset can't do it?
You have a point. However, looking for USB debug capable devices in PCI slots will require PCI enumeration and will sort of depend on the device tree and thus depend on stage2. Early USB debug code for builtin devices can be available in stage1.
I think the best way to solve the problem you bring up here is if you add a good help text to the USB Debug console switch a la "If your onboard USB controller has no debug port support, you need to plug a PCI USB adapter in order to use this feature."
Agreed. Do you know of any PCI USB adapter which has this feature? It would be nice for testing.
Regards, Carl-Daniel