John Plocher wrote:
> Freeman Liu wrote:
>> Taking these applications into consideration, we can change the name
>> to something else, for example,
>> /dev/private_dsp, and it will be found by those applications. As for
>> sadasupport, the change is trivial.
>> And sadasupport is the only consumer of this device file in this phase.
>>
>> Do you think it a reasonable approach ?
>
>
> If you intend to expose it in the future, but not today,
> the question is whether you expect to change its behavior
> between now and then?
>
> If not, then what is the "problem" you are protecting
> users and developers from by restricting their access
> today?
>
> If, in fact, the existence of /dev/dsp is effectively a
> de-facto public committed interface in the OSS meta-community
> today, then changing it incompatibly in phaseI seems wrong,
> especially if you intend on re-exposing it under the de-facto
> name in a later phase.
>
> (Note that the interface taxonomy levels do not equate
> in any way to the idea of secrecy or inaccessibility, but
> only to expectation setting advice about how much risk of
> incompatible change you take on by depending on something)
Having a /dev/dsp, which we don't really intend to "support", is IMO
wrong, given the existence of "de-facto" standards.
Publishing it under a different name might be a workaround, but as
others have pointed out, you'll find people who write scripts to locate
it, and then the funky "semi-private" name "evolves" into a new de-facto
standard for Solaris. Urk. Better not to expose the name at all.
The internal pathname approach is, IMO, far better. But it may have the
same limitations that /dev nodes have, which is that they are physical
paths rather than logical paths. A possible workaround is to use a
pseudo-driver to provide the "logical" path. Another possible
workaround is to just have the kernel components crawl the device tree
looking for the physical path. Yet another is to create a "registry"
where physical drivers can register their physical path so that the
kernel consumers can find them. Which one of these is best will vary.
-- Garrett