Hey Thomas Fletcher

Alain_Bonnefoy2 · October 12, 2001, 9:44am

I wanted to have a look at the following page:
http://staff.qnx.com/~thomasf/wtf-resmgr.html

Is it possible to find it somewhere?

Thanks,
Alain.

Poseidon · October 12, 2001, 10:23am

All of the staff pages staff.qnx.com/~someone have gone for a Burton.
What gives?

Poseidon

Miguel_Simon1 · October 12, 2001, 2:11pm

Hi…

Some of it is at developers.qnx.com

Bests…

Miguel.

Poseidon wrote:

All of the staff pages staff.qnx.com/~someone have gone for a Burton.
What gives?

Poseidon

–

my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.

Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
http://www.saic.com

Frank_Liu1 · October 12, 2001, 4:30pm

I don’t think QSSL is doing the right thing of shutting down
staff.qnx.com. Maybe Redhat should also shutdown people.redhat.com too,
with the same argument?

I am still looking for the SHM stuff from Kris, to try it with my
XFree86 port. developers.qnx.com just doesn’t have much in there.

Frank

On Fri, 12 Oct 2001, Miguel Simon wrote:

Hi…

Some of it is at developers.qnx.com

Bests…

Miguel.

Poseidon wrote:

All of the staff pages staff.qnx.com/~someone have gone for a Burton.
What gives?

Poseidon

–

my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.

Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
http://www.saic.com

Bill_Caroselli_Q-TPS · October 12, 2001, 8:07pm

I agree.

Hell, there’s been unsupported (and somewhat untested) stuff on QUICS for
years.

So, let the buyer beware, but don’t take away our goodies.

Bill Caroselli

“Frank Liu” <liug@mama.indstate.edu> wrote in message
news:Pine.LNX.4.33.0110121127410.13153-100000@mama.indstate.edu…

I don’t think QSSL is doing the right thing of shutting down
staff.qnx.com. Maybe Redhat should also shutdown people.redhat.com too,
with the same argument?

I am still looking for the SHM stuff from Kris, to try it with my
XFree86 port. developers.qnx.com just doesn’t have much in there.

system · October 15, 2001, 5:20pm

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

I wanted to have a look at the following page:
http://staff.qnx.com/~thomasf/wtf-resmgr.html

Is it possible to find it somewhere?

Alain (and the crowd that followed),

The developer run pages will at some point be making a
comeback, when that will be has not yet been determined
(ie beyond my personal control). Developers.qnx.com is
the official source for non-official source packages
(ala old style quics). For developer controlled content
pages … stay tuned.

In the mean time here is the resmgr page you requested.

Thomas

Neutrino Resource Manager FAQ

Resmgrs rock … plain and simple. Sometimes, usually
late at night, things just don’t seem to always make sense.

This is just a collection of some of the more interesting
(and occasionally intersting) questions
that people have vented out as they work their way to resmgr
writing nirvana.

If you have a question you think should be posted, then mail
it to thomasf@qnx.com to
get it posted and get famous!

\ \

Why don't my clients die when I hit ^C
When you send a signal to the client and a client is reply blocked on a server, then a pulse is sent to the server. If your server/resource manager doesn't have an unblock handler to send a message back to the client, then the client will just block forever .. or at least until the server decides to reply.

What is the difference between a connect and an io function?
The connect functions are all the functions which are associated with performing an operation on a pathname. As such they all have a connect message (defined in ) as one of their parameters so you can access the path via msg->connect.path. These functions generally must do a pathname look-up operation to check the validity of the path being sent to them. This lookup is not required on device resource managers but is essential on filesystem resource managers. After the lookup is validated then the name can be mapped to an attribute structure and the remainder of the operation can continue. Examples of connect functions are:

open()

rename()

readlink()

unlink(): When you send a signal to the client and a client is reply blocked on a server, then a pulse is sent to the server. If your server/resource manager doesn't have an unblock handler to send a message back to the client, then the client will just block forever .. or at least until the server decides to reply.
What is the difference between a connect and an io function?
The connect functions are all the functions which are associated with performing an operation on a pathname. As such they all have a connect message (defined in ) as one of their parameters so you can access the path via msg->connect.path. These functions generally must do a pathname look-up operation to check the validity of the path being sent to them. This lookup is not required on device resource managers but is essential on filesystem resource managers. After the lookup is validated then the name can be mapped to an attribute structure and the remainder of the operation can continue. Examples of connect functions are:

open()

rename()

readlink()

unlink(): The connect functions are all the functions which are associated with performing an operation on a pathname. As such they all have a connect message (defined in ) as one of their parameters so you can access the path via msg->connect.path. These functions generally must do a pathname look-up operation to check the validity of the path being sent to them. This lookup is not required on device resource managers but is essential on filesystem resource managers. After the lookup is validated then the name can be mapped to an attribute structure and the remainder of the operation can continue. Examples of connect functions are:

open()

rename()

readlink()

unlink()
When I block in my read handler waiting for data, everything stops. What is going on!?
As mentioned previously, a path is resolved to a particular attribute in the connect functions. In the open function that attribute is then bound to an open context block, or ocb. This ocb is then passed to each of the io functions. Before an io function is called, the attribute is locked by the resource manager library layer. If your design requires that a thread will block for any length of time in one of the io functions, then that thread must call iofunc_attr_unlock() before it blocks and then iofunc_attr_lock() after it wakes up. If this isn't done then any other functions which need to access this attribute through the resource manager library will block attempting to acquire a lock on the attribute.
Don't block holding any locks

I can't get devctl() to work properly. Help?
Take a look at the devctl](http://staff.qnx.com/~thomasf/nto.html%22%3Edevctl) example here which shows how a client and a server work using a simple devctl.

I still can't get devctl() to return the value I specify. More help?
The devctl() function has its last argument as a pointer to an int which is a status/info value. This field is populated with the io_devctl_t.o.ret_val field from the resource manager.

devctl() is busted ... you can only return < 16k of data
The problem is most likely the fact that the command integer of the devctl() function is designed to be overloaded. From we see:
#define __DIOF(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_FROM) #define __DIOT(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_TO) #define __DIOTF(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_TOFROM) with #define _POSIX_DEVDIR_NONE 0 #define _POSIX_DEVDIR_TO 0x80000000 #define _POSIX_DEVDIR_FROM 0x40000000

Now if you defined the structure 'data' to be larger than 16 bits, it will likely overrun into the top bits of the devctl command integer. Unfortunately these top two bits are the only bits in the command integer that anything in the library looks at to determine if it should be sending or receiving data (or both). A better strategy is to encode the size of the data being passed inside the structure rather than have a huged enormous structure. You then pass the size to be transferred with the nbytes option to devctl() and this will indicate the number of bytes which will be used in MsgSend().

How do I know what messages contain?
All of the standard resource manager messages are defined as structures which typically take the form of:

typedef union { struct _io_ i struct _io__reply o } io__t

These messages are all defined in the header file <sys/iomsg.h>
which makes for some very intersting and occasionally insightful
reading.

How can I guarantee I'm the only person on a mountpoint?
The short answer is that you can't. You can avoid duplication of your server by using the resource database minor/major numbers in Proc (see rsrcdbmgr_devno_attach() in the documentation), but be aware that there is a limit of 64 major numbers in the system. In order for a device resource manager to avoid being overlaid by other device resource managers it could use the _RESMGR_FLAG_BEFORE flag to resmgr_attach(), but doing so, while it may work, is not considered "fair play" with other resource managers.

For more information on pathname resolution you might want to search
QDN for an article which explains
how the Neutrino filesystem resolves names to particular servers.

What is the 4th field (file_type) of resmgr_attach() used for?
The file type field is an optimization which is used in the C library name resolution code to avoid contacting resource managers who only want to handle specific requests. It is a hint from the resource manager side to avoid additional resolution delays since a client connection is also established using a file_type.

The way that the matching is done is through the following matrix:

Server file_type

Client
file_type _FTYPE_ALL (-1) _FTYPE_ANY (0) _FTYPE_XXX (>0)

_FTYPE_ALL (-1) Illegal Illegal Illegal

_FTYPE_ANY (0) Contact Contact Contact

_FTYPE_XXX (>0) Contact Ignore (types match) ? Contact : Ignore

The all standard file operations (open, stat, unlink etc) are performed with a
file type of _FTYPE_ANY which all resource managers receive. Special connection
operations such as mq_open() or sem_open() are performed targetting a specific
service, and as such use a specific file_type of _FTYPE_MQUEUE or _FTYPE_SEM.

There is no conventional way through the currently documented API to take
advantage of this service/file_type provision.

What is the proper way to fill in directory information in the read handler
There are a number of different techniques to use. For simple information (ie no extended stat information) then this code sample should work properly:
#include /* For ALIGN and ALIGNBYTES */ ... struct dirent *dent; int reclen;
/*
Determine the size of the next entry and make sure that we have
enough space for it. Make sure to include the alignment adjustment
(even though the last entry to be sent doesn’t need it). Note that
the length of the string does not include an extra character for
the null, because this extra null character is already accounted for
in the dirent structure (name[1]).
*/
reclen = ALIGN(sizeof(*dent) + strlen(fname));
if (nbytes < reclen) {
break;
}

/* Fill in the dirent structure now that we know we have space /
dent->d_ino = some_inode_value;
dent->d_offset = some_offset_value;
/ This is the aligned record length /
dent->d_reclen = reclen;
/ This is the name length, name is null terminated but this is a hint */
dent->d_namelen = strlen(fname);
strcpy(dent->d_name, fname);

dent = (struct dirent *) ((char *)dent + dent->d_reclen);

\: As mentioned previously, a path is resolved to a particular attribute in the connect functions. In the open function that attribute is then bound to an open context block, or ocb. This ocb is then passed to each of the io functions. Before an io function is called, the attribute is locked by the resource manager library layer. If your design requires that a thread will block for any length of time in one of the io functions, then that thread must call iofunc_attr_unlock() before it blocks and then iofunc_attr_lock() after it wakes up. If this isn't done then any other functions which need to access this attribute through the resource manager library will block attempting to acquire a lock on the attribute.
Don't block holding any locks
I can't get devctl() to work properly. Help?
Take a look at the devctl](http://staff.qnx.com/~thomasf/nto.html%22%3Edevctl) example here which shows how a client and a server work using a simple devctl.

I still can't get devctl() to return the value I specify. More help?
The devctl() function has its last argument as a pointer to an int which is a status/info value. This field is populated with the io_devctl_t.o.ret_val field from the resource manager.

devctl() is busted ... you can only return < 16k of data
The problem is most likely the fact that the command integer of the devctl() function is designed to be overloaded. From we see:
#define __DIOF(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_FROM) #define __DIOT(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_TO) #define __DIOTF(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_TOFROM) with #define _POSIX_DEVDIR_NONE 0 #define _POSIX_DEVDIR_TO 0x80000000 #define _POSIX_DEVDIR_FROM 0x40000000

Now if you defined the structure 'data' to be larger than 16 bits, it will likely overrun into the top bits of the devctl command integer. Unfortunately these top two bits are the only bits in the command integer that anything in the library looks at to determine if it should be sending or receiving data (or both). A better strategy is to encode the size of the data being passed inside the structure rather than have a huged enormous structure. You then pass the size to be transferred with the nbytes option to devctl() and this will indicate the number of bytes which will be used in MsgSend().

How do I know what messages contain?
All of the standard resource manager messages are defined as structures which typically take the form of:

typedef union { struct _io_ i struct _io__reply o } io__t

These messages are all defined in the header file <sys/iomsg.h>
which makes for some very intersting and occasionally insightful
reading.

How can I guarantee I'm the only person on a mountpoint?
The short answer is that you can't. You can avoid duplication of your server by using the resource database minor/major numbers in Proc (see rsrcdbmgr_devno_attach() in the documentation), but be aware that there is a limit of 64 major numbers in the system. In order for a device resource manager to avoid being overlaid by other device resource managers it could use the _RESMGR_FLAG_BEFORE flag to resmgr_attach(), but doing so, while it may work, is not considered "fair play" with other resource managers.

For more information on pathname resolution you might want to search
QDN for an article which explains
how the Neutrino filesystem resolves names to particular servers.

What is the 4th field (file_type) of resmgr_attach() used for?
The file type field is an optimization which is used in the C library name resolution code to avoid contacting resource managers who only want to handle specific requests. It is a hint from the resource manager side to avoid additional resolution delays since a client connection is also established using a file_type.

The way that the matching is done is through the following matrix:

Server file_type

Client
file_type _FTYPE_ALL (-1) _FTYPE_ANY (0) _FTYPE_XXX (>0)

_FTYPE_ALL (-1) Illegal Illegal Illegal

_FTYPE_ANY (0) Contact Contact Contact

_FTYPE_XXX (>0) Contact Ignore (types match) ? Contact : Ignore

The all standard file operations (open, stat, unlink etc) are performed with a
file type of _FTYPE_ANY which all resource managers receive. Special connection
operations such as mq_open() or sem_open() are performed targetting a specific
service, and as such use a specific file_type of _FTYPE_MQUEUE or _FTYPE_SEM.

There is no conventional way through the currently documented API to take
advantage of this service/file_type provision.

What is the proper way to fill in directory information in the read handler
There are a number of different techniques to use. For simple information (ie no extended stat information) then this code sample should work properly:
#include /* For ALIGN and ALIGNBYTES */ ... struct dirent *dent; int reclen;
/*
Determine the size of the next entry and make sure that we have
enough space for it. Make sure to include the alignment adjustment
(even though the last entry to be sent doesn’t need it). Note that
the length of the string does not include an extra character for
the null, because this extra null character is already accounted for
in the dirent structure (name[1]).
*/
reclen = ALIGN(sizeof(*dent) + strlen(fname));
if (nbytes < reclen) {
break;
}

/* Fill in the dirent structure now that we know we have space /
dent->d_ino = some_inode_value;
dent->d_offset = some_offset_value;
/ This is the aligned record length /
dent->d_reclen = reclen;
/ This is the name length, name is null terminated but this is a hint */
dent->d_namelen = strlen(fname);
strcpy(dent->d_name, fname);

dent = (struct dirent *) ((char *)dent + dent->d_reclen);

\: Take a look at the devctl](http://staff.qnx.com/~thomasf/nto.html%22%3Edevctl) example here which shows how a client and a server work using a simple devctl.
I still can't get devctl() to return the value I specify. More help?
The devctl() function has its last argument as a pointer to an int which is a status/info value. This field is populated with the io_devctl_t.o.ret_val field from the resource manager.

devctl() is busted ... you can only return < 16k of data
The problem is most likely the fact that the command integer of the devctl() function is designed to be overloaded. From we see:
#define __DIOF(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_FROM) #define __DIOT(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_TO) #define __DIOTF(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_TOFROM) with #define _POSIX_DEVDIR_NONE 0 #define _POSIX_DEVDIR_TO 0x80000000 #define _POSIX_DEVDIR_FROM 0x40000000

Now if you defined the structure 'data' to be larger than 16 bits, it will likely overrun into the top bits of the devctl command integer. Unfortunately these top two bits are the only bits in the command integer that anything in the library looks at to determine if it should be sending or receiving data (or both). A better strategy is to encode the size of the data being passed inside the structure rather than have a huged enormous structure. You then pass the size to be transferred with the nbytes option to devctl() and this will indicate the number of bytes which will be used in MsgSend().

How do I know what messages contain?
All of the standard resource manager messages are defined as structures which typically take the form of:

typedef union { struct _io_ i struct _io__reply o } io__t

These messages are all defined in the header file <sys/iomsg.h>
which makes for some very intersting and occasionally insightful
reading.

How can I guarantee I'm the only person on a mountpoint?
The short answer is that you can't. You can avoid duplication of your server by using the resource database minor/major numbers in Proc (see rsrcdbmgr_devno_attach() in the documentation), but be aware that there is a limit of 64 major numbers in the system. In order for a device resource manager to avoid being overlaid by other device resource managers it could use the _RESMGR_FLAG_BEFORE flag to resmgr_attach(), but doing so, while it may work, is not considered "fair play" with other resource managers.

For more information on pathname resolution you might want to search
QDN for an article which explains
how the Neutrino filesystem resolves names to particular servers.

What is the 4th field (file_type) of resmgr_attach() used for?
The file type field is an optimization which is used in the C library name resolution code to avoid contacting resource managers who only want to handle specific requests. It is a hint from the resource manager side to avoid additional resolution delays since a client connection is also established using a file_type.

The way that the matching is done is through the following matrix:

Server file_type

Client
file_type _FTYPE_ALL (-1) _FTYPE_ANY (0) _FTYPE_XXX (>0)

_FTYPE_ALL (-1) Illegal Illegal Illegal

_FTYPE_ANY (0) Contact Contact Contact

_FTYPE_XXX (>0) Contact Ignore (types match) ? Contact : Ignore

The all standard file operations (open, stat, unlink etc) are performed with a
file type of _FTYPE_ANY which all resource managers receive. Special connection
operations such as mq_open() or sem_open() are performed targetting a specific
service, and as such use a specific file_type of _FTYPE_MQUEUE or _FTYPE_SEM.

There is no conventional way through the currently documented API to take
advantage of this service/file_type provision.

What is the proper way to fill in directory information in the read handler
There are a number of different techniques to use. For simple information (ie no extended stat information) then this code sample should work properly:
#include /* For ALIGN and ALIGNBYTES */ ... struct dirent *dent; int reclen;
/*
Determine the size of the next entry and make sure that we have
enough space for it. Make sure to include the alignment adjustment
(even though the last entry to be sent doesn’t need it). Note that
the length of the string does not include an extra character for
the null, because this extra null character is already accounted for
in the dirent structure (name[1]).
*/
reclen = ALIGN(sizeof(*dent) + strlen(fname));
if (nbytes < reclen) {
break;
}

/* Fill in the dirent structure now that we know we have space /
dent->d_ino = some_inode_value;
dent->d_offset = some_offset_value;
/ This is the aligned record length /
dent->d_reclen = reclen;
/ This is the name length, name is null terminated but this is a hint */
dent->d_namelen = strlen(fname);
strcpy(dent->d_name, fname);

dent = (struct dirent *) ((char *)dent + dent->d_reclen);

\: The devctl() function has its last argument as a pointer to an int which is a status/info value. This field is populated with the io_devctl_t.o.ret_val field from the resource manager.
devctl() is busted ... you can only return < 16k of data
The problem is most likely the fact that the command integer of the devctl() function is designed to be overloaded. From we see:
#define __DIOF(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_FROM) #define __DIOT(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_TO) #define __DIOTF(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_TOFROM) with #define _POSIX_DEVDIR_NONE 0 #define _POSIX_DEVDIR_TO 0x80000000 #define _POSIX_DEVDIR_FROM 0x40000000

Now if you defined the structure 'data' to be larger than 16 bits, it will likely overrun into the top bits of the devctl command integer. Unfortunately these top two bits are the only bits in the command integer that anything in the library looks at to determine if it should be sending or receiving data (or both). A better strategy is to encode the size of the data being passed inside the structure rather than have a huged enormous structure. You then pass the size to be transferred with the nbytes option to devctl() and this will indicate the number of bytes which will be used in MsgSend().

How do I know what messages contain?
All of the standard resource manager messages are defined as structures which typically take the form of:

typedef union { struct _io_ i struct _io__reply o } io__t

These messages are all defined in the header file <sys/iomsg.h>
which makes for some very intersting and occasionally insightful
reading.

How can I guarantee I'm the only person on a mountpoint?
The short answer is that you can't. You can avoid duplication of your server by using the resource database minor/major numbers in Proc (see rsrcdbmgr_devno_attach() in the documentation), but be aware that there is a limit of 64 major numbers in the system. In order for a device resource manager to avoid being overlaid by other device resource managers it could use the _RESMGR_FLAG_BEFORE flag to resmgr_attach(), but doing so, while it may work, is not considered "fair play" with other resource managers.

For more information on pathname resolution you might want to search
QDN for an article which explains
how the Neutrino filesystem resolves names to particular servers.

What is the 4th field (file_type) of resmgr_attach() used for?
The file type field is an optimization which is used in the C library name resolution code to avoid contacting resource managers who only want to handle specific requests. It is a hint from the resource manager side to avoid additional resolution delays since a client connection is also established using a file_type.

The way that the matching is done is through the following matrix:

Server file_type

Client
file_type _FTYPE_ALL (-1) _FTYPE_ANY (0) _FTYPE_XXX (>0)

_FTYPE_ALL (-1) Illegal Illegal Illegal

_FTYPE_ANY (0) Contact Contact Contact

_FTYPE_XXX (>0) Contact Ignore (types match) ? Contact : Ignore

The all standard file operations (open, stat, unlink etc) are performed with a
file type of _FTYPE_ANY which all resource managers receive. Special connection
operations such as mq_open() or sem_open() are performed targetting a specific
service, and as such use a specific file_type of _FTYPE_MQUEUE or _FTYPE_SEM.

There is no conventional way through the currently documented API to take
advantage of this service/file_type provision.

What is the proper way to fill in directory information in the read handler
There are a number of different techniques to use. For simple information (ie no extended stat information) then this code sample should work properly:
#include /* For ALIGN and ALIGNBYTES */ ... struct dirent *dent; int reclen;
/*
Determine the size of the next entry and make sure that we have
enough space for it. Make sure to include the alignment adjustment
(even though the last entry to be sent doesn’t need it). Note that
the length of the string does not include an extra character for
the null, because this extra null character is already accounted for
in the dirent structure (name[1]).
*/
reclen = ALIGN(sizeof(*dent) + strlen(fname));
if (nbytes < reclen) {
break;
}

/* Fill in the dirent structure now that we know we have space /
dent->d_ino = some_inode_value;
dent->d_offset = some_offset_value;
/ This is the aligned record length /
dent->d_reclen = reclen;
/ This is the name length, name is null terminated but this is a hint */
dent->d_namelen = strlen(fname);
strcpy(dent->d_name, fname);

dent = (struct dirent *) ((char *)dent + dent->d_reclen);

\: The problem is most likely the fact that the command integer of the devctl() function is designed to be overloaded. From we see:
#define __DIOF(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_FROM) #define __DIOT(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_TO) #define __DIOTF(class, cmd, data) ((sizeof(data)<<16) + ((class)<<8) + (cmd) + _POSIX_DEVDIR_TOFROM) with #define _POSIX_DEVDIR_NONE 0 #define _POSIX_DEVDIR_TO 0x80000000 #define _POSIX_DEVDIR_FROM 0x40000000

Now if you defined the structure 'data' to be larger than 16 bits, it will likely overrun into the top bits of the devctl command integer. Unfortunately these top two bits are the only bits in the command integer that anything in the library looks at to determine if it should be sending or receiving data (or both). A better strategy is to encode the size of the data being passed inside the structure rather than have a huged enormous structure. You then pass the size to be transferred with the nbytes option to devctl() and this will indicate the number of bytes which will be used in MsgSend().
How do I know what messages contain?
All of the standard resource manager messages are defined as structures which typically take the form of:

typedef union { struct _io_ i struct _io__reply o } io__t

These messages are all defined in the header file <sys/iomsg.h>
which makes for some very intersting and occasionally insightful
reading.

How can I guarantee I'm the only person on a mountpoint?
The short answer is that you can't. You can avoid duplication of your server by using the resource database minor/major numbers in Proc (see rsrcdbmgr_devno_attach() in the documentation), but be aware that there is a limit of 64 major numbers in the system. In order for a device resource manager to avoid being overlaid by other device resource managers it could use the _RESMGR_FLAG_BEFORE flag to resmgr_attach(), but doing so, while it may work, is not considered "fair play" with other resource managers.

For more information on pathname resolution you might want to search
QDN for an article which explains
how the Neutrino filesystem resolves names to particular servers.

What is the 4th field (file_type) of resmgr_attach() used for?
The file type field is an optimization which is used in the C library name resolution code to avoid contacting resource managers who only want to handle specific requests. It is a hint from the resource manager side to avoid additional resolution delays since a client connection is also established using a file_type.

The way that the matching is done is through the following matrix:

Server file_type

Client
file_type _FTYPE_ALL (-1) _FTYPE_ANY (0) _FTYPE_XXX (>0)

_FTYPE_ALL (-1) Illegal Illegal Illegal

_FTYPE_ANY (0) Contact Contact Contact

_FTYPE_XXX (>0) Contact Ignore (types match) ? Contact : Ignore

The all standard file operations (open, stat, unlink etc) are performed with a
file type of _FTYPE_ANY which all resource managers receive. Special connection
operations such as mq_open() or sem_open() are performed targetting a specific
service, and as such use a specific file_type of _FTYPE_MQUEUE or _FTYPE_SEM.

There is no conventional way through the currently documented API to take
advantage of this service/file_type provision.

What is the proper way to fill in directory information in the read handler
There are a number of different techniques to use. For simple information (ie no extended stat information) then this code sample should work properly:
#include /* For ALIGN and ALIGNBYTES */ ... struct dirent *dent; int reclen;
/*
Determine the size of the next entry and make sure that we have
enough space for it. Make sure to include the alignment adjustment
(even though the last entry to be sent doesn’t need it). Note that
the length of the string does not include an extra character for
the null, because this extra null character is already accounted for
in the dirent structure (name[1]).
*/
reclen = ALIGN(sizeof(*dent) + strlen(fname));
if (nbytes < reclen) {
break;
}

/* Fill in the dirent structure now that we know we have space /
dent->d_ino = some_inode_value;
dent->d_offset = some_offset_value;
/ This is the aligned record length /
dent->d_reclen = reclen;
/ This is the name length, name is null terminated but this is a hint */
dent->d_namelen = strlen(fname);
strcpy(dent->d_name, fname);

dent = (struct dirent *) ((char *)dent + dent->d_reclen);

\: All of the standard resource manager messages are defined as structures which typically take the form of:

typedef union { struct _io_ i struct _io__reply o } io__t

These messages are all defined in the header file <sys/iomsg.h>
which makes for some very intersting and occasionally insightful
reading.
How can I guarantee I'm the only person on a mountpoint?
The short answer is that you can't. You can avoid duplication of your server by using the resource database minor/major numbers in Proc (see rsrcdbmgr_devno_attach() in the documentation), but be aware that there is a limit of 64 major numbers in the system. In order for a device resource manager to avoid being overlaid by other device resource managers it could use the _RESMGR_FLAG_BEFORE flag to resmgr_attach(), but doing so, while it may work, is not considered "fair play" with other resource managers.

For more information on pathname resolution you might want to search
QDN for an article which explains
how the Neutrino filesystem resolves names to particular servers.

What is the 4th field (file_type) of resmgr_attach() used for?
The file type field is an optimization which is used in the C library name resolution code to avoid contacting resource managers who only want to handle specific requests. It is a hint from the resource manager side to avoid additional resolution delays since a client connection is also established using a file_type.

The way that the matching is done is through the following matrix:

Server file_type

Client
file_type _FTYPE_ALL (-1) _FTYPE_ANY (0) _FTYPE_XXX (>0)

_FTYPE_ALL (-1) Illegal Illegal Illegal

_FTYPE_ANY (0) Contact Contact Contact

_FTYPE_XXX (>0) Contact Ignore (types match) ? Contact : Ignore

The all standard file operations (open, stat, unlink etc) are performed with a
file type of _FTYPE_ANY which all resource managers receive. Special connection
operations such as mq_open() or sem_open() are performed targetting a specific
service, and as such use a specific file_type of _FTYPE_MQUEUE or _FTYPE_SEM.

There is no conventional way through the currently documented API to take
advantage of this service/file_type provision.

What is the proper way to fill in directory information in the read handler
There are a number of different techniques to use. For simple information (ie no extended stat information) then this code sample should work properly:
#include /* For ALIGN and ALIGNBYTES */ ... struct dirent *dent; int reclen;
/*
Determine the size of the next entry and make sure that we have
enough space for it. Make sure to include the alignment adjustment
(even though the last entry to be sent doesn’t need it). Note that
the length of the string does not include an extra character for
the null, because this extra null character is already accounted for
in the dirent structure (name[1]).
*/
reclen = ALIGN(sizeof(*dent) + strlen(fname));
if (nbytes < reclen) {
break;
}

/* Fill in the dirent structure now that we know we have space /
dent->d_ino = some_inode_value;
dent->d_offset = some_offset_value;
/ This is the aligned record length /
dent->d_reclen = reclen;
/ This is the name length, name is null terminated but this is a hint */
dent->d_namelen = strlen(fname);
strcpy(dent->d_name, fname);

dent = (struct dirent *) ((char *)dent + dent->d_reclen);

\: The short answer is that you can't. You can avoid duplication of your server by using the resource database minor/major numbers in Proc (see rsrcdbmgr_devno_attach() in the documentation), but be aware that there is a limit of 64 major numbers in the system. In order for a device resource manager to avoid being overlaid by other device resource managers it could use the _RESMGR_FLAG_BEFORE flag to resmgr_attach(), but doing so, while it may work, is not considered "fair play" with other resource managers.

For more information on pathname resolution you might want to search
QDN for an article which explains
how the Neutrino filesystem resolves names to particular servers.
What is the 4th field (file_type) of resmgr_attach() used for?
The file type field is an optimization which is used in the C library name resolution code to avoid contacting resource managers who only want to handle specific requests. It is a hint from the resource manager side to avoid additional resolution delays since a client connection is also established using a file_type.

The way that the matching is done is through the following matrix:

Server file_type

Client
file_type _FTYPE_ALL (-1) _FTYPE_ANY (0) _FTYPE_XXX (>0)

_FTYPE_ALL (-1) Illegal Illegal Illegal

_FTYPE_ANY (0) Contact Contact Contact

_FTYPE_XXX (>0) Contact Ignore (types match) ? Contact : Ignore

The all standard file operations (open, stat, unlink etc) are performed with a
file type of _FTYPE_ANY which all resource managers receive. Special connection
operations such as mq_open() or sem_open() are performed targetting a specific
service, and as such use a specific file_type of _FTYPE_MQUEUE or _FTYPE_SEM.

There is no conventional way through the currently documented API to take
advantage of this service/file_type provision.

What is the proper way to fill in directory information in the read handler
There are a number of different techniques to use. For simple information (ie no extended stat information) then this code sample should work properly:
#include /* For ALIGN and ALIGNBYTES */ ... struct dirent *dent; int reclen;
/*
Determine the size of the next entry and make sure that we have
enough space for it. Make sure to include the alignment adjustment
(even though the last entry to be sent doesn’t need it). Note that
the length of the string does not include an extra character for
the null, because this extra null character is already accounted for
in the dirent structure (name[1]).
*/
reclen = ALIGN(sizeof(*dent) + strlen(fname));
if (nbytes < reclen) {
break;
}

/* Fill in the dirent structure now that we know we have space /
dent->d_ino = some_inode_value;
dent->d_offset = some_offset_value;
/ This is the aligned record length /
dent->d_reclen = reclen;
/ This is the name length, name is null terminated but this is a hint */
dent->d_namelen = strlen(fname);
strcpy(dent->d_name, fname);

dent = (struct dirent *) ((char *)dent + dent->d_reclen);

\: The file type field is an optimization which is used in the C library name resolution code to avoid contacting resource managers who only want to handle specific requests. It is a hint from the resource manager side to avoid additional resolution delays since a client connection is also established using a file_type.

The way that the matching is done is through the following matrix:

Server file_type

Client
file_type _FTYPE_ALL (-1) _FTYPE_ANY (0) _FTYPE_XXX (>0)

_FTYPE_ALL (-1) Illegal Illegal Illegal

_FTYPE_ANY (0) Contact Contact Contact

_FTYPE_XXX (>0) Contact Ignore (types match) ? Contact : Ignore

The all standard file operations (open, stat, unlink etc) are performed with a
file type of _FTYPE_ANY which all resource managers receive. Special connection
operations such as mq_open() or sem_open() are performed targetting a specific
service, and as such use a specific file_type of _FTYPE_MQUEUE or _FTYPE_SEM.

There is no conventional way through the currently documented API to take
advantage of this service/file_type provision.
What is the proper way to fill in directory information in the read handler
There are a number of different techniques to use. For simple information (ie no extended stat information) then this code sample should work properly:
#include /* For ALIGN and ALIGNBYTES */ ... struct dirent *dent; int reclen;
/*
Determine the size of the next entry and make sure that we have
enough space for it. Make sure to include the alignment adjustment
(even though the last entry to be sent doesn’t need it). Note that
the length of the string does not include an extra character for
the null, because this extra null character is already accounted for
in the dirent structure (name[1]).
*/
reclen = ALIGN(sizeof(*dent) + strlen(fname));
if (nbytes < reclen) {
break;
}

/* Fill in the dirent structure now that we know we have space /
dent->d_ino = some_inode_value;
dent->d_offset = some_offset_value;
/ This is the aligned record length /
dent->d_reclen = reclen;
/ This is the name length, name is null terminated but this is a hint */
dent->d_namelen = strlen(fname);
strcpy(dent->d_name, fname);

dent = (struct dirent *) ((char *)dent + dent->d_reclen);

\: There are a number of different techniques to use. For simple information (ie no extended stat information) then this code sample should work properly:
#include /* For ALIGN and ALIGNBYTES */ ... struct dirent *dent; int reclen;
/*
Determine the size of the next entry and make sure that we have
enough space for it. Make sure to include the alignment adjustment
(even though the last entry to be sent doesn’t need it). Note that
the length of the string does not include an extra character for
the null, because this extra null character is already accounted for
in the dirent structure (name[1]).
*/
reclen = ALIGN(sizeof(*dent) + strlen(fname));
if (nbytes < reclen) {
break;
}

/* Fill in the dirent structure now that we know we have space /
dent->d_ino = some_inode_value;
dent->d_offset = some_offset_value;
/ This is the aligned record length /
dent->d_reclen = reclen;
/ This is the name length, name is null terminated but this is a hint */
dent->d_namelen = strlen(fname);
strcpy(dent->d_name, fname);

dent = (struct dirent *) ((char *)dent + dent->d_reclen);

\

Thomas Fletcher -- QNX](http://www.qnx.com/products/os/neutrino.html%22%3EQNX) Neutrino Development Group
, http://www.qnx.com/~thomasf
The opinions expressed on this page are those of Thomas Fletcher and not QNX Software Systems

Bill_Caroselli_Q-TPS · October 15, 2001, 7:55pm

<thomasf@qnx.com> wrote in message news:9qf5sb$3j8$1@nntp.qnx.com…

Alain (and the crowd that followed),

The developer run pages will at some point be making a
comeback, when that will be has not yet been determined
(ie beyond my personal control). Developers.qnx.com is
the official source for non-official source packages
(ala old style quics). For developer controlled content
pages … stay tuned.

“Offically, unofficial”?

“Protocol”, right?

Or is this subject really most sencerely dead?

*Server file_type*
Client file_type		_FTYPE_ALL (-1)	_FTYPE_ANY (0)	_FTYPE_XXX (>0)
_FTYPE_ALL (-1)	Illegal	Illegal	Illegal
_FTYPE_ANY (0)	Contact	Contact	Contact
_FTYPE_XXX (>0)	Contact	Ignore	(types match) ? Contact : Ignore

Hey Thomas Fletcher

–

my opinions are mine, only mine, solely mine, and they are not related in any possible way to the institution(s) in which I study and work.

–

my opinions are mine, only mine, solely mine, and they are not related in any possible way to the institution(s) in which I study and work.

Thomas

Neutrino Resource Manager FAQ

my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.

my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.