Joerg Schilling wrote:
> "Garrett D'Amore" <gdamore at sun.com> wrote:
>
>
>> Hang on... that /etc/rmt symbolic link *already* exists. I don't think
>> we need to do anything here -- its already there:
>>
>
> /etc/rmt is part of the rmt protocol as established in 1981 on BSD.
> If you remove it, you need to call star:
>
> RMT=/path/to/server star ....
>
> if you like to use remote "tape" access.
> I am not sure whether software that does not use librmt is able to deal with
> this at all.
>
OK, thanks for the clarification. (I've already realized my error about
/etc/rmt being in the network protocol... too bad I guess.)
>
>
>> Maybe integration into ON is superior here. Particularly if there is a
>> belief that star might one day replace some other Solaris archiver
>> (pax?) (It does strike me as unfortunate that we have three commands
>> that serve the same basic purpose -- cpio, pax, and tar, with three
>> different source bases, at least one of which remains closed.)
>>
>
> Star is an integrated source for all three CLI interfaces and more.
> Star could replace the current binaries in future, but then I/we need to
> implement support for private extensions in the current OpenSolaris code.
>
As far as I'm concerned, if we can make star do all this, integrate well
into Solaris (and probably ON), then I'm all for going down this route.
As a question, what is your take on dealing with possible code forks
here? I.e. if Solaris needs/wants some change to the source code at
some point in the future, how happy will you be to accommodate such a
change, even if it is not necessarily best for the "portable" version of
the code? (I don't have anything specifically in mind, other than
perhaps the automatic configuration bits.)
Being in ON would mean, ultimately, that other people could be making
changes to the source, without a guarantee of the bits being pushed
"upstream" (though I would really hope any RTI advocate would be savvy
enough to ask that you were at least included in the code review -- I
know I would -- but there wouldn't be a *guarantee* that this would happen).
>
>
>> The other issue is that integration into ON (with its more stringent
>> delivery requirements) may be more work than the project team (whether
>> Ken, Joerg, or other parties) is willing to take on. However, doing the
>> work now might simplify future matters, such as making
>> ufsdump/ufsrestore librmt aware. (Hmm... its even possible, I suppose,
>> that at that point it might be possible to do *that* change with very
>> little, or even no, ARC case work... just using private APIs within ON.)
>>
>
> It would be sufficient to write Solaris (ON) specific makefiles for star and
> the rest of the code.
I've refrained from offering to do so in the past, but if ultimately
this becomes the major stumbling block, I'll volunteer to help out
here. As byzantine as ON's build system is, it has become mostly
familiar to me over the course of time. (Some of the library related
makefile stuff and CTF support in the kernel still seems like voodoo to
me, but I seem to be able to manage.)
> I would need some help for this and a bit more help on how
> the autoconfiguration stuff may be integrated. I currently believe it should
> be
> run at the same time as rpcgen(1) creates some files for /usr/include/.
>
My strong preference is to avoid use of autoconfiguration in ON if at
all possible. The reasons for this are:
1) autoconfiguration significantly increases compile times
2) autoconfiguration adds a layer of complexity that makes it harder
to support if you don't need portability (nothing in ON needs it)
3) autoconfiguration can hinder cross-platform portability (c.f. the
earlier cross-compilation dicussion)
However, I'm totally fine with the idea that the build process can take
certain source files which may not be in C, and massage them into
compilable C code -- provided that the results are not subject to change
depending on the machine used to do the compilation. I think this is
true for rpcgen, and I know it is true for other similar tools like lex
and yacc. (Other solutions exist as well, such as custom sed/awk/perl
scripts, use of m4 or cpp, etc. Care needs to be taken to avoid
depending on the development machine though.)
-- Garrett
