Re: Thinking about "branes" for netbsd...

[Darren Reed <darrenr%netbsd.org@localhost>]

Now that folks are paying attention, I would like to
draw people's attention back to this issue. I would
seriosly like feedback from people on their thoughts
on two topics.


Firstly, there is this issue:
> * New tool to manage branes is required that does the following:
>  - create brane
>  - delete brane
>  - list branes
>  - assign a network interface to a brane
>  - remove a network interface from a brane
>  - this should potentially be a generic tool, such as nicctl,
>    or branectl or ... that is dedicated to managing network
>    interfaces and not IP, etc.
>  - ifconfig is not an appropriate tool for managing branes
>    or which brane an interface belongs to because it cannot
>    see all branes. This means that "ifconfig -a" will not
>    report all interfaces when branes are in use.

Next there is the issue of interface naming.

I will add that it may be that "struct devnet" can
be of help to SMP networking, I don't know...

> ...
> Interface naming
> ================
> For each brane to have a lo0 accessible within it requires that
> each brane have its own network interface name space. This is
> almost a separate project in its own right.
>
> The first approach is to describe this name space as a logical
> name space that sits above the network device name space. To
> implement this requires that each brane would have its own
> mapping table of network device names. This would be used by
> the system to translate network interface names in ioctls that
> work with "struct ifnet". This creates other problems as other
> code inside the kernel would need to be aware of this mapping -
> such as code that calls ifunit() - or the mapping is enforced
> elsewhere as well.
>
> A second alternative to this is to implement a logical network
> interface abstraction that sits on top of the device name space.
> That is, design and implement a "struct lifnet" (logical ifnet)
> for NetBSD. This is a rather large exercise and its presence will
> be felt in many applications that issue ioctls for "struct ifnet"
> that ultimately are for unkown interfaces.
>
> A third alternative would be for the "struct ifnet" to become the
> logical network interface structure that is exposed through IP
> and other interfaces. Under "struct ifnet" would be a new data
> structure ("struct devnet" for example) that was used by all
> network devices in lieu of "struct ifnet". There would be a strict
> one to one relationship between "struct ifnet" and "struct devnet".
> Initially, all of the data that is currently within "struct ifnet"
> would stay there and it would serve only as a tool to support a
> namespace that is globally unique (that of network devices) with
> one or more "struct ifnet" sets inside branes on top of that.
> In the fullness of time it might be appropriate to move some data
> elements out of "struct ifnet" and into "struct devnet".