paulbarker wrote:
Apart from number 9 about using standard libraries (not always possible for a kernel), all these things do apply to systems programming as much as applications programming.
In a sense,
especially number 9 applies to systems programming.
1) If you name a kernel function after a standard C function, make very sure that it behaves identically to the standard one.
2) If you create a function that is very close but not identical to a standard C function, reconsider whether it would be possible to make it
identical, and cater for the small differences between the standard and your expectations elsewhere.
Both items reduce the probability of someone else being "surprised" by your code. It's OK if your kprintf() doesn't cater for floating point values because you don't use any in your kernel, but it's not OK if it turns "%%" into something else but "%", does support "%d" but not "%i", automatically adds a '\n' at the end, or doesn't return an int. If you insist on doing it differently, don't call the function kprintf() but something else, and if at all possible, make it consistent with whatever user-space API you provide for formatted output.
Same for kmalloc() - if you make it accept more than a single parameter, or return something different from the standard, call it something else, because people see "(k)malloc" and expect it to behave in a certain way.