[openbeosnetteam] Re: about net_server and food for thought

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: