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

|