Re: [patch] one-to-many HAL integration



On Fri, Aug 13, 2004 at 11:48:12AM +0200, Alexander Larsson wrote:
> On Thu, 2004-08-12 at 22:17, Sriram Ramkrishna wrote:
> > On Thu, Aug 12, 2004 at 09:08:36AM +0200, Alexander Larsson wrote:
> > > Also, the gnome-vfs-volume-ops.c parts means we have to link gnome-vfs
> > > to libhal. I had hoped we could keep that dependency to the vfs daemon,
> > > to decrease the number of libraries every app links to. (especially the
> > > number of unstable libs.)
> > 
> > I agree that reducing dependicies is a godo thing, but wouldn't
> > that require some code movement to do that?  If so, I have something
> > related.
> 
> Why? We already only use HAL from the daemon, not from the lib.

Ah.

> > I'm trying to write my iriver driver which is not based on the
> > usb mass storage driver but I have to communicate with the iriver
> > mp3 player using USB commands.  But I want to be able to have the
> > gnome-vfs daemon detect that the iriver is plugged in through HAL.
> 
> Yes, long term this is something i want to do. Extend the module API
> with something you can load into the gnome-vfs daemon to look for plug
> in/out of some hardware device the kernel doesn't handle, then use that
> to create GnomeVFSVolumes with a uri to the method that allows you to
> access the device. [I.E. the uri has to be of the form something like 
> method://<device>/<path>, and not just method:///<path>, so we can
> handle multiple devices etc]

Great!  In the meantime I will suppose I will just write the driver
itself and not worry about HAL for now.

> > Currently davidz's patch does not address this corner case as it
> > only receives from the HAL dbus channel events where the capability
> > of the device is something the kernel sees as a 'disk'.  But the
> > capability would have to go into gnome-vfs proper but thats not
> > really optimal as you would have to support a lot of usb devices that
> > uses libusb instead of usb mass storage.  
> 
> Yes. the current HAL code is only for file:/// mounted devices. Until we
> extend the APIs (which won't happen for 2.8) this will continue to be
> true.

Looking forward to seeing something after 2.8 release then!

sri



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