Date: Mon, 24 Apr 2000 02:19:07 -0700 From: Julian Elischer <julian@elischer.org> To: Boris Popov <bp@butya.kz> Cc: freebsd-hackers@freebsd.org Subject: Re: Request for the major device number Message-ID: <3904118B.446B9B3D@elischer.org> References: <Pine.BSF.4.10.10004241538440.3515-100000@lion.butya.kz>
next in thread | previous in thread | raw e-mail | index | archive | help
Boris Popov wrote:
>
> 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)
>
> 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?
>
> Of course, said above doesn't mean that mount_smbfs will hang as a
> daemon.
>
> 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
:-)
>
> --
> Boris Popov
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000
---> X_.---._/ presently in: Perth
v
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?3904118B.446B9B3D>