Its actually a bit more complex.
I need the *link number*, which is normally generated by devfsadm as
part of configuring a new device. And I need this in the kernel, so a
devinfo snapshot in user space is not (by itself) sufficient. See the
problem isn't that I just want to know what devices are present -- I
also need to know the *path* (not /devices, but the /dev nickname path)
by which they are known.
I also *do* need to know which physical devices are present in the
system, so that I can provide answers for them as well.... (the OSS API
here is horribly brain damaged, it clearly wasn't well thought out with
hotplug and deferred attach in mind.)
Right now the way this works is a bit hairy:
devfsadm -i audio configures the audio pseudo device (and takes a
long time iterating over other parts of the tree we don't care about)
devfsadm audio plugin collects a devinfo snapshot, and iterates over
all audio devices. For each one, it does an "open" of the device node,
and sends down an ioctl to register the "number" with the device
itself. This also has the side effect of registering the audio driver
with the framework, so we can know the precise details of each and every
audio device. This is important, because many of the details are not
necessarily reflected in the devinfo tree. (The drivers themselves
register a ddi-autodetach property to keep them from vanishing and
invalidating this state.)
In retrospect, I can't eliminate the SMF service, because I still need
to iterate over the audio devices to get that information. (I really,
really hate that OSS requires this -- the idea that I need to know more
about the device than its device node path *before* I have opened it,
causes enormous grief here.)
The other option would be to have every audio driver ship a driver.conf
that included a ddi-forceattach and ddi-no-autodetach property. Its
pretty disgusting that this is necessary.
Now that said, I *could* replace the devfsadm code with another command
that runs and does the logical equivalent snapshotting the state, and
sending it to the framework. (A new subcommand for audioctl perhaps?)
This might at least avoid the use of devfsadm -i, and would avoid the
creation of a new statefile.
-- Garrett
Edward Pilatowicz wrote:
> so if you've already talked to someone about devinfo snapshots then i
> appoligize for the noise, but it really seems like you should be using
> them in this case.
>
> it seems like all the information your caching in this file is already
> cached elsewhere. hence, this file seems like a bad idea because
> invariably it will get out of sync, need to be maintained, etc.
>
> looking at the current svc:/system/device/audio:default start method, it
> seems like your using the wrong hammer. your invoking "devfsadm -i
> audio", which forces traversal of the entire device tree and a
> re-enumeration of audio device nodes, which as you note is a very heavy
> weight operation. then as part of that heavy weight operation you have
> the devfsadm audio plugin tell the kernel about the re-enumerated nodes.
>
> but really, instead of re-enumerating device nodes in the kernel you
> actually just want to know what audio devices exist on the system. you
> can determine this without any re-enumeration. this information is
> already stored in the devinfo snapshot cache. so instead of using
> devfsadm indirectly, why don't you just have a seperate utility that
> requests a libdevinfo snapshot, and then then iterates over it and tell
> the kernel about the /dev paths. that would be pretty easy and fast.
>
> ed
>
> On Mon, Nov 23, 2009 at 12:51:42PM -0800, Garrett D'Amore - sun microsystems
> wrote:
>
>> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
>> This information is Copyright 2009 Sun Microsystems
>> 1. Introduction
>> 1.1. Project/Component Working Name:
>> /etc/audio_numbers
>> 1.2. Name of Document Author/Supplier:
>> Author: Garrett D'Amore
>> 1.3 Date of This Document:
>> 23 November, 2009
>> 4. Technical Description
>>
>> Summary:
>>
>> This case introduces a new project-private statefile for the Boomer
>> (PSARC 2008/318) audio subsystem. The file will be shared between the
>> kernel and userland. This will replace the system/device/audio:default
>> SMF service, so that no other startup service will be necessary.
>>
>> These changes are necessary to properly address CR 6902551 (audio service
>> timeout not sufficient for service to start).
>>
>> Binding:
>>
>> This case seeks Minor binding.
>>
>> Problem:
>>
>> Due to the way the Open Sound System API was originally specified (designed
>> for Linux), we have to know the "number" of an audio device (e.g. /dev/dsp1
>> would be "1") in the kernel, because these numbers are reported back from
>> the kernel to userland via ioctls.
>>
>> The problem is that the enumeration of these numbers is done entirely in user
>> space by devfsadm.
>>
>> Currently, we regenerate this information and send it down at each boot by
>> performing a devfsadm operation during boot using an SMF service. However,
>> it turns out that devfsadm on some systems is quite expensive, and this can
>> lead to timeouts in the audio SMF service
>>
>>
>> Solution:
>>
>> We propose to move from regenerating this state (and autoconfiguring each
>> device driver) at boot, and instead use a persistent state file to track
>> this information.
>>
>> The state file will be called "/etc/audio_numbers", and will be written by
>> devfsadm when it creates an audio link. The contents will be lines that
>> have the form
>>
>> number<ws>driver<ws>instance<newline>
>>
>> <ws> is a sequence of one or more tabs or space characters.
>> <newline> is an ASCII newline character.
>>
>> "number" will be the enumerated audio device number in decimal, i.e. the
>> suffix of the /dev/dspXX or /dev/audioXX link. (Also /dev/sound/XX, etc.)
>>
>> The "driver" is the name of the audio driver, e.g. "audiohd".
>>
>> The "instance" is the audio instance number. This will normally be the same
>> as the device instance (i.e. as from ddi_get_instance()), but for some
>> devices
>> it could be a different value. (E.g. for a multiport device there could be
>> multiple logical audio device instances per dev_info_t. The actual value
>> is the 2nd argument to audio_dev_alloc(9F) specified in Boomer, unless that
>> value is zero, in which case the ddi_get_instance() value is assumed.)
>>
>> Lines beginning with a hash mark (#) are treated as comments.
>>
>> Here is an example file:
>>
>> # Sample file - this is a comment
>> 0 audiohd 0
>> 1 usb_ac 0
>> 2 audiosolo 0
>> 3 audiosolo 1
>> 4 usb_ac 1
>>
>> The /etc/audio_number file and its contents shall be deemed Project Private.
>>
>> The devfsadm audio link module will cease its traversal of the /dev tree,
>> and instead rely on the statefile to determine suitable targets for symbolic
>> links.
>>
>> Finally, we will be able remove the SMF facility sys/devices/audio, which
>> is currently used to regenerate the state information on each boot.
>>
>> This project will need to import the kobj interfaces for reading a file from
>> kernel space. While there is no case work behind these interfaces, we
>> believe
>> they are Consolidation Private based on existing contracts for their use
>> from the Sun Cluster products.
>>
>> Imported Interfaces
>>
>> kobj_open_file() Consolidation Private
>> kobj_close_file() " "
>> kobj_getc() " "
>>
>> Exported Interfaces
>>
>> svc:/system/device/audio:default EOF
>> /etc/audio_numbers Project Private
>>
>>
>> 6. Resources and Schedule
>> 6.4. Steering Committee requested information
>> 6.4.1. Consolidation C-team Name:
>> ON
>> 6.5. ARC review type: FastTrack
>> 6.6. ARC Exposure: open
>>
