Hi, all,
I would like to make a summary of discussion of /dev/dsp issue and
give the solution of project team.
Sadasupport need an interface to access low-level driver. There are
two options, one is to use /dev/private_dsp, the other is to use some
one out of /dev dir, for example, an internal node or /devices node.
Project team prefer the first one. I will analysis the risks and
benefits to so.
What's the risk to create a project private interface /dev/private_dsp?
One concern is that it is possible that although
project team promise to change it to /dev/dsp and promote its
stability in following phases, things may change and it may be left
there uncared in the future. Here I would like to say that /dev/dsp
is one of the major interfaces of OSS, which is the goal of the whole
project. I see no reason we need to worry about it.
Another concern is that is may be leveraged by hackers. We have make
/dev/private_dsp owned by root with 600 permission. Therefore there is
little chance that weird user can do with it except verify its
existence. Sane application will turn to SADA interface in this phase,
which is the default, public interface.
From these discussion, we can say safely that the risk is low.
On the other hand, the advantage of this solution is that it is so
simple and straight (which may make it less challenging ;)) for now and
for future promotion. If both solution are of little risk, why dont we
choose the simple one ?
Thanks for all your thoughtful ideas.
Best regards
Freeman
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
