Fw: Re: Implemented OPLOCK for FreeBsd

[Jonathan Lemon]

On Fri, Sep 07, 2001 at 02:02:55PM -0700, Jordan Hubbard wrote:
> JFYI..
> 
> Jordan Hubbard wrote:
> > 
> > Thanks guys,
> > 
> > I also mailed some of this discussion to the freebsd developers
> > mailing list, and some of them have already come up with a way of
> > fully implementing the functionality needed by simply using kqueue.
> > I'm currently arguing that we should use kqueue internally and support
> > the Linux API externally, but in the interim I think Jonathan Lemon
> > will be able to help provide a freebsd_oplocks.c that mostly just
> > works out of the box if Ephi is willing to work with him a little.
> > 
> > - Jordan
> 
> Keeping the Linux external API would be good. We have 
> commitments from other (large) UNIX vendors to look at
> the Linux API as a "standard" way of doing this....


I do not think that we should be bound by this.  In fact, you could
argue that IRIX got there first, and that Linux should be adopting 
the IRIX API.  

The problem with the Linux API is that it provides no means of 
backchanneling the information back to the application, other 
than siginfo, which essentially forces you to use that model whether
you want to or not.  The IRIX API on the other hand, allows you
to attach the fd with the lease to another fd, similar to kq:

        if (fcntl(fsp->fd, F_OPLKREG, oplock_pipe_write) == -1) {

While not exactly the same, this is a better model than the Linux
API.  Note that there is nothing in the above code that precludes
a siginfo approach; the application could read from the pipe (or kq),
or choose to use signal delivery instead.  The point is that the 
Linux API is simply not flexible enough to handle either approach.

I'm not sure this is relevant to the Samba guys anyway, since they
have an abstracted model of the oplocks, in which the kqueue approach
will simply drop right into.
-- 
Jonathan