Asynchronous CDROM Events in Userland

Asynchronous CDROM Events in Userland

[Calin A. Culianu]

Is there any way, other than by polling, to have a user process be
notified of a change in status on a cdrom drive?  (Such as if the drive
opens, closes, gets new media, etc)?

Also, come think of it, other types of asynchronous events would be nice
too, like when a cdrom usb device gets hot-plugged into the system, etc.

The current ioctls are inadequate for this type of thing (they are
synchronous in nature). One nice thing would be if we can register SIGUSR
or other types of signals with the cdrom driver(s) so that it can notify a
user process of (cdrom) events it may be interested in.

The reason I ask this is that the current autorun program that comes with
kde is very inefficient because it polls the cdrom drives.  Also, this
program is completely unable to determine that a usb device has come
online, because it basically can't differentiate between bogus /etc/fstab
entries and offline usb devices.

At any rate, if anyone can suggest a way to asynchronously receive cdrom
events in userland, it would be appreciated.

If not what do you guys think about extensions to the cdrom drivers to
handle these types of things?

Re: Asynchronous CDROM Events in Userland

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.30.0202032333200.1158-100000@rtlab.med.cornell.edu>
By author:    "Calin A. Culianu" <calin@ajvar.org>
In newsgroup: linux.dev.kernel
>
> 
> Is there any way, other than by polling, to have a user process be
> notified of a change in status on a cdrom drive?  (Such as if the drive
> opens, closes, gets new media, etc)?
> 
> Also, come think of it, other types of asynchronous events would be nice
> too, like when a cdrom usb device gets hot-plugged into the system, etc.
> 
> The current ioctls are inadequate for this type of thing (they are
> synchronous in nature). One nice thing would be if we can register SIGUSR
> or other types of signals with the cdrom driver(s) so that it can notify a
> user process of (cdrom) events it may be interested in.
> 
> The reason I ask this is that the current autorun program that comes with
> kde is very inefficient because it polls the cdrom drives.  Also, this
> program is completely unable to determine that a usb device has come
> online, because it basically can't differentiate between bogus /etc/fstab
> entries and offline usb devices.
> 
> At any rate, if anyone can suggest a way to asynchronously receive cdrom
> events in userland, it would be appreciated.
> 
> If not what do you guys think about extensions to the cdrom drivers to
> handle these types of things?
> 

Rather than a signal, it should be a file descriptor of some sort, so
one can select() etc on it.  Personally I can't imagine polling would
take any appreciable amount of resources, though.

A more important issue is probably to get notification when the eject
button is pushed and the device is locked, so that it can try to
umount and eject it, unless busy.

	-hpa


-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: Asynchronous CDROM Events in Userland

[Calin A. Culianu]

n 3 Feb 2002, H. Peter Anvin wrote:

> Followup to:  <Pine.LNX.4.30.0202032333200.1158-100000@rtlab.med.cornell.edu>
> By author:    "Calin A. Culianu" <calin@ajvar.org>
> In newsgroup: linux.dev.kernel
> >
> >
> > Is there any way, other than by polling, to have a user process be
> > notified of a change in status on a cdrom drive?  (Such as if the drive
> > opens, closes, gets new media, etc)?
> >
> > Also, come think of it, other types of asynchronous events would be nice
> > too, like when a cdrom usb device gets hot-plugged into the system, etc.
> >
> > The current ioctls are inadequate for this type of thing (they are
> > synchronous in nature). One nice thing would be if we can register SIGUSR
> > or other types of signals with the cdrom driver(s) so that it can notify a
> > user process of (cdrom) events it may be interested in.
> >
> > The reason I ask this is that the current autorun program that comes with
> > kde is very inefficient because it polls the cdrom drives.  Also, this
> > program is completely unable to determine that a usb device has come
> > online, because it basically can't differentiate between bogus /etc/fstab
> > entries and offline usb devices.
> >
> > At any rate, if anyone can suggest a way to asynchronously receive cdrom
> > events in userland, it would be appreciated.
> >
> > If not what do you guys think about extensions to the cdrom drivers to
> > handle these types of things?
> >
>
> Rather than a signal, it should be a file descriptor of some sort, so
> one can select() etc on it.  Personally I can't imagine polling would
> take any appreciable amount of resources, though.

Yes, select()ing on it would be more useful, but I don't know if this
would clash with existing semantics, because currently select() on a set
of readfds that are cdrom drives always returns right away (I am not sure
why this would be, as if you open /dev/cdrom with O_NONBLOCK|O_RDONLY
you are supposed to be doing ioctls and no actual reading, no?).

Maybe such events can be in the exception fds?

-Calin

>
> A more important issue is probably to get notification when the eject
> button is pushed and the device is locked, so that it can try to
> umount and eject it, unless busy.
>
> 	-hpa
>
>
>

Re: Asynchronous CDROM Events in Userland

[john slee]

[ added dan to cc list ]

On Sun, Feb 03, 2002 at 09:07:24PM -0800, H. Peter Anvin wrote:
> > If not what do you guys think about extensions to the cdrom drivers to
> > handle these types of things?
> > 
> 
> Rather than a signal, it should be a file descriptor of some sort, so
> one can select() etc on it.  Personally I can't imagine polling would
> take any appreciable amount of resources, though.
> 
> A more important issue is probably to get notification when the eject
> button is pushed and the device is locked, so that it can try to
> umount and eject it, unless busy.

not so long ago dan kegel suggested an interface to signals based on
file descriptors, and perhaps even an alpha patch implementing such.
this allowed you to select() on them.

http://marc.theaimsgroup.com/?l=linux-kernel&m=99356014431024&w=2

of particular interest is this quote from dan's fantasy manpage:

> HISTORY
>      sigopen() first appeared in the 2.5.2 Linux kernel.

a bit late, but an uncanny prediction.
dan, are you nostradamus ? :-)

j.

-- 
R N G G   "Well, there it goes again... And we just sit 
 I G G G   here without opposable thumbs." -- gary larson

Re: Asynchronous CDROM Events in Userland

[Calin A. Culianu]

On Mon, 4 Feb 2002, john slee wrote:

> [ added dan to cc list ]
>
> On Sun, Feb 03, 2002 at 09:07:24PM -0800, H. Peter Anvin wrote:
> > > If not what do you guys think about extensions to the cdrom drivers to
> > > handle these types of things?
> > >
> >
> > Rather than a signal, it should be a file descriptor of some sort, so
> > one can select() etc on it.  Personally I can't imagine polling would
> > take any appreciable amount of resources, though.
> >
> > A more important issue is probably to get notification when the eject
> > button is pushed and the device is locked, so that it can try to
> > umount and eject it, unless busy.
>
> not so long ago dan kegel suggested an interface to signals based on
> file descriptors, and perhaps even an alpha patch implementing such.
> this allowed you to select() on them.
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=99356014431024&w=2
>
> of particular interest is this quote from dan's fantasy manpage:
>
> > HISTORY
> >      sigopen() first appeared in the 2.5.2 Linux kernel.
>
> a bit late, but an uncanny prediction.
> dan, are you nostradamus ? :-)
>

Hahah that's hilarious.  I really like the idea, by the way, of this
sigopen() feature.  An inverse of that owuld be to map existing file
descriptors to signals, that way an application doesn't have to explicitly
select() on them, but rather can install a very asynchronous fd reader for
whenever the data is available.  I am not sure how useful this would be,
but in the case of asynch. cdrom events it would be useful.  :)

Also, why did the author of this manpage seem to complain about
conflicting signals?  You can always find out what signals your process is
waiting for....

-Calin

Re: Asynchronous CDROM Events in Userland

[H. Peter Anvin]

john slee wrote:

> 
> not so long ago dan kegel suggested an interface to signals based on
> file descriptors, and perhaps even an alpha patch implementing such.
> this allowed you to select() on them.
> 


That's still not a good reason to use signals for this particular interface.

	-hpa

Re: Asynchronous CDROM Events in Userland

[Erik Andersen]

On Sun Feb 03, 2002 at 11:41:47PM -0500, Calin A. Culianu wrote:
> 
> Is there any way, other than by polling, to have a user process be
> notified of a change in status on a cdrom drive?  (Such as if the drive
> opens, closes, gets new media, etc)?

Nope.  It would be nice, but the current crop of hardware simply
doesn't support it.  From the Mt. Fuji spec (SFF8090i) 11.5 Get
Event/Status Notification:

    The GET EVENT/STATUS NOTIFICATION Command requests the Logical Unit to
    report event(s) and status as specified in the Notification
    ClassNotification Class Request field and provides asynchronous
    notification. Two modes of operation are defined here. They are
    polling and asynchronous modes.

    In polling mode, the Host will issue GET EVENT/STATUS NOTIFICATION
    Commands at periodic intervals with an immediate (Immed) bit of 1 set.
    The Logical Unit shall complete this Command with the most recently
    available event status requested. The Logical Unit shall support
    polling mode.

    In asynchronous mode, the Host will issue a single GET EVENT/STATUS
    NOTIFICATION Command with an Immed (immediate) bit of 0 requested. If
    the Logical Unit supports Asynchronous event status notification
    (through tagged queuing) the model outlined here shall be used. If the
    Logical Unit does not support Asynchronous Mode, the Command shall
    fail as an illegal request. If the Host requests Asynchronous Mode
    using a non-queable or non-overlappable request, the Command shall
    fail with CHECK CONDITION Status, 5/24/00 INVALID FIELD IN CDB.

Jens Axboe and I wrote a little test app a year or two ago to check
for whether drives supported asynchronous mode.  We found it to be
unsupported on 100% of the drives we tested (and we tested quite a
few)...

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Asynchronous CDROM Events in Userland

[Jens Axboe]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

On Mon, Feb 04 2002, Erik Andersen wrote:
> Jens Axboe and I wrote a little test app a year or two ago to check
> for whether drives supported asynchronous mode.  We found it to be
> unsupported on 100% of the drives we tested (and we tested quite a
> few)...

Yep, _no_ drives to date support queued event notification. However, a
polled approach is really not too bad -- it simply means that we'll push
it to user space instead. I've written a small utility for reference.

-- 
Jens Axboe


[-- Attachment #2: cd_poll.c --]
[-- Type: text/plain, Size: 2437 bytes --]

/*
 * simple media event poller for cdroms implementing the GET_EVENT
 * interface
 *
 * Copyright (C) 2001 Jens Axboe <axboe@suse.de>
 */
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <sys/ioctl.h>

#include <linux/cdrom.h>

#define INIT_CGC(cgc)	memset((cgc), 0, sizeof(struct cdrom_generic_command))

void dump_cgc(struct cdrom_generic_command *cgc)
{
	struct request_sense *sense = cgc->sense;
	int i;

	printf("cdb: ");
	for (i = 0; i < 12; i++)
		printf("%02x ", cgc->cmd[i]);
	printf("\n");

	printf("buffer (%d): ", cgc->buflen);
	for (i = 0; i < cgc->buflen; i++)
		printf("%02x ", cgc->buffer[i]);
	printf("\n");

	if (!sense)
		return;

	printf("sense: %02x.%02x.%02x\n", sense->sense_key, sense->asc, sense->ascq);
}

int wait_cmd(int fd, struct cdrom_generic_command *cgc, void *buffer,
	     int len, int ddir, int timeout)
{
	struct request_sense sense;
	int ret;

	memset(&sense, 0, sizeof(sense));

	cgc->timeout = timeout;
	cgc->buffer = buffer;
	cgc->buflen = len;
	cgc->data_direction = ddir;
	cgc->sense = &sense;
	cgc->quiet = 1;

	ret = ioctl(fd, CDROM_SEND_PACKET, cgc);
	if (ret == -1) {
		perror("ioctl");
		dump_cgc(cgc);
	}

	return ret;
}

int get_media_event(int fd)
{
	struct cdrom_generic_command cgc;
	unsigned char buffer[8];
	int ret;

	INIT_CGC(&cgc);
	memset(buffer, 0, sizeof(buffer));

	cgc.cmd[0] = GPCMD_GET_EVENT_STATUS_NOTIFICATION;
	cgc.cmd[1] = 1;
	cgc.cmd[4] = 16;
	cgc.cmd[8] = sizeof(buffer);

	ret = wait_cmd(fd, &cgc, buffer, sizeof(buffer), CGC_DATA_READ, 600);
	if (ret < 0) {
		perror("GET_EVENT");
		return ret;
	}

	return buffer[4] & 0xf;
}

int poll_events(int fd)
{
	int event, quit, first;

	quit = 0;
	first = 1;
	do {
		event = get_media_event(fd);
		if (event < 0)
			break;

		switch (event) {
			case 0:
				if (first)
					printf("no media change\n");
				break;
			case 1:
				printf("eject request\n");
				break;
			case 2:
				printf("new media\n");
				break;
			case 3:
				printf("media removal\n");
				break;
			case 4:
				printf("media change\n");
				break;
			default:
				printf("unknown media event (%d)\n", event);
				break;
		}

		first = 0;

		if (event)
			continue;

		sleep(2);

	} while (!quit);

	return event;
}

int main(int argc, char *argv[])
{
	int fd;

	fd = open("/dev/cdrom", O_RDONLY | O_NONBLOCK);
	if (fd == -1) {
		perror("open");
		return 1;
	}

	return poll_events(fd);
}

Re: Asynchronous CDROM Events in Userland

[Gregor Jasny]

Am Montag, 4. Februar 2002 08:57 schrieb Jens Axboe:
> Yep, _no_ drives to date support queued event notification. However, a
> polled approach is really not too bad -- it simply means that we'll push
> it to user space instead. I've written a small utility for reference.

You're wrong.

PLEXTOR CD-R PX-W2410A
media removal
eject request
media removal
media removal

HITACHI DVD-ROM GD-2500
no media change
new media
media removal

Just my 2 cents.

-Gregor

Re: Asynchronous CDROM Events in Userland

[Jens Axboe]

On Mon, Feb 04 2002, Gregor Jasny wrote:
> Am Montag, 4. Februar 2002 08:57 schrieb Jens Axboe:
> > Yep, _no_ drives to date support queued event notification. However, a
> > polled approach is really not too bad -- it simply means that we'll push
> > it to user space instead. I've written a small utility for reference.
> 
> You're wrong.

Not likely

> PLEXTOR CD-R PX-W2410A
> media removal
> eject request
> media removal
> media removal
> 
> HITACHI DVD-ROM GD-2500
> no media change
> new media
> media removal

I'm wrong about what? If you mean that my test app works, then yes of
course it works. It's a synchronous command poll for media status. I
said that _queued event notification_ isn't implemented in any drives.

Did you read the code?

-- 
Jens Axboe

Re: Asynchronous CDROM Events in Userland

[Alan Cox]

> Jens Axboe and I wrote a little test app a year or two ago to check
> for whether drives supported asynchronous mode.  We found it to be
> unsupported on 100% of the drives we tested (and we tested quite a
> few)...

I also found no drive with asynchronous and at best patchy and dubious
synchronous notification. Many cheap drives don't report an event if you
push the button with the door locked for example.

Something like volumagic, cleaned up, is a much better solution

oops booting 2.4.18-pre7-ac3

[Todd M. Roy]

Alan,
  I got an oops almost immediatly when booting 2.4.18-pre7-ac3
(ksymoops appended to bottom of dmesg extract).

-- todd --


PCI: PCI BIOS revision 2.10 entry at 0xfcaee, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
Unknown bridge resource 1: assuming transparent
Unknown bridge resource 2: assuming transparent
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
Limiting direct PCI/PCI transfers.
isapnp: Scanning for PnP cards...
isapnp: Card 'CS4236B'
isapnp: 1 Plug & Play card detected total
PnPBIOS: Found PnP BIOS installation structure at 0xc00fe2d0.
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xe2f4, dseg 0x40.
PnPBIOS: 14 nodes reported by PnP BIOS; 14 recorded by driver.
PnPBIOS: PNP0c01: ioport range 0x800-0x83f has been reserved.
PnPBIOS: PNP0c01: ioport range 0x850-0x85f has been reserved.
Unable to handle kernel NULL pointer dereference at virtual address 0000002c
c0126c04
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0126c04>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010046
eax: 00000000   ebx: 00000008   ecx: c150a000   edx: 00000000
esi: 00000000   edi: c02c5a20   ebp: 000001f0   esp: c150bf90
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 2, stackpage=c150b000)
Stack: 00000000 00000000 c02c5a20 c150bfd4 c011a850 00000000 000001f0 c150a000 
       00000000 00000000 c011c54f 00000000 00010f00 c151dfb8 c0111dbc 00000000 
       00000000 0008e000 c01d5589 00010f00 c151dfb8 00000000 0008e000 c010567f 
Call Trace: [<c011a850>] [<c011c54f>] [<c0111dbc>] [<c01d5589>] [<c010567f>] 
   [<c0105688>] 
Code: f6 46 2c 01 74 02 0f 0b 9c 5f fa 8b 4e 08 39 d9 75 22 8b 4e 

>>EIP; c0126c04 <swap_out+1c4/468>   <=====
Trace; c011a850 <collect_signal+cc/d4>
Trace; c011c54f <sys_setuid+eb/134>
Trace; c0111dbc <mm_init+68/a8>
Trace; c01d5589 <vesafb_set_cmap+9/7c>
Trace; c010567f <kernel_thread+1f/38>
Trace; c0105688 <kernel_thread+28/38>
Code;  c0126c04 <swap_out+1c4/468>
00000000 <_EIP>:
Code;  c0126c04 <swap_out+1c4/468>   <=====
   0:   f6 46 2c 01               testb  $0x1,0x2c(%esi)   <=====
Code;  c0126c08 <swap_out+1c8/468>
   4:   74 02                     je     8 <_EIP+0x8> c0126c0c <swap_out+1cc/468>
Code;  c0126c0a <swap_out+1ca/468>
   6:   0f 0b                     ud2a   
Code;  c0126c0c <swap_out+1cc/468>
   8:   9c                        pushf  
Code;  c0126c0d <swap_out+1cd/468>
   9:   5f                        pop    %edi
Code;  c0126c0e <swap_out+1ce/468>
   a:   fa                        cli    
Code;  c0126c0f <swap_out+1cf/468>
   b:   8b 4e 08                  mov    0x8(%esi),%ecx
Code;  c0126c12 <swap_out+1d2/468>
   e:   39 d9                     cmp    %ebx,%ecx
Code;  c0126c14 <swap_out+1d4/468>
  10:   75 22                     jne    34 <_EIP+0x34> c0126c38 <swap_out+1f8/468>
Code;  c0126c16 <swap_out+1d6/468>
  12:   8b 4e 00                  mov    0x0(%esi),%ecx

root [pcx4168] /home/tmr
$ 

Re: Asynchronous CDROM Events in Userland

[hugang]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

Now it can work!
On Mon, 4 Feb 2002 08:57:12 +0100
Jens Axboe <axboe@suse.de> wrote:

> On Mon, Feb 04 2002, Erik Andersen wrote:
> > Jens Axboe and I wrote a little test app a year or two ago to check
> > for whether drives supported asynchronous mode.  We found it to be
> > unsupported on 100% of the drives we tested (and we tested quite a
> > few)...
> 
> Yep, _no_ drives to date support queued event notification. However, a
> polled approach is really not too bad -- it simply means that we'll push
> it to user space instead. I've written a small utility for reference.
> 
> -- 
> Jens Axboe
> 
> 


-- 
thanks with regards!
hugang.胡刚.

***********************************
Beijing Soul Technology Co.,Ltd.
Tel:010-68425741/42/43/44
Fax:010-68425745
email:gang_hu@soul.com.cn
web:http://www.soul.com.cn
***********************************

[-- Attachment #2: diff --]
[-- Type: application/octet-stream, Size: 200 bytes --]

--- cd_poll.c~	Mon Feb  4 20:26:25 2002
+++ cd_poll.c	Mon Feb  4 22:03:21 2002
@@ -80,7 +80,7 @@
 		return ret;
 	}
 
-	return buffer[4] & 0xf;
+	return buffer[5] & 0xf;
 }
 
 int poll_events(int fd)

Re: Asynchronous CDROM Events in Userland

[Jens Axboe]

On Mon, Feb 04 2002, hugang wrote:
> Now it can work!

?

The first 4 bytes is the event header, then followed by the media event
descriptor. The first byte of that is the media event (well bit 0-3
anyways). You are instead returning the media status byte.

-- 
Jens Axboe

Re: Asynchronous CDROM Events in Userland

[Stevie O]

At 09:07 PM 2/3/2002 -0800, H. Peter Anvin wrote:
>Rather than a signal, it should be a file descriptor of some sort, so
>one can select() etc on it.  Personally I can't imagine polling would
>take any appreciable amount of resources, though.

Windows 95 polls the cd-rom drive for autorun.

It kills laptop batteries REAL quick.

CPU & memory aren't the only resources...


--
Stevie-O

Real programmers use COPY CON PROGRAM.EXE

Re: Asynchronous CDROM Events in Userland

[H. Peter Anvin]

Stevie O wrote:

> At 09:07 PM 2/3/2002 -0800, H. Peter Anvin wrote:
> 
>> Rather than a signal, it should be a file descriptor of some sort, so
>> one can select() etc on it.  Personally I can't imagine polling would
>> take any appreciable amount of resources, though.
> 
> 
> Windows 95 polls the cd-rom drive for autorun.
> It kills laptop batteries REAL quick.
> CPU & memory aren't the only resources...
> 

Does it spin up the CD-ROM doing so?

	-hpa

Re: Asynchronous CDROM Events in Userland

[Calin A. Culianu]

On Mon, 4 Feb 2002, H. Peter Anvin wrote:

> Stevie O wrote:
>
> > At 09:07 PM 2/3/2002 -0800, H. Peter Anvin wrote:
> >
> >> Rather than a signal, it should be a file descriptor of some sort, so
> >> one can select() etc on it.  Personally I can't imagine polling would
> >> take any appreciable amount of resources, though.
> >
> >
> > Windows 95 polls the cd-rom drive for autorun.
> > It kills laptop batteries REAL quick.
> > CPU & memory aren't the only resources...
> >
>
> Does it spin up the CD-ROM doing so?
>
> 	-hpa

Probably it doesn't, but just having the cpu be non-idle when it could
otherwise be idle does add up over time.  In linux, polling the cdrom
*seems* inexpensive enough, but if you look at 'top' it seems to average
out to like 1-2% cpu time!  (Ok, these stats aren't super-accurate,
they're just from running 'top' with the kde autorun tool running).

[Admitedly, the autorun tool is written kind of strangely (it does one
redundant ioctl, plus it wait()s on its children constantly rather than
installing a signal handler), but still.. it would be nice to get those
extra cycles for quake3 or wolfenstein...]

-Calin

>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Asynchronous CDROM Events in Userland

[H. Peter Anvin]

Calin A. Culianu wrote:

>>>
>>Does it spin up the CD-ROM doing so?
>>
> 
> Probably it doesn't, but just having the cpu be non-idle when it could
> otherwise be idle does add up over time.  In linux, polling the cdrom
> *seems* inexpensive enough, but if you look at 'top' it seems to average
> out to like 1-2% cpu time!  (Ok, these stats aren't super-accurate,
> they're just from running 'top' with the kde autorun tool running).
> 
> [Admitedly, the autorun tool is written kind of strangely (it does one
> redundant ioctl, plus it wait()s on its children constantly rather than
> installing a signal handler), but still.. it would be nice to get those
> extra cycles for quake3 or wolfenstein...]
> 


That just indicates a bullsh*t program.  It's also pretty certain that 
these kinds of things don't belong in the GUI; one of the things I'd 
like to do at some point is to write a daemon to mount things on insert 
(vold).

	-hpa

Re: Asynchronous CDROM Events in Userland

[Pavel Machek]

Hi!

> Rather than a signal, it should be a file descriptor of some sort, so
> one can select() etc on it.  Personally I can't imagine polling would
> take any appreciable amount of resources, though.

It may not eat CPU but it will definitely eat memory... Because polling
means deamon that normally could be swapped out needs to stay in memory.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: Asynchronous CDROM Events in Userland

[H. Peter Anvin]

Pavel Machek wrote:

> 
> It may not eat CPU but it will definitely eat memory... Because polling
> means deamon that normally could be swapped out needs to stay in memory.
>


At least a small part of it, yes.

	-hpa