> I can think of two reasons. The first is we already have ioctl and fcntl,
> both of which have the ability to handle arbitrary operations. We're now
> proposing a third. Do we really need a third such call?
>
> Second, will we be doing one operation, as in statvfs() where we
> get info,
> or will we be doing a sequence of operations? If it's the latter, the
> fcntl() approach is a little easier as we only do path resolution once.
>
> Granted, I don't think we will be doing any fs operations which need to
> happen in the fast-path, so it doesn't make a TON of difference, but it
> can be a bit easier to just do the lookup once.
>
> HP-UX's fsctl(2) call uses a file descriptor, so we have prior art here.
>
> I'm not saying we MUST do this, I just want us to explore it.

Just shooting from the hip here.....

I can use umount(8) two ways: umount /MNTPOINT or unmount /DEV/XXX.
Is this done by umount(2)? Or are the smarts in umount(8)?

It might be nice to have an fsctl() that allowed reference either
way. Something in umount([28]) allows reference to a mounted file
system even if it is not responding -- it's overcoming deadlock
scenarios. That could be quite handy for freezing/unfreezing
(varyon/varyoff).

Then again......

Interfaces like statvfs() can report results more precisely
than file system globals. For example, f_bavail and f_favail can
be derived to reflect quotas -- it says how much is actually
available to the calling uid. An emerging mechanism is quota
by directory, so the path to statvfs() could reference a
directory with space restrictions and f_bavail report that.

Just thought food.

Regards,
	-gww