[PATCH] implement agent_manager_new_device()

Steffen Winterfeldt snwint at suse.de
Fri Jul 8 03:35:35 PDT 2005


Hi David,

On Thu, 7 Jul 2005, David Zeuthen wrote:

> Well, one important point of HAL is to minimize the differences between
> OS'es such as Fedora and SUSE so app authors have a single interface to
> retrieve hw information and the app will work across distros (e.g. so
> app X doesn't need to use hwinfo on SUSE and kudzu on Fedora).

that's true. But I think that can be avoided (or minimized, realistically)
by extending the HAL specs to cover the respective device classes.

> Well, we don't currently allow construction of device objects. But I see
> your point.

If you are determined and evil enough you could feed hotplug events into HAL
just for the purpose of turning them into what you want via fdi files. :-)

> > > About the patch: I think the patch needs to delete the object when the
> > > client creating it disconnects, just like we give up locks. Yes, this
> > > means that people putting an object in the store needs to hang around
> > > but this is worth it /me thinks.

That's more close to the hotplug philosophy, yes. But it would just make
clients creating devices needlessly more complex. In fact the client would
just fork off a daemon for every device it creates that sits around and does
nothing.

> > That we want to avoid, the system management system wants do dump a few
> > devices into the hal-store after userspace has set them up. Stuff like
> > serial mice, isdn-cards, serial modems that can't be safely probed with a
> > hal-addon or they just can't be discovered automatically at all, but if
> > set-up from userspace after bootup are usable like a real device.
> 
> Yeah. Ideally we'll probe for these devices, put them in the hal device
> store  and autoconfigure them at every login / whenever they're used
> from some desktop piece (like g-v-m autoconfigures your storage devices,
> e.g. mounts them and NetworkManager does the same for your network
> devices). 
> 
> Things like serial mice or modems may take a long time to probe though.
> But see below.

Not only that but think about hardware the user has configured manually for
whatever reason (say, it's not auto-detectable at all). The config tool then
can create a device in HAL that can be reused after reboot. For apps this
would be just a normal device in HAL and make things more consistent.

Hey, you can even email your device to a friend, then. ;-)

> I'm not saying we shouldn't allow other software to populate the device
> store to achieve a single interface - I'm just trying to understand
> exactly what you want to achieve and I also really want to avoid, if
> possible, to populate the hal device store with incorrect information
> (say, if the user removes a modem while the system is powered down).

A point, but that cannot really be avoided with legacy non-detectable
hardware - and IMO users don't expect it.

> Also, is it not possible to just put 'capabilities' on existing device
> objects like we do with e.g. gphoto2 cameras? Here's an example
> 
>  - user has serial port /dev/ttyS0 - this is a physical connector
>    on the PC

And if the interface is missing in HAL, too?

But the real point is, that this would be inconsistent. If you look, for
example, at how usb mice show up in HAL, you see that there is actually an
_additional_ layer because the mouse isn't the usb device but the kernel
input device 'attached' to an usb device.

I think HAL objects should model hardware objects. At least reasonably
close. A serial interface is an interface and not a modem, for example. You
could give it properties like baud rate or io port but not modem init
strings.

Or take parallel ports. You can have both a zip drive and printer connected
to it. Would you want to turn the interface into a disk _and_ a printer at
the same time?

I'm looking for a practical way to get legacy devices into HAL. And the
device manager API does the trick - it just happened to be not implemented.


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



More information about the Hal mailing list