Re: Pushing Samba functions into the kernel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 13 Feb 2003, Richard Sharpe wrote: On Thu, 13 Feb 2003 [EMAIL PROTECTED] wrote: 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. OK, I am not familiar with this problem. Can you say more please. Win2k TSE uses a single TCP session to the file server and multiplexes all of the SMB sessions over that. cheers, jerry -- Hewlett-Packard- http://www.hp.com SAMBA Team -- http://www.samba.org GnuPG Key http://www.plainjoe.org/gpg_public.asc You can never go home again, Oatman, but I guess you can shop there. --John Cusack - Grosse Point Blank (1997) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE+TTB4IR7qMdg1EfYRAuv8AJ0W6QB1YHZCGvGRL/7CynmLMB0tNACgi3yQ troxuc585ZsbywGxNz36N/E= =/umr -END PGP SIGNATURE-
Pushing Samba functions into the kernel
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). In essence, what I want to raise a discussion on is ways to have Samba enable these things. It would be good if it were easy to splice our changes into the code base, and any fixes we develop for the GPLd code can be easily extracted and returned to the code base. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: Pushing Samba functions into the kernel
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.
Re: Pushing Samba functions into the kernel
On Thu, Feb 13, 2003 at 11:41:35AM -0800, Richard Sharpe wrote: : The return from the syscall would be a complete SMB, possibly with the NetBIOS header in a separate buffer, and maybe more. The entire NBT layer could be placed into the kernel. I would see, perhaps, LMB, DMB, and NBNS functionality in a daemon but the essential parts of the NBT layer are trivial (in comparison with the rest of SMB) and could definitely be isolated out. This would not impact SMB since, once the NBT Session is established, the NBT SMB packets are identical to naked TCP tranport-ed SMB packets. They can just be passed through to whatever piece handles SMB (even directly to the existing smbd, thus allowing kernelization in stages). The only issue is in any interprocess communication that Samba currently does between smbd and nmbd. I think that's isolated to LMB and DMB activity, but may be wrong there. Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Re: Pushing Samba functions into the kernel
On Thu, 13 Feb 2003 [EMAIL PROTECTED] wrote: 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. OK, I am not familiar with this problem. Can you say more please. 2). A utf8 case-insensitive filesystem (massive performance win). Yes. I agree. We are looking at this issue. 3). Implement SMBreadX/SMBwriteX in the kernel once a channel has been set up. Right. I think the open code would be best left to Userland, at least initially. However, some FIDs we would not want the kernel to handle, I suspect, eg RPC FIDs. So we need a mechanism to communicate things between Samba and the kernel. 4). Allow NT SD's stored in EA's to be interpreted by security code living in the kernel for open decisions. Indeed. We already have a mechanism in our File System that does this. It is not what I really want, because it should be in the kernel, but for the moment it is in the file system and works. With the privilege code coming into Samba, we also need privileges in the kernel as well, and in Linux, you might be able to map this onto capabilities, or perhaps do something orthogonal to capabilities with LSM. An additional area of concern here equivalence between NFS users and CIFS users. It seems (at least to me) that you can use one of two approaches: 1. Name equivalence, where you look up the name associated with a UID/GID and then check if an in incoming SID has the same name. 2. Administrative equivalence. Where you provide somewhere in a database the equivalence between SIDs and UIDs/GIDs. However, these become issues that Samba does not have to worry about these issues if they are done in the kernel. Everything else (IMHO) is better done in user space. I only want to move what makes sense ... Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: Pushing Samba functions into the kernel
On Thu, 13 Feb 2003, Steven French wrote: jra wrote 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. That is reasonably sensible, although the dirlookup may not be required to be in kernel to take advantage of the particular issue of case-insensitive file compares - if you are willing to live with case preserving/case insensitive behavior for local apps too for a particular partition - jfs allows formatting partitions case-insensitive (and it is probably doable in others with more work). Optimizing the Unicode string comparisons/conversions would be a huge performance win and worth looking at inkernel findfirst/findnext. OK, we don't care about local apps at all, being a NAS, and I suspect that a lot of others who are interested in this discussion don't care either. However, we do care about NFS clients and CIFS clients sharing the same storage space, and even though there is often little actual shared file access going on, we still want to serve both sets of clients from the one underlying file system. Have a look at Tridge's presentation on this issue. The new kernel nanosecond timestamps can probably be accessed in userspace without requiring in kernel - but that feature was a nice recent addition to the kernel. Well, the API for accessing 64-bit time stamps on files is not clear :-) Hooking in the kernel socket layer more sensibly for scatter/gather like operations for SMB read/write to take advantage of TOEs will be a big win. There is plenty of precedent for doing a subset of SMB ops in kernels, and throwing the rest to user space. The addition of LSM makes some very interesting authorization behaviors possible but is a distinct in-kernel piece.The addition of the well known xattr name for the 32 bit quantity system.dosattributes (in addition to the two existing well defined xattrs system.defaultacl etc.) would be helpful - probably something I should submit to the lkml - the xattr is transparent to everyone but cifs, smbfs and ntfs (only a few apps like backup apps and Samba would care) OK, so some of us are thinking of similar things. What I would like to progress to is some discussion around the sort of changes that would be needed to allow this to be easily done. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
