The CIFS filesystem has been updated to handle yesterday's changes to the
superblock structure and has been added to a new bitkeeper repository as a
single bitkeeper changset in order to be easier to apply. It is changeset
number 1.747 at bk://cifs.bkbits.net/linux-2.5-with-cifs and is low risk,
not changing core kernel files.
Documentation/filesystems/00-INDEX | 2
Documentation/filesystems/cifs.txt | 26
fs/Config.help | 27
fs/Config.in | 2
fs/Makefile | 1
fs/cifs/AUTHORS | 16
fs/cifs/CHANGES | 142 ++
fs/cifs/Makefile | 8
fs/cifs/README | 94 +
fs/cifs/TODO | 55
fs/cifs/asn1.c | 615 ++++++++++
fs/cifs/cifs_debug.c | 546 ++++++++
fs/cifs/cifs_debug.h | 74 +
fs/cifs/cifs_fs_sb.h | 27
fs/cifs/cifs_unicode.c | 136 ++
fs/cifs/cifs_unicode.h | 368 ++++++
fs/cifs/cifs_uniupr.h | 253 ++++
fs/cifs/cifsfs.c | 433 +++++++
fs/cifs/cifsfs.h | 90 +
fs/cifs/cifsglob.h | 333 +++++
fs/cifs/cifspdu.h | 1527 +++++++++++++++++++++++++
fs/cifs/cifsproto.h | 251 ++++
fs/cifs/cifssmb.c | 2155 +++++++++++++++++++++++++++++++++++
fs/cifs/connect.c | 2252 +++++++++++++++++++++++++++++++++++++
fs/cifs/dir.c | 303 ++++
fs/cifs/file.c | 1027 ++++++++++++++++
fs/cifs/inode.c | 691 +++++++++++
fs/cifs/link.c | 219 +++
fs/cifs/md4.c | 209 +++
fs/cifs/md5.c | 363 +++++
fs/cifs/md5.h | 38
fs/cifs/misc.c | 362 +++++
fs/cifs/netmisc.c | 879 ++++++++++++++
fs/cifs/nterr.c | 712 +++++++++++
fs/cifs/nterr.h | 547 ++++++++
fs/cifs/ntlmssp.h | 96 +
fs/cifs/smbdes.c | 416 ++++++
fs/cifs/smbencrypt.c | 454 +++++++
fs/cifs/smberr.h | 112 +
fs/cifs/transport.c | 245 ++++
fs/nls/Config.in | 2
41 files changed, 16107 insertions(+), 1 deletion(-)
The CIFS file system is ready to be included in the 2.5 Linux kernel and
only affects the usual small set of files outside its own directory
(fs/cifs) that a filesystem must change (e.g. fs/Config.in, fs/Makefile,
fs/Config.help) but does not require changes to any core kernel code.
The filesystem is designed for remote access to Samba, newer Windows
servers and also the many common CIFS based NAS appliances, but unlike
smbfs is optimized for the current version of the SMB/CIFS protocol. The
CIFS file system can coexist with smbfs. The CIFS file system is
reasonably stable, passing most but not all of the standard filesystem test
suites going to either Windows servers or Samba (NB a few Samba bug which I
am working is blocking fsx at the moment and memory mapping support is not
finished) running with the current 2.5 kernel. It has been tested at both
Connectathon and the CIFS Plugfest this year and has been under development
for over a year with the assistance from some others on the Samba team as
well as feedback from the standards group (SNIA CIFS Technical Workgroup)
and others at IBM. The project web site has more information on the
project http://us1.samba.org/samba/Linux_CIFS_client.html
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: [email protected]
On Thu, Oct 10, 2002 at 03:08:53PM -0500, Steven French wrote:
> The CIFS filesystem has been updated to handle yesterday's changes to the
> superblock structure and has been added to a new bitkeeper repository as a
> single bitkeeper changset in order to be easier to apply. It is changeset
> number 1.747 at bk://cifs.bkbits.net/linux-2.5-with-cifs and is low risk,
> not changing core kernel files.
>
> ...... stuff cut......
>
> The CIFS file system is ready to be included in the 2.5 Linux kernel and
> only affects the usual small set of files outside its own directory
> (fs/cifs) that a filesystem must change (e.g. fs/Config.in, fs/Makefile,
> fs/Config.help) but does not require changes to any core kernel code.
>
> The filesystem is designed for remote access to Samba, newer Windows
> servers and also the many common CIFS based NAS appliances, but unlike
> smbfs is optimized for the current version of the SMB/CIFS protocol. The
> CIFS file system can coexist with smbfs. The CIFS file system is
> reasonably stable, passing most but not all of the standard filesystem test
> suites going to either Windows servers or Samba (NB a few Samba bug which I
> am working is blocking fsx at the moment and memory mapping support is not
> finished) running with the current 2.5 kernel. It has been tested at both
> Connectathon and the CIFS Plugfest this year and has been under development
> for over a year with the assistance from some others on the Samba team as
> well as feedback from the standards group (SNIA CIFS Technical Workgroup)
> and others at IBM. The project web site has more information on the
> project http://us1.samba.org/samba/Linux_CIFS_client.html
I don't know if it will help, but here's my 2 cents (US :-). I'd love
this to be included into 2.5.x Linux, as it is a very nicely written,
modern CIFS client that we can use to start adding UNIX specific extensions
into Samba, and hopefully end up with a filesystem that uses UNIX semantics
when talking to a Samba server, and will fall back to Windows semantics
when talking to lagacy Windows server (I really love saying that :-) :-).
Should be a big help in making Linux the "universal client glue" we know
and love .... :-).
Cheers,
Jeremy Allison,
Samba Team.
[email protected] said:
> fs/cifs/md4.c | 209 +++
> fs/cifs/md5.c | 363 +++++
> fs/cifs/md5.h | 38
Unless these are somehow CIFS-specific, they should live in linux/lib/
--
dwmw2
David Woodhouse <[email protected]> writes:
> [email protected] said:
> > fs/cifs/md4.c | 209 +++
> > fs/cifs/md5.c | 363 +++++
> > fs/cifs/md5.h | 38
>
> Unless these are somehow CIFS-specific, they should live in linux/lib/
This would have the disadvantage that they would need to be always compiled into the
kernel, even though it may not need it. And we already have code bloat problems,
no need to make it worse.
Making them modular also isn't good. Each module takes a 4k page at least, so you
would waste a lot of memory because they're smaller than 4k.
As long as they are not used by anything else it's probably best to keep it
where they are.
-Andi