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.