Re: /dev/dsp* & /dev/audio* devices not present
per...@pluto.rain.com writes: > "Rick C. Petty" writes: > > Funny. But this isn't a bug disguised as a feature. > > It's a feature that you believe is a bug. > I would call it a bug that you believe is a feature. It is *by definition* a feature. The code works as intended. If it didn't, that would be a bug. The fact that you wish the code worked differently doesn't make it a bug. Anyway, you can complain until you're blue in the face, but it's not going to change, for a number of very good reasons (which have mostly been listed in other posts in this thread). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
On Sun, Jan 11, 2009 at 09:14:53PM -0800, per...@pluto.rain.com wrote: > > > Funny. But this isn't a bug disguised as a feature. > > It's a feature that you believe is a bug. > > I would call it a bug that you believe is a feature. Not just me, but freebsd developers including those who wrote devfs. > > > In any other part of the directory tree we expect ls to provide > > > a list of names that are available to be opened (subject to > > > permissions). Why should /dev be any different? > > > > Because it's a special filesystem. > > I think that constitutes an admission that it violates POLA, > and it's not much of a justification IMO. Only you and a small group of people seem to be astonished by this, something that's been in FreeBSD since 4.0. Glad you're voicing your opinion now, before it's too late. > The manpage for tun(4) says: > > tun does for network interfaces what the pty(4) driver does for > terminals ... The network interfaces are named ``tun0'', ``tun1'', > etc., one for each control device that has been opened ... The tun > interface permits opens on the special control device /dev/tun. > When this device is opened, tun will return a handle for the > **lowest** unused tun device ... > > (emphasis added). The whole point of cloning devices is to avoid > the need for the application to loop through a sequence of possible > names to find one that is not in use; it simply opens the generic > name and gets a (pseudo) device. Yes, when using /dev/tun, you get the lowest. That's expected behavior. But it doesn't say not to use your own numbering. I'll stand by my previous statements. > > but why create device nodes when they aren't necessary, as you > > have to clone the nodes (or create new ones) when an actual > > open(2) occurs? > > As I stated earlier in this thread: > > * It doesn't necessarily need to actually create them, but the > * results from readdir(2) should be as if they had been created. I think you may find this is not as trivial as you make it sound. > > Please provide the reference where it violates POSIX. > > I am not familiar with POSIX in detail, which is why I only suggest > that it *may* violate POSIX. That much is obvious. > You're welcome to research the matter. No thanks, I've read it back to front. But you seem to imply that you're the expert, so I was hoping for you to point out how I've misread it. > I would *expect* that research to find that there is supposed to be > a correspondence between what readdir reports as the contents of a > directory, and the results of attempting to open a filename in the > directory whose contents were read; if not, what would be the point > of having readdir in the first place? Good point. We should probably rewrite syscalls to use vnode references instead of names. That would solve all ambiguity problems as well. > Of course not, but we are not dealing here with a case in which > process A reads the directory, then process B creates a file in > it, and thus that file becomes visible to process A. Instead we > have a magical side-effect, wherein process A opens a file which > (per readdir) does not exist, and thereby calls into existence a > new file, while the name that process A opened *still* does not > exist. There is nothing magical about it, nor did this just happen overnight. Perhaps it's not well-documented but it is well-known. > > And what about msdosfs and case-insensitivity? You can > > certainly open files that weren't a part of your readdir. > > The semantics of msdosfs are driven by the need to maintain > compatibility with a certain other operating system -- the one > which defined that filesystem representation in the first place. Just like devfs, which defined the filesystem representation that there are invisible nodes and pseudo-nodes. > I hardly think it should be considered a good precedent. Obviously kernel developers disagreed with you. > > Also no one in their right mind would be coding a readdir/open > > solution against a filesystem known to be completely dynamic and > > especially against devfs. You would want to tie in directly to > > devctl, sysctl, or syscall. > > Programmatically, yes. But long-standing historical precedent, > going back at least as far as the AT&T sixth research edition, > would have an administrator or knowledgeable user believe that the > contents of /dev are related to the collection of drivers that the > system supports. So we should go back to the precedent and make all dev entries static once again? You can't argue for progress in the same case that you argue for precedence. > actually has that device attached. Why would we want to trash that > concept by allowing the existence of phantom drivers, which have no > presence in /dev unless/until they have been opened? The drivers aren't phantom-- their instances are. > > Why is it suboptimal? > > As in the case of the OP, it is suboptimal from the standpoint of > a human who
Re: /dev/dsp* & /dev/audio* devices not present
"Rick C. Petty" wrote: > On Sat, Jan 10, 2009 at 04:20:58AM -0800, per...@pluto.rain.com wrote: > > "Rick C. Petty" wrote: > > > > > > That's not how devfs works. It's actually a feature > > > that devfs doesn't list everything ever possible > > > > http://storage9.myopera.com/freejerk/files/bug-feature.jpg > > Funny. But this isn't a bug disguised as a feature. > It's a feature that you believe is a bug. I would call it a bug that you believe is a feature. > > > I'd rather be able to list to see things that are in use, > > > although at first glance I didn't like devfs hidden nodes. > > > Otherwise you'd be stuck printing tunXXX through infinity > > > instead of this: > > > > > > % ls /dev/tun* > > > /dev/tun0 /dev/tun115 /dev/tun194 > > > > In any other part of the directory tree we expect ls to provide > > a list of names that are available to be opened (subject to > > permissions). Why should /dev be any different? > > Because it's a special filesystem. I think that constitutes an admission that it violates POLA, and it's not much of a justification IMO. > > Since you aren't supposed to open (say) /dev/tun85, but only > > /dev/tun0, correspondence between readdir and open would not > > demand > > What? Why aren't you supposed to open tun85? I use this behavior > all the time and have for years. It helps keep track of things. > Otherwise I would have to keep my natd configuration, firewall > rules, and openvpn configuration all in sync. Please provide a > reference describing you're not "supposed to" open any arbitrary > tunnelling device. The manpage for tun(4) says: tun does for network interfaces what the pty(4) driver does for terminals ... The network interfaces are named ``tun0'', ``tun1'', etc., one for each control device that has been opened ... The tun interface permits opens on the special control device /dev/tun. When this device is opened, tun will return a handle for the **lowest** unused tun device ... (emphasis added). The whole point of cloning devices is to avoid the need for the application to loop through a sequence of possible names to find one that is not in use; it simply opens the generic name and gets a (pseudo) device. BTW I was slightly off -- it is /dev/tun rather than /dev/tun0 that's supposed to be opened -- but if anything this strengthens my point (see below). > > that readdir return the (large, if not infinite) list of > > potential instances. It would however seem reasonable for > > that ls command to show /dev/tun0 if its driver is loaded, > > even if the device has not been instantiated because the > > node has never been opened. > > I don't buy that argument at all. If anything it should show > "/dev/tun", Agreed it should be /dev/tun -- see above. > but why create device nodes when they aren't necessary, as you > have to clone the nodes (or create new ones) when an actual > open(2) occurs? As I stated earlier in this thread: * It doesn't necessarily need to actually create them, but the * results from readdir(2) should be as if they had been created. > > > This is not a bug, it is designed behavior. It was > > > intentionally written to dynamically create device > > > nodes when needed. > > > > That the code faithfully adheres to the design does not > > guarantee that the design is flawless. IMO it violates > > POLA, if not POSIX, > > Please provide the reference where it violates POSIX. I am not familiar with POSIX in detail, which is why I only suggest that it *may* violate POSIX. You're welcome to research the matter. I would *expect* that research to find that there is supposed to be a correspondence between what readdir reports as the contents of a directory, and the results of attempting to open a filename in the directory whose contents were read; if not, what would be the point of having readdir in the first place? > > for open(2) to succeed when applied to a name which, according > > to readdir(2), does not exist; > > What? This can happen already-- there is no atomicity between > a readdir and an open. Of course not, but we are not dealing here with a case in which process A reads the directory, then process B creates a file in it, and thus that file becomes visible to process A. Instead we have a magical side-effect, wherein process A opens a file which (per readdir) does not exist, and thereby calls into existence a new file, while the name that process A opened *still* does not exist. > And what about msdosfs and case-insensitivity? You can > certainly open files that weren't a part of your readdir. The semantics of msdosfs are driven by the need to maintain compatibility with a certain other operating system -- the one which defined that filesystem representation in the first place. I hardly think it should be considered a good precedent. > Also no one in their right mind would be coding a readdir/open > solution against a filesystem known to be completely dynamic and > especially against devfs.
Re: /dev/dsp* & /dev/audio* devices not present
On Sat, Jan 10, 2009 at 04:20:58AM -0800, per...@pluto.rain.com wrote: > "Rick C. Petty" wrote: > > > > That's not how devfs works. It's actually a feature > > that devfs doesn't list everything ever possible > > http://storage9.myopera.com/freejerk/files/bug-feature.jpg Funny. But this isn't a bug disguised as a feature. It's a feature that you believe is a bug. > > I'd rather be able to list to see things that are in use, although > > at first glance I didn't like devfs hidden nodes. Otherwise you'd > > be stuck printing tunXXX through infinity instead of this: > > > > % ls /dev/tun* > > /dev/tun0 /dev/tun115 /dev/tun194 > > In any other part of the directory tree we expect ls to provide > a list of names that are available to be opened (subject to > permissions). Why should /dev be any different? Because it's a special filesystem. > Since you aren't supposed to open (say) /dev/tun85, but only > /dev/tun0, correspondence between readdir and open would not demand What? Why aren't you supposed to open tun85? I use this behavior all the time and have for years. It helps keep track of things. Otherwise I would have to keep my natd configuration, firewall rules, and openvpn configuration all in sync. Please provide a reference describing you're not "supposed to" open any arbitrary tunnelling device. > that readdir return the (large, if not infinite) list of potential > instances. It would however seem reasonable for that ls command to > show /dev/tun0 if its driver is loaded, even if the device has not > been instantiated because the node has never been opened. I don't buy that argument at all. If anything it should show "/dev/tun", but why create device nodes when they aren't necessary, as you have to clone the nodes (or create new ones) when an actual open(2) occurs? > > This is not a bug, it is designed behavior. It was intentionally > > written to dynamically create device nodes when needed. > > That the code faithfully adheres to the design does not guarantee > that the design is flawless. IMO it violates POLA, if not POSIX, Please provide the reference where it violates POSIX. > for open(2) to succeed when applied to a name which, according to > readdir(2), does not exist; What? This can happen already-- there is no atomicity between a readdir and an open. And what about msdosfs and case-insensitivity? You can certainly open files that weren't a part of your readdir. Also no one in their right mind would be coding a readdir/open solution against a filesystem known to be completely dynamic and especially against devfs. You would want to tie in directly to devctl, sysctl, or syscall. > and it is suboptimal to have "stealth" > drivers whose availability for use cannot be discovered by examining > /dev. Why is it suboptimal? I think you have that backwards-- it's more optimal not to have to create superfluous device nodes when they are not needed, at least from the kernel efficiency perspective. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
Ulrich Spoerlein wrote: > I cannot really comment on the devfs(4) design issues, > and quite frankly it hasn't bothered my thus far. It evidently inconvenienced the OP. > Just another little quirk you get to remember. If we followed that line of reasoning to its logical conclusion we would eliminate POLA entirely. > > IMO it violates POLA, if not POSIX, for open(2) to succeed when > > applied to a name which, according to readdir(2), does not > > exist; and it is suboptimal to have "stealth" drivers whose > > availability for use cannot be discovered by examining /dev. > > You forgot directories with --x permissions. You can open many > files inside them, but readdir(2) will get you nowhere. So this > is a poor standard by which to judge devfs(4) device cloning. There are at least two problems with that analysis: * /dev does not ordinarily have --x permissions. Even if I amended the principle to allow for that case, it would not affect its application to this case. * readdir works for root, even in directories with --x permissions. For example: $ mkdir test $ touch test/file $ ls -la test total 4 drwxr-xr-x 2 perryh perryh 512 Jan 10 15:39 . drwxr-xr-x 3 perryh perryh 512 Jan 10 15:39 .. -rw-r--r-- 1 perryh perryh0 Jan 10 15:39 file $ chmod 111 test $ ls -ld test d--x--x--x 2 perryh perryh 512 Jan 10 15:39 test $ ls -la test total 0 ls: test: Permission denied # ls -la test total 4 d--x--x--x 2 perryh perryh 512 Jan 10 15:39 . drwxr-xr-x 3 perryh perryh 512 Jan 10 15:39 .. -rw-r--r-- 1 perryh perryh0 Jan 10 15:39 file ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
I cannot really comment on the devfs(4) design issues, and quite frankly it hasn't bothered my thus far. Just another little quirk you get to remember. On Sat, 10.01.2009 at 04:20:58 -0800, per...@pluto.rain.com wrote: > That the code faithfully adheres to the design does not guarantee > that the design is flawless. IMO it violates POLA, if not POSIX, > for open(2) to succeed when applied to a name which, according to > readdir(2), does not exist; and it is suboptimal to have "stealth" > drivers whose availability for use cannot be discovered by examining > /dev. You forgot directories with --x permissions. You can open many files inside them, but readdir(2) will get you nowhere. So this is a poor standard by which to judge devfs(4) device cloning. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
"Rick C. Petty" wrote: > On Thu, Jan 08, 2009 at 09:50:47PM -0800, per...@pluto.rain.com wrote: > > > In principle, everything that would be successfully created if > > open(2)'ed. It doesn't necessarily need to actually create them, > > but the results from readdir(2) should be as if they had been > > created. The whole point of things like ls(1) and readdir(2) is > > to find out what-all is available to be opened, without having to > > already know the answer. > > That's not how devfs works. It's actually a feature > that devfs doesn't list everything ever possible http://storage9.myopera.com/freejerk/files/bug-feature.jpg > (things looked terrible back in the old MAKEDEV days with > all those polluted names). Yes, MAKEDEV can create the opposite problem, wherein /dev contains nodes for devices whose drivers and/or hardware aren't present. Such orphan nodes aren't a whole lot better than missing nodes. > I'd rather be able to list to see things that are in use, although > at first glance I didn't like devfs hidden nodes. Otherwise you'd > be stuck printing tunXXX through infinity instead of this: > > % ls /dev/tun* > /dev/tun0 /dev/tun115 /dev/tun194 In any other part of the directory tree we expect ls to provide a list of names that are available to be opened (subject to permissions). Why should /dev be any different? Since you aren't supposed to open (say) /dev/tun85, but only /dev/tun0, correspondence between readdir and open would not demand that readdir return the (large, if not infinite) list of potential instances. It would however seem reasonable for that ls command to show /dev/tun0 if its driver is loaded, even if the device has not been instantiated because the node has never been opened. > This is not a bug, it is designed behavior. It was intentionally > written to dynamically create device nodes when needed. That the code faithfully adheres to the design does not guarantee that the design is flawless. IMO it violates POLA, if not POSIX, for open(2) to succeed when applied to a name which, according to readdir(2), does not exist; and it is suboptimal to have "stealth" drivers whose availability for use cannot be discovered by examining /dev. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
Ulrich Spoerlein wrote: > On Thu, 08.01.2009 at 21:50:47 -0800, per...@pluto.rain.com wrote: > > Ulrich Spoerlein wrote: > > Ummm, out of curiosity, are your receiving your mail via UUCP? :) http://lists.freebsd.org/pipermail/freebsd-net/2009-January/020645.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
On Thu, Jan 08, 2009 at 09:50:47PM -0800, per...@pluto.rain.com wrote: > > In principle, everything that would be successfully created if > open(2)'ed. It doesn't necessarily need to actually create them, > but the results from readdir(2) should be as if they had been > created. The whole point of things like ls(1) and readdir(2) is > to find out what-all is available to be opened, without having to > already know the answer. That's not how devfs works. It's actually a feature that devfs doesn't list everything ever possible (things looked terrible back in the old MAKEDEV days with all those polluted names). I'd rather be able to list to see things that are in use, although at first glance I didn't like devfs hidden nodes. Otherwise you'd be stuck printing tunXXX through infinity instead of this: % ls /dev/tun* /dev/tun0 /dev/tun115 /dev/tun194 Maybe you could argue that dsp should work differently, but some sound cards and configurations would give you infinite (within reason) device nodes, IIRC. > > This is a FAQ really. > > It may be an FAQ, but it is also a bug, granted one that may not be > easy to fix. This is not a bug, it is designed behavior. It was intentionally written to dynamically create device nodes when needed. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
On Thu, 08.01.2009 at 21:50:47 -0800, per...@pluto.rain.com wrote:
> Ulrich Spoerlein wrote:
Ummm, out of curiosity, are your receiving your mail via UUCP? :)
> > Please run
> > % cat /dev/sndstat
> > % ls -l /dev/dsp0 /dev/dsp0.0
> >
> > The reason you are not seeing them with 'ls /dev/dsp*' is because
> > devfs is creating the nodes when they are open(2)'ed. Using shell
> > globbing will search the output of readdir(2) for matches to dsp*
> > where devfs has no way of dynamically creating nodes (which ones
> > should it create anyway?)
>
> In principle, everything that would be successfully created if
> open(2)'ed. It doesn't necessarily need to actually create them,
> but the results from readdir(2) should be as if they had been
> created. The whole point of things like ls(1) and readdir(2) is
> to find out what-all is available to be opened, without having to
> already know the answer.
Not according to my understanding, which may be flawed of course.
devfs(4) would have to create all devices, which may be open(2)ed up
front, for dsp that would have to be 32 instances (for my system):
% ll /dev/dsp0.{0,9,11,21,31}
crw-rw-rw- 1 root wheel0, 142 Jan 9 20:57 /dev/dsp0.0
crw-rw-rw- 1 root wheel0, 153 Jan 9 20:20 /dev/dsp0.11
crw-rw-rw- 1 root wheel0, 154 Jan 9 20:20 /dev/dsp0.21
crw-rw-rw- 1 root wheel0, 151 Jan 9 20:20 /dev/dsp0.31
crw-rw-rw- 1 root wheel0, 152 Jan 9 20:20 /dev/dsp0.9
It would also cloud the information about devices in-use.
> > This is a FAQ really.
>
> It may be an FAQ, but it is also a bug, granted one that may not be
> easy to fix.
You really want all cloneable instances to show up with a readdir, which
would mean that they would have to created upon device attachment? I
really don't think so ... For /dev/dsp0 the semantics are pretty clear:
try to open /dev/dsp0, if it succeeds fine, if not, there is no vchan
available and you're SOL. No need to play the guess-a-free-dsp-device
game.
Cheers,
Ulrich Spoerlein
--
It is better to remain silent and be thought a fool,
than to speak, and remove all doubt.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
Ulrich Spoerlein wrote: > Please run > % cat /dev/sndstat > % ls -l /dev/dsp0 /dev/dsp0.0 > > The reason you are not seeing them with 'ls /dev/dsp*' is because > devfs is creating the nodes when they are open(2)'ed. Using shell > globbing will search the output of readdir(2) for matches to dsp* > where devfs has no way of dynamically creating nodes (which ones > should it create anyway?) In principle, everything that would be successfully created if open(2)'ed. It doesn't necessarily need to actually create them, but the results from readdir(2) should be as if they had been created. The whole point of things like ls(1) and readdir(2) is to find out what-all is available to be opened, without having to already know the answer. > This is a FAQ really. It may be an FAQ, but it is also a bug, granted one that may not be easy to fix. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
El día Thursday, January 08, 2009 a las 09:06:45AM +0200, Vladimir Terziev escribió: > Hi Matthias, > > i configured Ekiga and during the configuration process it didn't find > any Audio device, so i think /dev/dsp* devices must be present, isn't > it ? > > Regards, > > Vladimir Which version of Ekiga you are using? In the past I've send patches to the Ekiga maintainer to make /dev/dsp working. I don't know if they made it, for example, into the version the 7.0 port is using. matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ SPAMer of the year: Subject: Alle Software ist Deutsche Sprachen >From: -40 % die Neujahrsaktion ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
Hi Matthias, the version of Ekiga i'm exploring is built from ports and it's ekiga-2.0.11_4 . Regards, Vladimir On Thu, 2009-01-08 at 10:31 +0200, Matthias Apitz wrote: > El día Thursday, January 08, 2009 a las 09:06:45AM +0200, Vladimir > Terziev escribió: > > > Hi Matthias, > > > > i configured Ekiga and during the configuration process it didn't > find > > any Audio device, so i think /dev/dsp* devices must be present, > isn't > > it ? > > > > Regards, > > > > Vladimir > > Which version of Ekiga you are using? In the past I've send patches to > the Ekiga maintainer to make /dev/dsp working. I don't know if they > made > it, for example, into the version the 7.0 port is using. > > matthias > > -- > Matthias Apitz > Manager Technical Support - OCLC GmbH > Gruenwalder Weg 28g - 82041 Oberhaching - Germany > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.oclc.org/ > http://www.UnixArea.de/ > b http://gurucubano.blogspot.com/ > > SPAMer of the year: Subject: Alle Software ist Deutsche Sprachen > >From: -40 % die Neujahrsaktion > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
Thank you very much Ulrich! After running "ls -l /dev/dsp0 /dev/dsp0.0" the devices are present and Ekiga has found them. The reasonable question is why Ekiga was not able to discover them without the hack you suggested. Regards, Vladimir On Thu, 2009-01-08 at 10:07 +0200, Ulrich Spoerlein wrote: > On Thu, 08.01.2009 at 09:06:45 +0200, Vladimir Terziev wrote: > > Hi Matthias, > > > > i configured Ekiga and during the configuration process it didn't > find > > any Audio device, so i think /dev/dsp* devices must be present, > isn't > > it ? > > Please run > % cat /dev/sndstat > % ls -l /dev/dsp0 /dev/dsp0.0 > > The reason you are not seeing them with 'ls /dev/dsp*' is because > devfs > is creating the nodes when they are open(2)'ed. Using shell globbing > will > search the output of readdir(2) for matches to dsp* where devfs has no > way of dynamically creating nodes (which ones should it create > anyway?) > > This is a FAQ really. > > Cheers, > Ulrich Spoerlein > -- > It is better to remain silent and be thought a fool, > than to speak, and remove all doubt. > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
On Thu, 08.01.2009 at 09:06:45 +0200, Vladimir Terziev wrote: > Hi Matthias, > > i configured Ekiga and during the configuration process it didn't find > any Audio device, so i think /dev/dsp* devices must be present, isn't > it ? Please run % cat /dev/sndstat % ls -l /dev/dsp0 /dev/dsp0.0 The reason you are not seeing them with 'ls /dev/dsp*' is because devfs is creating the nodes when they are open(2)'ed. Using shell globbing will search the output of readdir(2) for matches to dsp* where devfs has no way of dynamically creating nodes (which ones should it create anyway?) This is a FAQ really. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
Hi Matthias, i configured Ekiga and during the configuration process it didn't find any Audio device, so i think /dev/dsp* devices must be present, isn't it ? Regards, Vladimir On Wed, 2009-01-07 at 20:10 +0200, Matthias Apitz wrote: > El día Wednesday, January 07, 2009 a las 06:52:31PM +0200, Vladimir > Terziev escribió: > > ... > > > device sound > > device snd_hda > > > > > > The driver seems to recognize the controller: > > > > $ dmesg | grep pcm > > > > pcm0: mem > > 0xe04c-0xe04c3fff irq 21 at device 27.0 on pci0 > > pcm0: [ITHREAD] > > pcm0: > > pcm0: > > > > > > This is also confirmed here: > > > > $ cat /dev/sndstat > > FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) > > Installed devices: > > pcm0: at memory > > 0xe04c irq 21 [20071129_0050] [MPSAFE] (1p:1v/1r:1v channels > duplex > > default) > > all fine until here; > > > > > Now the problem ... > > The strange thing is all audio related devices are missing in /dev > > > > $ ls -l /dev/audio* /dev/dsp* > > ls: /dev/audio*: No such file or directory > > ls: /dev/dsp*: No such file or directory > > fine too; you will not see /dev/dsp* with ls(1), just open the device > /dev/dsp with some application and it will appear; > > > Respectively i have no working sound support :( > > what you mean exactly with 'i have no working sound support'? > try changing the values with the mixer(1) command if no sound is > coming > out from apps; > > matthias > -- > Matthias Apitz > Manager Technical Support - OCLC GmbH > Gruenwalder Weg 28g - 82041 Oberhaching - Germany > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.oclc.org/ > http://www.UnixArea.de/ > b http://gurucubano.blogspot.com/ > > SPAMer of the year: Subject: Alle Software ist Deutsche Sprachen > >From: -40 % die Neujahrsaktion > > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
El día Wednesday, January 07, 2009 a las 06:52:31PM +0200, Vladimir Terziev escribió: ... > device sound > device snd_hda > > > The driver seems to recognize the controller: > > $ dmesg | grep pcm > > pcm0: mem > 0xe04c-0xe04c3fff irq 21 at device 27.0 on pci0 > pcm0: [ITHREAD] > pcm0: > pcm0: > > > This is also confirmed here: > > $ cat /dev/sndstat > FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) > Installed devices: > pcm0: at memory > 0xe04c irq 21 [20071129_0050] [MPSAFE] (1p:1v/1r:1v channels duplex > default) all fine until here; > > Now the problem ... > The strange thing is all audio related devices are missing in /dev > > $ ls -l /dev/audio* /dev/dsp* > ls: /dev/audio*: No such file or directory > ls: /dev/dsp*: No such file or directory fine too; you will not see /dev/dsp* with ls(1), just open the device /dev/dsp with some application and it will appear; > Respectively i have no working sound support :( what you mean exactly with 'i have no working sound support'? try changing the values with the mixer(1) command if no sound is coming out from apps; matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ SPAMer of the year: Subject: Alle Software ist Deutsche Sprachen >From: -40 % die Neujahrsaktion ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
