david at fubar.dk
Thu Oct 2 22:59:15 EEST 2003
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,
(of course this needs to be specified in the hal spec before we
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
(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) 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
 : it's implemented in different ways.. The OpenVPN stuff is a
network device, while e.g. SecuRemote is not.
More information about the xdg