tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pcmaudio(4), for fun and games.

On Sat, Sep 20, 2008 at 01:59:28PM +0530, Cherry G. Mathew wrote:
> >>>>> "Quentin" == Quentin Garnier <> 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

[... 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

Quentin Garnier - -
"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

Home | Main Index | Thread Index | Old Index