Book Note: Linux Device Driver Dos and Don'ts
http://janitor.kernelnewbies.org/docs/driver-howto.html
what a hardened (robust) device
driver should mean and how it should be implemented and measured.
1.3 Robust device drivers
-Follows the Linux CodingStyle.
-Efficient in managing faults and handling, reporting and recovering from errors.
(Also not panic() happy.)
-Complies with latest Linux kernel APIs and interfaces.
(Uses the new device driver model, kobjects and sysfs.)
-Properly manages resources (memory, semaphores, interrupts, etc.).
-Uses kernel-provided "C" I/O functions instead of assembly code.
2.0 Where do I start?
3.0 OK, I'm ready...
3.1 Efficient error handling, reporting and recovery:
1)<printk()>
you should always check printk() calls to include appropriate KERN_* constant.
2)<goto>
3) <Enumerated return codes> <return EWHATEVER should be return -EWHATEVER>
4) <No need to panic()>
Rather, the device driver should try to recover, re-initialize, or finally simply
return an appropriate error code, release allocated resources, log a message and
exit gracefully.
3.2.1 Module interface changes
<Initialization and cleanup>
<Module Reference Count macros>
You no longer need to adjust your own module reference count
-Reference counting from other modules:
;A Golden Rule: if you are calling through a function pointer into a (different) module,
you must hold a reference to that module.
Otherwise you risk sleeping in the module while it is unloaded.
You can get a reference to a module by using:
try_module_get(owner);
and you don't have to check if OWNER != NULL, this is done by try_module_g
