Description of problem:

Admittedly this is not really a bug, it's just that autofs4
is not working on 64-Bit architectures not covered by the auto_fs.h
header file. I guess autofs3 has been fixed appropriately, but
we really need autofs4 cause of hierarchical automounts. The
problem is, that the type of the wait queue token used to identify
threads waiting for a certain mount is a 32 unsigned in the kernel,
but when building autofs-4.0.XY e.g. on a AMD opteron the type will
be a 64 bit unsigned. I don't know, how it is achieved, that the
x86_64 kernel uses a 32 bit type, cause it should use the same
header file during build (?!?). ANyway here is the problematic
snippet from the kernel's auto_fs.h header:


#if !defined(__alpha__) && !defined(__ia64__)
typedef unsigned int autofs_wqt_t;
#else
typedef unsigned long autofs_wqt_t;
#endif

i have no idea, why a long type has ever been specified here.
In my opinion this is a classical case for e.g. u_int32_t
defined in types.h . If a variable should always be 32 bit
unsigned, the appropriate type definition that is available
anyway can be used.
I built autofs-4.0.0pre10 applying a hack to define the
autofs_wqt_t using the cpp adding -Dautofs_wqt_t=unsigned
to the CFLAGS in Makefile.rules , this is a hack of course,
but it proofs, that afterwards the automount daemon works.

Version-Release number of selected component (if applicable):
4.0.0XY

How reproducible:


Steps to Reproduce:
1. build autofs4 daemon on opteron
2. start automount daemon with a trivial map e.g. for the mountpoint /mnt/test
3. enter or ls a subdirectory of /mnt/test specified in the map
    
Actual results:
process hangs (cause the daemon waits for 4 more bytes to be shipped
from the kernel as wait queue token)

Expected results:
automounter daemon mounts the directory and contents are listed or
directory changed

Additional info: