"Garrett D'Amore" <gdamore at sun.com> wrote:
> Joerg Schilling wrote:
> >
> >
> > If people ask questions that are answered in the man pages, it is obvious
> > to
> > point to the related man pages. If the issues beyond integrating star at all
> > are not forgotten again, I can live with a phased integration.
> >
>
> 1) If there are more detailed man pages here, then they are absent from
> the case materials. I shouldn't have to googling around to find out
> materials that are intrinsic to the case.
I don't know what's in the case material. The star project is documented.
If you like to discuss documentation, fetch the related documentation first.
Recent star documentation is in the star source tree
ftp://ftp.berlios.de/pub/star/alpha/
>From time to time, there is a update in the web man pages at:
http://cdrecord.berlios.de/private/man/star/
BTW: the function you have been asking for is a function that only exists to
the benefit of ufsdump and it seems to be intentionally undocumented by Sun,
it is however documented in the man pages that come with librmt. See e.g.
http://cdrecord.berlios.de/private/man/star/rmtinit.3.html
> 2) The above paragraph conveys a message that you expect someone
> (PSARC?) to drive forward with making libshily (or whatever it is
> called) public. If you want to do that, then *you* (or some project
> team you might be working with) needs to do that. PSARC doesn't
> normally start new cases on its own -- a project team has to start the
> process. You can't hold the ARC hostage to your future demands, and you
> can't expect it to do work that you should be taking on yourself.
PSARC 2004/480 already coveres most of the changes. I believe we only need to
refresh things.
> 3) I'm a bit unhappy with the term "phased integration". While the
> integration may be phased, what I'm most concerned with is the review
> process. "phased review" might be a better term. More simply, I don't
> think we are talking about this case offering any review (and thus no
> opinion nor precedent) as to the integration (or lack thereof) of this
> "portability" layer.
The problem with the current rules (avoid to put new code into ON) is that it
requires a "phased integration".
If you like to compile code that depends on other code that is not located in
the same consolidation, you first need to make the dependencies available.
BTW: I would prefer to see a self contained ON source.
> 3) That said, are we in agreement that this case is just about star and
> rmt for now, and that if you want to do /usr/include/schily (or
> whatever) you will need to come back to ARC with a case for that?
See above, if you like to let ufsdump use librmt, then the current rules require
two additional PSARC cases and code integration phases:
1) Add /usr/include/schily/ and /usr/lib/librmt.so to SXCE to allow
future compilation of ON with enhanced code.
2) Enhance the code in ON to let ufsdump/ufsrestore/mt use the new
interfaces.
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
