network connections

[David Zeuthen]

On Thu, 2003-10-02 at 16:19, Sean Middleditch wrote:
> On Thu, 2003-10-02 at 01:34, Biju Chacko wrote:
> > On Wed, 01 Oct 2003 15:08:07 -0400, Sean Middleditch wrote:
> > 
> > >   What this needs on a Linux/UN*X box is rather simple: a standard
> > >  interface for requesting connectivity to a network.
> > 
> > I hope I'm not turning HAL into a silver bullet, but isn't this the sort of
> > thing it is meant to deal with?

Just to clarify, the current goal of HAL (as I see it; please complain
if you disagree ;-) ) is that is merely a combination of three things

 1. A ''database'' of devices along with useful, well-defined,
    information that is merged from several sources; and

 2. A single interface for each device to enable or disable it; and

    (In the future we *may* add other interface like getPictures() for
     a camera device. The current plan is to get buy-in, at some point,
     from library authors; for cameras libgphoto could take a HalDevice*
     object and take it from there.)

 3. Infrastructure for probing busses and act on add/remove signals
    (this is missing from 0.1, but will be an application of libusb, 
     libpci and other libraries)

And of course the spec. 

I personally want to keep HAL mean and lean for the time being.

> 
> Network connections are not hardware.  Many, many network connections
> are completely virtual and based solely on software.  HAL is more about
> autoconfiguring hardware as it becomes available, while my network
> connections proposal is to let users control networks whenever they
> please, along with applications having the ability to request networks
> when they're not available.
> 

That is true. For most users, however, network connection == network
device; but see below..

> HAL would certainly be useful for things like PCMCIA/cardbus network
> adapters, and perhaps cat5 cable plugin/removal.  They are complementary
> technologies.  ^,^
> 

At some point HAL will support legacy devices like serial devices, e.g.
modems. So, the obvious information to merge (from a device info file)
for a modem would be

  Vendor = SomeVendor
  Product = SomeProduct V.92
  Bus = serial           # could be usb or pci as well
  Category := Network
  SubCategory := Modem
  RequireEnable = true   # will have to explicitly enable the device
  KernelDevice = /dev/ttyS0
  BootProgram = some_dialing_script     # can inspect $HAL_<property>
  ShutdownProgram = some_hangup_script
  Network.Modem.InitString = ATZsomething
  Network.Media = PPP
  ConfigureRequiredProperties = Network.PPP.AuthLogin,
                                Network.PPP.AuthSecret,
                                Network.PPP.AuthType,
                                Network.PPP.Modem.PhoneNumber

(of course this needs to be specified in the hal spec before we
implement it)

So, when the device is discovered, it is not automatically enabled.
Using libhal it can be enabled by some application but the application
would need to set the required properties or the boot program would
fail.

(actually one of the Arklinux developers I talked to on IRC are working
on a libserial library (currently it can probe mice devices) so modem
support may actually happen soon.)

I agree that network connections should be treated differently (windows
also does this[1]) from devices, but I think the part where you interact
with the actual network device could be handled by HAL with benefits. 

One could probably tweak HAL to do what you want, but I'm guessing
usability guys would probably complain about that. Right?

Finally, I would be very happy to one day to be able to configure my
(wireless) OpenVPN connection between my laptop and firewall, and I
can't see that happening with only HAL and the direction I think it
should go in. Today it's such a pain with OpenVPN (although OpenVPN is
ubercool)...

Cheers,
David

[1] : it's implemented in different ways.. The OpenVPN stuff is a
      network device, while e.g. SecuRemote is not.