Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 May 2014 08:04:25 +0400
From:      Gleb Smirnoff <glebius@FreeBSD.org>
To:        Rui Paulo <rpaulo@FreeBSD.org>
Cc:        Anuranjan Shukla <anshukla@juniper.net>, "freebsd-arch@FreeBSD.org Arch" <freebsd-arch@freebsd.org>, Marcel Moolenaar <marcel@xcllnt.net>
Subject:   Re: Roadmap for ifnet(9) for FreeBSD 11
Message-ID:  <20140529040425.GT50679@glebius.int.ru>
In-Reply-To: <B00C215B-F87E-4C14-AC61-4C2A0D4822B8@FreeBSD.org>
References:  <FA49AADC-A853-49F0-B80C-F0FBA1219177@xcllnt.net> <B00C215B-F87E-4C14-AC61-4C2A0D4822B8@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 28, 2014 at 08:48:11PM -0700, Rui Paulo wrote:
R> On May 28, 2014, at 9:34, Marcel Moolenaar <marcel@xcllnt.net> wrote:
R> 
R> > All,
R> > 
R> > The ifnet structure represents a network interface. Right now it
R> > is known to all NIC drivers as well as to all protocols. This
R> > means that whenever we change the structure, we need at minimum
R> > recompile all drivers, but usually also change them. This severely
R> > slow downs the development in this area and also makes it hard, if
R> > not, impossible to merge things back to stable branches.
R> > 
R> > There were at least 3 efforts on fixing this:
R> > 
R> > 1)  Juniper’s JUNOS is a FreeBSD based operating system that has
R> >    its own (alternative) network stack, but that leverages the
R> >    network drivers from FreeBSD. Juniper mechanically changed all
R> >    ifnet dereferences to to accessor methods. This could have
R> >    been incorporated as early as 2011, but lacked good follow
R> >    through. Marcel Moolenaar was prime contact for this.
R> > 
R> > 2)  Andre Oppermann was sponsored in 2013 by the FreeBSD
R> >    Foundation to make ifnet(9) opaque. This is not complete as of
R> >    the time of this writing.
R> > 
R> > 3)  Gleb Smirnoff also planned to work on opaque ifnet(9), but
R> >    that always has been delayed due to 1) and 2).
R> 
R> This is indeed needed, but it would be nice to understand what would happen if the community has comments about your patch. Will Juniper be able to integrate back those comments?  For example, I think the type "if_t" should be "ifnet_t".  Another comment I have is: why do you have to cast if_t to (struct ifnet *) in all the accessor methods?  It would be better to create a private header typedef'ing if_t to struct ifnet, avoiding the copy & paste casting.  

Because for now patch supports compiling unconverted drivers. This requires
to pass 'void *' as argument. When all drivers are converted, this will be
removed. In if_var.h we would have:

struct ifnet;
typedef struct ifnet * if_t;

All casts to (struct ifnet *) will go away.


Speaking of the 'if_t' vs "ifnet_t'. The pros of if_t are:

- The functions in API all begin with 'if_', so we are inline with that.
- Once a driver is converted 'grep ifnet if_driver.c' will return 0, but will
  return 1 on unconverted driver. That's nice.
- We had a really nice comment in if_var.h that originates from 4.4BSD:

  /*
   * Structure defining a network interface.
   * 
   * (Would like to call this struct ``if'', but C isn't PL/1.)
   */

  Originally the idea was to have 'struct if', but that is impossible. So the
  'net' prefix was added as a workaround, that we do not need to carry now.
  And yes, the 'net' is a tautology. All stuff resides in the sys/net directory,
  so no need to repeat 'net' again. In the kernel the word 'interface' applies
  only to network interfaces, no need to repeat 'net' extra time.

- It is shorter.

-- 
Totus tuus, Glebius.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140529040425.GT50679>