[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

No Subject



Received: from bit.site.co.il by cs.huji.ac.il with SMTP id AA13662
  (5.67b/HUJI 4.153 for <linux-il@cs.huji.ac.il>); Sun, 24 Aug 1997 14:15:02 +0300
Received: (qmail 20382 invoked by uid 200); 24 Aug 1997 11:15:00 -0000
Delivered-To: linux-il-linux-il@linux.org.il
Received: (qmail 20370 invoked from network); 24 Aug 1997 11:14:52 -0000
Received: from dns.slink.co.il (194.90.41.254)
  by bit.site.co.il with SMTP; 24 Aug 1997 11:14:51 -0000
Received: from shlomi.slink.co.il (194.90.41.118) by dns.slink.co.il
 (EMWAC SMTPRS 0.81) with SMTP id <B0000028669@dns.slink.co.il>;
 Sun, 24 Aug 1997 14:14:55 +0300
Message-Id: <3.0.1.32.19970824141000.0069657c@dns.slink.co.il>
X-Sender: shlomi@dns.slink.co.il
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Sun, 24 Aug 1997 14:10:00 +0300
To: pacman@cqc.com
From: Shlomi Fish <shlomi@slink.co.il>
Subject: Re: Failure to open the /dev/dsp character device with a perl
Cc: linux-il@linux.org.il
In-Reply-To: <19970709130659.12262.qmail@defiant.cqc.com>
References: <3.0.1.32.19970709150236.006a9e54@dns.slink.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Status: RO
X-Status: 

At 08:06 AM 7/9/97 -0500, pacman@cqc.com wrote:

>I hadn't thought ahead, or I would have realized the ioctl would be a
>problem. But let me see... perl does have an ioctl function, which implies it
>should not bomb when opening device files... further investigation reveals
>that if the device is a tty, perl gets an ESPIPE, ignores it and moves on.
>
>Apparently perl is doing that lseek just to test for seekability, and it
>believes that the 3 results are: success->seekable, ESPIPE->unseekable,
>anything_else->bomb.
>
>If you want to test my theory, look for sound_lseek in the kernel source and
>change the error from EPERM to ESPIPE. I have 2.0.28 and there are 2 of them:
>one in drivers/sound/dmasound.c and drivers/sound/soundcard.c, I'm not sure
>which one is relevant. They're both one-line functions that just say
>"return -EPERM". Change that to -ESPIPE, and I theorize that perl might work
>with it.

Well, Mr. pacman (Alan Curry) was right.I changed the return value of
sound_lseek() in drivers/sound/soundcard.c to -ESPIPE, recompiled the
kernel and the perl script managed to open the device properly.

However, I realized that the values of the sound ioctl() IDs in perl do not
correspond to the correct numeric values in C. (even after doing a require
'linux/soundcard.ph') Using the right numeric values in an ioctl() call
works fine in perl, but the constants are bogus. I believe the latter is a
perl problem, but the second could relate to either perl or Linux. I'll do
my best to bring it to the attention of both the perl and the Linux kernel
maintainers, and work something out. 

IMO, since serial ports return ESPIPE if one tries to lseek() them, then so
should the audio device. Which means that the kernel would require a small
patch.

	Shlomi Fish



-----------------------------------------------------------------------------
Shlomi Fish                                Smart Link Ltd.
Home E-mail: shlomif@ibm.net               Work E-mail: shlomi@slink.co.il
Home Page: http://www.slink.co.il/~shlomi

"If I had not been insane already, I would have long ago driven myself mad."

                            The Enemy and how I Helped to Fight it.
-----------------------------------------------------------------------------