Fw: Re: Implemented OPLOCK for FreeBsd

[Andrew Tridgell]

> After all, as an engineer, you _do_ want to write well-designed and implemented
> portable code, yes?  The same concept applies to supporting multiple
> architectures in an operating system to ensure your machine independent code is
> truly MI.  Well, you have an oplock abstraction, so your oplock using code
> should be oplock implementation independent.

yep, we thought of that, and we in fact do have an abstract oplock
support layer in Samba, currently with support for two different
implementations (the one that IRIX uses and the one that Linux uses).

Personally I don't see a big problem with adding a 3rd which is kqueue
based. The kqueue design looks quite sane to me and potentially more
flexible than realtime signals. It also seems to avoid the inherent
race condition of combining signals with select (which we work around
in Samba using a rather ugly technique).

I haven't looked at the oplock/kqueue patch though, so there could be
ugly stuff under the covers that I don't know about yet.

Another thing to consider is the directory notification interface that
we added to Linux at the same time that we added kernel oplock
(ie. lease) support. See Documentation/dnotify.txt in the Linux kernel
sources for details, but basically this is another async notification
system that is needed by Samba and potentially widely applicable to
other applications. dnotify could easily generate far more events per
second than leases are likely to so performance issues are more
important.

dnotify also uses real time signals in Linux and could potentially use
kqueue on *BSD. Before deciding if you want to implement real time
signals you should probably look at dnotify and see if there is
anything in there that would be troublesome for kqueue.

Cheers, Tridge