[openbeosnetteam] Re: DHCP Client needed,what would stand in theway?
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Sat, 26 Jul 2003 02:15:53 +0200 CEST
"Philippe Houdoin" <philippe.houdoin@xxxxxxx> wrote:
> > > But we still edit driver_settings, can we?
> > What do you mean with this? driver_settings can be written
> > manually,
> > they can be programmatically edited, and written back to a file
> > easily with the new API extensions.
> Thru put_parameter(), right?
> Or did I miss the higher-level spit_driver_settings_into_file(),
> which
> don't required to allocate a buffer before?
Yes, you missed it, because it's not there :-))
put_parameter() is only the engine that could be used for that - I am
not yet sure what/if exactly is needed there. Maybe filling a buffer
would even be enough - and that's already be done by
get_driver_settings_string().
> > BTW I guess I will have to write a newsletter article about the
> > revised driver_settings API anyway.
> Please, don't do it just for us! ;-)
Well, time will tell :)
> > The advantage of having common settings files (like /etc/
> > resolv.conf)
> > is that everybody who knows Unix a bit will feel at home, and be
> > able
> > to config the system immediately without having to use a GUI :)
> Agreed, again.
> Being similar to Unix network-related files layout can be helpfull to
> shorten beginner learning curve.
> However, maybe we can come with some layout a bit clever, aka more
> BeOSish, for our BeOS old/power users who are hooked to clever way of
> doing ?
> ;-)
I wouldn't mind doing that at all :)
Even if resolv.conf is great for someone with Unix/BSD experience it is
not at all intuitive or a clever way of doing it IMO.
> > It's directly usable like I did for the DriverSettingsTest in src/
> > tests/kernel/libroot/os/ - just have a look in the Jamfile there.
> I saw that, yes, thanks.
> I was talking about how to design the new API to manage settings/
> attributs of protocols/interfaces/network layers in the experimental
> new_stack code. Using driver_settings API is really easy.
Okay :)
> > So we could have a whole basic configuration and the profiles will
> > just
> > change the IP address or switch DHCP on/off. I would be okay if
> > that
> > advanced feature would only be available through the command line
> > (at
> > first), though :)
> Something along this:
>
> /etc/
> resolv.conf -> ./network/settings/current/resolv.conf
> hostnames -> ./network/settings/current/hostnames
> inetd.conf -> ./network/settings/current/inetd.conf
> network/
> settings/
> current/ -> ./profile2
> default/
> resolv.conf
> hostnames
> inetd.conf
> stack.conf
> ...
> profile1/
> resolv.conf -> ../default/resolv.conf
> hostnames
> inetd.conf
> stack.conf -> ../default/stack.conf
> profile2/
> resolv.conf
> hostnames -> ../default/hostnames
> inetd.conf -> ../default/inetd.conf
> stack.conf
> ?
Not exactly - I was thinking of something like this (if the starting
point would be /etc):
network/
profiles/
default/
dns
hostname
interfaces
current/ -> at_home
at_home/
interfaces
at_work/
dns
The "default" profile would always be loaded initially, and the
existing structures would be augmented/overwritten by the current
profile, which would be at_home in this moment. Dunno if the current
driver_settings API is enough to do that, though, but I could have a
look at it, if that's what we want to do.
And while default/interfaces might contain everything, at_home/
interfaces could only contain:
/dev/net/sis900/0 {
dhcp on
}
> We could fallback on the the "default" profile content, coming with
> the
> stack, when some specific settings files
> is missing in the current profile.
> But that's (too?) many symlinks :-(
Yes, and it doesn't make it that clear/simple either.
> Anyway, it'll be better if every stack components/modules can works
> even without any user settings available.
> For example, interfaces may start in DHCP mode by default, or even
> ZeroConf mode, both unimplemented today.
Yes, that would be cool, too. I would also like to have a look at
Apple's Rendezvous at that time.
> Network preflet design is important to keep in mind too there, as
> the ease of use of stack.conf settings file from boot script *land*.
Yes, the network preferences app is definitely important.
Adios...
Axel.
Other related posts:
