From owner-freebsd-hackers Wed Nov 8 16:46: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from linus.dvart.com (linus.dvart.com [64.79.2.3]) by hub.freebsd.org (Postfix) with ESMTP id 9AA1A37B4C5 for ; Wed, 8 Nov 2000 16:46:01 -0800 (PST) Received: from dvart.com ([192.168.100.141]) by linus.dvart.com (8.9.3/8.9.3) with ESMTP id QAA09273; Wed, 8 Nov 2000 16:45:57 -0800 Message-ID: <3A09F3BF.B028E0F8@dvart.com> Date: Wed, 08 Nov 2000 16:45:51 -0800 From: bruno schwander X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: close call in a device ? References: <200011082033.NAA25455@usr08.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > when a process closes the device, I do not get a "close" call for each > > > process closing the device. I instead get a close only on the last > > > process closing the device. > > > > devices in a similar way as the one is used for scanning pty's). > > To add to this, the close calls can be forces; there is a flag > in the device structure wich can force notification. I'm not > sure what it does over a fork(), though: I think you really want > open notification. > You mean that when I register my device/kernel module, I can explicitely request that all close calls will notify my module ? That is exactly what I need. What do you mean by open notification ? I do get all "open" calls to my device, just not all the "close" > The main problem with per process resources is that the VFS that > implements devices, specfs, doesn't own its own vnodes. Could you develop a little ? I don't know about VFS, specfs and vnodes... What I did is make a module that defines a struct cdevsw with the open/read/ etc callbacks, then I register my calls for various devices entries with make_dev(), and at the end used the DEV_MODULE() macro to declare it to the system. I modeled that after the example in /usr/src/share/examples/kld of FreeBSD 4 Is there a different driver/module architecture ? > This is actually the primary reason that VMWARE can only run > one instance at a time of a virtual machine: there is no way > to have per open instance resources, which are not shared. > > If you were to use the TFS flag (grep for TFS in the headers, > that's a substring), you could make specfs own its own vnodes. > Where should I look for this ? I looked into /usr/src/ and only some references to NTFS and TFS filesystems turned up ? Would I have to roll out a custom filesystem to have this running ? > The way you would handle your problem then is by returning a > different instance of the device, with a different instance of > per process attached storage. It's pretty simple to do this: > just return a different vnode for the next open of the same > device, instead of the same vnode with an additional reference. this is really confusing me... in the example I had, the only thing I return from my open routine is an int telling success or errors happened... any pointers for the vnode stuff ? if it could apply to what I am trying to do ? Am I basing my driver on the wrong stuff ? > NB: If you are trying to do this for VMWARE or some other binary > code, there's no way that the pty opening soloution suggested in > the previous posting will be able to work for you, since the code Yes, I came to that conclusion too. > will expect a particular behaviour. Right now, FreeBSD doesn't > support this behaviour (cloning devices), but as pointed out > above, it's not hard to implement, it's mostly just labor > intensive. > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- ########################################################################### Bruno Schwander Senior Software Engineer Worldgate Communications, Inc email: bschwand@dvart.com ############################################################################ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message