--d6Gm4EdcadzBjdND
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 11, 2006 at 10:26:26PM -0500, Chapman Flack wrote:
> I'm back to SPLs again. This could be a dumb question (in which case,
> once I learn why, I'll know more than I do).

It's not, you're wandering into one of the fuzzy regions of all this.

> In a driver like midi, which can have lots of different sorts of
> hw devices as parents, and is hardcoded to use splaudio ... what
> should make me sure splaudio really covers the ipl used by
> whatever (existing or future) device I might be attached to?  Is
> it all just human knowledge of the code base, or is there some
> autoconfiguration magic that can make that information available
> or record constraints among levels to detect when they don't hold?

I think it's more that either splaudio() blocks the level or something is=
=20
broken. Thus it's more that it's an error to add midi goop to something=20
that's not at splaudio() or better.

> Could the following scenario in principle happen?
>=20
> 1. top half of driver calls start_output, imposes splaudio,
>    begins sending data
>=20
> 2. device responds quickly and interrupts for more data, at
>    level > splaudio, and gets in during top half's critical
>    section?

This scenario is exactly why we care about spl ordering. :-)

I think what would have to happen if we ever had a device that was at=20
higher than splaudio() (which I can imagine; Apple serial ports were able=
=20
to generate MIDI timing with add-on hardware) is that the start_output=20
routine could NOT do what you describe. If the hardware itself isn't at=20
splaudio(), the driver routines have to play games with other spl levels.

> Are there data structures with the parent's interrupt handlers
> and assigned spls available to examine at attach time?

No. But the driver should know what it's doing. :-)

Take care,

Bill

--d6Gm4EdcadzBjdND
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDxqIZWz+3JHUci9cRAlq0AJ4ketehp7tNJA+KEc0+TUs5PNpNcACcDNsC
xVidO2AinVR4LQapn4JQScw=
=9+9+
-----END PGP SIGNATURE-----

--d6Gm4EdcadzBjdND--