[openbeosnetteam] Re: about net_server and food for thought
- From: "Waldemar Kornewald" <wkornewald@xxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Mon, 2 Apr 2007 20:08:29 +0200
Hi Hugo,
On 4/2/07, 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 think this sounds reasonable.
2. Move to an add-on based infrastructure for auto-configuration
(and possibly more, depends on the interface).
Add-ons are indeed a nice concept, but they aren't practical or useful
for everything. Do you expect 3rd-parties to add new configuration
systems? Is there a real use for this and is it worth the programming
overhead?
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:
I don't know what the advantage is. I don't think the user will access
that file system directly (by hand), not even for advanced stuff. If a
file system is easier for developers then I'm fine with that, but I
think a nice API would be less cumbersome than digging through
directory trees.
Anyway, as a suggestion, the FS could provide most of the interface
information as attributes, so the file itself could be the direct pcap
interface and its attributes would contain name, address, etc.
Bye,
Waldemar Kornewald
Other related posts:
