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