[openbeosnetteam] Re: about net_server and food for thought
- From: "Hugo Santos" <hugosantos@xxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Mon, 2 Apr 2007 23:44:22 +0100
Hi Axel,
I completely understand the releasing R1 issue, and these points
very much depend on the objectives Haiku has for R1. Personally i
don't see the pursuing of better dynamicity as blocking to a release.
On 4/2/07, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
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.
Right now the net_server does not listen for device changes or the
adding or removal of devices. This is what i was pointing. It is not a
big change.
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.
Is IPv6 R1 material? If it is, i think that considering the amount
of effort on making at least the auto configuration modular it is
worth pursuing.
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.
Yes, exactly. :-) It should stop the auto-configuration.
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.
Filesystems are hierarchical interfaces which are very well
understood and we already have a bunch of APIs to handle file system
objects. I agree with your points regarding having this info available
to the user, but while we don't have filesystem namespaces (eheh) if
required this can be handled specially by the Tracker together with
the other special mount points.
Of course, I also wouldn't like all those special files to export the
addresses and pcap for the interfaces.
Assuming the risk of being pedantic, why not? :-) Why provide more
special calls, be it syscalls or ioctls, to the system? I think we
should point to convergence of interfaces and not divergence. New
interfaces only make sense if the existing ones are completely
unsuitable for whatever objective we have on hands.
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.
Like i mentioned above i completely agree with the releasing issue,
but when is the "one day"? The rest of us that would like to
contribute a bit in their own areas of interest need to coordinate
their efforts. :-) I think it's clear that for you these changes
aren't necessary but to do some of the things i would like to do, they
are. And i have the motivation to pursue these changes. Of course that
it makes no sense for me to engage in this development if its
incompatible with the objectives the developers have set.
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.
By similiar you mean a new interface or something that reuses
watch_node()? I agree with the API visibility point, this is not
really relevant for the API compliance R1 is after.
Hugo
Other related posts:
