[ENBD] enbd + x86_64 AND x86 mixed

[Lothar Brendel]

Peter T. Breuer wrote:


>>>>>>/root/enbd-2.4.33/nbd/enbd-maketest: line 348:  4208 Segmentation 
>>>>>>fault      nice -19 $ENBD_CLIENT $OPTCLI
>>>>>>            
>>>>>>
>>It appears to be caused by the "-d 1" flag (debug level 1) that the
>>script uses by default.
>>
>>   OPTCLI="$SERVER:$PORT $OPTSOCK $OPTBLK $OPTSIG $OPTTIME $OPTMD5SUM $OPTCLISSL $OPT_REQ_TIMEO $OPTJRNL $OPTASYNC -d 1 $DEVICE"
>>
>>Remove it and do without while I investigate.
>>    
>>
>
>Yessss .. simple error. Should have shown up on all platforms (if I
>ever ran with debugging on in any of them, that is!).  gdb shows the
>failure point at once.
>
>In enbd-client.c, around line 870, do:
>
>  static int
>  do_set_debug (struct nbd_client_session *session, char *arg)
>  {
>-     return really_do_optarg (session, 'd', NULL);
>+     return really_do_optarg (session, 'd', arg);
>  }
>
>Bad copy and paste in the coding. Apologies for the carelessness.
>
>With that change I can certainly run on ia64 amd. At least make test
>runs.
>  
>
YES! Same for me, thanx a lot! And sorry for not having been able to do 
some testing on my own since Wednesday last week (too busy).

So, "make test" with SERVER=CLIENT=localhost works fine, great!

Now you mention in INSTALL ssh being mandatory for "make test", and I 
supposed that you use it for the case SERVER!=CLIENT. But I cannot find 
ssh being used anywhere. And indeed, the SERVER only gets requests on 
port 3033, not 22. Hence, I have to start enbd-server on the SERVER by 
hand anyway? (Or "make test" on the SERVER as well? But no, target 
"test" will complain about the modules. Hmm...)


And... what about CLIENT being x86_64 while SERVER is x86? Any 
objections here?


One issue left from Issue 8:

>>>> >Lines 183 and 243 are just the same sort of thing. Fix the same way.
>>>> >Oh, line 51 too. That's it. Now all smooth.
>>>> >  
>>>> >
>>>      
>>>
>>> I changed also %d to %zd in PERR in netserver.c:366 and netserver.c:372 
>>> and in printf("BAD...) in enbd-test.c:1245. In x86_64 world, the sizeof 
>>> operator's results are no longer of type 'int' but 'unsigned long'  :-( 
>>    
>>
>
>Better to cast to int. Can't depend on being on x86 OR on having gcc as
>a compiler.
>  
>
Okay. On the other hand, there are rumours (e.g. 
http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,198,00.html) 
about the z-modifier being ANSI.


Finally, one minor issue: The fallback to "uname -r" in
KERNELRELEASE       := $(shell ( grep UTS_RELEASE 
$(KLINUXDIR)/include/linux/version.h|head -1|cut -f 2 -d'"'|tr -d '\n' ) 
2>/dev/null || uname -r)
in the Makefile does not work, since the status of the pipeline is that 
of "tr" (i.e. always 0). The fallback becomes important when doing only 
"make utils" on a server machine without kernel-stuff.

To fix it, a "|grep ." could be appended just after the "tr -d '\n'".

Loads of greetings
          Lothar