[PATCH] implement agent_manager_new_device()

[David Zeuthen]

On Thu, 2005-07-07 at 19:58 +0200, Kay Sievers wrote:
> > Right, this sounds like an useful idea. It does make me worry a bit that
> > code outside the hal tree can import stuff into the device store. So, I
> > think that *if* we're going to do this, we should probably try to ensure
> > that only code in the hal tree (or, maybe, alternatively, only code
> > under one or more suitable open source licenses) may use this (though
> > there may be issues in doing so). 
> 
> Well, there is no way to prevent anybody from doing so, they can use
> their own glue-code and you can't do anything, if they don't link
> against your lib. And we ourselves use a command-line tool to feed
> devices into the the HAL store... :)

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).

> > I don't know. I'm just worried about possible incompatibilities this may
> > cause if vendor X imports some objects into the store and vendor Y
> > imports other objects (of similar nature, only syntactically different)
> > into the store. Then app A is kind of in a problem. What do you think?
> 
> Well the problem is not bigger than some crazy fdi's/callouts that owerwrite
> values, right?

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

> 
> > 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 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.

> This is more a workaround for devices that have no sane hotplug kernel
> support, just to make the interface consistent. If we don't want to go that
> road, all the interfaces that are already available, but are not implemented,
> should be removed then, right?

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).

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

 - If an analog modem is attached we'd stick the capability 'modem' on
   the hal device object representing /dev/ttyS0 (and other appropriate
   modem.* properties)

 - Similarly, if a GPS reader is attached instead we'd put the
   capability 'gps_reader' (and other appropriate gps_reader.*
   properties)

 - Similarly, if a serial mouse is attached instead we'd put the
   capabilities 'input' and 'input.mouse'  (and all the other input.*
   properties)

 - We may want not to probe by default so some desktop piece needs to
   invoke org.freedesktop.Hal.Device.Rescan() to do the probe. We
   will save the value and properties ('modem', 'gps_reader' or 
   'input.mouse' in a look-a-side file and read this the next time hal
   detects e.g. /dev/ttyS0 (e.g. on next reboot). 

   The OS installer (anaconda or firstboot for e.g. Fedora) will want
   to do the Rescan() on all legacy ports as part of the OS install.

   Desktop software may do the Rescan() from a GUI "configure your
   hardware" interface (such as Yast on e.g. SUSE)

Wouldn't this be much nicer? I'm just thinking out loud here, btw. Maybe
this would be better to discuss at desktopcon / OLS though :-)

Cheers,
David


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