[PATCH] implement agent_manager_new_device()

[Kay Sievers]

On Thu, Jul 07, 2005 at 12:06:28PM -0400, David Zeuthen wrote:
> On Sat, 2005-07-02 at 18:46 +0200, Kay Sievers wrote:
> > This makes it possible to create and remove HAL devices without
> > kernel and sysfs support. Some legacy devices or userspace driven
> > devices may be useful in HAL to, but need to be maintained by
> > an application instead of the kernel itself.
> > 
> 
> 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... :)

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

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

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?

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