0

I'm slightly unclear as to the method/wisdom of breaking a kernel module into smaller source files. The recommendation is to have everything as static, which negates calling functions between source files. I've seen EXPORT_SYMBOL but I believe that applies to other modules and not to the the kernel. I could be wrong there though.

Is there a guide to how to do this without accidently clobbering some other function in the kernel? Or, if I preface each function with mymodule_function, is that good enough. I could always use #include "nextfile.c" in firstfile.c! I see a lot of driver code is in one very large file, possibly for this reason...

carveone
  • 889
  • 9
  • 16
  • The rationale behind using multiple files is to simplify the code by breaking a driver into functional blocks. You can share symbols by making them part of a struct and passing a pointer to that struct between functions. #include-ing any .c file from another is ugly, IMHO. – Peter L. Feb 26 '14 at 22:47
  • I understand but you'd still need the function to be visible. It's possible I'm overthinking things - I see plenty of non static functions in various sources. #including a c file (http://stackoverflow.com/questions/232693/including-one-c-source-file-in-another) is not an unreasonable thing to do IMHO - they're all just tools. Slightly ugly but I wouldn't go out of my way to not do it - in unit testing it's often necessary. – carveone Feb 27 '14 at 12:01
  • Sure, a little late, still presenting the idea: *If* including C files in other ones, I'd not do it like A including B including C including..., but I'd have one file not containing *any code at all* including all the other files. This way the real code files stay independent one from another. – Aconcagua Jul 20 '18 at 16:15

0 Answers0