Bill Caroselli (Q-TPS) wrote:
Actually I’ve used Dev.ditto like this. I didn’t know you could do it with
Dev.con too.
$ ls -l Dev.ditto
lrwxrwxrwx 1 root root 13 Apr 4 2001 Dev.ditto → /bin/Dev.ansi
$ ls -l Dev.con
lrwxrwxrwx 1 root root 13 Apr 4 2001 Dev.con → /bin/Dev.ansi
In effect, you are always “doing it” with Dev.con (Dev.ansi actually 
Rennie
“Werner Schweizer” <Werner.Schweizer@ch.mullermartini.com> wrote in message
news:aen87c$q2p$1@inn.qnx.com…
And this way you can watch whatever the user is typing on his console.
This makes telephone support much easier, some times.
Werner SchweizerSimply put, ditto is absolutely invaluable to diagnosing problems on a
remote system. It allow you to see what has already happened without
changing it (i.e. non-destructive).
Also, it does not require any new program be loaded on the system being
diagnosed. Many systems get into a state where they can’t load anything new
but there’s lots of useful information if you could just see the screens.
Several of my programs are constantly writing status information to a text
console that no one ever looks at just so that information is available IF
someone wants to look at it. I’ve always been disappointed that Dev.com
only had 10 consoles. I could have used 50. I would have each program have
it’s own status console.
Actually, ditto boiled down to
main()
{
console_open();
for(;
{
// wait for proxy
console_read();
// display data
}
}
Just give us back console_read() and we can write our own ditto.
As for all of that extra plumbing that was in the QNX4 dev.con, I’d like to
see it all back. i.e. 50 line mode and the QNX4 speed.
“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:aend52$7pd$1@nntp.qnx.com…
camz@passageway.com> > wrote in message news:aelkhp$i9p$> 5@inn.qnx.com> …
You’ve obviously never been in the position of supporting a system from
remote or you would never be asking this question.Considering that I was sysadmin for my university’s computer science
department for 2 years, I certainly have been in this situation and I can
understand the usefulness of ditto. I also understand that any remote
host
running qnet is wide open and to suggest that leaving qnet running on a
host
which is accessable from elsewhere is a viable solution to the remote
admin
situation is madness. A solution that I used in the past for remote
console
access was to have a modem hooked to a serial port and a console running
on
it. This also has it’s problems but you do what you have to do and try to
make it as secure as you can.The main situation I can see ditto being useful is in the development lab.
We have a lab full of targets that people in the building can access. If
they crash the machine, it’s handy for them to have a console so they
don’t
have to run into the lab to see what happened. Consider this however:
qnet, as of yet, does not function properly between machines of different
architecture. So, even if it were to exist, we can’t guarantee that it
would work anywhere other than x86 to x86.I know that this is something many people want. Rest assured that I’m not
filtering the suggestions and that ditto will be on the development list
that I submit. What I’m giving you is a little bit of the cost/benefit
analysis that this will have to go through for management approval. There
was a significant amount of plumbing in the qnx4 console driver for this
to
work. Apparantly the guts of ditto was all of about a dozen lines of code
since the heavy lifting was hidden behind the console interface. If it’s
going to be re-implemented for qnx6, then we’d better a) have a pretty
good
case for why we need it, b) at least an idea of how we’re going to
implement
it in a portable way and c) an estimate of just how much work b will be.cheers,
Kris
Cheers,
Camz.
“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:aenjhl$d6p$1@nntp.qnx.com…
“What level of security is expected?” Should it be safe to use over the
internet or strictly for internal use?I think you are missing the point. ditto is NOT a network or security
issue.
Give us the functionallity of the console-*() functions in QNX4 and we can
write ditto.
I would say that for a console_read() to work the user must have read
permission for that console. For console_write() to work the user must have
write permission for that console.
This is a case where you don’t need/want to think outside the box (the box
being the computer). If I can write() to a file, then I can just as easily
write() to that file remotely. The file doesn’t know or care where I am and
doesn’t need to. So remote ditto is just a natural consequence of remote
access + ditto.
“What are the likely situations that this will be used for?” We have the
situation of the lab and the tech support. Are there others?I’m sure there are others. I’m hoping that we can properly specify
exactly
what the problem is, which will allow us to properly specify the solution.
We may find that parts of ditto will not be required because other
mechanisms exist. So far, most usage scenarios that I’ve seen come down
to
“I want to see what is happening/has happened on the console” which is a
smaller problem to solve than the solution ditto provides. Perhaps a way
to
start devc-con with a certain cache size and then an interface to retrieve
that information would be sufficient.cheers,
Kris
“Adam Mallory” <amallory@qnx.com> wrote in message
news:aenama$5ka$1@nntp.qnx.com…
IMHO, limiting ones thinking to “this is the way it should be done”, is
just
that… limiting.Hi Adam,
I think that Kris’s original request was, “What are some of the QNX4
features that we need to add to QNX6?”
<camz@passageway.com> wrote in message news:aeniaa$4af$1@inn.qnx.com…
Adam Mallory <> amallory@qnx.com> > wrote:
I think it’s important to keep in mind that much of the QNX4 world was
based
on the “x86 assumption”. Ditto’ing a terminal from a different platform
isn’t as straight forward as you’d think. While I agree that the tool
was
useful, perhaps instead of replicating the old chain, advances should be
made to make better tools that incorporate similar functionality.I don’t think ANY of use really care if it was tied to x86 or not. It
provided
a useful function. As Mario points out it has uses where you used
Dev.ditto
to create a console for a system (embedded target) that might not have had
a real console at all. This is probably a scenario that is quite common
in
the “new world” that QNX6 exsits in. Not all non-x86 platforms have the
concept of a console. The concept of a console is very useful, and
appears
in many situations, both javascript and java virtual machines provide a
“console”. These are not related to the underlying hardware at all. The
concept of a “console” is 100% valid and useful.In QNX4 there were still issues of QNX terminal emulation vs. ANSI terminal
emulation.
The user knew that if they used different stuff it wouldn’t work right.
Thanks for all the great suggestions everyone. You made my homework much
easier.
Kris
“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:aedho6$q6o$1@nntp.qnx.com…
Attention QNX users.
I am compiling a wish-list for utilities development over the next 6
months
to a year. I’m mostly looking for things that existed in QNX4 but don’t
in
QNX6 but I’m also taking general utils feature requests.So, if there are any utilities you wish you had or enhanced functionality
to
existing utilities, now is the time to let me know so I can try to get
them
on the road map.cheers,
Kris
">
I think others have answered the above much as I would have, so let me put
approach matters from a slightly different perpective…I came to QNX4 from the MS camp (escaped perhaps8-) and I carry no
Unix/Linux baggage. What attracted me was a superb RTOS with the benefits
of
a Unix-like system but with a number of very POWERFUL and EASY-TO-USE
features that set QNX apart from the rest of the herd. In the main these
were -QNX native networking with name location, IPC and media independence.
Ditto
The Photon “Jump Gate”
The ability to run a single Photon desktop over multiple video cards
and/or
nodes.The point being that anybody with half a brain can produce stunning
results
very quickly by harnessing the power of these sort of facilities. OK, the
results are not portable and possibly not POSIX compliant, but who cares
when you can achieve (and usually exeed) your goal in half the time? I
have
managed to produce a number of (QNX4) networked products so far without
knowing the first thing about TCP/IP. I won’t start down the QNX6/QNet
rocky
road…QNX6 is a “me too” OS and QSSL seems to have lost sight of what made QNX4
so
understandable and attractive to non-Unix programmers. Any wrappers that
can
be placed around intricate features to hide the complexity are welcome to
me - Ditto being one such.Jim
I have to agree with Jim, QNX 6 is seems to have become more complex and
more difficult to do some of the seamliess things I was used to doing. My
biggest concern is that QNX’s message passing architecture is actually being
diminished in it importance. QNET does not match the functionality of
FLEET, and seems harder to use.
I don’t like this notion that seems to be permiating that we should just
use TCP/IP for all our stuff. I really dislikeTCPIP for embedded systems.
It makes no sense to me to use it after having been spoiled with FLEET on
QNX 4. I look at the S/R/R interface for QNX6 and I don’t understand why
somethings where done. (Channels for example) So I guess my point is, the
beauty of QNX was it making a network of QNX nodes into one virtual CPU.
I just finished writing a resource manager and there are some things about
it that bug me. I’m not sure I can articulate them yet, but I will be in a
the next few months as I play with it some more.
I don’t know if you want to call it syntax sugar, or what but, like Jim
said, QNX4 was easy and I’m finding road blocks and disapointments with QNX6
(GDB for exmaple I really liked watcom’s debugger in comparson. It seems
that GDB is a step back, not forward, the compile times with gcc are also
annoying). I was surprised when QNET was not offered from the start with
Neutrino, it made me wonder if the IPC architecture had been watered down
such that it wasn’t possible to do stuff like in the past.
Kris, in a post here you responded to Mario and asked “You left qnet running
on your machine in the field?”
I hope this was a sarcastic question or that I took it out of context. If
it wasn’t and I didn’t then you clearly don’t understand why at least I have
choosen to base my systems on QNX. It is exactly because I want to run QNET
in the field. It is this idea that machines can be hooked together to
create a fault tolerant, redundant and parallel system without the
clunkyness of a technology that is at least 2 decades old. In QNX 4 I was
able to debug over radio modems by using QNX’s native netowrking. Now I
have to install and configure TCIP./IP then PPP and all that garbage to do
the same thing, and its slower and uses more bandwidth thats lame! Qith
QNX4, could run my vehcile control system from any node. I know I still can
with QNX6, but it’s not as easy. I’m finding road blocks with QNX6 and they
surprise me when I come up against them. So far I’ve found ways around
them, but they initially strike me as uncecessary.
Look, I know things are still coming, Xiaodan has been working hard on QNET,
and he may be allowed to turn some features on that I personally have been
missing, and I know that there are other things in the works, but I hope the
main idea that at least I expect the same features from QNX4 to be present
is understood.
I think the ditto thing for me is that the idea that a QNX4 box could be
almost 100% controled from anywhere in the network was a consistant theme
througout the OS (utilities, API, etc). The same just isn’t true yet for
QNX6. We’re still missing stuff. Things like://4 some_binary was so cool
(ok, syntax surgar, but still the idea of a seamless multi cpu connected
with a network was demonstrated).
QNX has to be distinct from the other Unix like OS’s, you can’t conform and
expect to be noticed. There have to be things that give an aura of being
superior in most if not all areas, then people have to be educated on how
and why it is better so they understand. I like the idea that we can
compile other stuff on it and run it, but I don’t like the idea of making it
just like linux or unix. It can’t be just another clone. The ideas that
QNX expouses are good and benificial, they have to be kept and highlighted.
Using tcpip for everything is lame game.
Ok, thanks for letting me rant…I look forward to seeing many of the
suggestions made here make their way into some future offerings.
Best Regards,
Kevin
Kevin Stallard <kevin@ffflyingrobots.com> wrote:
[ Comments snipped ]
I don’t like this notion that seems to be permiating that we should just
use TCP/IP for all our stuff. I really dislikeTCPIP for embedded systems.
It makes no sense to me to use it after having been spoiled with FLEET on
QNX 4. I look at the S/R/R interface for QNX6 and I don’t understand why
somethings where done. (Channels for example) So I guess my point is, the
beauty of QNX was it making a network of QNX nodes into one virtual CPU.
I hate to drive this further off topic, but …
To clarify about channels …
With QNX6 you are now using real threads. While we could have gone
with the QNX4 approach of just wacking a message at a process, that
would have been rather limiting (Only a single message queue per
process, no clear way to define thread involvement with resources
for the purpose of priority inheritance etc). As a result the
communication channel had to be extracted/abstracted from the
process container. (just in the same way that QNX4 conveniently
tied them together to a pid (and nd), because you could only ever
have one).
So QNX4 you had:
node, pid, chid == pid so ignore the chid
Under QNX6 you have:
node, pid, chid
An on extensibility …
The QNX6 mechanism makes it possible in the future to have a pool
of threads which can service multiple channels rather than just one,
which in turn cuts down your overall resourcing. Not that we have
such a broadcast/multiple queue receive API in place right now, but
it is conceivable that you could. Under QNX4 it would have been
must more difficult.
[More comments snipped]
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Core OS Technology Group
(613)-591-0931 http://www.qnx.com/
Mritunjai <mritun@solitaire.hostel4.iitb.ac.in> wrote:
Hello folks
Sorry for my ignorance… but will it be too difficult for community to
make one if QSSL opens source to devc-con and devc-tcon ?IMHO, a simple design where devc-con opens a “clone” device (eg.
/dev/ttyp1.ditto for /dev/ttyp1) and clones the content of the tty to it
BUT sends the current buffer to the client on connection to it should
suffice. Then using a simple terminal emulation program eg. a
(modified ?) qtalk , one should be able to connect to any console she wants.
Heh, I just told Kris how one can do a ditto outside of dev-con
It won’t be perfect though.
No, you can’t “clone” a dev-con device, but you can have your
own res manager regist “/dev/con1” (with FLAG_BEFORE); So whoever
open("/dev/con1") your manager got the request, it then relay
the request to the “real” /dev/con1.
Then you use a buffer to remember (say last 8k) datas write to you,
and whoever “ditto” to /dev/con1 (which will open/devctl your manager),
you send back the buffer, and taking care the sharing.
The problem is strings write to a console may have ESC sequence, and
break a sequence could result garbige showing up on dittoer’s screen.
-xtang
Kevin Stallard <kevin@ffflyingrobots.com> wrote:
[snip]
It makes no sense to me to use it after having been spoiled with FLEET on
QNX 4. I look at the S/R/R interface for QNX6 and I don’t understand why
somethings where done. (Channels for example) So I guess my point is, the
beauty of QNX was it making a network of QNX nodes into one virtual CPU.
Channels were created because in QNX 4 communications was done on a
process ID to process ID basis; in QNX 6 you have threads, which are
ephemeral (misspelled $10 word), so you can’t just decide which thread
you want to talk to – you might want to have, for example, two pools
of threads that handle two different services, so hence the channel
was created to abstract that away…
I just finished writing a resource manager and there are some things about
it that bug me. I’m not sure I can articulate them yet, but I will be in a
the next few months as I play with it some more.
I’d be interested in hearing your articulations; to me a QNX 6 resmgr
is just that much simpler than a QNX 4 driver of the same functionality.
I don’t know if you want to call it syntax sugar, or what but, like Jim
said, QNX4 was easy and I’m finding road blocks and disapointments with QNX6
(GDB for exmaple I really liked watcom’s debugger in comparson. It seems
that GDB is a step back, not forward, the compile times with gcc are also
I haven’t noticed. The printf() debugger is still the same under QNX 6
as it was under QNX 4
annoying). I was surprised when QNET was not offered from the start with
Neutrino, it made me wonder if the IPC architecture had been watered down
such that it wasn’t possible to do stuff like in the past.
I think it was just a timing thing. They wanted to get QNET done right,
so instead of releasing it over and over again, they delayed it…
Kris, in a post here you responded to Mario and asked “You left qnet running
on your machine in the field?”
It currently has known security issues… and since it’s on top of IP,
it’s a lot more “visible” than FLEET was – consider the case of
a cablemodem (broadband) type of network, and you can see where having
your /net directory populated with the machine names of other QSSL
developers who live in your neighbourhood is, to say the least, interesting
I hope this was a sarcastic question or that I took it out of context. If
it wasn’t and I didn’t then you clearly don’t understand why at least I have
choosen to base my systems on QNX. It is exactly because I want to run QNET
in the field. It is this idea that machines can be hooked together to
create a fault tolerant, redundant and parallel system without the
clunkyness of a technology that is at least 2 decades old. In QNX 4 I was
able to debug over radio modems by using QNX’s native netowrking. Now I
have to install and configure TCIP./IP then PPP and all that garbage to do
the same thing, and its slower and uses more bandwidth thats lame! Qith
QNX4, could run my vehcile control system from any node. I know I still can
with QNX6, but it’s not as easy. I’m finding road blocks with QNX6 and they
surprise me when I come up against them. So far I’ve found ways around
them, but they initially strike me as uncecessary.
There’s nothing wrong with running QNET on a closed and secure
system; hopefully the security issues will be addressed Real Soon Now…
[snip]
QNX has to be distinct from the other Unix like OS’s, you can’t conform and
expect to be noticed. There have to be things that give an aura of being
superior in most if not all areas, then people have to be educated on how
and why it is better so they understand. I like the idea that we can
compile other stuff on it and run it, but I don’t like the idea of making it
just like linux or unix. It can’t be just another clone. The ideas that
QNX expouses are good and benificial, they have to be kept and highlighted.
Using tcpip for everything is lame game.
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
“Kevin Stallard” <kevin@ffflyingrobots.com> wrote in message
news:aenoof$8ki$1@inn.qnx.com…
Kris, in a post here you responded to Mario and asked “You left qnet
running
on your machine in the field?”I hope this was a sarcastic question or that I took it out of context. If
it wasn’t and I didn’t then you clearly don’t understand why at least I
have
choosen to base my systems on QNX. It is exactly because I want to run
QNET
in the field. It is this idea that machines can be hooked together to
create a fault tolerant, redundant and parallel system without the
clunkyness of a technology that is at least 2 decades old. In QNX 4 I was
able to debug over radio modems by using QNX’s native netowrking. Now I
have to install and configure TCIP./IP then PPP and all that garbage to do
the same thing, and its slower and uses more bandwidth thats lame! Qith
QNX4, could run my vehcile control system from any node. I know I still
can
with QNX6, but it’s not as easy. I’m finding road blocks with QNX6 and
they
surprise me when I come up against them. So far I’ve found ways around
them, but they initially strike me as uncecessary.
Actually, it was purely from a security standpoint. When I said it, I was a
picturing a network running qnet that was, in some way, accessable to the
public network. I absolutely agree that QNET (as FLEET was before) is a
good solution for networking if the system is isolated. The only reason I
have reservations is because more and more things are being hooked up to the
public networks (fridges and toasters on the internet anyone?)
cheers,
Kris
Want to pipe up with a counterpoint.
We chose QNX exactly because of its slavish adherence to POSIX. If QNX
was not POSIX, we wouldn’t have looked twice at it.
I don’t mind wrappers or whathaveyou for people who feel POSIX makes
things too hard, but please don’t “water down” the POSIX compliance. To
us, that’s the #1 priority. QNX has already distinguished itself
with it’s POSIX compliance; some say that “oh it’s just another
POSIX-based RTOS”, but if you look into this (as I have) you’ll see that
most of the OSs out there say they’re POSIX, and some of those (like
Linux) legitimately want to be POSIX, but there are few or none that
are POSIX, at least enough to implement robust, reliable environments
without a slew of non-standard hacks. QNX does it.
We need TCPIP; our entire system is predicated on it.
Watcom was probably nice for Intel folks, but they have no solution
whatever for non-Intel platforms, so we don’t care about them. And we’d
much rather have (and I’m sure QSSL agrees) a single toolkit that works
on all the platforms.
So, in all these ways QNX is getting it exactly right, IMO. Keep it up!
My concern: I hope we don’t see the all-too-common “GUI mindset” take
over at QSSL. I’ve seen far too many companies making good, useful
development tools virtually ruin their products by deciding they must
have fancy GUI interfaces: invariably they spend 85% of their time
trying to get the GUI working, debugging it, supporting it, etc. and
meanwhile the infinitely more useful command line interfaces are left to
languish and wither.
GUI: just say no!
These are my opinions—Nortel Networks takes no responsibility for them.
“Paul D. Smith” <pausmith@nortelnetworks.com> wrote in message
news:p5adpscvcf.fsf@lemming.engeast.baynetworks.com…
My concern: I hope we don’t see the all-too-common “GUI mindset” take
over at QSSL. I’ve seen far too many companies making good, useful
development tools virtually ruin their products by deciding they must
have fancy GUI interfaces: invariably they spend 85% of their time
trying to get the GUI working, debugging it, supporting it, etc. and
meanwhile the infinitely more useful command line interfaces are left to
languish and wither.
Well, if it’s of any reassurance, the gui is talking to the command line
tools so it’s in our best interest that the command line stuff is top notch.
Kris
<camz@passageway.com> wrote in message news:aeniaa$4af$1@inn.qnx.com…
Adam Mallory <> amallory@qnx.com> > wrote:
[…]
…While I agree that the tool [ditto] was
useful, perhaps instead of replicating the old chain, advances should be
made to make better tools that incorporate similar functionality.
The fundamental problem here is that QNX6 was hyped as being ‘bigger and
better’, but when we got our hands on it we found that a lot of the
convenience/time-saving features of QNX4 had been swept away. The various
discussion can be summarised as -
… As Mario points out it has uses where you used Dev.ditto
to create a console for a system (embedded target) that might not have had
a real console at all. This is probably a scenario that is quite common
in
the “new world” that QNX6 exsits in. Not all non-x86 platforms have the
concept of a console. The concept of a console is very useful, and
appears
in many situations, both javascript and java virtual machines provide a
“console”. These are not related to the underlying hardware at all. The
concept of a “console” is 100% valid and useful.
What it comes down to is we want to anthropomorphise the computer and give
it a ‘voice’ so that it (s/he?) can tell us what it is doing. It has to be
separate from the application GUI on the basis that this sort of commentary
is not intended for the user, and to date, the console is the best (only)
way we have of achieving this. Maybe we should be looking at speech
modules…?..
Jim
[…]
Kevin Stallard wrote:
Even with a thread pool, you have one receive() that passes work off to
other threads that then reply.
In the model I am interested in, each thread calls receive, but only one
thread calls receive at a time.
Having a receive in a thread (the main
thread) and then worker threads I don’t see how that would be limiting.
Lots easier to figure out who to send to…
The whole point is, who cares what thread does the work (all threads
travel through the same code) ? The process is capable of performing a
set of services, threads only enable it to do what it does
simultaneously (if you are on an SMP box).
Rennie
“Robert Krten” <nospam88@parse.com> wrote in message
news:aenslj$b06$1@inn.qnx.com…
There’s nothing wrong with running QNET on a closed and secure
system; hopefully the security issues will be addressed Real Soon Now…[snip]
QNX has to be distinct from the other Unix like OS’s, you can’t conform
and
expect to be noticed. There have to be things that give an aura of
being
superior in most if not all areas, then people have to be educated on
how
and why it is better so they understand. I like the idea that we can
compile other stuff on it and run it, but I don’t like the idea of
making it
just like linux or unix. It can’t be just another clone. The ideas
that
QNX expouses are good and benificial, they have to be kept and
highlighted.
Using tcpip for everything is lame game.TCP/IP is routable; FLEET wasn’t. Once security gets put into TCP/IP,
imagine the benefits of being able to “cd /net/australia/some_machine”
and have it “just work” instead of the QNX 4 method where you would have
required a specialized tunnel…
Thank you Robert. My fingers are sometimes faster than my brain and I
certainly didn’t mean anything negative. The security model for QNET is
improving daily with things like root-squashing etc. My concern was, like
the cable modem issue, for the possibility of inadvertant danger. I recall
someone saying once that a great compliment to a designer is when his
invention is used in ways in which he had never envisioned and the power of
‘cd /net/australia/some_machine’ is very seductive…especially to the tech
support guys.
Kris
%% “Kris Warkentin” <kewarken@qnx.com> writes:
kw> Well, if it’s of any reassurance, the gui is talking to the
kw> command line tools so it’s in our best interest that the command
kw> line stuff is top notch.
It’s some reassurance, but that in itself doesn’t guarantee that non-GUI
uses of the command line are still paid attention to… front-ends like
that tend to have very specific use patterns, and while those may be
very robust they may not be all that similar to what non-GUI users want.
I’m speaking in pure generalities here, so I’ll shut up now for lack of
concrete examples. But, we’ll be watching .
These are my opinions—Nortel Networks takes no responsibility for them.
“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:aenkho$5nq$1@inn.qnx.com…
“Werner Schweizer” <> Werner.Schweizer@ch.mullermartini.com> > wrote in
message
news:aen87c$q2p$> 1@inn.qnx.com> …And this way you can watch whatever the user is typing on his console.
This makes telephone support much easier, some times.
Werner SchweizerSimply put, ditto is absolutely invaluable to diagnosing problems on a
remote system. It allow you to see what has already happened without
changing it (i.e. non-destructive).Also, it does not require any new program be loaded on the system being
diagnosed. Many systems get into a state where they can’t load anything
new
but there’s lots of useful information if you could just see the screens.Several of my programs are constantly writing status information to a text
console that no one ever looks at just so that information is available IF
someone wants to look at it. I’ve always been disappointed that Dev.com
only had 10 consoles. I could have used 50. I would have each program
have
it’s own status console.
You can, just start another Dev.con and you can create another set of
10 consoles, which can only be view via ditto though I’ve seen system
with 30 consoles.
Xiaodan Tang <xtang@qnx.com> wrote:
| No, you can’t “clone” a dev-con device,
Well, since this would be internal to devc-con and just has two ways to
access the same device. The only difference is that after connecting to
tty*.ditto, the first thing you get is the buffer.
|but you can have your
| own res manager regist “/dev/con1” (with FLAG_BEFORE); So whoever
| open("/dev/con1") your manager got the request, it then relay
| the request to the “real” /dev/con1.
| Then you use a buffer to remember (say last 8k) datas write to you,
| and whoever “ditto” to /dev/con1 (which will open/devctl your manager),
| you send back the buffer, and taking care the sharing.
Simply Brilliant !!
A open to “real” /dev/con1 would require some quirks though. This can be
handled by using the approach that I used for process/IO accounting
support in libc.
| The problem is strings write to a console may have ESC sequence, and
| break a sequence could result garbige showing up on dittoer’s screen.
There can be two solutions to this problem -
–
Keep Smiling
Regards
http://www.me.iitb.ac.in/~mritun
http://mritun.qnx.org.ru
http://www.qnxzone.com/~mritun