"Toru Nishimura" <locore64@alkyltechnology.com> writes:

> I think it's a wrong practice to have NetBSD device configuration
> tree literally applied to do whole initialization.  In specific, it's too
> problematic to have clean/bright/smart/clever i2c "bus" device driver just
> for read/write NV values or RTC manipulation.  It's off-focus to "practice
> NetBSD" in that way, I believe in.  Having bus illusion to do such the
> simple task in very embryonic stage is dogmatic.  Similar story would be
> applied for com_cn_attach() woe (indeed they are obstacles for easy
> porting and spoiling for many NetBSD instances)

I agree. The problem being here occurs when the data-flow and
relationship between devices doesn't match the idea of a single,
rooted device hierarchy. We already have this problem and a variety of
poor workarounds in a number of contexts: ethernet addresses on the
sparc and sparc64 ports, interactions between i2c and other devices
on, for example, macppc audio devices, and general mismatches between
the device tree and the firmware information - whether RedBoot
boot_info, OpenFirmware trees, or ACPI.

        - Nathan