Fw: Re: Implemented OPLOCK for FreeBsd
jlemon at flugsvamp.com
Fri Sep 7 19:56:30 GMT 2001
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
> 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
More information about the samba-technical