[openbeosnetteam] Re: our package
- From: "Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx>
- To: <openbeosnetteam@xxxxxxxxxxxxx>
- Date: Fri, 3 Sep 2004 11:41:26 +0200
> Built-in "databases" is the best, yep.
> Having default "databases" as global data (arrays of structures, most
> probably)
> make sense, until we didn't forget to look first for any customized settings
> in
> locations like
> /boot/{home/system}/config/data/network/{services|protocols|networks|resolv.conf|you
> name it!}.
> If such file don't exists or key cannot be found, simply fallback to builtin
> data.
>
> That way, Haiku's libbind.so/libnet.so will come ready out-of-box, without
> dependencies on external config files. Very BeOSish. :-)
Yes, that sounds nice.
> The bad news is this require changing BIND code :-(
Cool, you are on my side! :)
Seriously, this is a change that is worth the work, IMHO.
> BTW, I like the /boot/system/config/..., it make lot of sense...
You are as confused as I am. :) /boot/beos/system, but /boot/config is probably
better.
>> Is /etc/networks only used by "route"? If so, we could possibly drop it? :)
>
> I've modified my /etc/services to add SANE remote scanning protocol just 4
> days
> ago. We can't assume any of these "databases" are static forever, even if
> /etc/networks is not often needed for... well, I don't even know what's his
> purpose!
I think it is for making "route" (bin) translate IP addresses into nice names
(like reverse DNS, or "hosts"). Nothing useful for desktop users.
>> What is left is only resolv.conf. We should at some point replace it with a
>> kernel DNS handler (which could support temporary and static DNS entries, I
>> wrote this too often).
>
> But we'll have still to support persistence of the static DNS entries after a
> reboot. Resolv.conf can be supported like others files in fact, except that
> instead of static arrays of default databases values, it should be a dynamic
> list of DNS entries.
> Empty at start, the list is filled by DHCP and
> /boot/{home|system}/config/settings/network/resolv.conf content(s), if any.
I thought of a driver_settings file. If you add a static DNS entry it is saved
to disk, but if you add a temporary entry it is stored only in memory. After a
reboot only the temporary entries are removed, while the static ones are kept.
I wanted to implement this with net-module attributes (like in our newstack)
and additional flags saying "static", "temporary". Static ones will be saved.
Alternatively, we could just add a driver_settings structure to every
net-module and let the stack automatically load it on boot and save it when
something changes. The API could look like this:
settings = aquire_settings(module_name, static/temp)
release_settings(settings).
On release, static settings get saved to disk.
> That means by default Haiku will access to Internet out-of-box if DHCP is used
> (Dialup or LAN, doesn't matter).
Is there a difference to Windows/Linux?
> Anyway, should we rewrite DNS handler as a kernel module.
> I feel so: DHCP support need to interact with DNS name servers list, and
> network
> file systems will be happy to resolve names from kernel too.
> Plus post-R1 ZeroConf support will need multicast DNS responder builtin in the
> stack too.
Does IPv6 need this, too? It has some ZeroConf capabilities built-in. Well, it
surely cannot handle host names, so DNS is still needed, right?
Does a multicast DNS responder need a simple DNS server (e.g.: complete BIND
suite ;)?
> But I've fear about it.
Do you fear buffer-overflows because BIND is so popular?
> Do you guys know about good/better opensource (and compatible with Haiku
> licence) DNS resolver than BIND's one?
No, but BIND9 really looks good. I had a look at the older versions and they
were really messy. BIND9 is rather clean, but huge. Axel, you see, we really
need kernel-land-libraries. This would allow putting libbind into the kernel
and creating a simple module that handles requests and routes them to libbind.
>> /boot/system/config would be better, IMHO. That would allow the same naming
>> scheme as in /boot/home/config.
>> But we already have /boot/system/add-ons. Should we replace it with a link
>> and move the folder to /boot/system/config (or /boot/config?) in order to be
>> more consistent with the /boot/home/config directory structure?
>
> Ah. Well, that's right. Maybe /boot/system/"config" is not that great, then.
> /boot/system/data ?
> /boot/system/etc ? ;-)
>
> Hell, what's in a name!!!
> Starting from now, I'll refer it by B_COMMON_DATA_DIRECTORY only and don't
> worry
> anymore. That's the purpose of using find_directory(), right!?
> :-)
:)
I think we can agree on /boot/config/{data, cache, settings}.
Bye,
Waldemar
Other related posts:
