Go to the FreeLists Home Page Home Signup Help Login
 



[openbeosnetteam] || [Date Prev] [09-2003 Date Index] [Date Next] || [Thread Prev] [09-2003 Thread Index] [Thread Next]

[openbeosnetteam] Re: Network preflet, the future?

  • From: "Philippe Houdoin" <philippe.houdoin@xxxxxxx>
  • To: openbeosnetteam@xxxxxxxxxxxxx
  • Date: Fri, 19 Sep 2003 00:06:53 GMT
> > > However, while I was working on this, 
> > > I realised
> > > not only the front end needs to be designed, but also the back 
> > > end. 
> > Yep. Only the BIND part of libnet.so require, use and support 
> > external settings 
> > files (/etc/protocols, /etc/services and co...).
> > The current stack should be configure via ifconfig tool.
> 
> Oh, so we can eventually get rid of these settings files? (or at 
> least, 
> move there somewhere else, like in a network/ subfolder?)

Well, changing the path where this files are expected by these BIND 
code is easy as modifying a #define in headers/posix/resolv.h, etc.
So, why not, yes!?

> > That's basicly the way our current stack is setup today: via 
> > ifconfig.
> > BONE do that in his /beos/boot/netscript, too.
> > I find this way too Unix-y, too init.d-y.
> 
> The good thing is, that if we are using driver_settings all over the 
> place, the stack could load its initial settings automatically.

Yep. That the idea.

> What we still need, however, is something that starts the stack. 
> It 
> would only need to open the stack once, to keep it loaded and 
> running, 
> it could end directly after this.

The /dev/net/stack driver will be load and fire at boot time, like 
every driver are.
He can then start the stack and keep it loaded. B_KEEP_LOADED flag on 
core module can do that, or 
the /dev/net/stack can tweak the kernel to stay opened, by opening 
himself. It's already there in the code.

> > The current (or default if none) profile should be determined by 
> > the 
> > stack "settings" helpers functions, and the settings loads from 
> > them 
> > at each 
> > module request.
> > For example, interfaces modules may want to load 
> > from /etc/network/profiles/current/interfaces the settings 
> > from "/dev/net/tulip/0" section, "dhcp" option.
> > 
> > /dev/net/tulip/0 {
> >   dhcp on
> >   mtu  1492
> >   mode full-duplex
> > }
> > 
> > If this file don't exists, the helper function will try to get it 
> > from /etc/network/profiles/default/interfaces file.
> 
> I like that. We could even say "if that section is missing" instead 
> of 
> "if this file doesn't exist", at least I would like that even more.

Yep. I though I wrote that in my previous post, but I guess after the 
first web mail page crash, I forgot to 
type it again.
Absolutly, at parameter level, not file.
 
> Do we really need this "restart the stack" button at all? I think 
> even 
> a "Stop Stack" button would make more sense to me, than just 
> restarting. At least, I don't understand, what it is good for?

It's good for... restarting!? ;-)
Well, unloaded all modules can help, but I'm not sure it will help 
often as a crashed stack most probably will 
kill the system too.

And as I want the stack to detect on regular basis any new kernel 
module(s) not already loaded (and used), I can't see why we'll need 
a restart feature when the stack is working fine, not even for 
installing a new network module.
 
> Why not commit it to the repository? It wouldn't hurt, would it?

It would hurt Niels, who works on same task.
I guess we should agree on which one to choose.

Maybe I could put that under src/tests/kits/net/preflet/*
Okay, i'm convinced!!!
:-p

-Philippe



--
Fortune Cookie Says:

The primary requisite for any new tax law is for it to exempt enough
voters to win the next election.






[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.