unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Julien Lepiller <julien@lepiller.eu>
To: Vladimir Sedach <vas@oneofus.la>
Cc: guix-devel@gnu.org
Subject: Re: Guile Netlink 1.0 released
Date: Mon, 15 Mar 2021 00:59:50 +0100	[thread overview]
Message-ID: <20210315005950.69d7b933@tachikoma.lepiller.eu> (raw)
In-Reply-To: <878s6pl48q.fsf@t510.orion.oneofus.la>

Thanks for the feedback Vincent and Vladimir!

Le Sun, 14 Mar 2021 16:12:05 -0700,
Vladimir Sedach <vas@oneofus.la> a écrit :

> Julien Lepiller <julien@lepiller.eu> writes:
> > I'm proud to announce the first release of Guile Netlink!  
> 
> This is great! I have been wishing for this for Guile ever since I
> started using Guix. Thank you.
> 
> Vincent Legoll <vincent.legoll@gmail.com> writes:
> >>   (addr-add "enp1s0" "2001:db8::1a4c/64" #:ipv6? #t)  
> >
> > what does the "ipv6?" parameter add ? This could be
> > deduced from the address length, no ?  
> 
> IPv6 configuration is so different from IPv4 configuration that I
> think it should have its own functions, not just a keyword parameter.
> 
> For example, right now you cannot assign multiple static IPv6
> addresses to the same interface (a basic IPv6 task) with
> static-networking-service. Putting the conditional logic for IPv4
> versus IPv6 rules inside the same functions is an invitation for more
> similar bugs. Trying to dispatch based on parsing the provided string
> makes it even more confusing. Dispatching based on a keyword
> parameter is not much better, and introduces the possibility of user
> error ("I forgot the #:ipv6 keyword").

The high-level API is just a wrapper around the low-level API, and in
rtnetlink, the only different between IPv4 and IPv6 is a family
parameter in message, namely AF_INET or AF_INET6. Basically, the
messages are exactly the same, except that in the IPv6 case, you use
IPv6 addresses which obviously take a little bit more space, so I
expect the wrappers to work the same.

If you want multiple addresses on the same interface, you can simply
call addr-add multiple times, one per address, and that has nothing to
do with whether it is IPv6 or IPv4 (you can have multiple IPv4
addresses on the same interface).

I don't think there's any reason why the procedures should be separate
between IPv4 and IPv6. I like the idea of deducing IPv4 vs IPv6 from
address format (not length though, as that may vary and overlap. After
all, 1.1 and ::1 are valid IPv4 and IPv6 addresses of the same length
;)). But simply detecting a dot vs a colon should work well. I've
always been bothered by "ip" vs "ip -6".

I don't really like the idea of having to separate the address and
prefix len, simply because this is the notation used by iproute2. It's
also easier for consumers of the API: you pass a string that contains
all the information, and don't really have to care.

> 
> --
> Vladimir Sedach
> Software engineering services in Los Angeles https://oneofus.la


  reply	other threads:[~2021-03-15  0:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-14 19:31 Guile Netlink 1.0 released Julien Lepiller
2021-03-14 20:40 ` Vincent Legoll
2021-03-14 23:12   ` Vladimir Sedach
2021-03-14 23:59     ` Julien Lepiller [this message]
2021-03-15 10:17 ` Léo Le Bouter
2021-03-15 17:12 ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210315005950.69d7b933@tachikoma.lepiller.eu \
    --to=julien@lepiller.eu \
    --cc=guix-devel@gnu.org \
    --cc=vas@oneofus.la \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).