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?
Followup to: <[email protected]>
By author: "Calin A. Culianu" <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
n 3 Feb 2002, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: "Calin A. Culianu" <[email protected]>
> 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
>
>
>
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--
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
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
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
> 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
[ 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
Now it can work!
On Mon, 4 Feb 2002 08:57:12 +0100
Jens Axboe <[email protected]> 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:[email protected]
web:http://www.soul.com.cn
***********************************
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
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
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
$
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
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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
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
H. Peter Anvin ([email protected]) wrote :
>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
Oh, you didn't see magicdev yet ? :-)
( it is the GNOME counterpart of autorun, only worse )
> 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).
Pleeeeeaaaase do this soon !
Removable media handling in linux just sux. And the key linux developers
looking the other way doesn't help at all.
Maybe the work could be combined somehow with the hotplug system, as there seem
to be some similarities ?
Oh, BTW , did you in your test find any ATAPI device ( CD-ROM and/or writer )
that supports overlapped commands ( the ATA counterpart of disconnect/reconnect ) ?
>
> -hpa
--
David Balazic
--------------
"Be excellent to each other." - Bill S. Preston, Esq., & "Ted" Theodore Logan
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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.
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