Idea: "Universal Control Panel"

[Robert_Krten1]

How’s this for an off-the-wall product idea.

A universal control panel for software. What it does is it allows
you to modify variables through a controlled-access resource manager
in running programs.

Why? I’ve often had some kind of 24x7 server running and decided,
“ah crap, I need to turn on debugging for a while”. I really hate
the thought of having to restart the server with the -D flag, run
it for a bit, and then restart it again with out the -D flag.

So, here’s a set of API’s that I’m proposing to fix this.

In your server’s main(), you’d put something like:

main ()
{
// initialize your normal stuff here

control_panel_register (“servername”);
control_panel_register_variable (&debug_flag, “Debug Flag”);

// proceed with server stuff and the rest of your code
}

Then, from a command line or GUI, the “universal control panel” would
simply open “/dev/controlpanel/servername”, and get a list of variables
that are controllable. In this example, it would just come up with
a text string that sez “Debug Flag” and some id number.

From the universal control panel, I could then turn on the debug flag,
turn it off, examine it, etc.

There are a few details here that are of interest as well.

1. why not have every server do it its own way? (I think that question
   just answered itself)
2. how do we control access between the implicit resmgr thread and the
   regular server threads to the variables?
   Well, I thought about that, and there are a number of clever solutions:
   a) we don’t. If we “cripple” this idea to just accessing single
   char variables, there’s no issue with atomic operations.
   Even if we don’t limit it to just char variables, we can still
   do a “good enough” approach even without atomic operations.
   Certain operations can be coded to be non-atomic tolerant.
   b) we implement a set of macros that do mutex operations on the
   controlled variables, effectively providing a read/write
   interface. I don’t like the idea of anyone explicitly having
   to worry about the mutex functions, because that just leads to
   trouble, and makes this idea a lot more intrusive to the code
   to implement. I like the idea of just coding up the usual
   “if (debug_flag) { … }” kind of stuff.
3. for variables that come in and out of scope, there could be an
   “unregister” call as well, which would effectively remove that address
   from the control of the resmgr thread.
4. why can’t we do this with GDB or the /proc filesystem? You could do some
   of it, but certainly not the synchronizational aspects.

The true beauty in this scheme lies in the fact that I have one year to
patent it! Er, I mean, the true beauty in this scheme lies in the fact
that it’s not intrusive to the code; just a few lines up front in the
code. The control_panel_*() functions could even look at an environment
variable to allow them to “opt-out” in case of limited sizes on embedded
systems. And, it’s not just for servers – it can be quite useful for
long-running tasks that aren’t servers.

Thoughts?

Cheers,
-RK

–
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.

[Robert_Rutherford1]

We already do this (in a somewhat cruder way).

All our server processes accept a standard message which allows an external
process to easily change the server’s environment (and also triggers certain
processing based on such changes). For example if I want to turn on verbose
logging on an already running running server I just do:

$ setenv -P server_name “DEBUG_ALL=TRUE”

This is absolute life-saver at times. Your idea is a more general extension
of this. The main benefit I see from your concept is the ability to
determine at run-time the variables that are available for manipulation, and
to see their current value, rather than having to insepct the manual/source
to see what variables are available.

Go for it!

Of course the traditional Unix way of achieving the same (or similar) is
just to have your server re-read its configuration file on receipt of a
signal like SIGHUP.

Rob Rutherford

“Robert Krten” <nospam86@parse.com> wrote in message
news:ai78ke$ser$1@inn.qnx.com…

How’s this for an off-the-wall product idea.

A universal control panel for software. What it does is it allows
you to modify variables through a controlled-access resource manager
in running programs.

Why? I’ve often had some kind of 24x7 server running and decided,
“ah crap, I need to turn on debugging for a while”. I really hate
the thought of having to restart the server with the -D flag, run
it for a bit, and then restart it again with out the -D flag.

So, here’s a set of API’s that I’m proposing to fix this.

In your server’s main(), you’d put something like:

main ()
{
// initialize your normal stuff here

control_panel_register (“servername”);
control_panel_register_variable (&debug_flag, “Debug Flag”);

// proceed with server stuff and the rest of your code
}

Then, from a command line or GUI, the “universal control panel” would
simply open “/dev/controlpanel/servername”, and get a list of variables
that are controllable. In this example, it would just come up with
a text string that sez “Debug Flag” and some id number.

From the universal control panel, I could then turn on the debug flag,
turn it off, examine it, etc.

There are a few details here that are of interest as well.

1. why not have every server do it its own way? (I think that question
   just answered itself)
2. how do we control access between the implicit resmgr thread and the
   regular server threads to the variables?
   Well, I thought about that, and there are a number of clever solutions:
   a) we don’t. If we “cripple” this idea to just accessing single
   char variables, there’s no issue with atomic operations.
   Even if we don’t limit it to just char variables, we can still
   do a “good enough” approach even without atomic operations.
   Certain operations can be coded to be non-atomic tolerant.
   b) we implement a set of macros that do mutex operations on the
   controlled variables, effectively providing a read/write
   interface. I don’t like the idea of anyone explicitly having
   to worry about the mutex functions, because that just leads to
   trouble, and makes this idea a lot more intrusive to the code
   to implement. I like the idea of just coding up the usual
   “if (debug_flag) { … }” kind of stuff.
3. for variables that come in and out of scope, there could be an
   “unregister” call as well, which would effectively remove that address
   from the control of the resmgr thread.
4. why can’t we do this with GDB or the /proc filesystem? You could do
   some
   of it, but certainly not the synchronizational aspects.

The true beauty in this scheme lies in the fact that I have one year to
patent it! Er, I mean, the true beauty in this scheme lies in the fact
that it’s not intrusive to the code; just a few lines up front in the
code. The control_panel_*() functions could even look at an environment
variable to allow them to “opt-out” in case of limited sizes on embedded
systems. And, it’s not just for servers – it can be quite useful for
long-running tasks that aren’t servers.

Thoughts?

Cheers,
-RK

–
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.

[Robert_Krten1]

Robert Rutherford <ruzz@nospamplease.ruzz.com> wrote:

We already do this (in a somewhat cruder way).

All our server processes accept a standard message which allows an external
process to easily change the server’s environment (and also triggers certain
processing based on such changes). For example if I want to turn on verbose
logging on an already running running server I just do:

$ setenv -P server_name “DEBUG_ALL=TRUE”

This is absolute life-saver at times. Your idea is a more general extension
of this. The main benefit I see from your concept is the ability to
determine at run-time the variables that are available for manipulation, and
to see their current value, rather than having to insepct the manual/source
to see what variables are available.

Go for it!

Of course the traditional Unix way of achieving the same (or similar) is
just to have your server re-read its configuration file on receipt of a
signal like SIGHUP.

YUCK! I HAVE FREAKIN’ SIGNALS!!!

The main advantages, are like you said the runtime thing, but also the fact
that it could be standardized with a QSSL or community buy-in. This then
means that one control panel GUI or text-mode app can analyze any number
of QSSL and third-party products!

The other brainfart I had was to include a “timed monitor” aspect to it,
so that it could be used as a passive “front panel” to your application.
Imagine being able to have a GUI app that refreshes the values of various
variables at fixed intervals – packet counts, errors, number of frames
processed – whatever; it would be a good “insite” into the operation of
the utility.

I’m all over it, it’s my next project, I’ll include it in my next
upcoming “The QNX Neutrino Cookbook” book (he said, completely ignoring
the name “Momentics” again)

Anyone care to write the GUI part once I get the API finalized?
I’m thinking something with a tree-widget on one side to select
processes under /dev/controlpanel, and then a bunch of selectors for
the variables, including a right-click to set a monitoring period, etc.
Heck, it could even periodically log-to-disk

Cheers,
-RK

Rob Rutherford

“Robert Krten” <> nospam86@parse.com> > wrote in message
news:ai78ke$ser$> 1@inn.qnx.com> …
How’s this for an off-the-wall product idea.

A universal control panel for software. What it does is it allows
you to modify variables through a controlled-access resource manager
in running programs.

Why? I’ve often had some kind of 24x7 server running and decided,
“ah crap, I need to turn on debugging for a while”. I really hate
the thought of having to restart the server with the -D flag, run
it for a bit, and then restart it again with out the -D flag.

So, here’s a set of API’s that I’m proposing to fix this.

In your server’s main(), you’d put something like:

main ()
{
// initialize your normal stuff here

control_panel_register (“servername”);
control_panel_register_variable (&debug_flag, “Debug Flag”);

// proceed with server stuff and the rest of your code
}

Then, from a command line or GUI, the “universal control panel” would
simply open “/dev/controlpanel/servername”, and get a list of variables
that are controllable. In this example, it would just come up with
a text string that sez “Debug Flag” and some id number.

From the universal control panel, I could then turn on the debug flag,
turn it off, examine it, etc.

There are a few details here that are of interest as well.

1. why not have every server do it its own way? (I think that question
   just answered itself)
2. how do we control access between the implicit resmgr thread and the
   regular server threads to the variables?
   Well, I thought about that, and there are a number of clever solutions:
   a) we don’t. If we “cripple” this idea to just accessing single
   char variables, there’s no issue with atomic operations.
   Even if we don’t limit it to just char variables, we can still
   do a “good enough” approach even without atomic operations.
   Certain operations can be coded to be non-atomic tolerant.
   b) we implement a set of macros that do mutex operations on the
   controlled variables, effectively providing a read/write
   interface. I don’t like the idea of anyone explicitly having
   to worry about the mutex functions, because that just leads to
   trouble, and makes this idea a lot more intrusive to the code
   to implement. I like the idea of just coding up the usual
   “if (debug_flag) { … }” kind of stuff.
3. for variables that come in and out of scope, there could be an
   “unregister” call as well, which would effectively remove that address
   from the control of the resmgr thread.
4. why can’t we do this with GDB or the /proc filesystem? You could do
   some
   of it, but certainly not the synchronizational aspects.

The true beauty in this scheme lies in the fact that I have one year to
patent it! Er, I mean, the true beauty in this scheme lies in the fact
that it’s not intrusive to the code; just a few lines up front in the
code. The control_panel_*() functions could even look at an environment
variable to allow them to “opt-out” in case of limited sizes on embedded
systems. And, it’s not just for servers – it can be quite useful for
long-running tasks that aren’t servers.

Thoughts?

Cheers,
-RK

–
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.

–
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.

[system]

Robert Krten <nospam86@parse.com> wrote:

Why? I’ve often had some kind of 24x7 server running and decided,
“ah crap, I need to turn on debugging for a while”. I really hate
the thought of having to restart the server with the -D flag, run
it for a bit, and then restart it again with out the -D flag.

You could do this with devctl() as well, all you need to do is define
a standard structure for changing the variables, and possibly another
for querying them. There shouldn’t be any need for an extra resmgr
layer. Of course, that only works for programs that use the resmgr
framework and would be able to use this.

I think that the db server from the slinger project may already be
providing some of the framework you are after, although I have not
looked at the capabilities of this db server lately, it might bear a
review.

Cheers,
Camz.

[Xiaodan_Tang1]

You may want to look at “sysctl” (I thought it is BSDism).
QNX6 sysctl only implemented for “net.inet”, but it suppose
to be able to contral all “configuarable params” in things
like Filesystem, or VM.

Yes, I agree it needs a little extands (to take advantage
of message passing) to support “general servers”…

-xtang


Robert Krten <nospam86@parse.com> wrote:

How’s this for an off-the-wall product idea.

A universal control panel for software. What it does is it allows
you to modify variables through a controlled-access resource manager
in running programs.

Why? I’ve often had some kind of 24x7 server running and decided,
“ah crap, I need to turn on debugging for a while”. I really hate
the thought of having to restart the server with the -D flag, run
it for a bit, and then restart it again with out the -D flag.

So, here’s a set of API’s that I’m proposing to fix this.

In your server’s main(), you’d put something like:

main ()
{
// initialize your normal stuff here

control_panel_register (“servername”);
control_panel_register_variable (&debug_flag, “Debug Flag”);

// proceed with server stuff and the rest of your code
}

Then, from a command line or GUI, the “universal control panel” would
simply open “/dev/controlpanel/servername”, and get a list of variables
that are controllable. In this example, it would just come up with
a text string that sez “Debug Flag” and some id number.

From the universal control panel, I could then turn on the debug flag,
turn it off, examine it, etc.

There are a few details here that are of interest as well.

1. why not have every server do it its own way? (I think that question
   just answered itself)
2. how do we control access between the implicit resmgr thread and the
   regular server threads to the variables?
   Well, I thought about that, and there are a number of clever solutions:
   a) we don’t. If we “cripple” this idea to just accessing single
   char variables, there’s no issue with atomic operations.
   Even if we don’t limit it to just char variables, we can still
   do a “good enough” approach even without atomic operations.
   Certain operations can be coded to be non-atomic tolerant.
   b) we implement a set of macros that do mutex operations on the
   controlled variables, effectively providing a read/write
   interface. I don’t like the idea of anyone explicitly having
   to worry about the mutex functions, because that just leads to
   trouble, and makes this idea a lot more intrusive to the code
   to implement. I like the idea of just coding up the usual
   “if (debug_flag) { … }” kind of stuff.
3. for variables that come in and out of scope, there could be an
   “unregister” call as well, which would effectively remove that address
   from the control of the resmgr thread.
4. why can’t we do this with GDB or the /proc filesystem? You could do some
   of it, but certainly not the synchronizational aspects.

The true beauty in this scheme lies in the fact that I have one year to
patent it! Er, I mean, the true beauty in this scheme lies in the fact
that it’s not intrusive to the code; just a few lines up front in the
code. The control_panel_*() functions could even look at an environment
variable to allow them to “opt-out” in case of limited sizes on embedded
systems. And, it’s not just for servers – it can be quite useful for
long-running tasks that aren’t servers.

Thoughts?

Cheers,
-RK

[Robert_Krten1]

camz@passageway.com wrote:

Robert Krten <> nospam86@parse.com> > wrote:
Why? I’ve often had some kind of 24x7 server running and decided,
“ah crap, I need to turn on debugging for a while”. I really hate
the thought of having to restart the server with the -D flag, run
it for a bit, and then restart it again with out the -D flag.

You could do this with devctl() as well, all you need to do is define
a standard structure for changing the variables, and possibly another
for querying them. There shouldn’t be any need for an extra resmgr
layer. Of course, that only works for programs that use the resmgr
framework and would be able to use this.

Exactly. I like it for non-servers as well. That does bring about
an excellent suggestion though and that would be to standardize the
implementation of the API so that if you already are a server,
then you could just tie into the API instead of having a separate
thread. Although it brings into question the “how do we find the
damn thing”, because I was kinda counting on the /dev/controlpanel
thing for the namespace. Problems, problems…

I think that the db server from the slinger project may already be
providing some of the framework you are after, although I have not
looked at the capabilities of this db server lately, it might bear a
review.

I’ll hafta take a look, thanks for the lead!

Cheers,
-RK

–
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.

[Robert_Krten1]

Xiaodan Tang <xtang@qnx.com> wrote:

You may want to look at “sysctl” (I thought it is BSDism).
QNX6 sysctl only implemented for “net.inet”, but it suppose
to be able to contral all “configuarable params” in things
like Filesystem, or VM.

Yes, I agree it needs a little extands (to take advantage
of message passing) to support “general servers”…

I’ll look into that, thanks Xiaodan!

Cheers,
-RK

–
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.

[Rennie_Allen2]

Robert Krten wrote:

How’s this for an off-the-wall product idea.

A universal control panel for software. What it does is it allows
you to modify variables through a controlled-access resource manager
in running programs.

Useful idea, however, the fact that the writer of the product to be
controlled must be aware of the api, and incorporate it into their
program, makes it unlikely to be truly “universal”. I wrote an almost
“universal control panel” for QNX4/Photon using the qnx_debug() interface.
With it I could attach to a program, get a list of symbols, and
read/write a variable (the requirement was that the executable have symbol
information). Basically a debugger that doesn’t halt the program, and
with a limited interface (read/write variables). No special code required
in the target program. It was almost universal, since it still required
that symbol information be present, and controllable variables had to be
global static (never-the-less I found it very handy).

For the product I currently work on we use the signal approach (which I
dislike as much as you do - wasn’t my idea).

Anyway, bottom line is I like the idea, but it would only be highly
successful if QSSL promoted it (and had it in the docs). Of course, a
nice little Photon app (available in a default installation under
“utilities”), that allowed you to get an “inventory” of controllable
symbols would be mandatory.

[Bill_Caroselli_Q-TPS]

“Robert Krten” <nospam86@parse.com> wrote in message
news:ai7dkq$2ka$1@inn.qnx.com…

YUCK! I HAVE FREAKIN’ SIGNALS!!! >

Gee Robert. I assume that was supposed to be HATE signals.

Signals are a pain in the left butt cheek to set up, but once you’ve done it
in one program that’s what cut_and_paste is for.

Hey, I just noticed that you don’t even really mention how to use signals in
you Neutrino book. It ain’t that hard! And it’s not like you can ignore
their existence either. Too many outside factors generate them to
completely ignore them. Unless your willing to just die.

[Thomas_Emberso]

“Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:

“Robert Krten” <> nospam86@parse.com> > wrote in message
news:ai7dkq$2ka$> 1@inn.qnx.com> …

YUCK! I HAVE FREAKIN’ SIGNALS!!! >

Gee Robert. I assume that was supposed to be HATE signals.

Yeah, that would be Rennie who can say he has Freakin’ signals


regards,
Tom

[Robert_Krten1]

“Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:

“Robert Krten” <> nospam86@parse.com> > wrote in message
news:ai7dkq$2ka$> 1@inn.qnx.com> …

YUCK! I HAVE FREAKIN’ SIGNALS!!! >

Gee Robert. I assume that was supposed to be HATE signals.

D’oh! See? I was so enraged with the idea of signals I lost the ability to spell!

(Signal rage!)

Signals are a pain in the left butt cheek to set up, but once you’ve done it
in one program that’s what cut_and_paste is for.

Hey, I just noticed that you don’t even really mention how to use signals in
you Neutrino book. It ain’t that hard! And it’s not like you can ignore
their existence either. Too many outside factors generate them to
completely ignore them. Unless your willing to just die.

That’s true, signals were left out in an effort to discourage their use
The way I generally handle signals (if I have to, i.e., I’m not just willing to die)
is to disable them and periodically poll for the ones I’m interested in (like ^C).

This has worked for me in the past, and I haven’t really seen a need to change
that thinking. Now, I’m sure there are signal nazi’s out there who use them up
the ying yang. But “no signals for me”!

Cheers,
-RK

–
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.

[Steve_Reid1]

Robert Krten <nospam86@parse.com> wrote:
: D’oh! See? I was so enraged with the idea of signals I lost the ability to spell!

Don’t worry about it – it seems to happen to a lot of developers.

---

Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

[system]

“Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:

YUCK! I HATE FREAKIN’ SIGNALS!!! >

Signals are a pain in the left butt cheek to set up, but once you’ve done it
in one program that’s what cut_and_paste is for.

It’s the asyncronous nature of signals that makes them so undesireable.

Hey, I just noticed that you don’t even really mention how to use signals in
you Neutrino book.

I seem to recall that in Neutrino there was some way to tell the kernel that
you wanted your signals delivered as pulses instead of their normal async
manner. If that’s true, then there IS a way to use them without the pain
of the whole async mess.

Cheers,
Camz.

[Robert_Krten1]

camz@passageway.com wrote:

“Bill Caroselli (Q-TPS)” <> QTPS@earthlink.net> > wrote:
YUCK! I HATE FREAKIN’ SIGNALS!!! >

Signals are a pain in the left butt cheek to set up, but once you’ve done it
in one program that’s what cut_and_paste is for.

It’s the asyncronous nature of signals that makes them so undesireable.

Hey, I just noticed that you don’t even really mention how to use signals in
you Neutrino book.

I seem to recall that in Neutrino there was some way to tell the kernel that
you wanted your signals delivered as pulses instead of their normal async
manner. If that’s true, then there IS a way to use them without the pain
of the whole async mess.

Nope, not that I’m aware of. The solution is easy though – block off all signals
in all your threads, and create a thread that converts signals to pulses

Cheers,
-RK

–
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.

[Peter_Weber1]

Hi Robert,
we use such an aproach for our processes. The GUI is like a tree with all
processes as the root item, in each process you see groups of variables and
in each group the variable itself
which you can manipulate, record, log etc. We use the Quark realtime server
which is a pool of time
stamped variables for all communicating processes.
We can reload config files, restart the process w/o reload or switching
options on and off.
It is a little more than only ‘remote control’ of processes, we have full
sight into the whole process data.
see att. picture (sorry for using an attachment in news groups:-)
cheers, Peter

“Robert Krten” <nospam86@parse.com> schrieb im Newsbeitrag
news:ai7dkq$2ka$1@inn.qnx.com…

Robert Rutherford <> ruzz@nospamplease.ruzz.com> > wrote:
We already do this (in a somewhat cruder way).

All our server processes accept a standard message which allows an
external
process to easily change the server’s environment (and also triggers
certain
processing based on such changes). For example if I want to turn on
verbose
logging on an already running running server I just do:

$ setenv -P server_name “DEBUG_ALL=TRUE”

This is absolute life-saver at times. Your idea is a more general
extension
of this. The main benefit I see from your concept is the ability to
determine at run-time the variables that are available for manipulation,
and
to see their current value, rather than having to insepct the
manual/source
to see what variables are available.

Go for it!

Of course the traditional Unix way of achieving the same (or similar) is
just to have your server re-read its configuration file on receipt of a
signal like SIGHUP.

YUCK! I HAVE FREAKIN’ SIGNALS!!! >

The main advantages, are like you said the runtime thing, but also the
fact
that it could be standardized with a QSSL or community buy-in. This then
means that one control panel GUI or text-mode app can analyze any number

of QSSL and third-party products!

The other brainfart I had was to include a “timed monitor” aspect to it,
so that it could be used as a passive “front panel” to your application.
Imagine being able to have a GUI app that refreshes the values of various
variables at fixed intervals – packet counts, errors, number of frames
processed – whatever; it would be a good “insite” into the operation of
the utility.

I’m all over it, it’s my next project, I’ll include it in my next
upcoming “The QNX Neutrino Cookbook” book (he said, completely ignoring
the name “Momentics” again) >

Anyone care to write the GUI part once I get the API finalized?
I’m thinking something with a tree-widget on one side to select
processes under /dev/controlpanel, and then a bunch of selectors for
the variables, including a right-click to set a monitoring period, etc.
Heck, it could even periodically log-to-disk >

Cheers,
-RK


Rob Rutherford

“Robert Krten” <> nospam86@parse.com> > wrote in message
news:ai78ke$ser$> 1@inn.qnx.com> …
How’s this for an off-the-wall product idea.

A universal control panel for software. What it does is it allows
you to modify variables through a controlled-access resource manager
in running programs.

Why? I’ve often had some kind of 24x7 server running and decided,
“ah crap, I need to turn on debugging for a while”. I really hate
the thought of having to restart the server with the -D flag, run
it for a bit, and then restart it again with out the -D flag.

So, here’s a set of API’s that I’m proposing to fix this.

In your server’s main(), you’d put something like:

main ()
{
// initialize your normal stuff here

control_panel_register (“servername”);
control_panel_register_variable (&debug_flag, “Debug Flag”);

// proceed with server stuff and the rest of your code
}

Then, from a command line or GUI, the “universal control panel” would
simply open “/dev/controlpanel/servername”, and get a list of variables
that are controllable. In this example, it would just come up with
a text string that sez “Debug Flag” and some id number.

From the universal control panel, I could then turn on the debug flag,
turn it off, examine it, etc.

There are a few details here that are of interest as well.

1. why not have every server do it its own way? (I think that question
   just answered itself)
2. how do we control access between the implicit resmgr thread and the
   regular server threads to the variables?
   Well, I thought about that, and there are a number of clever
   solutions:
   a) we don’t. If we “cripple” this idea to just accessing single
   char variables, there’s no issue with atomic operations.
   Even if we don’t limit it to just char variables, we can still
   do a “good enough” approach even without atomic operations.
   Certain operations can be coded to be non-atomic tolerant.
   b) we implement a set of macros that do mutex operations on the
   controlled variables, effectively providing a read/write
   interface. I don’t like the idea of anyone explicitly having
   to worry about the mutex functions, because that just leads to
   trouble, and makes this idea a lot more intrusive to the code
   to implement. I like the idea of just coding up the usual
   “if (debug_flag) { … }” kind of stuff.
3. for variables that come in and out of scope, there could be an
   “unregister” call as well, which would effectively remove that
   address
   from the control of the resmgr thread.
4. why can’t we do this with GDB or the /proc filesystem? You could do
   some
   of it, but certainly not the synchronizational aspects.

The true beauty in this scheme lies in the fact that I have one year to
patent it! Er, I mean, the true beauty in this scheme lies in the fact
that it’s not intrusive to the code; just a few lines up front in the
code. The control_panel_*() functions could even look at an
environment
variable to allow them to “opt-out” in case of limited sizes on
embedded
systems. And, it’s not just for servers – it can be quite useful
for
long-running tasks that aren’t servers.

Thoughts?

Cheers,
-RK

–
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.


\

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.

[Robert_Krten1]

Peter Weber <pw@dolphin.de> wrote:

This is a multi-part message in MIME format.

Hi Robert,
we use such an aproach for our processes. The GUI is like a tree with all
processes as the root item, in each process you see groups of variables and
in each group the variable itself
which you can manipulate, record, log etc. We use the Quark realtime server
which is a pool of time
stamped variables for all communicating processes.
We can reload config files, restart the process w/o reload or switching
options on and off.
It is a little more than only ‘remote control’ of processes, we have full
sight into the whole process data.
see att. picture (sorry for using an attachment in news groups:-)
cheers, Peter

Interesting. Looks more like a “process control” (as in “industrial control”)
kind of application, no?

But yes, definitely a nice product. The usual, how much is it, where do you
buy it, etc…

–
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.

[Peter_Weber1]

I bought it at my own company Robert
It’s a product of my company dolphin GmbH and we used Quark for many
projects.
Quark uses 6k code and the PhQuark monitor about 60k, We handle 2500
IO-points in realtime with
this little nice ‘particle’ (Which is a logical consequence if neutrinos
and photons flying around
It’s available for Q4 and Q6 with a hand full API like
connect(),disconnect(),arm(),disarm(),fetch(),register() etc…
If you can read german we have a website for Quark (english version is
still under constrrrrr…urgh:-/)
http://www.dolphin.de/Produkte/Quark.html , there you will also see a
typical code sequence using Quark.

Back to the topic…switching options like DEBUG on and off is only one
thing neccessary in a real applic.
Here I think more for practice. Following the codepath is one thing and
monitoring/logging data is another one.
An API for a resmgr must be more generic than an ‘fd’ based interface. My
experience is, that
the resmgr-framework is not backdraft free (definitely too slow) for a
realtime appl.
I thought about building Quark for Q6 as a resmgr but this aproach would be
20 times slower than the current
IPC-SRR implementation.
In the server I have one jump (via a jumptable), one integer operation and a
MsgReplyv() to fetch a bulk of data…that’s it!
On the client side there is: two short assignments, one _setmx and the
MsgSendv().
I receive pulses in the client when data has changed in one or more data
groups. This is exactly what I need to drive
control processes, GUI’s etc. and watch/log the data. Exporting data out of
an appl. or resmgr using your approach
has always something to do with synchron access to this data. Changes are
only usefull if the resmgr is on the main
blocking point.

main ()
{
// initialize your normal stuff here

control_panel_register (“servername”);
control_panel_register_variable (&debug_flag, “Debug Flag”);

// proceed with server stuff and the rest of your code
and_now(?
}

This is exactely what the Quark API does! Using it for IPC with data
distribution or as a spyglass for a running process
is the same I think. The difference lays in the point where the data gets
manipulated in the application.
However, for each appl. there is a specific part to maintain and my
experience showed me that it often ends in a ioctl() ))
…
Just an idea for your book:
As a pilot, checklist are my best friend! Building a resmgr I would like to
see a detailed decision path diagram to
build a resmgr. Each decision path schould be well documented…so we get a
kind of resmgr-generator.
Next step is to write an perl script which generates all the well documented
source
and this for block, char, graphics, network…based resmgr etc. hmmm )))

“Robert Krten” <nospam86@parse.com> schrieb im Newsbeitrag
news:aim9kd$skj$1@inn.qnx.com…

Peter Weber <> pw@dolphin.de> > wrote:
Hi Robert,
we use such an aproach for our processes. The GUI is like a tree with
all
processes as the root item, in each process you see groups of variables
and
in each group the variable itself
which you can manipulate, record, log etc. We use the Quark realtime
server
which is a pool of time
stamped variables for all communicating processes.
We can reload config files, restart the process w/o reload or switching
options on and off.
It is a little more than only ‘remote control’ of processes, we have
full
sight into the whole process data.
see att. picture (sorry for using an attachment in news groups:-)
cheers, Peter

Interesting. Looks more like a “process control” (as in “industrial
control”)
kind of application, no?
If you want…but it is the same as your control_panel_xxxx(), using only

the invers direction.

But yes, definitely a nice product. The usual, how much is it, where do
you
buy it, etc…

cheers, Peter

[Robert_Krten1]

Peter Weber <pw@dolphin.de> wrote:

I bought it at my own company Robert >
It’s a product of my company dolphin GmbH and we used Quark for many
projects.
Quark uses 6k code > > and the PhQuark monitor about 60k, We handle 2500
IO-points in realtime with
this little nice ‘particle’ > > (Which is a logical consequence if neutrinos
and photons flying around >
It’s available for Q4 and Q6 with a hand full API like
connect(),disconnect(),arm(),disarm(),fetch(),register() etc…
If you can read german > > we have a website for Quark (english version is
still under constrrrrr…urgh:-/)
http://www.dolphin.de/Produkte/Quark.html > , there you will also see a
typical code sequence using Quark.

Back to the topic…switching options like DEBUG on and off is only one
thing neccessary in a real applic.
Here I think more for practice. Following the codepath is one thing and
monitoring/logging data is another one.
An API for a resmgr must be more generic than an ‘fd’ based interface. My
experience is, that
the resmgr-framework is not backdraft free (definitely too slow) for a
realtime appl.
I thought about building Quark for Q6 as a resmgr but this aproach would be
20 times slower than the current
IPC-SRR implementation.
In the server I have one jump (via a jumptable), one integer operation and a
MsgReplyv() to fetch a bulk of data…that’s it!
On the client side there is: two short assignments, one _setmx and the
MsgSendv().
I receive pulses in the client when data has changed in one or more data
groups. This is exactly what I need to drive
control processes, GUI’s etc. and watch/log the data. Exporting data out of
an appl. or resmgr using your approach
has always something to do with synchron access to this data. Changes are
only usefull if the resmgr is on the main
blocking point.

Interesting! I’ll have to steal some of those ideas

main ()
{
// initialize your normal stuff here

control_panel_register (“servername”);
control_panel_register_variable (&debug_flag, “Debug Flag”);

// proceed with server stuff and the rest of your code
and_now(?

Well, what I meant there was “do whatever you would normally do”, meaning
that after this point the control_panel() functions are no longer important,
they’re off running in their own thread…

}



This is exactely what the Quark API does! Using it for IPC with data
distribution or as a spyglass for a running process
is the same I think. The difference lays in the point where the data gets
manipulated in the application.
However, for each appl. there is a specific part to maintain and my
experience showed me that it often ends in a ioctl() > > ))

One thought someone had was to make a devctl() compatible outcall, so that if your
application is already a resource manager, it just simply outcalls to the
control panel stuff, rather than having a separate resource manager…

…
Just an idea for your book:
As a pilot, checklist are my best friend! Building a resmgr I would like to
see a detailed decision path diagram to
build a resmgr. Each decision path schould be well documented…so we get a
kind of resmgr-generator.
Next step is to write an perl script which generates all the well documented
source >
and this for block, char, graphics, network…based resmgr etc. hmmm > > )))

Start with /dev/null and add stuff? That’s my building block approach.
At one point I had an idea to write a cgi-bin that would allow a webpage to
have a “resmgr creator” that would do just that. Unfortunately, there was
a stunning lack of enthusiasm, so I abandoned that…

Cheers,
-RK

“Robert Krten” <> nospam86@parse.com> > schrieb im Newsbeitrag
news:aim9kd$skj$> 1@inn.qnx.com> …
Peter Weber <> pw@dolphin.de> > wrote:
Hi Robert,
we use such an aproach for our processes. The GUI is like a tree with
all
processes as the root item, in each process you see groups of variables
and
in each group the variable itself
which you can manipulate, record, log etc. We use the Quark realtime
server
which is a pool of time
stamped variables for all communicating processes.
We can reload config files, restart the process w/o reload or switching
options on and off.
It is a little more than only ‘remote control’ of processes, we have
full
sight into the whole process data.
see att. picture (sorry for using an attachment in news groups:-)
cheers, Peter

Interesting. Looks more like a “process control” (as in “industrial
control”)
kind of application, no?
If you want…but it is the same as your control_panel_xxxx(), using only
the invers direction.

But yes, definitely a nice product. The usual, how much is it, where do
you
buy it, etc…

cheers, Peter

–
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.

[Alain_Bonnefoy2]

I did something like that for some dlls, I have a shell utility i have a
shell utility to turn on/off debugging mode as well as to give were to
display the message: it could be.

mydll_ctrl --debug 1 --out_debug /dev/ttyp1

I likke the the idea of Robert Rutherford too!

regards,
Alain.

Robert Krten wrote:

How’s this for an off-the-wall product idea.

A universal control panel for software. What it does is it allows
you to modify variables through a controlled-access resource manager
in running programs.

Why? I’ve often had some kind of 24x7 server running and decided,
“ah crap, I need to turn on debugging for a while”. I really hate
the thought of having to restart the server with the -D flag, run
it for a bit, and then restart it again with out the -D flag.

So, here’s a set of API’s that I’m proposing to fix this.

In your server’s main(), you’d put something like:

main ()
{
// initialize your normal stuff here

control_panel_register (“servername”);
control_panel_register_variable (&debug_flag, “Debug Flag”);

// proceed with server stuff and the rest of your code
}

Then, from a command line or GUI, the “universal control panel” would
simply open “/dev/controlpanel/servername”, and get a list of variables
that are controllable. In this example, it would just come up with
a text string that sez “Debug Flag” and some id number.

From the universal control panel, I could then turn on the debug flag,
turn it off, examine it, etc.

There are a few details here that are of interest as well.

1. why not have every server do it its own way? (I think that question
   just answered itself)
2. how do we control access between the implicit resmgr thread and the
   regular server threads to the variables?
   Well, I thought about that, and there are a number of clever solutions:
   a) we don’t. If we “cripple” this idea to just accessing single
   char variables, there’s no issue with atomic operations.
   Even if we don’t limit it to just char variables, we can still
   do a “good enough” approach even without atomic operations.
   Certain operations can be coded to be non-atomic tolerant.
   b) we implement a set of macros that do mutex operations on the
   controlled variables, effectively providing a read/write
   interface. I don’t like the idea of anyone explicitly having
   to worry about the mutex functions, because that just leads to
   trouble, and makes this idea a lot more intrusive to the code
   to implement. I like the idea of just coding up the usual
   “if (debug_flag) { … }” kind of stuff.
3. for variables that come in and out of scope, there could be an
   “unregister” call as well, which would effectively remove that address
   from the control of the resmgr thread.
4. why can’t we do this with GDB or the /proc filesystem? You could do some
   of it, but certainly not the synchronizational aspects.

The true beauty in this scheme lies in the fact that I have one year to
patent it! Er, I mean, the true beauty in this scheme lies in the fact
that it’s not intrusive to the code; just a few lines up front in the
code. The control_panel_*() functions could even look at an environment
variable to allow them to “opt-out” in case of limited sizes on embedded
systems. And, it’s not just for servers – it can be quite useful for
long-running tasks that aren’t servers.

Thoughts?

Cheers,
-RK

[Alain_Bonnefoy2]

About GUIs, we are thinking about something more general to
monitor/control our application, soething that could be used through
Internet and more, without necessarly having a QNX station.
I like very much the idea of SWAT, the little web server to configure SAMBA.

Did you use it?

I think I will go to this direction.

Alain.

Robert Krten wrote:

Robert Rutherford <> ruzz@nospamplease.ruzz.com> > wrote:

We already do this (in a somewhat cruder way).


All our server processes accept a standard message which allows an external
process to easily change the server’s environment (and also triggers certain
processing based on such changes). For example if I want to turn on verbose
logging on an already running running server I just do:


$ setenv -P server_name “DEBUG_ALL=TRUE”


This is absolute life-saver at times. Your idea is a more general extension
of this. The main benefit I see from your concept is the ability to
determine at run-time the variables that are available for manipulation, and
to see their current value, rather than having to insepct the manual/source
to see what variables are available.


Go for it!


Of course the traditional Unix way of achieving the same (or similar) is
just to have your server re-read its configuration file on receipt of a
signal like SIGHUP.


YUCK! I HAVE FREAKIN’ SIGNALS!!! >

The main advantages, are like you said the runtime thing, but also the fact
that it could be standardized with a QSSL or community buy-in. This then
means that one control panel GUI or text-mode app can analyze any number
of QSSL and third-party products!

The other brainfart I had was to include a “timed monitor” aspect to it,
so that it could be used as a passive “front panel” to your application.
Imagine being able to have a GUI app that refreshes the values of various
variables at fixed intervals – packet counts, errors, number of frames
processed – whatever; it would be a good “insite” into the operation of
the utility.

I’m all over it, it’s my next project, I’ll include it in my next
upcoming “The QNX Neutrino Cookbook” book (he said, completely ignoring
the name “Momentics” again) >

Anyone care to write the GUI part once I get the API finalized?
I’m thinking something with a tree-widget on one side to select
processes under /dev/controlpanel, and then a bunch of selectors for
the variables, including a right-click to set a monitoring period, etc.
Heck, it could even periodically log-to-disk >

Cheers,
-RK


Rob Rutherford


“Robert Krten” <> nospam86@parse.com> > wrote in message
news:ai78ke$ser$> 1@inn.qnx.com> …

How’s this for an off-the-wall product idea.

A universal control panel for software. What it does is it allows
you to modify variables through a controlled-access resource manager
in running programs.

Why? I’ve often had some kind of 24x7 server running and decided,
“ah crap, I need to turn on debugging for a while”. I really hate
the thought of having to restart the server with the -D flag, run
it for a bit, and then restart it again with out the -D flag.

So, here’s a set of API’s that I’m proposing to fix this.

In your server’s main(), you’d put something like:

main ()
{
// initialize your normal stuff here

control_panel_register (“servername”);
control_panel_register_variable (&debug_flag, “Debug Flag”);

// proceed with server stuff and the rest of your code
}

Then, from a command line or GUI, the “universal control panel” would
simply open “/dev/controlpanel/servername”, and get a list of variables
that are controllable. In this example, it would just come up with
a text string that sez “Debug Flag” and some id number.

From the universal control panel, I could then turn on the debug flag,
turn it off, examine it, etc.

There are a few details here that are of interest as well.

1. why not have every server do it its own way? (I think that question
   just answered itself)
2. how do we control access between the implicit resmgr thread and the
   regular server threads to the variables?
   Well, I thought about that, and there are a number of clever solutions:
   a) we don’t. If we “cripple” this idea to just accessing single
   char variables, there’s no issue with atomic operations.
   Even if we don’t limit it to just char variables, we can still
   do a “good enough” approach even without atomic operations.
   Certain operations can be coded to be non-atomic tolerant.
   b) we implement a set of macros that do mutex operations on the
   controlled variables, effectively providing a read/write
   interface. I don’t like the idea of anyone explicitly having
   to worry about the mutex functions, because that just leads to
   trouble, and makes this idea a lot more intrusive to the code
   to implement. I like the idea of just coding up the usual
   “if (debug_flag) { … }” kind of stuff.
3. for variables that come in and out of scope, there could be an
   “unregister” call as well, which would effectively remove that address
   from the control of the resmgr thread.
4. why can’t we do this with GDB or the /proc filesystem? You could do

some

of it, but certainly not the synchronizational aspects.

The true beauty in this scheme lies in the fact that I have one year to
patent it! Er, I mean, the true beauty in this scheme lies in the fact
that it’s not intrusive to the code; just a few lines up front in the
code. The control_panel_*() functions could even look at an environment
variable to allow them to “opt-out” in case of limited sizes on embedded
systems. And, it’s not just for servers – it can be quite useful for
long-running tasks that aren’t servers.

Thoughts?

Cheers,
-RK

–
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.
\