Alan Burlison wrote:
> Garrett D'Amore wrote:
>
>> Probably, but you'd sacrifice some functionality that there is no good
>> reason to sacrifice, and which would likely be missed even in a
>> minimized install:
>>
>> 1) command line kstat access (formerly we had netstat -k, but that was
>> removed)
>
> Because it wasn't kept up to date with the kernel as the kstats
> changed, and bitrot was rampant - see my previous mail.
This makes no sense to me. Its easy to iterate over all the stats and
dump them. The only time you have to change the code is when adding new
kstat types. (E.g. KSTAT_TYPE_INTR, etc.) This has only happened twice
since Solaris 2.5 that I'm aware of ... once to add 64-bit values, and
once again to provide a cleaner way to represent strings in kstats.
Dumping all stats doesn't require some massive table of information in
the program. Indeed, kstat(1M) demonstrates this. (And netstat's -k
flag just iterated over all named kstats as well; it didn't have any
particular information about different stats. The whole implementation
of of that bit of code in netstat was in k_report() and print_kn() ...
which was implemented in 72 lines and of C, at least in the Solaris 9
version (yes, I have access to Solaris 9 source).
I think the reason it was gutted from netstat was that it was generally
believed that netstat was the wrong place for generic kstat access, and
the kstat program provided a cleaner alternative. (And netstat -k was
never a documented flag.)
A much bigger problem in netstat was its use of particular
interpretation of kmem_cache states, etc. But those did
_interpretation_ of the data, which kstat has never offered.
>
>> 2) project management (projadd, etc.)
>> 3) psrinfo (which used to be a C program, but someone decided to rewrite
>> it into perl)
>> 4) lgrpinfo
>> 5) intrd
>>
>> I strongly fail to understand why any of these programs need perl. I
>> think at least part of the reason that some of these are provided in
>> perl is to take advantage of Solaris::Kstat. Maybe we need a friendlier
>> kstat access method from C? There is already libkstat.
>
> Because they were quicker to write, smaller in terms of source and
> easier to modify and, and therefore probably have fewer bugs as well.
> Go look at the number of bugs logged against /bin/kstat, for example,
> then compare it to any of the other *stat programs.
kstat is _new_ compared to all the other *stat programs, and it doesn't
do any signficant interpretation on the data. The bug count has very
little to do with the source language and much more to do with the kind
of data it provides. (See above.)
I could easily implement all of the kstat functionality except regular
expression/glob matches, in a similar number of lines of C, and the
result would be just as readable and maintainable. (Most of the meat in
kstat(1) is really in the Sun::Solaris::Kstat module. :-)
I've looked at psrinfo, and its straight-forward to do in C as well.
(Once upon a time it was in C.)
>From casual examination, I think this is true of the project managment
If you can't see that, then I suspect it may be a result of your
particular inclination towards perl, and not a natural result from the
languages themselves.
>
>> I wouldn't mind taking on rewriting any or all of the above components
>> into C. (The biggest challenge there will be to continue to support
>> kstat(1)'s use of Perl regular expressions.)
>
> If you feel that strongly, have at it. However I'm pretty sure there
> are other more important things that could more usefully be addressed.
> And as I've already said, your gripe about the size of perl is
> off-base anyway, /usr/perl5/5.8.4 includes all the pod and manpages,
> as well as all the unicode goop. And I've already pointed you at
> SUNWperl584core, but you seem to have developed a tin ear.
I hear you about perl584core, I haven't looked at it. (And I haven't
responded to this argument because of just that ... I've not had a
chance to examine it.)
Off the cuff, it does strike me that the very need for a separate
perl584core, as well as backwards compatibility 5.6.1 and 5.8.4 (and
previously 5.003, etc. ad naseum) demonstrates very well the problem
with deploying core applications written in perl. They don't work well
in constrained environments without creating _extra_ headaches
associated with maintaining separate versions of the runtime, and there
can be a complex runtime compatibility matrix between version of the
application and the run time used.
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
