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. >
