[openbeosnetteam] Re: PPP homepage

> > > I do not understand what you mean here. Calling load_image() from 
> > > kernel-land?  
> >  
> > Yep. 
> 
> Evil!!! :)
> Where do we get the environment pointer from?

From bash: /bin/sh -c our_userland_dialup_app?
Otherwise, I agree, we got an big issue here...

Anyway, I did try and it seems it works fine, except for some 
environment variables that are not set, starting with $HOME :-(

Here a quick hack to test using load_image() from kernel land:
http://philippe.houdoin.free.fr/phil/beos/openbeos/kload_image.zip

It's a very thin driver, Install & Run script is included, just compile 
and run the script.
I try direct app argument or via /bin/sh -c, no huge difference, excet 
maybe on environment side.
Tweak the very simple driver.c code to test with different app to 
launch...

I may look after some private api about environment variables settings 
in BeOS kernel, maybe is just hidden there in front of me/us.

For OBOS kernel, no issue, 'cause like Axel said, we will make it do 
what we want :-)

So, looks like it can works, but I didn't stress it at length yet, in 
particular I didn't check if application flags are honored, and we may 
want to set Exclusive Launch...

> > But a regular userland app (GUI or not) can perfectly do to that. 
> > Even kernel drivers and modules can do files creation/modification/
> > deletion, 
> > in fact. 
> > No need here for a daemon/permanent process waiting ad vitam 
> > eternam for 
> > something net-related to do...  
> 
> A daemon could remove the entries on shutdown. If there was a 
> B_SHUTTING_DOWN kernel message so PPP could know when to disconnect and 
remove the DNS entry it would work okay, too, but this can only be done 
by us.

You got a point here, as I don't think our kernelland stuffs (driver 
and modules) will be notified nor unload at shutdown, not by BeOS/Zeta 
kernel. Something interesting to add in OBOS driver & module API BTW, 
but not mandatory (will slow shutdown...)

However, these DNS entries could also be marked/remembered as highly 
volatile (valids only while a PPP interface is up...) and removed 
automagically at (next) startup from, what, resolv.conf file?

> Anyway, if that works I will create an app that is executed each time 
> a connection is being established so it can check if the user must 
enter a password or if he wants to be asked before dialing.

Looks load_image() can do the trick here.
The specific app to launch can even be made PPP interface based, read 
from settings.

BTW, do you think we need a way to display and interact with user 
during the connection, thru some "display connexion"? I guess, alas, 
there is still some PPP connexion which require some connexion special 
process, thru a expected/reply strings pairs in a script and/or such 
connexion *chat* window.

> Still, for immediate updating of the PPP settings (like default 
> connection) I need kernel-land node-monitoring support (when will the 
kernel finally be usable?).

It would be great.
But, until that and for R5 kernel, can't we broadcast some 
SETTINGS_CHANGED_PLEASE_RELOAD notification thru the stack (each 
modules) via a net_stack_control_module?

> Oh, I did not plan to use the whole preflet for showing so little 
> information. Also, there is no code in the preflet that handles the 
statistics.

It could be a separate app, but it don't need to be a permanent one.
Obvioulsy, if the user set his deskbar a default one, it will be a 
permanent one.
But we don't need to handle that ourselves by making this DUN 
monitoring a background process, just a normal deskbar view pooling 
every period for a specific PPP interface new status and statistics. 
The Deskbar, a quasi permanent app under BeOS, will offer the permanent 
hosting for free to us!
> 
> > But it's not a mandatory design to follow. 
> > I just guess users are used to such small GUI in Windows... and 
> > BeOS R5.0.x. 
> 
> Yes, a small window showing only the most important information is 
> better than having loads of stuff the user is not interested in, but 
this does not have to be done by the preflet code.

Agreed.
Small is good.

> Right, but I would like to change the R5 design and add one symbol 
> per connection. It will be possible to make the symbol always active 
for each interfaces individually, but that will not be the default.

Like under Windows since w2k? Even for each (W)LAN card?
Well, why not.

- Philippe

--
Fortune Cookie Says:

"When I was crossing the border into Canada, they asked if I had any
firearms with me.  I said, `Well, what do you need?'"
                -- Steven Wright

Other related posts: