[OpenAFS-devel] Re: autoconf

[Derek Atkins]

aeneous@speakeasy.org writes:

> Most of the "features" that are system-dependent, on which AFS depends,
> are not features at all, and are not things that autoconf is going to 
> know about.
> 
> They are things like -- is the "size" field in the inode named "size",
> or "i_size"?  How many parameters does vfs_strategy take? Should I use
> socket code in the kernel or TLI?  How do I lock an in-core inode?

This is only the kernel module.  Yes, the kernel module is always
going to depend upon the platform (CPU+hardware architecture) and the
OS (including version number).  The rest of AFS (which is pretty much
MOST of the code) doesn't depend on that-much kernel-specific code.
Which implies that you could autoconf the rest of AFS.

Porting will still require kernel-specific knowledge.  But that will
never change.  But if someone ported the OpenAFS kernel to, say, the
PPC under NetBSD, and I already had a port to Linux, then autoconf
should be able to combine the PPC + linux code and it _should_ just
work.

> I'm not sure this is "merely tedious".  I think Bill S. underestimates 
> the magnitude of the final merge if it's to be all done at once.  

No, it's not "easy", but you can abstract a lot of it out.  In
user-space you can autoconf based on features.  In the kernel, you can
autoconf based on two separate (and hopefully orthogonal) issues,
CPU/Platform and OS.

And no, I don't think Bill under-estimates the magnitude of the final
merge.  I know Bill, and I know he knows exactly what it entails.
Besides, merging in CVS is a relatively simple task.  What it means is
that once the autoconf code is completed, you merge any changes off
the mainline into your branch and then you commit it back to the
mainline.

> However, I do think that the job can be tackled in stages.
> First, don't touch any of the code itself, just restructure the build
> environment so as not to need washtool and then set up a simple 
> set of #defines from autoconf system identifiers to AFS_SYSID names.

I'm not convinced this is the right approach, in the long run.  It may
be the stages that are done.  But I agree that autoconf shoudn't be
committed until it is "done".  And FTR, you can build the tree as it
is without washtool.

> Once that is done, you can go through the code module by module and 
> #ifdef AFS_NEXT_ENV (eg) with #if BSD_SIGNALS or whatever as 
> appropriate.
> 
> The hardest module will be the CM.  Perhaps the others really will be 
> merely tedious.  We can hope.

I agree that the CM will be the hardest part.  But I think that needs
to be done differently, as I stated above.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available