Date: Fri, 21 Sep 2012 02:12:47 -0700 From: Anuranjan Shukla <anshukla@juniper.net> To: George Neville-Neil <gnn@neville-neil.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: Proposal for changes to network device drivers and network stack (RFC) Message-ID: <CC817A77.1A2B5%anshukla@juniper.net> In-Reply-To: <5F3C03B6-01D0-42DE-BE9E-323DBDC90C8E@neville-neil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi George, On 9/5/12 1:15 PM, "George Neville-Neil" <gnn@neville-neil.com> wrote: > >> Building FreeBSD without the network stack (network stack as a module) >> ---------------------------------------------------------------------- >> Today, not compiling networking stack related files in the kernel breaks >> the kernel build due to dependencies the OS has on the network stack >> (calling into functions in the network stack). Network stack module >>isn't >> there. We've added these in JUNOS. The benefits for us are obvious (we >>can >> load our own version of network stack if we desire!), but most likely >>this >> functionality will benefit others too. >>=20 >> The detailed implementation is indicated later in this email. In short >>the >> changes are: >>=20 >> - Load network stack as a module. For now via loader, not dynamically >> loaded. (Is there interest in dynamic loading?). >> - To facilitate calling network stack functionality from the generic >> kernel, a new interface has been defined with the kobj framework. >> - Some files and tunables needed to move to generic kernel areas (accept >> filters) >> - Generic socket code calls into network stack for interface and route >> related ioctls. Network stack now registers these ioctl groups >> - Other changes: uuid generation (register/query uuid sources), fib/sctp >> system calls (moved to network stack code, with system calls register >> dynamically). >>=20 > >This would be interesting for many reasons, and I think it would be a good >contribution. Does the work you've done in this area handle the VNET >stuff that is in the stack as well? That is, how well does the network >stack >as a module play with the vnet architecture? Full VNET friendliness is expected by the time we finalize this work. In the diff provided, vnet support (vent.c) is already made optional additionally for netstack option. We plan to validate these changes with VIMAGE. We should have the broken down diffs by next week. Thanks for your input.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CC817A77.1A2B5%anshukla>