On Mon, Jun 25, 2007 at 04:16:04PM -0700, ron minnich wrote:
Right, I did this arch/lib.h thing in response to a request; people did not like arch/x86/lib.h in includes. I personally like it, as it reduces "magic".
We shouldn't need "magic" - just some simple logic.
Ie. 1:1 rules for what files go together - clear relationships between include/ and all that used to be in src/.
I would rather NOT have the arch directory, and i would rather NOT have duplicate names like lib.h.
include/lib.h currently has:
log2, {u,m,}delay, beep_{short,long}, smbus_read_byte, ram_failure and ram_initialize.
Shouldn't they just go into separate .h files? Or shouldn't all of the other files go into lib.h? I'm sorry if I've forgotten what we thought about all of this.
So, quick, somebody, make a suggestion. Where do we put cpu-dependent library functions? cpu.h?
Sounds good. In fact, include/arch/x86/cpu.h already has some (all?) of the code in the lx patch.
//Peter