On Sat, Sep 20, 2008 at 01:59:28PM +0530, Cherry G. Mathew wrote: > >>>>> "Quentin" == Quentin Garnier <cube%cubidou.net@localhost> writes: > > > [...] > > > Quentin> I am not happy at all with the way autoconf(9) is abused > Quentin> in that patch. > > This is not very different from how pcppi(4) handles autoconf(9), > actually, it depends on it. Yes, it is different. > The feeling I got was that the constraint on the pcppi(4) <-> > attimer(4) relationship required by midi_pcppi, for example, is hard > to express via autoconf(9) in a generic fashion. (See comment about > dev/ic/attimer.c: attimer_attach_speaker()). I'll grant you that you may not know the exact history of attimer(4), but you could have at least checked who wrote it before trying to explain to me how it works. > > [...] > > > Quentin> If I understand that patch correctly, you're basically > Quentin> attaching an audio device to pcppi(4), pretty much like > Quentin> we're already attaching a midi(4) device to it. I don't > Quentin> see any reason for an intermediate device. > > To state what I understand a bit more explicitly: > > autoconf(9) doesn't have a generic mechanism to express > non-hierarchical relationships between instances of devices. > > In this example: > > > --------------ISA-BUS--------------------------- > / \ ^ > / \ | > / \ | > / \ | > pcppi(4) <---> attimer(4) | > ^ / > | / > | / > | / > pcmaudio(4)-------/ > > > ie; pcmaudio(4) can only attach based on the fact that there is an > "association" between a pcppi(4) instance and a attimer(4) and the > fact that both of them are attached to the isa-bus. Ok, so you completely missed my point: there is no need for a pcmaudio(4) device. The only reason for the existence of attimer(4) is that it's very hard to do device abstraction with mixed register ranges. ACPI tables split resources that way, even though pcppi needs resources from attimer to actually function. So keep that in mind before getting too lyric: the existence of attimer(4) is purely artificial. I had to rush it at the time because a fellow developer had committed stuff without a complete grasp of the issue. The issue with it is that there is no guarantee that the attimer(4) device pcppi(4) finds is the correct one. However, the likeliness of having more than one attimer(4) device is very, very low. Think of attimer(4) has the provider of a service pcppi(4) needs to function. [... blababla ...] Man, you really *are* bored. It's almost sad to see such energy (and good ideas, too, the feature is fun, I'll admit that much) spent that way when NetBSD currently needs so much work to make 5.0 happen and be worthwhile. -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgpyb6KgfZUyG.pgp
Description: PGP signature