IO RESMGR QUESTION - Extending IOFUNC_ATTR_T multiple times


This is my first (useful) resource manager so please bare with me. I’m writing a resource manager for an IO card that has 8 input and 8 output channels.

I am wanting to register multiple devices so you will be able to see:


Now my problem starts with how does the resmgr_io_funcs_ functions figure out which one was opened (in0, or out3 etc). My thought was to extend the IOFUNC_ATTR_T structure to contain an “io channel id” and create an array of these structures that is initialized with a different “io channel id” value for each element. This way whenever the _io_read function runs, it will be able to look up the value of ocb->attr->io_channel_id and know exactly which device is being used.

First question is: Is there a more standard way of figuring out which device was sent a open/read/write/etc request for a resource manager with multiple registered devices??

The next thing I wanted to do is create two different extenstions of IOFUNC_ATTR_T (one for the input channels and one for the output channels), but by using the #define statement I don’t think theres another way. I guess I could add a in/out flag to the extended attribute structure, but this seems messy.

Second question: Is there a way of overriding the IOFUNC_ATTR_T with multiple functions?

I hope this made sense.

Matter of preferences, but it would map


/dev/in all is desirable because you may want to read more then one input atomicaly.


Again all/setall/resetall can be desirable for atomic operation. Also the setall and resetall can be masks based. You set to 1 the io bits you’d want to alter.

I find having each io’s inside subdirectory a nice precaution in case your system grow to 128 IO’s; ls /dev/ would become rather crowded :wink:

That’s how I would do it.

Not that I’m aware of. The attribute as a path avaible I beleive you could use that to parse it and extract the “channel id” but extending the attribute is the clean way to do this.

If you split the in and out in two distinct C files and each having their own read, write attribute you could use #define.

That being said you have the other alternative of implementing the paths as I suggested above and have only two mount point (hence attribute). One for /dev/in and one of /dev/out, the two entires would be mounted as directory and your resource manager would be responsible for handling directory and path name within the directory. I prefer to do that because make me feel empowered :wink: This is well described in Robert’s Cook Book.

Are you suggesting to use the “filesystem mount” aspect of resource managers ala the RAM Filesystem from the Cook Book (if so, I read that yesterday, got thouroughly confused and decided to scale back the complexity)

Thanks for your help