[openbeosnetteam] Re: our package

Axel wrote:
> > I think that there is no need for such a directory either - the system
> > directory itself should only contain the base OS, and no user or system
> > settings at all. All components of the OS should come with useful built
> > -in settings.

100% agreed.

Waldemar then replied:
> That is what I searched for as the best solution. :)
> I can try to write a small perl script that translates those etc files into
> structures and then we can import it into our libbind.

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. :-)

The bad news is this require changing BIND code :-(

BTW, I like the /boot/system/config/..., it make lot of sense...

> I cannot imagine that
> "services" changes often (if at all)I will try to integrate the following
> into libbind and libnet:
> services
> protocols
>
> 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!

Anyway, importing default "databases" into libraries will hide this file too
without "dropping" his support and still allow user/system admin to customize
it.
Sounds goods, right?

> 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.

That means by default Haiku will access to Internet out-of-box if DHCP is used
(Dialup or LAN, doesn't matter).

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.

But I've fear about it.
Do you guys know about good/better opensource (and compatible with Haiku
licence) DNS resolver than BIND's one?

> /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!?
:-)

-Philippe

Other related posts: