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

["Philippe Houdoin" <philippe.houdoin@xxxxxxx>]

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

> 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! ;-)
 
> > > It's just that our current get*byname() implementation is based 
> > > on 
> > > ISC Bind client, which use /etc/resolv.conf.
> > > Changing the way nameserver(s) list are stored will involve 
> > > modifying
> > > /
> > > forking ISC Bind client code.
> > > Not that I'm against it, as our implementation is not a port but 
> > > an 
> > > adaptation, and I always found 
> > > these /etc/resolv.conf and /etc/hosts too much Unix-y for BeOS.
> > Is it so big?
> 
> OTOH, the location /etc for network settings is the right one as long 
> as we don't have a /boot/common/settings/ directory (or 
> B_COMMON_SETTINGS_DIRECTORY).

Agreed.

> I dunno what find_directory() will return for this constant right 
> now, 
> but I think we might want to introduce that directory in OpenBeOS, 
> maybe even in R1.
> 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 ?
;-)
 
> 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.

> > > And supporting Network preflet Profiles feature (aka different 
> > > net 
> > > settings) will be far easier that way than with multiple network-
> > > related settings files to switch/backup/replace/modify...
> > How do you want to do that? Using directories for profiles (and the 
> > current profile is just a link to the real profile)?
> 
> I would rather like to have more than one settings file, and if it's 
> for the single reason that the file doesn't have to be saved that 
> often.

[...]

> If there are more than one file per profile, we should just put them 
> all into one directory per profile.
> Also, (independently from the directory/file structure) we could do 
> neat things like have a basic profile that others will inherit if 
> specifications are missing.
> 
> 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
?

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 :-(

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.

Profiles can be kept together under a /etc/network/settings/profiles 
directory, where 
default settings file can be moved one folder up into /etc/network/
settings.
Don't know what's better. 
A alternate layout, not shown here, I guess! ;-)

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

-Philippe

--
Fortune Cookie Says:

Anything that is good and useful is made of chocolate.