"Garrett D'Amore" <gdamore at sun.com> wrote:
> > What "GNU software" does is basically to follow the documentation for
> > "autoconf". This is: "take this code fragment and copy it into your source".
> >
> > What /usr/include/schily/ and /usr/include/ast do is to put the portability
> > code _once_ into a central location instead.
> >
>
> Okay. But that isn't what we've been asked to review. What we've been
> asked to review is a couple of utility programs and a supporting
> library. Creating a portability layer and exposing that to the rest of
> ON was not part of the case materials.
Well, I remember that a similar case (made for ksh93 integration) did already
add such a portability layer although (using the same rules as for star) the
ksh93 case needs those files only for private interfaces.
The star integration adds more than private interfaces, note that librmt is
supposed to be used by ufsdump/ufsrestore too.....
> > /usr/include/schily/utypes.h
> > /usr/include/schily/param.h
> >
>
> The case before ARC at the moment makes no mention of any of these other
> headers.
I don't know why.
> I suppose one could argue that they are an implementation detail. But I
> feel like we (the ARC) have not been presented with the full picture.
See above, it they are an implementation detail, then /usr/include/ast/ does
not belong into Solaris for the same reason.
> > Try to explain why there is /usr/include/ast/, maybe this helps you to
> > understand the "problem".
> >
>
> No, not really. If you want to create a new portability layer, then
> please propose a new case. This case is about the rmt and star
> application programs, and the supporting librmt.
This is not a new portability layer. It is in use since more than 15 years.
> Going through the case materials further, I'm pretty unhappy about the
> paucity of documentation in librtmt(3). It contains references to
> things like rmtinit(), but no actual documentation -- not even a
> function prototype. This is insufficient information for ARC to
> properly review these APIs, nor for developers to use them.
If you like to discuss the internals of librmt, I would encourage you to first
read the man pages...
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
