Randy Fishel wrote: > On Thu, 24 Jan 2008, 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, >> 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. >> >> > > It seems to me that the best answer is for phase 1 apps to open the > /devices/ name and not create the /dev/ link. When you want to > promote it, effectively all you need to do is create the link. Apps > that hunt for it in /devices will still continue to work, and there is > no rename problem. Seems like the lowest risk to me. > The path under the /devices is not fixed. Is there some way like grep in kernel to filter nodes whose name includes hdaudio? Or we will use internal path only visable to kernel.
Best regards Freeman > > ---- Randy > >
