Fw: Re: Implemented OPLOCK for FreeBsd

[Greg Lehey]

On Saturday,  8 September 2001 at  0:13:50 -0700, Jeremy Allison wrote:
> On Sat, Sep 08, 2001 at 12:00:17PM +0930, Greg Lehey wrote:
>
>> I think we should be careful not to go too far in the opposite
>> direction.  If nobody ever deviates from the standards, we get almost
>> no progress (only when the committee can decide).  kqueue promises
>> significantly higher performance than real time signals.  Just because
>> Samba doesn't need this level of performance (yet) doesn't mean that
>> we should choose an inferior implementation.
>
> But there's a difference between an interface 

... and an implementation, as you quote below.

> that all other systems (Solaris, HPUX, Linux etc.) have standardized
> on - POSIX realtime signals, and one group determined to do
> something different seemingly for the sake of it.

"Seemingly" is subjective.  I have no doubt that it seems that way to
you, and possibly Jonathan hasn't explained the reasons well enough,
but this is not some kind of NIH, it has solid technical backing.
Jonathan can describe this much better than I can, so I'll leave it to
him.

>> What I'm seeing here, though, is a confusion between interfaces and
>> implementations.  Obviously we should support a real-time signal
>> interface.  That doesn't mean that the implementation should be the
>> same.
>
> I'm not saying the you should drop kqueue, only that it would be
> better to have POSIX realtime signals implemented as well (on top of
> kqueue if you like, I don't care)

Agreed, it makes sense to have an implementation of real time
signals.

> and the oplock interface defined in terms of the standard that
> everyone supports.

I don't understand the issues enough to know whether that is the
correct way to layer things.  For that matter, I'm not sure that
anybody understands all the issues well enough yet.

> That way, if kqueue is better than realtime signals under the covers
> then good for you - you get the best implementation.

Assuming that the interface to the real time signals, while a good way
to implement real time signals, is not a suboptimal way to implement
oplocks.

> But insisting you will only support kqueue and not POSIX.4 and
> application developers be dammed is not helpful and does not
> encourage people to port complex code to FreeBSD.

Agreed.  I don't think anybody is advocating that.

Greg
--
See complete headers for address and phone numbers