Lustre devel - Sep 2013 - portability in lustre code.

Hi All,

I "happy" to see moving to lustre kernel generate a first results.
my MacOS fuse client brooked to build after sources updates.

In file included from
/Users/shadow/work/lustre/work/WC-review/mac-os/libcfs/include/libcfs/posix/libcfs.h:108,
                 from
/Users/shadow/work/lustre/work/WC-review/mac-os/libcfs/include/libcfs/libcfs.h:45,
                 from nidstrings.c:43:
/Users/shadow/work/lustre/work/WC-review/mac-os/libcfs/include/libcfs/user-bitops.h:80:
error: conflicting types for ‘fls’
/usr/include/strings.h:90: error: previous declaration of ‘fls’ was here

that bug introduced by commit
>>
commit d38d331fa6525ffc02665f48fa52f94626360631
Author: James Simmons <uja.ornl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date:   Tue Aug 27 12:51:06 2013 -0400

    LU-1346 libcfs: cleanup macros in portals_compat25.h
>> 
so that commit - isn''t correctly inspected for systems other to linux
and introduce a new regression for systems other then Linux.
I was pointed about similar situation in past - but hit that in real world.
Andreas, did you remember my concerns about lost portability ?

batch changes code in way without ability to replace a cfs specific function to
any existent in build env.
>>>
diff --git a/libcfs/include/libcfs/user-bitops.h
b/libcfs/include/libcfs/user-bitops.h
index 2e31e88..1b16ca7 100644
--- a/libcfs/include/libcfs/user-bitops.h
+++ b/libcfs/include/libcfs/user-bitops.h
@@ -76,7 +76,7 @@ static inline int test_bit(int nr, const unsigned long *addr)
 }
 
 /* using binary seach */
-static __inline__ unsigned long __cfs_fls(long data)
+static __inline__ unsigned long fls(long data)
 {
        int pos = 32;
 
@@ -147,8 +147,8 @@ static __inline__ unsigned long __cfs_ffs(long
data)
>>
but fls from BSD userland have a different prototype and we don''t able
to replace with flsl from build env.

from man page
FFS(3)                   BSD Library Functions Manual                   FFS(3)

NAME
     ffs, ffsl, fls, flsl -- find first or last bit set in a bit string
HISTORY
     The ffs() function appeared in 4.3BSD.  Its prototype existed previously in
<string.h> before it was moved to <strings.h> for IEEE Std
1003.1-2001
     (``POSIX.1'''') compliance.

     The ffsl(), fls(), and flsl() functions appeared in FreeBSD 5.3.


and we don''t have a way to the replace fls with flsl for MacOS/BSD or
use own implementation without reverting a cleanup for fls function.


----------------------------------------------
Alexey Lyahkov
alexey_lyashkov-qCPWdT176rRBDgjK7y7TUQ@public.gmane.org

On 2013/09/21 2:39 AM, "Alexey Lyahkov"
<alexey_lyashkov-qCPWdT176rRBDgjK7y7TUQ@public.gmane.org>
wrote:
>I "happy" to see moving to lustre kernel generate a first results.
>my MacOS fuse client brooked to build after sources updates.
>
>In file included from
>/Users/shadow/work/lustre/work/WC-review/mac-os/libcfs/include/libcfs/posi
>x/libcfs.h:108,
>                 from
>/Users/shadow/work/lustre/work/WC-review/mac-os/libcfs/include/libcfs/libc
>fs.h:45,
>                 from nidstrings.c:43:
>/Users/shadow/work/lustre/work/WC-review/mac-os/libcfs/include/libcfs/user
>-bitops.h:80: error: conflicting types for Œfls¹
>/usr/include/strings.h:90: error: previous declaration of Œfls¹ was here
>
>that bug introduced by commit
>>>
>commit d38d331fa6525ffc02665f48fa52f94626360631
>Author: James Simmons
<uja.ornl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>Date:   Tue Aug 27 12:51:06 2013 -0400
>
>    LU-1346 libcfs: cleanup macros in portals_compat25.h
>>> 
>so that commit - isn''t correctly inspected for systems other to
linux and
>introduce a new regression for systems other then Linux.
>I was pointed about similar situation in past - but hit that in real
>world.
>Andreas, did you remember my concerns about lost portability ?
Yes, I definitely remember this discussion.

As we discussed a year ago the MacOS, Windows, and liblustre code are
currently unused, and have been unmaintained since that time.  I don''t
think it is reasonable for us to maintain this code for your private
FreeBSD Fuse port.  The code would need to continuously built and tested
in public for it to even consider it maintained at the most basic level.

Even prior to this recent compile problem, I would be incredibly surprised
if this code was working.  The liblustre code has been unmaintained since
Oracle times, and the Windows client has never been publicly released.
If MacOS _was_ working under your testing, it would have made sense to
share this code publicly last year.
>batch changes code in way without ability to replace a cfs specific
>function to any existent in build env.  and we don''t have a way to
the
>replace fls with flsl for MacOS/BSD or use own implementation without
>reverting a cleanup for fls function.
It would be fairly straight forward for you to apply a patch or run the
code through a sed script before build to replace the few conflicting names
with their equivalent MacOS functions.  This could be similar to how
ldiskfs is built from the ext4 code.

You are of course also free to keep a private or public branch of the code
for your own use.  We were planning to deleting the liblustre, MacOS, and
WinNT code entirely from the repository in the next release, because it is
unused and causes an ongoing maintenance and development complexity for
the Linux code without any benefit.  In particular, the abstractions in
CLIO are far more complex than they need to be for just Linux clients
because the Linux and MacOS VM/VFS interfaces are wildly different.

Cheers, Andreas
-- 
Andreas Dilger

Lustre Software Architect
Intel High Performance Data Division