[SLOF] [PATCH 08/11] Do not link libnet to net-snk anymore

[Alexey Kardashevskiy]

On 14/09/16 23:52, Thomas Huth wrote:
> On 14.09.2016 14:53, Alexey Kardashevskiy wrote:
>> On 14/09/16 19:18, Thomas Huth wrote:
>>> On 14.09.2016 10:55, Alexey Kardashevskiy wrote:
>>>> On 10/09/16 05:52, Thomas Huth wrote:
>>>>> Since libnet is now linked to Paflof directly, we do not have to
>>>>> link it into net-snk anymore.
>>>>>
>>>>> Signed-off-by: Thomas Huth <thuth at redhat.com>
>>>>> ---
>>>>>  clients/net-snk/Makefile     | 2 +-
>>>>>  clients/net-snk/app/Makefile | 2 +-
>>>>>  clients/net-snk/app/main.c   | 5 -----
>>>>>  lib/libnet/Makefile          | 3 +--
>>>>>  lib/libnet/netload.c         | 2 +-
>>>>>  5 files changed, 4 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/clients/net-snk/Makefile b/clients/net-snk/Makefile
>>>>> index 1cab7ae..c0bb73a 100644
>>>>> --- a/clients/net-snk/Makefile
>>>>> +++ b/clients/net-snk/Makefile
>>>>> @@ -17,7 +17,7 @@ include $(TOP)/make.rules
>>>>>  OBJS	=  kernel/kernel.o oflib/oflib.o libc/libc-glue.o app/app.o
>>>>>  .PHONY : subdirs clean depend mrproper
>>>>>  
>>>>> -CLIENTLIBS = $(LIBCMNDIR)/libelf.a $(LIBCMNDIR)/libnet.a $(LIBCMNDIR)/libc.a
>>>>> +CLIENTLIBS = $(LIBCMNDIR)/libelf.a $(LIBCMNDIR)/libc.a
>>>>>  
>>>>>  all:	.depend subdirs
>>>>>  	$(MAKE) client
>>>>> diff --git a/clients/net-snk/app/Makefile b/clients/net-snk/app/Makefile
>>>>> index 52d446c..2da02b9 100644
>>>>> --- a/clients/net-snk/app/Makefile
>>>>> +++ b/clients/net-snk/app/Makefile
>>>>> @@ -16,7 +16,7 @@ export TOP
>>>>>  endif
>>>>>  include $(TOP)/make.rules
>>>>>  
>>>>> -CFLAGS +=$(ADDCFLAGS) -I$(LIBCMNDIR)/libnet
>>>>> +CFLAGS +=$(ADDCFLAGS)
>>>>>  
>>>>>  OBJS = main.o
>>>>>  
>>>>> diff --git a/clients/net-snk/app/main.c b/clients/net-snk/app/main.c
>>>>> index 22aeba7..17c16b6 100644
>>>>> --- a/clients/net-snk/app/main.c
>>>>> +++ b/clients/net-snk/app/main.c
>>>>> @@ -13,7 +13,6 @@
>>>>>  #include <string.h>
>>>>>  #include <stdio.h>
>>>>>  #include <of.h>
>>>>> -#include <netapps.h>
>>>>>  #include <libbootmsg.h>
>>>>>  
>>>>>  #ifdef SNK_BIOSEMU_APPS
>>>>> @@ -31,10 +30,6 @@ main(int argc, char *argv[])
>>>>>  	int i;
>>>>>  	of_set_callback((void *) &_callback_entry);
>>>>>  
>>>>> -	if (strcmp(argv[0], "netboot") == 0 && argc >= 5)
>>>>> -		return netboot(argc, argv);
>>>>> -	if (strcmp(argv[0], "ping") == 0)
>>>>> -		return ping(argc, argv);
>>>>
>>>>
>>>> After this change we do not have working "ping" - it is added in the next
>>>> patch, not good for bisectability. Was this intentional?
>>>
>>> Yes, it's ugly to lose bisectability for one step here, but since "ping"
>>> is IMHO not such an important command in SLOF, I decided that it is OK
>>> to break it for one commit: If we want to add the Forth-to-C wrapper for
>>> ping in libnet.code before this commit, I would need to write the
>>> wrapper in a similar fashion as I've done it for the netboot() wrapper
>>> in the previous patch, i.e. parse the string that has been created by
>>> the forth code with:
>>>
>>>  s" ping " my-args $cat
>>>
>>> ... and then pass argc and the created argv[] array to the ping() function.
>>> But since it's much easier for ping() to directly work with the my-args
>>> parameter, I wanted to avoid that step.
>>
>>
>> Well. Why did not you change netboot() the same way? :)
> 
> I'm still planing to do this as an optimization later there, too. But
> it's a bigger change for netboot() compared to ping(), since all that
> $cat string handling in slof/fs/packages/obp-tftp.fs needs to be
> disentangled, too, and the netboot() function itself accesses various
> members of the argv[] array, so that code then also needs a rework, too.
> That means the patch gets quite a bit bigger and maybe harder to review.
> But if you prefer, I can also rework the patch to do that immediately
> instead of a clean-up/optimization patch later.


Well, this does not fix any urgent bug so imho there is no hurry (is not
there?) and I suppose I could wait till netboot() or/and ping() prototypes
rework which would not break bisectability.

How much faster does QEMU in TCG take to boot with these patches?


> (Note: Also the client-buffer handling in obp-tftp.fs can finally go
> away ... not sure whether I already should include that now or do it in
> a separate patch later... Do you have any preferences?)

I do not.


-- 
Alexey