[cgl_discussion] Re: [OCF]draft 0.8 of the SAF Application Interface specification

[Joe DiMartino]

On Thu, 2003-01-09 at 11:05, David Brower wrote:
<<snip>>

> In 5.1.2, where it introduces the type, it says, "The file descriptor
> for select or poll".   It doesn't provide an API for doing the poll,
> so it makes the assumption that the user knows it's a FD and can do
> "the right thing"; but formally, the type should be opaque, with API
> provided functions to do the wait.  The assumption that an app has
> a way to wait is not valid, I do not believe.
> 
> Simlarly, the SASystemNotifierT lets you get a handle, but you can't
> do anything with it.  There are numberous HandleGet operations that
> all return different types, eg, the saSelectionObject, the 
> saSystemSyncronizatoinObject, the saSystemNotifierT, etc.  It is not
> promised that there is a common wait point for them all (which may
> be correct non-promise).  It really only holds together if one assumes
> they are FDs and one can use select/poll.
> 
> OCF is unapologeticly fd based, which is fine for what it
> is targeted to be.   CGL probably doesn't care either, and maybe
> SAF doesn't, because it is really only going to be used on UNIX
> variants and maybe Windows.  If so, it's may be a good idea to
> adopt that position and say so, allowing direct use of the OS
> primitives and types where appropriate.  eg, having explicit
> GetFD and GetWaitObject calls for the opaque handles.   It would
> still be a good idea to provide generic Wait APIs for the handles,
> in case the implmentor uses something for which the generic OS wait
> won't work (some shared memory thing for instance.)

The first two drafts and the most recent draft of the OCF event service
use an opaque object that can be converted into a file descriptor.  We
DO assume that the underlying OS has a mechanism similar to poll/select.

The latest draft abstracts away the need for both fd and select/poll for
one of the programming models.  In the other programming model, we were
confronted with the "mixing" problem you state two paragraphs below -
if we give an opaque object and abstract the wait mechanism, how will
most unix style apps (that use select/poll) combine their waits
efficiently.  It just didn't seem worth the effort since most of the
expected target OS's have select/poll anyway.


> > It is true that we didn't look at many OSes such as OS/390 to make sure 
> > that there is a way to map the abstract type on something reasonable but 
> > someone in our group checked that this could be easily mapped on NT 
> > (without using the POSIX emulation).
> 
> It probably works OK until you mix sockets with Objects, resulting
> in the need to mix waits.  The "mu" answer is wait for the different
> things in different threads.  This isn't really SAF's fault, but
> it is indicative of the problems in a unified "waitfor" API.

See comments above.  This was a motivating factor in having an interface
to convert from object-to-fd.


> > 
> > I would appreciate if you could point out the parts which are unnecessary 
> > complicated so that we can give it a try at simplifying them.
> 
> Well, OCF doesn't currently include checkpoint or DLM; that is what I meant
> as embellished features compared to OCF.    I don't think I ever said
> "unnecessary" (that being something I don't want to decide).   The existence
> of those features adds huge complexity.  Compare the thickness of the SAF
> 0.8 to the OCF stuff.  (Given that, the attempt to "simplfy" the DLM semantics
> struck me as ironic, leaving a partial DLM with no way for clients to portably 
> use other features, like lock conversion.)

I think it was understood, if not explicitly stated, that OCF would use
the openDLM in its full glory, complete with lock conversion and async
notification of blocked lock requests.  At least that was my plan.

Any attempt to water it down seems naive.  That must be another one of
those SAF things that the greater portion of us were not privy to.  None
of us non-SAF-members were able to track or contribute to the SAF APIs,
while SAF could freely monitor the OCF progress (or lack of it).

-- 
Joe DiMartino <joe at osdl.org>