Fw: Re: Implemented OPLOCK for FreeBsd

[Jonathan Lemon]

On Fri, Sep 07, 2001 at 02:44:38PM -0700, Jeremy Allison wrote:
> On Fri, Sep 07, 2001 at 04:23:46PM -0500, Jonathan Lemon wrote:
> 
> > 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 siginfo model is much cleaner than the arbitrary pipe
> backchannel approach.

And I could argue that kqueue approach is cleaner than the siginfo
model, as well as having better performance.  There were several papers
presented at this year's USENIX discussing this very point.


> > 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.
> 
> Except that we really don't want to add to this abstraction
> layer. We have a decent API - the Linux based one. Why not
> provide a FreeBSD implementation of the same ?

The abstraction layer is already there.  And I could also twist
the question around; why not provide a model that does not constrain
the user to one approach?


> It's the same API than an NFSv4 server would use. I don't want
> the FreeBSD developers to punt this issue by saying "Samba will
> handle all the underlying UNIX incompatibilities". I don't want
> Samba to have to do that. What's wrong with adopting the Linux
> API as a standard ? I don't see a good technical reason not to
> do that, given that POSIX realtime signal handling with the added
> data argument is a POSIX standard already that you will have to
> support in FreeBSD.

Also note that realtime signal handling is essentially a crock;
it does not scale, and is not reliable.  For better or worse, the
*BSD's have never slavishly adhered to the POSIX standards, choosing
rather to implement things based on their own merits, not what a 
committee decides.


> There's no sense in being different just for the sake of it.  
> I invented the IRIX interface and even I'm not very fond of
> it - it'd be good to see it die and one standard (Linux) method
> of doing this be chosen.

We're not being "different for the sake of it".  However, we do 
have an existing framework for solving the problem that already
exists in the kernel.  I don't see why there should be yet another
variant of the same thing re-implemented.

Right now, Linux appears to have:

        fcntl(fd, F_SETSIG, RT_SIGNAL_LEASE);
        fcntl(fd, F_SETLEASE, leasetype);

Where the first call sets up the siginfo handler, and the second 
registers the lease.  Note that the second call implicitly sets up
a backchannel to the application, instead of having it be explicit.
I would at least prefer to be able to specify the notification
delivery method.
-- 
Jonathan