HAL methods at storage device level, to mount/unmount/eject volumes

Kay Sievers kay.sievers at vrfy.org
Tue Dec 13 08:56:09 PST 2005


On Tue, Dec 13, 2005 at 11:38:38AM -0500, David Zeuthen wrote:
> On Mon, 2005-12-12 at 18:58 +0100, Kay Sievers wrote:
> > > Hence, the suggestion about moving policy-decision about whether to use
> > > the in-kernel ntfs driver or the captive user-space stuff, down to the
> > > hal helper script for mounting sounds pretty good to me. You can even
> > > test for the presence of these tools and it'll just work even if the
> > > user installs this post-OS-installation.
> > > 
> > > What is wrong with doing that?
> > 
> > Well what's wrong with having it? It's a user policy if you want to use
> > fuse or subfs and not a system-wide config option. It should even be possible
> > to configure that policy in the user session for specific devices. The mount
> > script is not supposed to look-up data in the user session, right?
> 
> Right, yea, I guess that's a point worth considering. Let's go for
> passing the desired fs (with "" being use the one volume_id detected)
> then but let's be super paranoid about when we allow overrides. 

Fine. It already is a whitelist, that throws "InvalidMountType", if
anything else than the listed options are given. It also uses
$HAL_PROP_VOLUME_FSTYPE if the string is empty, which it is supposed
to be in most cases.

Kay


More information about the hal mailing list