Adam Mallory <amallory@qnx.com> wrote:
Whoa - I never suggested anything of the sort. There is no end to the
number of people that ask for “function x” for pidin, just because sin did
it, regardless of it relevance in Neutrino. In addition, Xtang made a
“tongue in cheek” remard about ‘sin vc’ - so for the sake of others reading,
I just mentioned that some features where not relevant.
Actually, I didn’t think it was “tongue in cheek”. Obviously, the
literal meaning of “sin vc” could NOT make sense. But the metaphoric –
the ability to get a list of who has remote connections to your node,
and to which node(s) you have remote connections, and who/which processes
have them is quite useful.
Actually you can find out what IRQ’s are in use based on the events emitted;
further you could even find out which IRQ events are causing scheduling
events so another process to can run. Open files are the same idea (events
emitted from Proc) - if you prefer the way sin did it, that’s fine.
So, we ask for the functionality because it was useful to us, not simply
because “QNX4 had it”.
I was simply saying that if the same functionaly existed in different form,
I think we should concentrate on getting new and/or improved features
instead of duplicating what is already there.
Sure, you could do this with the instrumented kernel, by looking for
all those events…if that happens to be the best way to implement
“sin irq” or “pidin irq”, then doing it by filtering the system
event logs could do it. Part of the problem, though, is digestibility –
if I have to pull up a GUI log of all the system events, to get what
“sin irq” gave me in a quick, convenient format, that isn’t nearly
as helpful.
I think I commented on this way earlier – I gave a few of the
summary/info things from sin that I wanted to see. I didn’t
ask for “sin ldt”, “sin gdt” or “sin idt”, because I never
knew how to use them anyway, and I don’t think they have meaning
anymore either – they were x86 only, and I don’t think we
implement even our x86 vm in a way in which those would be
meaningful under QNX6.
My high-runner list happens to be: irq, rt, ve, fi
(A “sin fd” does seem to exist already, otherwise it would also
be on the list.)
Something not in sin, and which I don’t think there seems to be
anyway to list, but might be useful: some way to get a list of
channels in a process, along with the channel flags set on that
channel. (This somewhat parallels the “sin fl” of QNX4, in that
much of what used to be a process flag under QNX4 has become a
channel flag under QNX6. Of course, given the previous mention
of the idea that under QNX4 pid,pid = QNX6 pid,chid, this is not
entirely surprising.)
“sin na” becomes “ls /dev/name/local”
“sin gn” will become “ls /dev/name/global”
“sin net” becomes “ls /net” (kind of)
“sin pr” is a bit more interesting. The idea of a proxy is totally
lost under QNX6 – there is no real idea of an independent OS resource
like a proxies – pulses don’t have this create/destroy type of life
cycle. But, what was also really nice about “sin pr” was to see the
count of the proxy, that is, to see if a process was missing/not keeping
up with the incoming proxies. The ability to get a list/count of
queued pulses for a channel would be quite handy.
“sin root”, and “sin dir” I’ve never used. (gives prefix root,
and cwd, for each process.) Could be helpful, but probably not important.
“sin se” I’ve used occasionally – list of sessions, not high-runner,
“sin tree” is a pretty version of “sin fa” → pidin fa
My (highly inflated) 2 cents analysis of “everything sin does”.
Hm… having some of the stuff in sin, and some of it in pidin
under Neutrino is a bit annoying. (And, sin not putting column
headings on anything…)
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.