Re: spkr vs spkr_synth module

[Paul Goyette <paul%whooppee.com@localhost>]

On Mon, 12 Dec 2016, Nathanial Sloss wrote:

> > > (christos wrote)
> > > Why does speaker_attach_mi exists? when autoconf calls spkrattach in
> > > the spkr_sync case, the parent is audio0...
> > >
> > > Also the wskbd code can just check that bell != NULL and call the bell
> > > stuff else do the normal thing, only in the bell function and nothing
> > > else needs to change...
> > >
> > > Or am I missing something?

> As for the module I think more platforms have audio than pcppi, so that spkr
> synth should be the prominent one.
>
> And as for wskbd I was thinking that the bell function should use the speaker
> ioctl. Opening /dev/speaker would either use pcppi or spkr_synth if they were
> available.

That might work if only one device is available, but it won't work for 
most x86 platforms (or anything that has both pcppi and an audio card!).

Both drivers are

        spkr0 at <attachment>

There can only be one instance of spkr0 (and indeed, if I read the
driver code correctly, only one instance of spkr*), so only one will
attach - and I'm not sure which one will work.

Additionally, both modules are written as though they own the speaker's
device major number, so only one module will succeed in the call to
devsw_attach();  the other will get EEXIST and the module (and driver) 
initialization will fail.

I'm unsure which driver will "take control" - it depends on which one 
"gets there first" (ordering of object module contributions to the 
module subsystem's link_set).

So, it's entirely possible that a kernel with _both_ drivers "built-in" 
can end up with neither driver being operational!  Driver_A may end up 
owning the device major, but the parent device might not exist;  even if 
Driver_B parent exists, it cannot work because it can't set-up the devsw 
entry!

(In the case of non-built-in modules, only one could be loaded at any 
point in time.  Each module would have its own copy of "struct cfdriver 
spkr_cd", so attempting to load a second module should result in a 
"multiply-defined global symbol" error.)

We should probably deprecate spkr_pcppi.  After releasing NetBSD-8 we 
can uncomment the spkr_synth lines in i386 and amd64 kernels, and add 
comments to the spkr_pcppi lines.



+------------------+--------------------------+------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+