[openbeosnetteam] Re: about net_server and food for thought
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Tue, 03 Apr 2007 02:04:11 +0200 CEST
Hi Hugo,
"Hugo Santos" <hugosantos@xxxxxxxxx> wrote:
> 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.
Not really blocking - but delaying in case you would spend your time
working on something else we need for R1 ;-)
It's your call, of course - if you rather want to tackle a certain
issue, I certainly won't stop you; and as long as you produce something
that we can keep, it's also not wasted time or anything close to that.
It's still very much appreciated, don't get me wrong.
> 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.
Okay, maybe I just misunderstood you then :-)
> > 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.
I don't think we would delay R1 for IPv6, but it surely doesn't hurt to
have it on board :)
Besides, when the GSoC happens, this should be your main objective (the
mentoring organization will also receive some money in case the student
completed his project, btw) :-)
That being said, if you really want to add add-on support before R1, do
it; it's a good thing, it would happen anyway at some point in the
future, it's just not urgent.
> > 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.
Yes, of course, Tracker would completely ignore them - as /pipe (and /
dev, for that matter).
> > 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.
Well, you couldn't do a lot with those files, and the file vs. function
mapping is a bit too open for my taste. You would still need to talk to
the directory in order to remove/add/change an address; at least I
would find it weird to do a "cat /net/interfaces/0/0" and see
"192.168.0.2" in my shell, and especially "echo 192.168.0.2 > /net/
interfaces/0/0".
For example, we could also export all sockets in /net/sockets/ - but if
you want to do anything useful with those entries, you'll need some
special functions (via ioctl()) again; you actually gain very little
IMO.
So the best reason to do it as a file system is the node monitoring
service.
> > 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.
I notice I should have mentioned that only once, probably ;-)
> > 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.
Not watch_node() in userland (as that would indeed need a file system),
but the backend in the kernel.
Bye,
Axel.
Other related posts:
