Date: Mon, 24 Apr 2000 17:00:05 +0700 (ALMST) From: Boris Popov <bp@butya.kz> To: Julian Elischer <julian@elischer.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Request for the major device number Message-ID: <Pine.BSF.4.10.10004241634570.3773-100000@lion.butya.kz> In-Reply-To: <3904118B.446B9B3D@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Apr 2000, Julian Elischer wrote: > > Sure. smbfs actually consists of two major parts - SMB requester > > and filesystem itself. SMB requester handles all protocol details and > > gives clear interface like 'connect to server', 'connect to share', 'send > > request' etc. An opened device used as a handle for above primitives and > > this saves some code which should track these handles. > > if I'm understanding this right, then a particular process has it's > own session to the server? Does the filesystem not just get mounted? > how does a process that is unaware of the smbfs open a session? > (I think I'm missing something here) No, it doesn't (unless it want to establish its own session to server). smbfs by itself doesn't require any special treating and looks as plain network filesystem. It uses its own connection to SMB share (which may (or may not) have separate TCP connection to server). SMB requester by itself can be used for tasks like sending jobs to remote printer. smbprint command can use its own session (or use already established one) and may require user to authenticate, etc.. > > For example: any new connection established by userland process > > should be dropped when the process-owner is terminated. This can be done > > via at_exit handler and set of syscalls, but why to reinvent the wheel ? > > Kernel already does this job and does it well. (at_exit technique > > used in the netncp code and I don't like it much :) > > what is the 'userland process'? The process that wants to read the data, > or some daemon that is doing work to maintain the session? No, there is no need in any daemon to maintain session. All such things handled by kernel-side code. A simple example - the mount_smbfs command need to setup session to the server. It opens device, passes parameters (user name, share name, password etc) and establish session. Next, it passes device handle to smbfs code and closes the device (but session keept opened because smbfs code keeps reference to it). Another example is a smbprint command which also setups session but performs SMB requests from userland and releases handle when it coredumps or exit normally. SMB requester handles all connections and different programs can use the same connection to server (unlike Samba client which always establishes new connection/VC/session to server). Permanent connections can be created with smblogin command and this process doesn't involve smbfs code. > > The only disadvantage is the necessity to create N nsmb devices, > > but this should gone when device clones will be available (in fact, > > clones are implemented, but there is some unnegotiated conventions with > > Poul-Henning and lack of spare time). > > it would be nice of these convensions were shared with the rest of us > :-) Let me finish this task and then move to another :) -- Boris Popov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10004241634570.3773-100000>