On 08/12/06, Fabio De Francesco <fabiomdf@xxxxxxxx> wrote: ...
In hacking Linux code often we have to access data structures and variables embedded in them. We all know that most of these objects need some special attention when manipulating them, like previous verifying of some particular condition, acquiring locks, atomically r/w and so on. This is why developers of core structure usually provide some standardized controlled data access method as macros and as other function interfaces. As an example (maybe it is not the most appropriate), "set_task_state(task, state)" not only sets the given task the given state, it also provide a memory barrier() when needed (SMP). If I am not missing something, only on UP it is a simpler "task->state = state". The problem is that any client code handling the variable "task->state" could change its value without being forced to only use the set_task_state() macro. This may well be a bug. Obviously the example can be extended to any data variable that needs particular care in dealing with. Someone hacking kernel code might not even know that a special interface has been created and should be used. Those interfaces are disseminated in headers so that overlooking them might be not so exceptional. Sometimes it also happens to me to miss the existence of an interface and so I write code that directly manipulate that data which only by chance, often either from reading code developed by others or when debugging something that doesn't work, I eventually find the proper way to access. Now I have three question: 1) Is what I discuss here a perceived problem?
No. It is generally seen as an advantage, not a problem.
Am I missing something that makes this a no problem?
The reason it is not seen as a problem is that it is expected that people know or learn the proper interfaces before writing code. There are also situations where you want to "bend the rules" if you know from context that use of the proper interface is not required - this may be used to implement optimizations in certain cases or do other clever hacks.
2) Is it possible to enforce, in client's code, the use of the proper interfaces to core kernel structures?
No.
(I mean something like the object oriented language as C++ do with "private" objects embedded data that can only be initialised, accessed and finalized by public interfaces).
The kernel is written in C, not C++. As a result you get great flexibility and enough rope to hang yourself ;) People writing kernel code are expected to know C well and to know when to be careful and when to take advantage of the freedom C gives you.
3) If both C language and GCC extension couldn't help, is there any idea for practical solutions within Linux kernel?
It's not a problem. No solution needed. -- Jesper Juhl <jesper.juhl@xxxxxxxxx> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
