D
Deleted member 54719
Guest
I noticed something the other day when configuring the OSS sound drivers on an old Dell Inspirion Nforce MCP61 desktop machine; something that bothers my sensibilities. One of the first things I do when checking to see if a device or service is available is to look for the device entries in /dev.
In my mind that would indicate that the driver, or a supplemental component is not loaded. The really weird thing is that when I did something like
In what world is it normal or acceptable to be able to read a file, for which no directory entry exists, then the system creates a similar directory entry when the device is accessed? Can someone explain the rationale or the history of why this even works? Seems to me that in any NIX trying to read from a non-existent file node should return an error, not create a similarly named entry and read from it. This is very odd behaviour to me.
dmesg showed that the sound hardware was found and /dev/sndstat had two PCM devices listed in it. However, no /dev/dsp* or /dev/pcm* file nodes existed.In my mind that would indicate that the driver, or a supplemental component is not loaded. The really weird thing is that when I did something like
cat < /dev/dsp the command worked and read binary sound samples from the sound card. A subsequent ls -l /dev/dsp* showed that a device node of /dev/dsp0.0 mysteriously appeared...not even the same device name I used when reading the audio data.In what world is it normal or acceptable to be able to read a file, for which no directory entry exists, then the system creates a similar directory entry when the device is accessed? Can someone explain the rationale or the history of why this even works? Seems to me that in any NIX trying to read from a non-existent file node should return an error, not create a similarly named entry and read from it. This is very odd behaviour to me.
