> From: Matt Brubeck <[EMAIL PROTECTED]> > > The issue of 'uname -pm' is separate, and I agree with you there.
Matt- You are right. These are two separate issues. - Regarding kernel -powermac appened in pre-compiled kernel images: OK. I think I got it. I point my includes to the header files I downloaded separately (kernel-headers) and then I get the correct version (the version.h is correct.) BUT: if I compile a driver in my project using these non-custom headers (with -I/usr/src/kernel-headers...) and then insmod the built driver against this pre-compiled kernel I am using, I get an error with version clashing still (which I made a warning by forcing the insmod to ignore version for now.) This is still far from ideal. So unless I recompile the kernel (which I can't do as it's buggy and doesn't even compile), I have to either modify the version.h file, either ignore version when doing insmod. Nothing fancy, I just want to follow what's in the Device Drivers book from O'Reilly. And this doesn't work when I am on testing. - Regarding the uname -p returning unknown: What can I do to help resolve this issue? Right now, the kludge I have implemented to get my makefiles to function on linux without changing anything, let alone being able to use them cross-platform, is ugly at best (I overload the bogus uname command on linux with a script that returns what uname -m returns for uname -p. The script lives in a path that shows earlier than /bin. Yuk!) I do that because I don't think it's right to change all my makefiles. I could have tested uname -s then exec uname -m in case of linux, or a uname -p if something else. Still Yuk! uname -p is far from being unknown: it's the processor of the machine. I have decided to report this as a bug to [EMAIL PROTECTED] Is that the right thing to do? Your input is, as usual, greatly appreciated. Laurent
