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


Reply via email to