declare 2 names for 1 resmgr

Hi,
I explain:
I’d like to declare something like that:
/var/my_resmgr/diagnosis/formatted
/var/my_resmgr/diagnosis/raw

You should understand a bit what does it mean.

So I wonder how to declare these 2 names.
The first one, say /var/my_resmgr/diagnosis/formatted will be declared
by a resmgr_attach()
But I think that the second one could be simply declared by a symlink
and test in my io_read_diagnosis func the resmgr id to know which one is
accessed.

I don’t really see how to do.

Could you help me?

Thanks,
Alain.

Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:

Hi,
I explain:
I’d like to declare something like that:
/var/my_resmgr/diagnosis/formatted
/var/my_resmgr/diagnosis/raw

You should understand a bit what does it mean.

So I wonder how to declare these 2 names.
The first one, say /var/my_resmgr/diagnosis/formatted will be declared
by a resmgr_attach()
But I think that the second one could be simply declared by a symlink
and test in my io_read_diagnosis func the resmgr id to know which one is
accessed.

I don’t really see how to do.

I think the easiest is to just resmgr_attach them both with a different
attr/handle – then, in your various functions, you just need to compare
against the attr that gets passed to you and you’ll know which one
you are handling the requests for…

Cheers,
-RK

Thanks,
Alain.


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.

Thanks Robert,
This is what I did.


Robert Krten a écrit:

Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:


Hi,
I explain:
I’d like to declare something like that:
/var/my_resmgr/diagnosis/formatted
/var/my_resmgr/diagnosis/raw





You should understand a bit what does it mean.





So I wonder how to declare these 2 names.
The first one, say /var/my_resmgr/diagnosis/formatted will be declared
by a resmgr_attach()
But I think that the second one could be simply declared by a symlink
and test in my io_read_diagnosis func the resmgr id to know which one is
accessed.





I don’t really see how to do.



I think the easiest is to just resmgr_attach them both with a different
attr/handle – then, in your various functions, you just need to compare
against the attr that gets passed to you and you’ll know which one
you are handling the requests for…

Cheers,
-RK


Thanks,
Alain.


\

Robert Krten <nospam84@parse.com> wrote:

Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Hi,
I explain:
I’d like to declare something like that:
/var/my_resmgr/diagnosis/formatted
/var/my_resmgr/diagnosis/raw

You should understand a bit what does it mean.

I don’t really see how to do.

I think the easiest is to just resmgr_attach them both with a different
attr/handle – then, in your various functions, you just need to compare
against the attr that gets passed to you and you’ll know which one
you are handling the requests for…

For a small number of devices, especially if it is a static
small number of devices, that method makes fine sense.

For larger numbers of devices, you might want to register

/var/my_resmgr/diagnosis

And then start handling directory read operations and all that sort
of fun.

A couple of Rob’s recently posted samples, his tar file system, and
his RAM driver, would probably be good places to start for how to
handle this.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

David Gibbs <dagibbs@qnx.com> wrote:

Robert Krten <> nospam84@parse.com> > wrote:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Hi,
I explain:
I’d like to declare something like that:
/var/my_resmgr/diagnosis/formatted
/var/my_resmgr/diagnosis/raw

You should understand a bit what does it mean.

I don’t really see how to do.

I think the easiest is to just resmgr_attach them both with a different
attr/handle – then, in your various functions, you just need to compare
against the attr that gets passed to you and you’ll know which one
you are handling the requests for…

For a small number of devices, especially if it is a static
small number of devices, that method makes fine sense.

For larger numbers of devices, you might want to register

/var/my_resmgr/diagnosis

And then start handling directory read operations and all that sort
of fun.

A couple of Rob’s recently posted samples, his tar file system, and
his RAM driver, would probably be good places to start for how to
handle this.

Thanks Dave, :slight_smile:

Empirical evidence suggests that 1000 is the maximum number of discretely
manifestable pathnames, as suggested by a recent experiment using
find -name “*.tar” | xargs mount -T tarfs -m

I think the numbers I was given by PeterV a long time ago were something
along the lines of “dozens is fine, hundreds is not” :slight_smile:

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.

Ok David,
I used that method in some other applications.
Thanks,
Alain

David Gibbs a écrit:

Robert Krten <> nospam84@parse.com> > wrote:


Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:


Hi,
I explain:
I’d like to declare something like that:
/var/my_resmgr/diagnosis/formatted
/var/my_resmgr/diagnosis/raw





You should understand a bit what does it mean.





I don’t really see how to do.





I think the easiest is to just resmgr_attach them both with a different
attr/handle – then, in your various functions, you just need to compare
against the attr that gets passed to you and you’ll know which one
you are handling the requests for…



For a small number of devices, especially if it is a static
small number of devices, that method makes fine sense.

For larger numbers of devices, you might want to register

/var/my_resmgr/diagnosis

And then start handling directory read operations and all that sort
of fun.

A couple of Rob’s recently posted samples, his tar file system, and
his RAM driver, would probably be good places to start for how to
handle this.

-David

Hi RK…

Robert Krten wrote:

Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:

I think the easiest is to just resmgr_attach them both with a different
attr/handle – then, in your various functions, you just need to compare
against the attr that gets passed to you and you’ll know which one
you are handling the requests for…s

Will you have an example in your upcoming book for this?

regards…

Miguel.

Cheers,
-RK

Thanks,
Alain.

Hi Miguel,

The following example should help you. Just ‘cat /var/resmgr_0x’ to see
the result.
Be root to run the server.

$ >qcc -o server main.c

>./server&

$ >cat /var/resmgr_02




Miguel Simon a écrit:

Hi RK…

Robert Krten wrote:

Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:




I think the easiest is to just resmgr_attach them both with a different
attr/handle – then, in your various functions, you just need to compare
against the attr that gets passed to you and you’ll know which one
you are handling the requests for…s


Will you have an example in your upcoming book for this?

regards…

Miguel.


Cheers,
-RK

Thanks,
Alain.

\

Miguel Simon <simon@ou.edu> wrote:

Hi RK…

Robert Krten wrote:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:

I think the easiest is to just resmgr_attach them both with a different
attr/handle – then, in your various functions, you just need to compare
against the attr that gets passed to you and you’ll know which one
you are handling the requests for…s

Will you have an example in your upcoming book for this?

There’s one in the existing book :slight_smile: Look under the “atoz.c” filesystem…

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.

Miguel Simon <simon@ou.edu> wrote:

Hi RK…

I thought that I had seen every thing in your book. Humm… yup, I see
that. Thanks!

Miguel.



P.S. when will your next book be out? Are you going to talk about
eclipse in your book?

No; eclipse is not something I use – I use make, vi, and the printf debugger :slight_smile:
Everything else is derivative.

Book should be out around summer/fall of this year…

New geek pr0n, BTW: http://www.parse.com/~rk/server/

Cheers,
-RK

Robert Krten wrote:
Miguel Simon <> simon@ou.edu> > wrote:

Hi RK…


Robert Krten wrote:

Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:


I think the easiest is to just resmgr_attach them both with a different
attr/handle – then, in your various functions, you just need to compare
against the attr that gets passed to you and you’ll know which one
you are handling the requests for…s


Will you have an example in your upcoming book for this?


There’s one in the existing book > :slight_smile: > Look under the “atoz.c” filesystem…

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.

Hi Alain…

Great! Thanks. Very useful.

regards…

Miguel.


Alain Bonnefoy wrote:

Hi Miguel,

The following example should help you. Just ‘cat /var/resmgr_0x’ to see
the result.
Be root to run the server.

$ >qcc -o server main.c

>./server&

$ >cat /var/resmgr_02






\

#include <stdio.h
#include <stdlib.h
#include <errno.h
#include <string.h
#include <sys/iofunc.h
#include <sys/dispatch.h
#include <sys/netmgr.h
#include <sys/neutrino.h
#include <sys/resmgr.h


dispatch_t *dpp;
dispatch_context_t *ctp;

resmgr_connect_funcs_t connect_funcs;
resmgr_io_funcs_t io_funcs;
resmgr_attr_t rattr;
iofunc_attr_t ioattr[10];

char replied_string[27] = {"You are reading resmgr "};

int io_my_read(resmgr_context_t *ctp, io_read_t *msg, iofunc_ocb_t *ocb) {
int nbytes, nleft, status;
char buffer[100] = {0};

if ((status = iofunc_read_verify(ctp, msg, ocb, NULL)) != EOK) {
return(status);
}
//figure out how many bytes are left
nleft = ocb->attr->nbytes - ocb->offset;

// and how many bytes we can return to the client
nbytes = min(nleft, msg->i.nbytes);

if (nbytes) {
// This method is very bad! We should find a better solution to create our file content
// as io_read() func maybe called several times depending on the client’s buffer length.
sprintf(buffer, “%s%02d\n”, replied_string, ocb->attr->inode);

if (MsgReply(ctp->rcvid, nbytes, buffer + ocb->offset, nbytes) == -1) {
printf(“MsgReply() : %s\n”, strerror(errno));
exit(EXIT_FAILURE);
}

ocb->offset+= nbytes;

if (msg->i.nbytes > 0)
ocb->attr->flags |= IOFUNC_ATTR_ATIME | IOFUNC_ATTR_DIRTY_TIME;
} else {
if (MsgReply(ctp->rcvid, EOK, NULL, 0) == -1) {
printf(“MsgReply() : %s\n”, strerror(errno));
exit(EXIT_FAILURE);
}
}

return(_RESMGR_NOREPLY);
}


int main(int argc, char *argv) {
char pathname[_POSIX_PATH_MAX];
int i;


if ((dpp = dispatch_create()) == NULL) {
printf(“dispatch_create() : %s\n”, strerror(errno));
exit(EXIT_FAILURE);
}
memset(&rattr, 0, sizeof(rattr)); /
using the default for rattr */

/*

  • initialize the connect function and I/O functions tables to their defaults and then
  • override the defaults with the functions that we are providing.
    */
    iofunc_func_init(_RESMGR_CONNECT_NFUNCS, &connect_funcs, _RESMGR_IO_NFUNCS, &io_funcs);
    io_funcs.read = io_my_read;

for (i = 0; i < 9; i++) {
iofunc_attr_init(&ioattr> , S_IFREG | 0666, NULL, NULL);

sprintf(pathname, "/var/resmgr
%02d", i+1);
printf(“register pathname %s\n”, pathname);

ioattr> .nbytes = 27; // our file length
ioattr> .inode = i+1; // 0 means 'not used"

if (resmgr_attach(dpp, &rattr, pathname, FTYPE_ANY, 0, &connect_funcs, &io_funcs, &ioattr> ) == -1) {
printf(“resmgr_attach() : %s\n”, strerror(errno));
exit(EXIT_FAILURE);
}
}


if ((ctp = dispatch_context_alloc(dpp)) == NULL){
printf(“dispatch_context_alloc() : %s\n”, strerror(errno));
exit(EXIT_FAILURE);
}

while (1) {
if ((ctp = dispatch_block(ctp)) == NULL) {
printf(“dispatch_block() : %s\n”, strerror(errno));
exit(EXIT_FAILURE);
}

if (dispatch_handler(ctp) == -1) {
printf(“dispatch_handler() : %s\n”, strerror(errno));
exit(EXIT_FAILURE);
}
}
}

Hi RK…

I thought that I had seen every thing in your book. Humm… yup, I see
that. Thanks!

Miguel.


P.S. when will your next book be out? Are you going to talk about
eclipse in your book?



Robert Krten wrote:

Miguel Simon <> simon@ou.edu> > wrote:

Hi RK…


Robert Krten wrote:

Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:


I think the easiest is to just resmgr_attach them both with a different
attr/handle – then, in your various functions, you just need to compare
against the attr that gets passed to you and you’ll know which one
you are handling the requests for…s


Will you have an example in your upcoming book for this?


There’s one in the existing book > :slight_smile: > Look under the “atoz.c” filesystem…

Cheers,
-RK

Hi RK…

Robert Krten wrote:





No; eclipse is not something I use – I use make, vi, and the printf debugger > :slight_smile:
Everything else is derivative.

I know people that would say that a debugger would make you more
productive than printf(), but I digress.

What about ddd? I just want to have someone buy your book and say “here
is how you debut, figure it out…”. printf() debugging requires some
art and actual knowledge + intuition, and I do not want to spend too
much of the time explaining. (specially true if they are students
learning what a pc104 + QNX is).

Book should be out around summer/fall of this year…

New geek pr0n, BTW: > http://www.parse.com/~rk/server/

what is a “new geek prOn”?

regards…

Miguel.

Cheers,
-RK

Miguel Simon <simon@ou.edu> wrote:

Hi RK…

Robert Krten wrote:

No; eclipse is not something I use – I use make, vi, and the printf debugger > :slight_smile:
Everything else is derivative.

I know people that would say that a debugger would make you more
productive than printf(), but I digress.

We can have that discussion in qdn.cafe if you like :slight_smile:

What about ddd? I just want to have someone buy your book and say “here
is how you debut, figure it out…”. printf() debugging requires some
art and actual knowledge + intuition, and I do not want to spend too
much of the time explaining. (specially true if they are students
learning what a pc104 + QNX is).

Since it’s not something I use, I wouldn’t be comfortable writing about it – I find
that I need to really “understand” and “use” something before I can write about it.

Book should be out around summer/fall of this year…

New geek pr0n, BTW: > http://www.parse.com/~rk/server/

what is a “new geek prOn”?

“pr0n” is slang for “pornography”, and the specific variant, “geek porn”
is pictures of machines; wires; cabling; etc. :slight_smile:

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 <nospam84@parse.com> wrote:

what is a “new geek prOn”?

“pr0n” is slang for “pornography”, and the specific variant, “geek porn”
is pictures of machines; wires; cabling; etc. > :slight_smile:

Oh Robert, your turning me on!

Bill Caroselli <qtps@earthlink.net> wrote:

Robert Krten <> nospam84@parse.com> > wrote:

what is a “new geek prOn”?

“pr0n” is slang for “pornography”, and the specific variant, “geek porn”
is pictures of machines; wires; cabling; etc. > :slight_smile:

Oh Robert, your turning me on!

Now Bill, you have a girlfriend, so try and restrain yourself!

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.

Miguel Simon <simon@ou.edu> wrote:

Robert Krten wrote:

I know people that would say that a debugger would make you more
productive than printf(), but I digress.

What about ddd? I just want to have someone buy your book and say “here
is how you debut, figure it out…”. printf() debugging requires some
art and actual knowledge + intuition, and I do not want to spend too
much of the time explaining. (specially true if they are students
learning what a pc104 + QNX is).

I have a logging system that I use for QNX4. I like it better than
any debugger. Granted, it won’t help if the problem causes a complete
system failure. It is very similar to QNX4s’ tracelogger. But trace
logger didn’t have a big enough buffer for me, and it couldn’t store
text type messages.

The package includes:

  • a C++ header file with a very extensive set of logging cover functions.
  • a linkable library module with methods to Put() any kind of data.
  • a server module with 2 threads that Receive() and log the log records.
  • a LGut utility that displays the logged data.

Because it writes out binary data, it doesn’t have to format anything,
so it doesn’t impose overhead like printf()s. I have used it in audio
device drivers logging as many as 500 messages a second without
significantly impacting system performance.

Each log message has a severity/type code that is not necessarily in
any hiarchical order. I.E. You can filter on types 1, 3 adn 5 without
seeing 2 or 4. The server process has a command line option to specify
what severity/types do/don’t get logged. The Put() methods that get
linked into the client process can also look at an envirnment variable
to decide which messages to attempt to log. This helps, because once you
compile all of the logging into a program, you can still turn it on and
off either globally, or for specific processes. It is efficient enough
to use both for program debugging and for normal activity logging.

The LGut utility can find/filter specific data by program/function ID
grep text, message grep text, date/time stamps, etc. It can also merge
log files from multiple nodes and display a single report. This is
extreamly useful for debugging multi hosts messaging bugs/performance
issues. If can also write out new log files based on the record that it
just read. This allows you to log everything in a running system, but
after a few days of no problems being reported you can filter out the
more debug type of messages and keep only the normal system activity
type of messages.

The server process has a special mode to run on diskless workstations
and relay it’s messages to a remote server process on another node.
This helps keep performance up on the diskless workstation.

A companion feature of this was a Tracer and ObjectTracer C++ object
that can be used to trace every entrance and exit into a function (or
other instance of curly braces) or the creation/destruction of a piece
of data. These events are also logged into the logging system.
(Note: this was copied from Dr. Dobbs long ago. They are not my own.)

Another companion feature is a function that logs the command line of
any programs that gets loaded. Useful for seeing when someone loaded
your program inappropriately and that’s why it isn’t working.

I have not yet ported this to QNX6. Would anyone else be interested in
this for a nominal fee?


Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net