Re: Newbie: ENBD on kernel 2.6?

"Also sprach [email protected]:"
> >Don't worry about it. Just show me what you have. I doubt there are
> >many things different. Show me what the relevant section of yours looks
> >like ...
> >
> I have attached the appropriate kernel sources for your inspection:

No! I only need to see a couple of lines! ...

> /lib/modules/2.6.9-1.667/build/include/asm/byteorder.h

of the below:

> /lib/modules/2.6.9-1.667/build/include/linux/byteorder/little_endian.h

> /lib/modules/2.6.9-1.667/build/include/linux/cdrom.h:14,
>                  from /usr/local/downloads/nbd-2.4.32/nbd/ioctl.c:59:
> /lib/modules/2.6.9-1.667/build/include/linux/byteorder/little_endian.h:43: 
> error: syntax error before "__cpu_to_le64p"
> /lib/modules/2.6.9-1.667/build/include/linux/byteorder/little_endian.h:44: 
> warning: return type defaults to `int'
> /lib/modules/2.6.9-1.667/build/include/linux/byteorder/little_endian.h: 
> In function `__cpu_to_le64p':
> /lib/modules/2.6.9-1.667/build/include/linux/byteorder/little_endian.h:45: 
> error: `__le64' undeclared (first use in this function)
> 
> First, note that all of these errors are cos the type __le64 is undefined.
> 
> The line in little_endian.h is:
> 
> 43: static inline __le64 __cpu_to_le64p(const __u64 *p)

Oh, OK. The type is undefined. It's a 64 bit type.


> 44: {
> 45:    return (__force __le64)*p;
> 46: }


> Now, __le64 is defined in file 
> /lib/modules/2.6.9-1.667/build/include/linux/types.h, which is included 

Oh, OK. But under an #ifdef.

> from line 11 of  little_endian.h:
> 
> 11: #include <linux/types.h>
> 
> Line 154 of types.h is
> 
> 154: typedef __u64 __bitwise __le64;
> 
> But, lines 16 through 156 of types.h are protected by:
> 
> 16: #ifndef __KERNEL_STRICT_NAMES
> ...
> 156: #endif /* __KERNEL_STRICT_NAMES */

Well, in 2.6.11.1 I have:

#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
typedef __u64 __bitwise __le64;
typedef __u64 __bitwise __be64;
#endif

(lines 160-3)

and __KERNEL_STRICT_NAMES ends way above there.  If
__KERNEL_STRICT_NAMES includes those __le64 definitions in your file,
then I would say it is a mistake that has later been corrected.

At any rate, I see no need for the protection. Just put the definitions outside
the ifndef. 2.6.11.1 has:

  /*
   * Below are truly Linux-specific types that should never collide with
   * any application/library that wants linux/types.h.
   */

  #ifdef __CHECKER__
  #define __bitwise __attribute__((bitwise))
  #else
  #define __bitwise
  #endif
  
  typedef __u16 __bitwise __le16;
  typedef __u16 __bitwise __be16;
  typedef __u32 __bitwise __le32;
  typedef __u32 __bitwise __be32;
  #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
  typedef __u64 __bitwise __le64;
  typedef __u64 __bitwise __be64;
  #endif
  
  struct ustat {
          __kernel_daddr_t        f_tfree;
          __kernel_ino_t          f_tinode;
          char                    f_fname[6];
          char                    f_fpack[6];
  };
  
  #endif /* _LINUX_TYPES_H */

and that's that.


> And, indeed, __KERNEL_STRICT_NAMES is defined when these files are 
> included from ndb/ioctl.c.

Leave it defined and move the relevant definitions outside the
protection.



> So, my first attempt was to #undef __KERNEL_STRICT_NAMES before line 59 
> of nbd/ioctl.c. This solved the above compile error, but caused further 
> compile errors.

Nooo.

> My second attempt was to simply define the __leNN types myself in 
> nbd/ioctl.c, as described previously. This appeared to work.

Yes.

> Note that I haven't changed any of the kernel sources. I have merely 
> added some typedefs to nbd/ioctl.h.

That's fine, but you can change the kernel include. It was clearly in
error. I can see that it had already been corrected in 2.6.10 too, so 
it looks like an aberration in 2.6.9 only (2.6.8 had all #defines and
no inlines).


> I didn't fix this compile error by running as root. I fixed it by 
> manually inserting some typedefs.

OK. That looks good.


>                       " \
>                   TOPDIR=/lib/modules/2.6.9-1.667/build \
>                   VERSION="2" \
>                   PATCHLEVEL="6" \
>                   SUBLEVEL="9" \
>                   EXTRAVERSION="-1.667" \
>                    \
>                   $file ; \
>        done
> /bin/sh: line 0: [: -ge: unary operator expected
> make[1]: Entering directory `/lib/modules/2.6.9-1.667/build'
> *** Warning: Overriding SUBDIRS on the command line can cause
> ***          inconsistencies
> mkdir -p /tmp/linux-2.6.x/.tmp_versions
>  CHK     include/asm-i386/asm_offsets.h
> /bin/sh: include/asm-i386/asm_offsets.h.tmp: No such file or directory

Well, you have a kernel sources problem. Make sure that you can make
the kernel normally first of all (and make sure that you HAVE). Oh - 
this part of the compile might have to run as root if you don't have
perms to write minor temp files in the kernel area. It's a pain, I
know.

You might have to make clean before getting a sensible result, as some
empty files might  have been created.


Peter