| |||||||||||||
HALs considered harmfulHALs considered harmfulPosted Mar 17, 2005 12:40 UTC (Thu) by sdalley (subscriber, #18550)Parent article: HALs considered harmful
Although it might have been gone over "a thousand times before" I am totally at a loss to understand this reasoning.
It is *sometimes* necessary to program as close to the metal as possible for reasons of speed. However, for reasons of maintainability, it always makes sense to do what is called "information hiding", i.e. to hide the specifics of the OS-specific interfaces in one place under more generic wrappers, and call those wrappers from the device-specific stuff. This does not just make things easier for the vendor to target multiple OSes, it also localises the linux-kernel interface calls in a small area, typically one file. The kernel maintainers then have only one file to worry about when the inevitable function call interface changes occur.
Done right, it should make the kernel maintainer's job easier as well as the vendor's job. What am I missing here ? (scratches head).
(Log in to post comments)
HALs considered harmful Posted Mar 17, 2005 13:30 UTC (Thu) by vonbrand (subscriber, #4458) [Link] You are certainly right about "information hiding". But if each driver does the hiding in its own particular way, you get nowhere fast. Yes, Linux has information hiding in place (like the list handling macros, much of the driver interface, ...). Use that. You could even write a glue layer from Linux conventions to other systems ;-)
HALs considered harmful Posted Mar 17, 2005 21:38 UTC (Thu) by farnz (guest, #17727) [Link] The kernel API provides its own HAL; what these drivers do is provide a "HAL to HAL" translation layer from their own internal HAL to the kernel HAL, often adding variants on existing kernel infrastructure (your own spinlock implementation, for example), because the existing infrastructure has different semantics to your internal version, and you don't want to translate between them.
|
|||||||||||||