Fw: Re: Implemented OPLOCK for FreeBsd

[Jeremy Allison]

On Fri, Sep 07, 2001 at 05:44:17PM -0500, Jonathan Lemon wrote:

> 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?

Because Samba doesn't want to have all these #ifdefs 
to support platforms that are deliberately choosing
to be different.

The linux API already exists. Give me a good *technical*
reason why you want to do it differently.

> 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.

This is a pathetic excuse and is silly. Samba runs *only* on POSIX
systems. We depend on it. If you want to be non-POSIX, fine.
Samba only supports POSIX API's. When you break Samba by being
non POSIX, we not going to change Samba for you.

Realtime signal handling is in POSIX and you will end up
supporting it, or become even more irrelevent.

> 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.

Why don't you wrap your kernel interface in a user-level wrapper
in libc that provides the Linux interface ? This is easily done,
and doesn't belong in Samba.

Remember, we're trying to *standardize* API's here, not
gratuitously proliferate them. If you want to do that,
join the Redmond API-of-the-month club.

Jeremy.