From owner-freebsd-hackers Fri Dec 21 14:44:43 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 5F19237B416 for ; Fri, 21 Dec 2001 14:44:35 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id DF73181E0C; Fri, 21 Dec 2001 16:44:29 -0600 (CST) Date: Fri, 21 Dec 2001 16:44:29 -0600 From: Alfred Perlstein To: rsharpe@ns.aus.com Cc: FreeBSD-hackers@freebsd.org Subject: Re: Adding si_fd to struct __siginfo ... Message-ID: <20011221164429.U48837@elvis.mu.org> References: <3C23AF6E.90202@ns.aus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C23AF6E.90202@ns.aus.com>; from sharpe@ns.aus.com on Sat, Dec 22, 2001 at 08:23:50AM +1030 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Richard Sharpe [011221 15:11] wrote: > Hi, > > One of my tasks is to add oplock support to FreeBSD so that we (Panasas) > can allow correct caching of files by Windows clients in the presence of > NFS clients using the same files. > > We have a preliminary implementation, based on the Linux implementation, > but it is a gross hack because there is no way for the kernel, when it > delivers a signal, to indicate the fd that caused delivery of the signal. > > Linux and Solaris have an fd field in struct siginfo_t which allows the > kernel to indicate, for signals relating to files, to indicate which fd > the signal relates to. > > I notice that in FreeBSD struct siginfo_t seems to have int > __spare__[7]; and would like to use one of those spare fields as si_fd. > > While I can do that in our code base, if I want to contribute the OpLock > code it would be useful if the FreeBSD community finds this change > agreeable. > > Are there any counter suggestions or any big objections? There was already a big mess of a discussion about how this would be much better done via kqueue than with realtime signals. I guess if you can get a working implementation that is compatible with the existing interfaces it would work, however it's a _much_ better idea to use kqueue to deliver this sort of notification. And yes, it has been discussed in the lists already. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message