If /dev/snd/controlCx EACCES vs. ENODEV mixup

If /dev/snd/controlCx EACCES vs. ENODEV mixup

[Lennart Poettering]

Hi!

If /dev/snd/controlC0 is not accessible due to a permission problem
(EACCES), then alsa-libs will lie and return ENODEV. This is quite a
bit confusing:

<snip>
$ sudo chmod 000 /dev/snd/controlC0
$ aplay -D hw:0
ALSA lib pcm_hw.c:1207:(_snd_pcm_hw_open) Invalid value for card
aplay: main:546: audio open error: No such device
</snip>

(and strace shows that the actual problem is EACESS, as one would
assume.

I also filed this as bug on the BTS:

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3600

BTW, what's the status of the BTS? Takashi asked me to post all my
issues on the ML instead of on the BTS. So why have the BTS at all?
It's even linked on the alsa-project.org front page under "I found a
bug!", which is a bit misleading. If this Mantis thing is not liked at
all, would it be possible to make some replacement available? Maybe
just use the kernel bugzilla on bugzilla.kernel.org? It's very fast,
and certainly more fun to work with than with Mantis.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: If /dev/snd/controlCx EACCES vs. ENODEV mixup

[Jaroslav Kysela]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 622 bytes --]

On Sun, 25 Nov 2007, Lennart Poettering wrote:

> Hi!
> 
> If /dev/snd/controlC0 is not accessible due to a permission problem
> (EACCES), then alsa-libs will lie and return ENODEV. This is quite a
> bit confusing:
> 
> <snip>
> $ sudo chmod 000 /dev/snd/controlC0
> $ aplay -D hw:0
> ALSA lib pcm_hw.c:1207:(_snd_pcm_hw_open) Invalid value for card
> aplay: main:546: audio open error: No such device
> </snip>
> 
> (and strace shows that the actual problem is EACESS, as one would
> assume.

Could you try attached patch?

						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1677 bytes --]

diff -r 672c5387645d src/control/cards.c
--- a/src/control/cards.c	Fri Nov 23 15:46:48 2007 +0100
+++ b/src/control/cards.c	Sun Nov 25 22:36:57 2007 +0100
@@ -39,12 +39,7 @@
 #define SND_FILE_LOAD		ALOAD_DEVICE_DIRECTORY "aloadC%i"
 #endif
 
-/**
- * \brief Try to load the driver for a card.
- * \param card Card number.
- * \return 1 if driver is present, zero if driver is not present
- */
-int snd_card_load(int card)
+static int snd_card_load1(int card)
 {
 	int open_dev;
 	char control[sizeof(SND_FILE_CONTROL) + 10];
@@ -61,9 +56,20 @@ int snd_card_load(int card)
 #endif
 	if (open_dev >= 0) {
 		close (open_dev);
-		return 1;
-	}
-	return 0;
+		return 0;
+	} else {
+		return -errno;
+	}
+}
+
+/**
+ * \brief Try to load the driver for a card.
+ * \param card Card number.
+ * \return 1 if driver is present, zero if driver is not present
+ */
+int snd_card_load(int card)
+{
+	return !!(snd_card_load1(card) == 0);
 }
 
 /**
@@ -104,7 +110,7 @@ int snd_card_next(int *rcard)
  */
 int snd_card_get_index(const char *string)
 {
-	int card;
+	int card, err;
 	snd_ctl_t *handle;
 	snd_ctl_card_info_t info;
 
@@ -116,13 +122,16 @@ int snd_card_get_index(const char *strin
 			return -EINVAL;
 		if (card < 0 || card > 31)
 			return -EINVAL;
-		if (snd_card_load(card))
+		err = snd_card_load1(card);
+		if (err >= 0)
 			return card;
-		return -ENODEV;
+		return err;
 	}
 	for (card = 0; card < 32; card++) {
+#ifdef SUPPORT_ALOAD
 		if (! snd_card_load(card))
 			continue;
+#endif
 		if (snd_ctl_hw_open(&handle, NULL, card, 0) < 0)
 			continue;
 		if (snd_ctl_card_info(handle, &info) < 0) {

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: If /dev/snd/controlCx EACCES vs. ENODEV mixup

[Jaroslav Kysela]

On Sun, 25 Nov 2007, Lennart Poettering wrote:

> BTW, what's the status of the BTS? Takashi asked me to post all my
> issues on the ML instead of on the BTS. So why have the BTS at all?
> It's even linked on the alsa-project.org front page under "I found a
> bug!", which is a bit misleading. If this Mantis thing is not liked at
> all, would it be possible to make some replacement available? Maybe
> just use the kernel bugzilla on bugzilla.kernel.org? It's very fast,
> and certainly more fun to work with than with Mantis.

I prefer BTS but Takashi not. It's matter of personal preference. Mantis 
is easy maintainable and we have more projects (or packages) not only 
drivers.

						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project

Re: If /dev/snd/controlCx EACCES vs. ENODEV mixup

[Lennart Poettering]

On Sun, 25.11.07 22:42, Jaroslav Kysela (perex@perex.cz) wrote:

> 
> On Sun, 25 Nov 2007, Lennart Poettering wrote:
> 
> > BTW, what's the status of the BTS? Takashi asked me to post all my
> > issues on the ML instead of on the BTS. So why have the BTS at all?
> > It's even linked on the alsa-project.org front page under "I found a
> > bug!", which is a bit misleading. If this Mantis thing is not liked at
> > all, would it be possible to make some replacement available? Maybe
> > just use the kernel bugzilla on bugzilla.kernel.org? It's very fast,
> > and certainly more fun to work with than with Mantis.
> 
> I prefer BTS but Takashi not. It's matter of personal preference. Mantis 
> is easy maintainable and we have more projects (or packages) not only 
> drivers.

The kernel bugzilla already is used for stuff like klibc and other
userspace support code for the kernel. I am sure noone would oppose to
move the complete bug tracking of ALSA to the kernel bz.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: If /dev/snd/controlCx EACCES vs. ENODEV mixup

[Jaroslav Kysela]

On Sun, 25 Nov 2007, Lennart Poettering wrote:

> On Sun, 25.11.07 22:42, Jaroslav Kysela (perex@perex.cz) wrote:
> 
> > 
> > On Sun, 25 Nov 2007, Lennart Poettering wrote:
> > 
> > > BTW, what's the status of the BTS? Takashi asked me to post all my
> > > issues on the ML instead of on the BTS. So why have the BTS at all?
> > > It's even linked on the alsa-project.org front page under "I found a
> > > bug!", which is a bit misleading. If this Mantis thing is not liked at
> > > all, would it be possible to make some replacement available? Maybe
> > > just use the kernel bugzilla on bugzilla.kernel.org? It's very fast,
> > > and certainly more fun to work with than with Mantis.
> > 
> > I prefer BTS but Takashi not. It's matter of personal preference. Mantis 
> > is easy maintainable and we have more projects (or packages) not only 
> > drivers.
> 
> The kernel bugzilla already is used for stuff like klibc and other
> userspace support code for the kernel. I am sure noone would oppose to
> move the complete bug tracking of ALSA to the kernel bz.

But why to change to bugzilla? The basic functions of both BTSes are very 
similar (except the fact I don't like perl at all). Actually, ALSA 
services (server) run on a dedicated virtual XEN machine, so we can 
install any software we need.

						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project

Re: If /dev/snd/controlCx EACCES vs. ENODEV mixup

[Takashi Iwai]

At Sun, 25 Nov 2007 22:53:00 +0100,
Lennart Poettering wrote:
> 
> On Sun, 25.11.07 22:42, Jaroslav Kysela (perex@perex.cz) wrote:
> 
> > 
> > On Sun, 25 Nov 2007, Lennart Poettering wrote:
> > 
> > > BTW, what's the status of the BTS? Takashi asked me to post all my
> > > issues on the ML instead of on the BTS. So why have the BTS at all?
> > > It's even linked on the alsa-project.org front page under "I found a
> > > bug!", which is a bit misleading. If this Mantis thing is not liked at
> > > all, would it be possible to make some replacement available? Maybe
> > > just use the kernel bugzilla on bugzilla.kernel.org? It's very fast,
> > > and certainly more fun to work with than with Mantis.
> > 
> > I prefer BTS but Takashi not. It's matter of personal preference. Mantis 
> > is easy maintainable and we have more projects (or packages) not only 
> > drivers.
> 
> The kernel bugzilla already is used for stuff like klibc and other
> userspace support code for the kernel. I am sure noone would oppose to
> move the complete bug tracking of ALSA to the kernel bz.

The problem is the total lack of man power for debugging.
You'll understand easily if you see too many open bugs.  And the bug
report quality isn't always good.  Many reports, e.g. about HD-audio
issue, are either too old, irrelevant, or simply unsupported device
(or all of them are mixed up).  Only a few of them are really
interesting.  But, even filtering them takes too much time.

So, I guess it won't matter whether it's bugzilla or not.  Unless
someone sweeps bug entries regularly, BTS can't work properly.


BTW, regarding bugzilla vs mantis.  There are a few features that are
missing in mantis.  For example, the below are what I'd love to have
vastly:

- properly create a mail per entry
  currently mantis mail notification is broken and useless

- has optional status like NEEDINFO or WAIT_FOR_TESTING
  so we cannot mark the entries whether a user-action is required or
  not, make difficult to filter


Takashi

Re: If /dev/snd/controlCx EACCES vs. ENODEV mixup

[Jaroslav Kysela]

On Mon, 26 Nov 2007, Takashi Iwai wrote:

> At Sun, 25 Nov 2007 22:53:00 +0100,
> Lennart Poettering wrote:
> > 
> > On Sun, 25.11.07 22:42, Jaroslav Kysela (perex@perex.cz) wrote:
> > 
> > > 
> > > On Sun, 25 Nov 2007, Lennart Poettering wrote:
> > > 
> > > > BTW, what's the status of the BTS? Takashi asked me to post all my
> > > > issues on the ML instead of on the BTS. So why have the BTS at all?
> > > > It's even linked on the alsa-project.org front page under "I found a
> > > > bug!", which is a bit misleading. If this Mantis thing is not liked at
> > > > all, would it be possible to make some replacement available? Maybe
> > > > just use the kernel bugzilla on bugzilla.kernel.org? It's very fast,
> > > > and certainly more fun to work with than with Mantis.
> > > 
> > > I prefer BTS but Takashi not. It's matter of personal preference. Mantis 
> > > is easy maintainable and we have more projects (or packages) not only 
> > > drivers.
> > 
> > The kernel bugzilla already is used for stuff like klibc and other
> > userspace support code for the kernel. I am sure noone would oppose to
> > move the complete bug tracking of ALSA to the kernel bz.
> 
> The problem is the total lack of man power for debugging.
> You'll understand easily if you see too many open bugs.  And the bug
> report quality isn't always good.  Many reports, e.g. about HD-audio
> issue, are either too old, irrelevant, or simply unsupported device
> (or all of them are mixed up).  Only a few of them are really
> interesting.  But, even filtering them takes too much time.
> 
> So, I guess it won't matter whether it's bugzilla or not.  Unless
> someone sweeps bug entries regularly, BTS can't work properly.

That's true.

> BTW, regarding bugzilla vs mantis.  There are a few features that are
> missing in mantis.  For example, the below are what I'd love to have
> vastly:
> 
> - properly create a mail per entry
>   currently mantis mail notification is broken and useless

Seems that mantis developers are aware of this now:

http://www.mantisbt.org/wiki/doku.php/mantisbt:diff_emails_requirements

> - has optional status like NEEDINFO or WAIT_FOR_TESTING
>   so we cannot mark the entries whether a user-action is required or
>   not, make difficult to filter

I will add this status ASAP.

					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project

Re: If /dev/snd/controlCx EACCES vs. ENODEV mixup

[Takashi Iwai]

At Sun, 25 Nov 2007 22:03:59 +0100,
Lennart Poettering wrote:
> 
> BTW, what's the status of the BTS? Takashi asked me to post all my
> issues on the ML instead of on the BTS. So why have the BTS at all?
> It's even linked on the alsa-project.org front page under "I found a
> bug!", which is a bit misleading. If this Mantis thing is not liked at
> all, would it be possible to make some replacement available? Maybe
> just use the kernel bugzilla on bugzilla.kernel.org? It's very fast,
> and certainly more fun to work with than with Mantis.

BTS works well if enough human resources are available for fixing a
bug in one-to-one way.  But, ALSA development is certainly no such a
case.  It doesn't scale at all.

Thus, currently, you'd have far more chance to show your problem by
posting to alsa-devel ML than BTS because it's open.


I once suggested to feed all BTS inputs to alsa-devel ML because I was
too tired of responding each, but this didn't work either.  It ended
up with flood of bug reports just like SPAM.  The bug resolution
didn't get improved and the list became unreadable.  So it had to be
stopped.  A sad but true story. 


Takashi

Re: If /dev/snd/controlCx EACCES vs. ENODEV mixup

[Takashi Iwai]

At Mon, 26 Nov 2007 08:47:12 +0100 (CET),
Jaroslav Kysela wrote:
> 
> > BTW, regarding bugzilla vs mantis.  There are a few features that are
> > missing in mantis.  For example, the below are what I'd love to have
> > vastly:
> > 
> > - properly create a mail per entry
> >   currently mantis mail notification is broken and useless
> 
> Seems that mantis developers are aware of this now:
> 
> http://www.mantisbt.org/wiki/doku.php/mantisbt:diff_emails_requirements

Well, it's not only about the diff mail.  In many cases, the mail is
just empty but only with headers.  Maybe it became too long and cut
out...  Anyway, if this gets fixed, it'd be a great step forward.
Really.


Takashi

Re: If /dev/snd/controlCx EACCES vs. ENODEV mixup

[Jaroslav Kysela]

On Mon, 26 Nov 2007, Takashi Iwai wrote:

> At Mon, 26 Nov 2007 08:47:12 +0100 (CET),
> Jaroslav Kysela wrote:
> > 
> > > BTW, regarding bugzilla vs mantis.  There are a few features that are
> > > missing in mantis.  For example, the below are what I'd love to have
> > > vastly:
> > > 
> > > - properly create a mail per entry
> > >   currently mantis mail notification is broken and useless
> > 
> > Seems that mantis developers are aware of this now:
> > 
> > http://www.mantisbt.org/wiki/doku.php/mantisbt:diff_emails_requirements
> 
> Well, it's not only about the diff mail.  In many cases, the mail is
> just empty but only with headers.  Maybe it became too long and cut
> out...  Anyway, if this gets fixed, it'd be a great step forward.
> Really.

You may limit max. count of notes and setup e-mail details in mantis 
preferences. But I do not exclude that it's an error in the mantis e-mail 
notification system. I'll try update mantisbt to 1.0.8 and immediately to 
1.1.0 (when available) then.

						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project