[openbeosnetteam] Re: about net_server and food for thought

Hi Hugo,

"Hugo Santos" <hugosantos@xxxxxxxxx> wrote:
>   1. Instead of instantiating interfaces based on settings, have
> net_server watch /dev/net/ for device interfaces and use the 
> available
> settings to create the network interface or proceed with the default
> (configurable) setting of auto-configuration. As the loopback
> interface has no device interface it would have to be configured
> statically as it is right now.

I don't see any advantage to change how it's done now; in the end, the 
net_server has to do both: listen for configuration changes (ie. 
settings files), and listen to device changes. If a new device pops up, 
it needs to look for settings, and if the settings are changed, it 
needs to look up and configure the device.

>   2. Move to an add-on based infrastructure for auto-configuration
[...]

While this is certainly something to pursue at a later time, I don't 
think this is something we should consider before R1 is out of the 
door.

>   As a side point, we also need some way to track the adding and
> removal of network interfaces (not device interfaces), the adding and
> removal of addresses (some more dynamic network applications depend 
> on
> this), etc. Net_server itself requires this capability to a point as
> any user may manually remove a network interface.

net_server shouldn't really care if the user is changing the interfaces 
directly; if you manually clobber with your interfaces, why and how 
should the net_server interfere?
The only thing it should do is to stop an ongoing automatic 
configuration for this interface in this case.

>   We could add yet another interface to the system to track these
> events (Linux did Netlink, BSD did AF_ROUTE, etc) but considering 
> that
> we have native node monitoring and attributes i was thinking if we
> could re-use these to provide the required events. More specifically,
> and i'm sure some will consider this blasphemous, but the network
> stack could have a filesystem that gets mounted to /net (net_server
> could mount it) where several information is published and available
> for monitoring. It could look something like this:
[...]
>   This is a very initial idea, so please let me read your comments.

A file system is not so different from a device, but I'm not sure I 
like the idea - I also don't like /pipe for that matter, and /dev only 
works on BeOS for me :-)
But I'm also not opposed to the idea - a file system is a proven way to 
communicate with the userland. I find it ugly to expose this 
functionality in the standard user file name space, but beyond that it 
would be a natural choice.
Of course, I also wouldn't like all those special files to export the 
addresses and pcap for the interfaces.

Anyway, at this point, I would recommend not to do broad changes that 
aren't really necessary; I definitely want to get R1 out of the door 
one day.

For now, I would only add a notification mechanism that works similar 
to the FS notifications - as we wanted to make that a more generic 
kernel service anyway, it could just make use of it. The API doesn't 
even have to be public for R1 IMO.

Bye,
   Axel.

Other related posts: