Resource manager questions

I’m trying to write my first resource manager. The resmgr will act as a
device driver allowing access to various I2C peripherals on a custom PPC
8240-based board (a real-time-clock, for example).

Unlike a file based resmgr, this one is more packet or message oriented
vs stream oriented. Each read would not advance a file pointer, but
generate a new transaction on the I2C bus to fetch data.

In this case, how do I handle the nbytes field in the _iofunc_attr
structure? Should it always be zero?

Since each read request would be a generate a new I2C transaction, I
wouldn’t return EOF. This would seem to prevent utilities like “cat
/dev/i2c/rtc” from working.

I’ve read the docs, Krten’s book and the various articles on resmgrs,
but I’m still confused. Any pointers / tips / sample code would be
appreciated.

Thanks!

Dan Giorgis

Dan Giorgis <dang@tridium.com> wrote:

I’m trying to write my first resource manager. The resmgr will act as a
device driver allowing access to various I2C peripherals on a custom PPC
8240-based board (a real-time-clock, for example).

Unlike a file based resmgr, this one is more packet or message oriented
vs stream oriented. Each read would not advance a file pointer, but
generate a new transaction on the I2C bus to fetch data.

In this case, how do I handle the nbytes field in the _iofunc_attr
structure? Should it always be zero?

It’s “whatever you feel like”. You can be clever, and use it to log how
many transactions your device has processed. Or how many errors. That
way, a quick “ls -l /dev/my_device” will instantly show you :slight_smile:

Since each read request would be a generate a new I2C transaction, I
wouldn’t return EOF. This would seem to prevent utilities like “cat
/dev/i2c/rtc” from working.

Does it make sense to “cat” the device? I.e., is there any data that
you could conceivable get that could be served up and processed on a
stdin/stdout basis? If not, then don’t bother making cat work – just
use the null iofunc_read_default() and iofunc_write_default() functions
that come pre-installed with the iofunc_func_init() call.

Sounds like if what you’re sending is only control packets, I’d just
go with an io_devctl() handler. See the example for the “simple”
io_devctl handlers in the book.

I’ve read the docs, Krten’s book and the various articles on resmgrs,
but I’m still confused. Any pointers / tips / sample code would be
appreciated.

Does this help? If not, ask more!

Cheers,
-RK


Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Consulting and Training at www.parse.com
Email my initials at parse dot com.

Dan Giorgis <dang@tridium.com> wrote:

I’m trying to write my first resource manager. The resmgr will act as a
device driver allowing access to various I2C peripherals on a custom PPC
8240-based board (a real-time-clock, for example).

Sure.

Unlike a file based resmgr, this one is more packet or message oriented
vs stream oriented. Each read would not advance a file pointer, but
generate a new transaction on the I2C bus to fetch data.

Sure. mqueue is, in some ways, a packet resource manager for message queues –
and it handles semaphores as file system entries as well, which are completely
not file pointer based.

Also, in a stream oriented case, there may be no concept of a current read
location either.

In this case, how do I handle the nbytes field in the _iofunc_attr
structure? Should it always be zero?

Sure, it can always be zero. The internals of the library only use it (from what
I can see) in the default handling for stat, to give the file size. If you want,
you could assign it some other meaning for your device.

Since each read request would be a generate a new I2C transaction, I
wouldn’t return EOF. This would seem to prevent utilities like “cat
/dev/i2c/rtc” from working.

This is perfectly reasonable. There is no such thing as an EOF from a serial
port either, right? Or, if you want, try “cat /dev/random” to see another device
that doesn’t return EOF. Hm… you might want to be ready to close that pterm
window if you cat /dev/random, and quickly, as you’ll probaby generate a LOT of
beeps as well as other garbage. :slight_smile:

I’ve read the docs, Krten’s book and the various articles on resmgrs,
but I’m still confused. Any pointers / tips / sample code would be
appreciated.

You sound like you’re doing fine. You get an io_read request, you send a request
out on the bus, get the answer, and reply with the data. Makes sense to me.

-David

QNX Training Services
I do not answer technical questions by email.