Fw: Re: Implemented OPLOCK for FreeBsd

[Julian Elischer]

On Fri, 7 Sep 2001, Jeremy Allison wrote:

> On Fri, Sep 07, 2001 at 04:23:46PM -0500, Jonathan Lemon wrote:
> 
> > 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.  
> 
> Except that the IRIX API isn't very good (my fault) and
> Linus refused to accept it. He helped us design a much
> cleaner interface which is of more generic use than just Samba.
> 
> > 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.
> 
> > 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 ?
> 
> 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.

We have a good framework for arbitrary event handling in FreeBSD.
we don't want to implement a half dead (signals suck) implementation
in adition to it.

It shouldn't be much work to make a FreeBSD oplock plugin given that you
have an abstraction layer. I doubt it will require extending that
abstreaction layer. Anything the Linux model can do can be done with 
kqueue.


> 
> Jeremy.
>