HAL and CD monitoring
Carlos Perelló Marín
carlos at pemas.net
Tue Dec 9 19:55:41 EET 2003
El mar, 09-12-2003 a las 18:38, David Zeuthen escribió:
> On Tue, 2003-12-09 at 17:49, Bastien Nocera wrote:
> > Hello David, and all,
> > As Owen was overly busy already, and I was hacking a tidbit on magicdev,
> > I'm now the new maintainer for it.
> > And I was looking at the current monitoring code in HAL, and it looks
> > very much like the functionality it implements is something that I was
> > looking into for the future of magicdev (see my dead "magicplug" code,
> > and things like that ;)
> > 2 questions:
> > - Are there any plans to implement the monitoring code for 2.4 kernels?
> It's certainly *possible* to support 2.4 as one of the ideas of HAL is
> to be able to support many operating systems and indeed 2.4 was the
> first target.
It's not possible, is needed because 2.4 will be around for some years
(I'm sure it will be around more than 5 years)
> However, I quickly got turned off by the difficulties in 2.4 in reliably
> obtaining e.g. the /dev/sda1 node for e.g. usb-storage and started using
> 2.6 and udev. Having said that, it should be possible to write 2.4 code
> for HAL as well. It may difficult to do and it may be distro-specific
> though. I'm not sure...
> My 2.6 code does not appear to be distro-specific at all; I've got good
> feedback from people using other distros than myself (And as soon as I
> got 2.6 working on my Powerbook I will test on debian as well).
> > - Would changes to implement disc-change monitoring be accepted (once
> > written and reviewed) in HAL itself?
> Disc-change monitoring is clearly something that should just work!
> I see it closely related to mounting removable storage, e.g. a volume
> manager as Carlos suggested in September on this list.
> With the new (almost 100% rewritten) HAL it should be possible to write
> such a volume manager. I actually wrote a small python example for doing
> most of this here
> It's quite simple, yes? If you look at
> you can see that HAL also detects optical and floppy drives; optical
> drives got the capability removableMedia.cdrom; this is all derived from
> /sys and /proc in the 2.6 kernel (there are still issues with handling
> SCSI hardware devices as I've got none, but this can be resolved once
> someone tests this on a system with SCSI hardware).
> So, yeah, it's indeed possible for a volume manager to find these
> devices using HAL and do the disc-change monitoring on them. When a disc
> is detected this volume manager should create and maintain one or more
> (multi-session discs may have several volumes) Volume device objects as
> seen here for usb-storage
> Now, desktop file managers can simply just listen for hal device objects
> with the capability volume.
> (it should be noted that hal can interoperate with existing volume
> managers / automounters since the hal monitor parts looks for changes in
Hmm, are you only looking at that file? then you will not know when is
inserted a new CD. Am I missing something?
> > If so, then we might be looking at the future for magicdev in HAL :)
> Yeah, that would be great! magicdev is also a more catchy name than
> volume manager :-)
Bastien, will magicdev change from a GNOME application to a non desktop
It could be really cool, the idea should be that the actual GNOME
frontend must configure hal events instead of the magicdev daemon.
> I must admit that I need to update the hal spec to mention all this and
> make the 0.2 release; I promise to do this real soon now when I've
> shuffled internals around enough. Until then, it's still in CVS.
Grrr, I need more free time to help you with it. Sorry :-(
> Xdg-list mailing list
> Xdg-list at freedesktop.org
Carlos Perelló Marín
Debian GNU/Linux Sid (PowerPC)
Linux Registered User #121232
mailto:carlos at pemas.net || mailto:carlos at gnome.org
Valencia - Spain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
Url : http://lists.freedesktop.org/archives/xdg/attachments/20031209/8dc60b98/attachment.pgp
More information about the xdg