views:

70

answers:

2

I just wrote a RTC driver for an NXP RTC chip on my board, it works great. This chip also has some battery backed RAM that I'd like to make available to a user space application. The RTC framework doesn't support this. It's only 512 bytes but I'm tossed between doing a seekable CHAR driver or a full blown BLOCK driver. I've never done a block driver before but it appears to require a bit more information than a simple CHAR.

I could also interface with IOCTLS but that doesn't feel as clean as it could be. What feels like the best way to make these bytes available to userland?

[EDIT] I forgot to mention that that the RTC chip is hanging off an I2C port, it's not mapped into memory, thus not making it a good candidate for mmaping. [/EDIT]

+1  A: 

I think a character device driver implementing mmap should be adequate. Linux Device Drives covers that in chapter 15.

Edit:

Well, i2c is a serial bus, so mmap is not an option. I will refer you to Essential Linux Device Drivers book. I believe it has a sample i2c EEPROM char device driver in Chapter 8. Hope this helps.

Nikolai N Fetissov
Nikolai, the RTC chip is on an I2C bus, without having the NVRAM mapped into memory I don't see how mmap is a likely candidate, but I might be wrong.
+1  A: 

Block drivers are only for devices that look like disk drives. Are you going to put a filesystem on your 512 bytes? No? Make it a character device.

You could just do it like other drivers have. Check out drivers/char/nvram.c. That creates a char device you can open(), read(), write(), lseek(), and close().

JayM
While your answer came later than the implementation, it was what I ended up doing. I just implemented a simple char driver with lseek and it's working just fine.