2008/043 [Phase 1 of OSS for Solaris]

[Freeman Liu]

Hi, Darren,

Thanks for the clarification. Although we will surely begin phase 2 
after phase 1 and address the other
issues including stability of /dev/dsp, we will take the other approach 
mentioned by Garrett to make
this node an internal path that only visible to kernel because the risk 
of having /dev/dsp visible but not usuable.
However, to be blunt, I have not seen any practical serious risks to do 
so besides it is kind of ugly.
Therefore, I will be grateful if you can explain further here. I feel 
here is a window through which I can look
into the architecture world.

Best regards
  Freeman


Darren J Moffat wrote:
> Freeman Liu wrote:
>>
>>>>>
>>>> In this phase, only sadasupport open it by ldi_ interface. And in 
>>>> the future, both user land applications and
>>>> sadasupport will use it. I feel this solution can avoid unexpected 
>>>> effect as well as make the future migration
>>>> smooth.
>>>
>>> So in this case there is no userland program that will ever need to 
>>> open /dev/dsp ?  If so then I think the best option is not to create 
>>> it at all even as /dev/private/dsp.
>
>>  From this point of view, you are right. While from another point of 
>> view, since the visibility of  this interface will be promoted in 
>> following phases,
>
> Best to only make it visible when it is usable for the reasons others 
> have pointed out.
>
> Also if for some reason the future cases never happened or end up 
> being different we aren't left with an unusable /dev/dsp in the 
> namespace.
>
>> we feel the current approach is a simple one without too much risk. 
>> Anyway, if any serious concern emerges which we have overlooked, making
>> it a internal node will be a good approach.
>
> I believe what you are hearing from ARC memebers is that the risk of 
> having /dev/dsp visible when it isn't usable is too high to be 
> acceptable.
>