> I don't object performing the actual login procedure in user space,
> this is where it belongs. However, as a result of the login, I assume
> smbmount obtains a session key or something that gets passed to the ker=
> nel
> (I'll have yet to study the details of SMB).
> So I suggest the same procedure: smbmount is a plain executable,
> performs the login, then passes the results to the kernel using mount(2=
> ).
It sad, but it is a bit more difficult with smb. The server is allowed
to kill the connection when the client is idle. The server decides
whether to kill connections, there are no rules, and there is no way
to prevent it. When it has been killed, you have to perform the
complete login procedure again. So my current design consists of a
daemon that only waits for a SIGUSR1 being issued by smbfs. The daemon
then logs in and passes the fresh file descriptor to smbfs via an
ioctl.
This design allows the implementation of other nice features. For
example, it might become possible to support Microsofts DFS.
> The kernel then checks whether the file system supports user mounts,
> and proceeds mounting it.
What exact rules do you have in mind?
> If you absolutely want to introduce a new system call, don't forget
> to fix the problems of the current one. For example, user space should
> provide a size for the data argument.
Yep, and passing the device as a fd as well is another good
idea. Other opinions?
Volker
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBM9hxgT/9BWnmOc5FAQFLcQP8Cm0IHmoBT10tf5W1Pl4lg9AavtNLSoSx
hujPXwkrXNqzzNR8ieDaImHoAvR+lS/yKKB8hWbs6T4C5sk3wwR/gPh+oyigXs/B
fX2yET0aI/daHtkuDmO6oMtiVWd6NT/vUJNshyq3ykZo8TbgmNnFqozPqL3/4EIL
aO+8LBuoNro=
=+/U7
-----END PGP SIGNATURE-----