On 1 Aug 00 at 14:38, Urban Widmark wrote:
>
> To correct this with the current binary solution that requires a new
> protocol version and a new smbmount (possibly with all sorts of
> compile/version problems since it includes kernel headers directly). With
You should not do it... For example you can compile userspace ncpfs
on 2.0.0 kernel and although you did this, such binary will understand
all kernels between 2.0.0 and 2.4.0-test6-pre1 - even 32bit uids will
work...
> an ascii option string it would probably not have been done like that in
> the first place, but changing it requires only administrator changes (fix
> your fstab entry, autofs map, script).
At least with ncpfs there is problem that some of mount options are
parsed completely in userspace (passwd,ipserver), some are passed to
mountpoint with ioctl (ttl,volume,codepage), some are mapped into VFS flags
(ro,rw,noatime,...), some are ignored completely (auto,noauto) and some
are pasted into binary mount structure (mode,uid,gid,owner)... So
ncpmount has to parse options anyway...
> I know you were talking about VFS-level options. Is it more acceptable for
> fs-level options? If not, is there a plan/goal to make mount(8) start
> passing a binary struct as *data?
And what about read_super returning error code except simple NULL/non-NULL
error code? So ncpmount could distinguish different reasons of why
mount() failed. If there is general consensus that passing binary
structure to mount() is stupid, I can change ncpfs behavior for 2.5.x...
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
