Re: [GSoC] Progress Report 1

[Ludovic Courtès]

Hi Rohan,

Rohan Prinja <address@hidden> skribis:

> Code written thus far (the source is at
> http://git.savannah.gnu.org/cgit/guix/dhcp.git):
> 1 Wrote classes for DHCP packets, network interfaces, DHCP options and
> DHCP configuratiion instances.
> 2 Wrote code to read the system's network interfaces and populate the
> network-interface instances' fields (name, hwaddr, family).
> 3 Refactored the above to records on the advice given by Ludo (who
> pointed out that OOPS is unidiomatic and in any case not really needed
> here).
> 4 Wrote incomplete testing code for the the items in 1 (incomplete
> because the tests did not test the serialisation of DHCP message
> records into bytevectors).
> 5 Began writing code to send a bytevector to a specified sockaddr, and
> began the skeleton of the main client module.

Neat!

> Current focus:
> 1 Test the code to send and receive packets
> 2 Code to make and send ARP messages on the link layer, and
> corresponding unit tests

Have you tried sending DISCOVER packets to a real server so far?  Is
there something blocking that?

> 2 Complete the (dhcp client) module (this includes the implementation
> of the main DHCP client algorithm, and lease storage), and complete
> the (dhcp *) modules' tests
> 3 Read the dhcpd server source (this package:
> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/admin.scm#n378)
> to figure out how to have a server for test the client

OK.

> Questions:
> 1 Ludo: I looked at the implementations of packed structs. DHCP
> packets are in general variable-length because of the options field,
> while packed structs require need to have the field lengths known
> ahead of time. So do you recommended making some changes to the packed
> structs implementations to accomodate the variable-length options
> field (I'll have to think about how to do this) or simply refactor the
> serializer/deserializer I wrote back when the code was in GOOPS to use
> records?

I’m not sure exactly.  packed-struct.scm in Guile-OpenGL is not a
perfect fit, for other reasons as well, so I guess it may have to be
adjusted.

Actually I’m just realizing that we also have a packed-struct thing in
(guix build syscalls), called ‘define-c-struct’, which can handle
endianness (see the examples there.)  It does not handle variable-length
fields though.  Would it work for you?

Are variable-length fields in the middle of the packet, or rather at the
end?  In the latter case, you could still use define-packed-struct for
the packet header, and then handle the rest manually.  In the former
case, define-packed-struct probably won’t help.

> 2 Ludo: please could you clarify exactly what the Copyright header for
> a source file should look like when it uses code from another project?
> For example, (dhcp interfaces) copies code from (guix build syscalls)
> (a couple of variable definitions that (guix build syscalls) didn't
> export).

Just keep the copyright and license header as-is, adding a copyright
line for yourself if/when you modify something.

Regarding that module, I see that some of the tests use (guix build
syscalls), so perhaps it would make sense to use that consistently
everywhere?

Also, we should add bindings to libc’s getifaddrs in (guix build
syscalls) so that interfaces.c is no longer needed.  Could you try that,
using ‘define-c-struct’ to define the ‘ifaddrs’ structure?

Besides, I’ll see if I can add a minimal autotools setup to the repo, to
facilitate things.

Thanks, and happy hacking!  :-)

Ludo’.