[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ha-dev
Subject:    Re: [Linux-ha-dev] uuid and e2fsprogs
From:       David Lee <t.d.lee () durham ! ac ! uk>
Date:       2004-11-15 17:44:14
Message-ID: Pine.GSO.4.58.0411151658350.9800 () arachne ! dur ! ac ! uk
[Download RAW message or body]

On Fri, 12 Nov 2004, David Lee wrote:

> On Thu, 11 Nov 2004, Alan Robertson wrote:
>
> > [...]
> > I also think this sounds good.  I had been after Gouchun to look at
> > restructuring (and layering) the way we use uuids, probably by
> > encapsulating the uuid array inside of a structure, so that a uuid becomes
> > a full-fledged normal type to the 'C' compiler.
> >
> > These two ideas seem to fit together - hiding the interface more, changing
> > the type definition, and making it compatible with both uuid packages.
>
> Thanks.  Glad you like it.  I'll push ahead with tidying it up.
>
> To clarify and/or confirm: I think this is a two-level thing:
>
> 1. My level (lower) is, in effect, providing a structure which allows
> the e2fsprogs interface to be emulated on systems where the e2fsprogs
> implementation is, for whatever reason, lacking.
>
> (a) with e2fsprogs: as now: except that the compile-time "include" path
>     takes a tiny diversion to reach its <uuid/uuid.h>;
> (b) with OSSP: compile-time mimic of e2fsprogs interface: run-time
>     diversion of e2fsprogs interface into emulation layer onto OSSP;
> (c) other implementations can be slotted in as per OSSP;
> (d) pathological(!): someone could code up their own uuid implementation
>     and slot it in as yet another emulation of that interface.
>
> 2. Gouchun working at a higher level, needing no knowledge at all of
>    which implementation is in use, to achieve the aims you state.


Further to my message above ...  I've hit a snag: it seems I didn't do my
homework too well.  Oh dear.

The "e2fsprogs" progs interface, which seems very common (probably
including native Solaris 9 (but almost undocumented) and the yet-to-come
Solaris 10), deals directly with arguments of type "uuid_t".  (It seems
"uuid_t" is an array of the raw 16-byte uuid.)  So functions such as
"uuid_compare()" are, in effect, handing this raw data back and forth.

But OSSP arguments are of the form "pointer to uuid_t".  And the thing
being pointed to is not the raw 16-byte uuid.  Rather we (as the client of
the uuid library) are to regard it as an opaque type.  Functions such as
"uuid_compare()" operate on such "pointer to opaque" things.

So we cannot easily map the "e2fsprogs" interface onto the OSSP one,
because we have lost information on return from the uuid creation
operation.  It would, in theory, be possible in our "uuid_compare()"
emulation to re-create new abstract objects each time from the raw 16-byte
data, but this could be ponderous and inefficient.

I think our choices are:

1. Do an optional full replacement of uuid functionality along the lines
of the material already in our "replace" directory, either:
 (a) our coding;
 (b) copying the "e2fsprogs" code (which seems to be GPL).

2. Abandon systems which don't have e2fsprogs uuid.  Naturally, I don't
   like this idea, as no current version of Solaris has a documented
   uuid (and what about HPUX, AIX, ...?);

3. Get heartbeat to use a slightly higher level abstraction onto uuid
   functionality.

If we pursue option (3), I think this could simply be an internal
interface that looks rather like that of "e2fsprogs", but:
1. Arguments are "pointer to opaque type" (e.g. *uuid_t);
2. Add a "_destroy()" function call for completeness, to free the memory
   allocated by our new version of "_generate()";
3. The code that handles native uuid_t on the wire might need some
   attention (at a cursory grep-and-glance: "lib/clplumbing/cl_msg.c"
   etc.).

Where should this live?  I see we already have an empty "lib/uuid"
directory.

What should our function calls and types be?  ("hb_uuid_generate()" and
"hb_uuid_t"?)  I see Alan has already (Oct 18th) talked about a
"cl_uuid_t" (what does "cl" mean?).  But I would be proposing something
like a "void *" (crucially its level of pointer indirection) from the
perspective of the main code and only getting into the messy business of
mapping it closer to the system-variant "uuid_t" within our little
interface library.

For more info on OSSP uuid interface see:
   http://www.ossp.org/man/man.cgi/pkg/lib/uuid/uuid.pod

(Note, too, that the OSSP interface seems to offer a much greater range of
error-checking than the "e2fs" one.)


How does that seem?  (Is there any further homework I have overlooked??)

-- 

:  David Lee                                I.T. Service          :
:  Senior Systems Programmer                Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 334 2752                  U.K.                  :
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
[prev in list] [next in list] [prev in thread] [next in thread]