HAL and PPP interfaces

[Dan Williams]

On Wed, 2004-12-08 at 22:22 +0300, Andrei Yurkevich wrote:
> Ok, you almost convinced me, but that would be not the PDA but a device 
> in a PC - either a serial port or a bluetooth/usb/whatever device. See, 

I still don't think this is a HAL problem, since the PDA isn't a device
actually connected to the computer.  At least with USB we can see that
there is some device on the other end, and hopefully with serial devices
there's a way to figure out whats there too.

> I need to know that there is a PPP connection available before I am able 
> to talk to a PDA, and the most logical way of knowing about a new PPP 
> interface would be querying HAL. So what about adding a "net.ppp" 

The actual management of the PPP connection still seems like something
HAL should _not_ be doing.  PPP is _not_ a hardware device, and so it
shouldn't be showing up in HAL.  Likewise, tun/cipsec interfaces show up
as actual devices, but we don't show those in HAL.  Its the exact same
problem.  Before I can communicate with a corporate VPN (or before you
can communicate with your PDA) you need to bring up a non-hardware
interface.  That's not HAL's job, that's the job of a daemon/program
outside HAL.  When you _plug__in_ the PDA, then HAL should notice that
and execute a callout script or notify a daemon over DBUS, but that
script should be responsible for the setup/teardown of the PPP
connection and for notification that the connection is live.  This
callout could likely set certain properties on the PDA device in HAL.

The point is, the connection to your PDA is _NOT_ PPP.  The connection
to your PDA is either bluetooth, serial, or USB.  That's HAL's job, the
hardware.  You could certainly talk directly over USB to the device
without PPP, but using PPP is a convenience.  HAL deals with the
hardware, not the convenience.

Remember, you can also just use DBUS and HAL, and roll a daemon of your
own.  How about this architecture?  HAL notices that the PDA device is
now present over USB.  A daemon that you write gets the notification
over DBUS from HAL, and brings up the PPP connection.  Then, your client
applications talk to _the__daemon_ you've written (using DBUS, or Unix
domain socket, or whatever) to get the upper-level details of the PPP
connection and device.  Its not really that hard.

This is exactly what NetworkManager does right now, for example.  HAL
isn't responsible for bringing up a network interface, that's a policy
decision for a different application, in this case NetworkManager.  If
your application (like Firefox) wants to know if it can get to the
Internet, it can do 1 call to NetworkManager and find out.  Likewise, in
a PPP model for you, your user applications that need to figure out how
to talk to the PDA would ask your daemon what's available, and how to
talk to it.

> namespace and merging properties like these to devices capable of 
> running a ppp link:
> 
> net.ppp.link (bool) /* TRUE if there's a PPP link available
>                         over this device */
> net.ppp.interface (string)  /* name of the ppp interface,
>                                 e.g. ppp0; this might as well
>                                 be just "net.interface" */
> 
> Perhaps, there could be some other useful properties like 
> net.ppp.link_name (string) or net.ppp.protocol.{ip/ipx/whatever} (bool), 
> but I'm not sure if those can be acquired from outside of pppd.

We should probably get David to comment on this, but it sounds
reasonable if the solution above is overkill.  We already expose some
protocol things like 802.11 and 802.3.  However, I don't think HAL
developers want to go very far with specific protocol/upper-level
information on devices, since that's not what HAL is supposed to do.
I'm not sure how far David thinks we should go with random user
applications setting device attributes/properties on a whim either.
David?

Dan

_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal