--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 04, 2007 at 12:29:31AM +0100, David Laight wrote:
> On Tue, Jul 03, 2007 at 07:46:00PM +0200, Joerg Sonnenberger wrote:
> > On Tue, Jul 03, 2007 at 06:42:06PM +0100, David Laight wrote:
> > > I'm beginning to think that both changes are needed:
> > > 1) Add a new mount system call and library function that passes the
> > >    length of the 'data' buffer into the kernel (and returns it for
> > >    MNT_GETARGS).
> > > 2) Default the buffer size to that from 'struct vfsops' when none
> > >    provided.
> >=20
> > How much sense does it make to keep MNT_GETARGS in the current form and
> > not just move to string-based input?
>=20
> That is completely orthogonal to the question I asked.
>=20
> It the options were a string, problib/XML, problib/binary (etc) you have =
even
> bigger problems when the application's data/buffer isn't known by the ker=
nel.

But we already face this issue with any place where we send a proplib into=
=20
the kernel. The problem should already be solved. If it's not, we just=20
pass the length along too (and thus canonically sove the problem most=20
likely :-)

I fail to see how this is a problem.

> As a data-point, would you want to be supporting netbsd's sys_mount()
> system call on (say) freebsd if the application passed in a buffer that
> wasn't a simple C structure to translate ?

I'm not certain why we care. If you're emulating NetBSD, you need to be=20
able to deal w/ proplib. I fail to see how sys_mount(2) would be any more=
=20
onerous than other instances.

sys_mount() is the system call that has always been at the top of my list=
=20
for proplibifying. We have had versioning issues over time (this being one=
=20
more of them), and using an extensible format can finally solve the issue.

We could continue in a fashion like we have. In that case, we need just=20
define a mount structure header that all mount operations would use.=20
Include the overall length, a file system type name ('ffs' 'lfs' etc.) and=
=20
a mount args version number. Then the file system can figure out what=20
length of data needs to be read in. But I think it'd be easiest to just go=
=20
with a readily extensible format now.

Take care,

Bill

--ikeVEW9yuYc//A+q
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFGi9qgWz+3JHUci9cRAg0WAJ9PCjx+rkTNezVWIqPFqreaJIcQmwCfXkJO
Sz99po147gEmpxe5D5hnn7o=
=uecs
-----END PGP SIGNATURE-----

--ikeVEW9yuYc//A+q--