[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Thinking about "branes" for netbsd...
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...
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".
Main Index |
Thread Index |