Nicolas Williams wrote:
> On Wed, Aug 20, 2008 at 01:11:27PM -0400, James Carlson wrote:
>
>> Darren J Moffat writes:
>>
>>> Given all the above this case should be marked as withdrawn sine nothing
>>> in the case is valid for the new proposal. A new case for delivering top
>>> should be started.
>>>
>> What would be the point of that? I think reusing the same case (and
>> providing a more up-to-date synopsis) would be the better answer.
>>
>
> It's probably useful, though marginally so, to look at case summaries
> and see that "prstat utility enhancements to look and act more like top"
> was withdrawn and shortly after a case was submitted and approved for
> "top for OpenSolaris." Is that sufficiently useful to warrant withdrawing and
> submitting a new case?
>
> Dunno, but if not the IAM does need to be updated so the case shows up
> as "top for OpenSolaris" instead of "prstat utility enhancements to look
> and act more like top."
>
> Nico
>
Okay, so while providing (shipping) unix top seems at first blush not a
bad idea, there is one significant hiccup. FOSS top (the last time I
looked) grunges around in kmem, making use of uncommitted and
undocumented APIs, structures, etc.. (Possibly this has changed, but I
sort of doubt it.)
So, *particularly* given its distribution in another consolidation, I
think the project team needs to either:
a) document and get contracts for any non-public APIs, structures, or
such that it uses
or
b) convert the backend data collection in top to use
documented/stable/committed APIs (/proc, dtrace, or whatever.)
Just "shipping" top is probably not (IMO) less work than enhancing
prstat; its certainly not a simple slam dunk as some on this list have
asserted.
Another significant thing that must be documented with top is any
security implications. I believe top is normally installed sgid or suid
so it can access /dev/kmem. There are also issues with some of the
actions it can perform (killing, renicing processes) -- how, if at all,
are such actions audited, etc. (Does top yield privileges after
attaching to kmem? There might also be concerns about interaction with
least privilege awareness -- I've not studied this problem enough to
know for sure.) While its likely that on a single user desktop these
considerations are not important, the situation is very different in a
multi-user (possibly multi-zone) enterprise environment.
As a final note: I don't think we should care about the precise
presentation format of data -- the fact that there are multiple
implementations of top, each of which presents somewhat different
output, means that we can probably safely not worry too much about that
(basic usability considerations aside). Nobody should be parsing output
from top on any system. (This might make conversion of prstat to
support top-like features more attractive/easier than updating top to
deal with the considerations I've raised above. I'm not sure.)
-- Garrett
