Hi Lennart,

>>>> +        uint32_t ciaddr;
>>>> +        uint32_t yiaddr;
>>>> +        uint32_t siaddr;
>>>> +        uint32_t giaddr;
>>> 
>>> Hmmm, why uin32_t? Shouldn't this be32_t? THis is network byte order,
>>> right? which is just synoymous to big endian...
>>> 
>>> Or even, if you now use "struct in_addr" elsewhere anyway, why not
>>> just use that here too?
>> 
>> be32_t seems reasonable, the 'struct in_addr' was deemed to add slightly
>> too much cruft without being particularly useful in internal code. What
>> if we figure out whether this patch set is otherwise reasonable and fix
>> this and add the remaining parts of DHCP in a coming patch set?
>> Meanwhile Tom could take the code for an official test spin...
> 
> This code looks as if it's ready to be merged. WHatever else comes up
> can be fixed post-commit. I think it would be best if you'd get commit
> access so that you can maintain this.

are you fine with the layout of files and directories? Then I can start 
handling maintaining it and dealing with patches.

Regards

Marcel

_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to