Plans for hal 0.5.x

[David Zeuthen]

On Mon, 2004-12-13 at 09:47 +0100, Martin Pitt wrote:
> If I understand correctly, the main cause of a hanging hal is reading
> /proc/bus/usb/devices. 

Not really, you may look here

 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136255

for a minimal test program that does this. People say it's better in
2.6.10-rc2, I should probably go ahead and test it.

It's true that reading /proc/bus/usb/devices causes other errors but I
don't think it's realted!

> Since newer kernels export the same information
> in /sys too, I rather think hal should look at sysfs. 

Yeah, I actually wrote that kernel patch :-)

> Do you plan to
> do this soon?
> 

Will do in the new version.

> Second, with the migration from the old hotplug to the newer
> udevd/udevsend architecture should finally help to get rid of the
> sequence sorting and many deadlocks as well.
> 

That's right - I had some discussions with Kay about this and in my view
it looks like udevd should tell hald about hotplug events; we need to do
it from udevd because the spawned dev.d hal.dev programs may race
against each other and come out of sequence. 

Whether udevd should talk to hald directly (having only one socket
connection to maintain order) or through an intermediate (e.g. D-BUS
signals) is an open question. Problem with the former case is that hald
goes into state D then udevd could also be screwed. I'm sure Kay can
comment here. The latter case give other nice things such as udevd
owning D-BUS service org.kernel.udev with interfaces to provide udevinfo
functionality. Dunno..

> >  1) cameras; we already support these, but I'd really like to kill of
> >     hal_hotplug_map and get the list of cameras as one gigantic .fdi
> >     file - ideally the gphoto2 package would install that .fdi file
> >     on the system.
> 
> Is there a recommended method of automatically generating an fdi file
> from a module map? 
> 

Not sure, I gphoto got it stored somewhere. In the source I think. I
know that Hubert also got a list here

 http://www.teaser.fr/~hfiguiere/linux/digicam.html

that also includes USB Mass Storage cameras (see ; whether that is part
of gphoto, I'm not sure. But the .fdi files can come from several
sources, if gphoto doesn't supply the USB Mass Storage ones we might
just ship them with hal (since they got little to do with gphoto). 

> >  1) I actually think it would be nice to have a hal-aware mount wrapper
> >     shipped with the hal package. This could read properties from the
> >     desktop sessions preferences system (e.g. gconf) to see if something
> >     should be mounted sync/async. Could also interact with the session
> >     and say "I need the root password to mount read/write" for e.g.
> >     hotpluggable devices. See this rant
> >     http://www.pbs.org/cringely/pulpit/pulpit20040916.html
> >     and ponder about the sections concerning Epoxy glue :-). We would
> >     use the storage.policy.* namespace for this.
> >     Such a wrapper would ideally be split up into GNOME, KDE, whatever
> >     frontends (the GNOME version would read from gconf and use GTK+
> >     for dialogs). The wrapper would also use libhal-storage.
> 
> Ubuntu and Debian is currently using a very simple script pmount-hal
> which does about that: reading properties from hal and invoking pmount
> with the right options. It is currently written in shell, but if it is
> to be found too slow, I am not opposed to an implementation in Perl or
> C.
> 

Cool.

> David, I'm looking forward to the new hal. There are great new
> thoughts and ideas!
> 

Thanks!

Cheers,
David


_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal