Hi all,
I am writing a driver for a device which acts as both mouse and joy stick based on the bits set in the status registers and uses spi and twi protocols . My application sends ioctl to change device mode and bus mode whenever it needs to change. I also have to load patch file into the device when the driver is initalising. My application also queries about the device state information whenever it requires through ioctl.
My question is how can a driver maintains all these information because my application don't need to know maintains this informations. So my driver has to maintain this information i.e device mode whether it is mouse or joystick and bus modes whether it is spi or twi and patch file location to load into the device. And also when the system reboots the device has to be in the previous state what ever it is before shutdown. Can any one help me in this case.
I try to store the information in a file through structure which contains device mode ,busmode and patch file location and peform file operations through driver whenever any one of the structure element changes but it is not working because we are not supposed to do file operations in a kernel module . Please help whether there is any way to do this. I also want to know how normal driver in linux are maintaining the device configuration files i.e how display driver maintains the screen height and width i.e at any time i can change the screen size and resolution when the system reboots also the screen will be in same height and resolution which i was set before shutdown. How this is maintained by the drivers whether the driver or maintaining or someelse is maintaining this information.

In the case of "screen size and resolution," for example, that is probably being maintained by XWindows, a user-land daemon program, not by the kernel at all.

One of the pointers in the device-block is a pointer to driver data, and there's a similar per-instance pointer available in the file-block for each open instance of a (device) file. So there are various places to squirrel away what you need. But none of these are persistent, because for devices you generally don't "save state." You initialize the device the way that you want it, or you ask the device what its current state is and, in the case of removable devices, you make sure that you have a way of being notified of changes. The previous (saved) state of a device has absolutely no bearing on what its state might be now: all that you can do is ask, and tell.

The way that I think I would approach this problem is by adding one additional layer of user-land code to the mix: a shared library. This code would know all about your specific IOCTLs and, if it needed to save some state information it would do that, using an ordinary user-land file in the user's home directory.

For example, the initialization-sequence for your joystick cum mouse, as implemented in the library, might consist of opening the device, ordering it to go into joystick mode, reading the latest patch-number, writing one or more patches to it, and so-on. Perhaps dozens of specialized IOCTL calls. Your interface library, not the low-level kernel code, is "the real smartypants" here.