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