HAL methods at storage device level,
to mount/unmount/eject volumes
Danny Kukawka
danny.kukawka at web.de
Sat Dec 10 06:25:49 PST 2005
On Friday 09 December 2005 23:25, Kevin Ottens wrote:
> Le Vendredi 9 Décembre 2005 19:36, Danny Kukawka a écrit :
> > So why not support it?
>
> Sure, and it can be supported thanks to the hal-system-storage-mount that
> can be fine tuned by distributors (for example). I still don't see why the
> applications calling Mount() would need to bother specifying the fs type...
Where is the problem? Currently (CVS-HEAD) you can let the fstype option empty
to get and use the fstype from hal for the mount command. I don't see any
problem.
If a distributor (as e.g. SUSE) want to extend this he need only to change the
mount script (or replace with a binary or what ever), but don't need to
change the hal interface - this is the same for all. Every other per
distributor solution would be a maintainance desaster for enterprise products
and also for every other product because you maybe need to fix many other
applications.
> They only need to know if the mount failed or not, and don't care about
> _how_ it's actually done (that's up to the script to hide such
> implementation details IMHO).
I don't understand the problem. We would allow to give the user the control to
mount as he want. This was the intention of Kay and also the SUSE KDE guys as
we discussed and proposed this change.
If you would give the user the freedom to mount over the desktop by a applet
or any other application (IMO Stephan Kulow work on a KDE
solution/integration) and you would allow the user to mount, if he want,
fuse/subfs or what ever, you need a way to do this over the HAL interface in
a clear way. And this is the current solution in the CVS. As above: If you
don't like to change the filesystem let the parameter empty or/and use the
fstype from HAL.
IMO it's the wrong way to hide this somewhere, somehow in the mountoption in
the script - bad idea.
> Am I missing something? I really don't see use cases for the fs type
> parameter...
*?*
Cheers,
Danny
More information about the hal
mailing list