Re: -mm merge plans for 2.6.20

[Steve French <smfltc@us.ibm.com>]

akpm wrote:
> deprecate-smbfs-in-favour-of-cifs.patch
> deprecate-smbfs-in-favour-of-cifs-docs.patch
>
> Am still waiting to hear from sfrench on the appropriateness of this.


smbfs deprecation is ok but there are a few things to consider:
1) Secure mounts:  although more secure mounts are possible now to
Windows (not just Samba) with the most recent NTLMv2 patch in the cifs
tree, implementation of Kerberized mounts are stuck in debates about the
right upcall mechanisms (gssapi/spnego blobs can be almost 64K in size,
and userspace turned out to need to keep state across a sequence of two 
to three
upcalls before discarding its state which complicates things).   smbfs 
can handle
kerberos mounts in some cases so this is critical, even though in 
practice ntlmv2
is often good enough.

2) minor holes in backlevel server (OS/2 and Windows 9x/WindowsME) support
cifs is better in many cases than smbfs for this now, but cifs does
not handle utimes() remotely to them  yet  ie setting date/time the old 
style
DOS or OS/2 way (cifs can of course query the time fine).   This may not 
matter
for most cases and would be pretty easy to finish up

3) Documentation - minor cifs vs. smbfs differences in 
syntax/behavior.   I have
added some of this to the cifs documentation .odt file but have not 
posted the
pdf yet nor updated the shorter fs/cifs/README with some of this
helpful information (differences in syntax to help users migrating from 
smbfs).
I will post that to the cifs project site as PDF and .ODT this weekend.

4) Hot bugs ... For most users we should be ok here, but there is one major
unresolved bug that worries me: the cache_reap bug ("sleeping function
called from invalid context" in list_del+0x9/0x6c)
   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214622
Not sure whose bug that will turn out to be and ACPI settings seem to
affect it but it obviously affects some 2.6.19 users.

Running simple tests on smbfs, I run into so many problems now though, it
is probably time to mark it as deprecated as Fedora etc. apparently 
already have.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/