Pushing Samba functions into the kernel

[jra at dp.samba.org]

On Thu, Feb 13, 2003 at 11:41:35AM -0800, Richard Sharpe wrote:
> Hi,
> 
> I wanted to start a discussion on the following:
> 
>     Implementing some SMB functions in the Kernel, within a Samba base,
>     or,
>     Bending and twisting Samba out of shape.
> 
> There are a number of reasons for wanting to use the Samba code base, but 
> at the same time, extend it to allow more functions to be pushed into the 
> kernel.
> 
> Some of the things I want to do are:
> 
> 1. I would like to take advantage of the header splitting capabilities
>    offered by the raft of current and future Theory of Everything chips, 
>    as well as allow zero copy and page flipping code to be useful, and
>    to implement recvfile (the analog of sendfile).
> 
>    Each of these seems to require a slightly different approach to 
>    receiving SMBs to the current approach. One that I am thinking of
>    is to have a syscall that receives an SMB or generates a time out
>    or return a socket error in the event of an error.
> 
>    The return from the syscall would be a complete SMB, possibly with the
>    NetBIOS header in a separate buffer, and maybe more.
> 
> 2. The current sendfile code is great, and is implemented in a better way
>    that I originally implemented it where I currently work. However, I
>    believe that there are more cases where I can use sendfile than
>    what Samba currently knows about. It would be useful to have some
>    infrastructure in Samba for doing this.
> 
> 3. I would like to move down a path of moving simple functions into the
>    kernel, and this is, in some ways, an extension of point 1 above.
>    It would be useful if the system call that gets an SMB can also 
>    implement some subset of SMB in the kernel (although I will want some
>    way to indicate that some FIDs not have this treatment, for example
>    those associated with RPCs).

Ok, my feelings on "Samba in the kernel" are the following.

1). We need to be able to de-multiplex incoming SMB's at the kernel
level to get over the W2K Terminal Server problem.

2). A utf8 case-insensitive filesystem (massive performance win).

3). Implement SMBreadX/SMBwriteX in the kernel once a channel has
been set up.

4). Allow NT SD's stored in EA's to be interpreted by security
code living in the kernel for open decisions.

Everything else (IMHO) is better done in user space.

Jeremy.