Well, given that the protocol specification isn't 100% finalised, it's
not clear that pushing for inclusion now is entirely sensible. We
don't want people to be using an NFSv4 on Linux that is incompatible
in some subtle way with other vendors.
Also, I suspect that NFSv4 will be fairly localised in the changes it
makes and could well go in to 2.6.10 of whatever (afterall, reiserfs
went in at 2.4.2).
There are some changes that NFSv4 would like to make that affect
common code, such as making open(,O_EXCL) work for a networked
filesystem, but we can live without that (as we do with NFSv3), but
hopefully that functionality will get in before halloween anyway.
My understanding is that the CITI team will be funneling some of their
NFSv4 code though the maintainers (Trond and myself) to at least get
some of the code into 2.5. This will likely not include support for
all the fancy state and locking, but will support the well established
aspects of the protocol and will allow minimal operability. This will
also mean there is a clear base in the mainline kernel for other bits
to be added as appropriate.
Obviously we will clarify the license before forwarding to Linus.
I'm particularly keen to get the crypto authentication stuff in and I
will be looking into that RealSoonNow.
NeilBrown
-
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/