On Wednesday, March 16, 2005 10:50:31 PM -0600 Troy Benjegerdes <[EMAIL PROTECTED]> wrote:
On Wed, Mar 16, 2005 at 07:57:18PM -0500, Jeffrey Hutzelman wrote:
On Monday, March 14, 2005 11:27:08 AM +0100 Harald Barth <[EMAIL PROTECTED]> wrote:
> >> (e.g. most Solaris versions need the C compiler from >> the SUNWspro suite). > > I wrote configure 2 tests a long time ago which test if the Solaris or > the AIX compiler are "good enough". Still waiting for them to be used. > > According to my view of things, folks setting CC should know what they > do and the makefiles should not override it. For folk _not_ setting > CC the makefiles can do what they figure is best.
Unfortunately, this is pretty hard to get right, because once the AC_PROG_CC test has run, there is really no way to tell if the resulting value of CC came from the user or from the test. And it's pretty hard to get AC_PROG_CC not to run.
Further, I don't think it's reasonable to assume that folks setting CC on configure's command line understand the kernel compiler issue, or that people who do understand the issue necessarily want to override the kernel compiler whenever they set CC to select a userland compiler.
I don't think it's reasonable to assume that 'cc' is what you want to build with. If folks can't set CC, they will go hack the makefiles directly.
Maybe you're not reading the same thread I am. I didn't say users shouldn't be able to override the compiler; I said it was hard to get it right, particularly with the behaviour haba described. If it were easy, it'd have already been done, and we wouldn't be having this conversation.
Harald suggested that if a user sets CC on the command line, we should assume they know what they are doing. As I explained, there are two problems with this:
- It is impossible for the Makefiles, or even most of the configure tests, to tell the difference between a value of CC that was set on the command line and one that was set by AC_PROG_CC - It is a bad idea to assume that a user who sets CC on the command line "knows what they are doing" and expects to use that compiler to build the kernel module, because they probably don't know what they're doing wrt the kernel compiler issue, and if they do, they probably don't want to use that compiler for the kernel module.
The kernel compile better be using the compiler the kernel was built with. In the case of Linux, I think this is all handled with the kernel makefiles.
Actually, the Linux makefiles generally assume you want to use 'gcc' unless you specify something else on the command line. This often turns out to be the right choice, but not always.
And of course, OpenAFS is a multi-platform software package, not a Linux-2.6-specific one, so even if kbuild solved the problem, that wouldn't excuse us from dealing with it on AIX and Solaris and HPUX and Linux 2.4.
This issue would be a lot easier to sort out if the kernel and userland code were clearly separated. Or at least the build process. Is there documentation or whitepapers that I can look up at what afsd actually does before handing off control to libafs in the kernel? I'm wondering why both afsd and libafs are so big.
You can read src/afsd/afsd.c; it's actually a fairly simple program. I'm not sure why you believe afsd is 'big'; mine is all of 168K.
What happens if I have a 32 bit userland, and a 64 bit kernel, for example. So far I've always punted and built all of afs 64 bit.
With the exception of afsd, we are rapidly approaching the point where 32-bit userland tools can be expected to work on most of the 64-bit Linux platforms. As of the 1.3.80 release due out shortly, I expect this will work for any process using the /proc interface (wihch is the case for anything linked against a reasonably modern version of either the OpenAFS libraries or KTH's libkafs), and for processes using the syscall interface on those architectures where we successfully locate and patch the secondary 32-bit syscall table. You will be able to tell if this works by looking at dmesg output after loading the libafs module; it print either the address of the 32-bit syscall table, or a message indicating it could not be located.
There is currently no guarantee that a 32-bit afsd will work with a 64-bit kernel. For this to work, the kernel code would have to translate some of the data structures passed in by a 32-bit afsd, and I don't believe the analysis has been done to determine which structures are affected and make sure they are handled.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
_______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
