FreeLists / openbeosnetteam / [openbeosnetteam] Re: DHCP Client needed,what would stand in theway?

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

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