[OpenAFS] Linux 2.6 support

[Jeffrey Hutzelman]

On Tuesday, June 08, 2004 12:01:50 -0400 Derek Atkins <warlord@MIT.EDU> 
wrote:

> "chas williams (contractor)" <chas@cmf.nrl.navy.mil> writes:
>
>> In message <40C5D0CD.1080703@ics.muni.cz>,Miroslav Ruda writes:
>>>  checking if kernel uses MODVERSIONS... no
>>>  checking which kernel modules to build... MP SP
>>>  configure: WARNING: Cannot determine sys_call_table status. assuming
>>>  it isn' t exported
>>
>> configure is making the wrong guess.  it hard to determine if
>> sys_call_table is exported (without examing the kernel itself).
>> for now, after running configure, modify afsconfig.h and change
>> it so that it think sys_call_table is exported.
>
> the question is: why is configure making the wrong guess?

Because it is in fact a guess, rather than a test.

In 2.4, there is no easy way to test without CONFIG_MODVERSIONS, so we have 
to guess instead.  We always guess the same thing -- that's what makes it a 
"guess" rather than a "test".

In 2.6, there is no easy way to test, period.  So just for the purpose of 
configure, we pretend that CONFIG_MODVERSIONS is not defined even if it 
really is.  The result is that the "guess" logic is invoked.  Again, we 
always guess the same thing.


It used to be that we guessed that sys_call_table _was_ exported, because 
if not, well, you were probably screwed (particularly, since we can't test 
whether symbols are exported, there's no way to determine which variant of 
the scanning code to use).

Now, that's not true any more -- you can get by without the sys_call_table 
export, as long as you don't care about PAGs, because everything that used 
to be done using the AFS syscall can be done instead using the new 
interface.

Which brings me back to the original poster's problem.  If he's really 
building recent CVS against a stock 2.6.6 or newer kernel, then not having 
sys_call_table exported is NOT the reason why afsd won't start -- it will 
use the new interface and not even try the syscall.  And in any case, it 
certainly won't "hang forever" -- that implies that it's actually getting 
into kernel code, since there's no substantial code in afsd itself.

It seems more likely that the problem is that we've really only ported to 
2.6 _on the i386 architecture_.  There are quite a variety of places where 
cases have been added for i386_linux26 but not for other *_linux26.  And 
even once that's done, it is likely that each platform has its own special 
problems to be addressed, as is usual.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA