[PATCH] implement agent_manager_new_device()

[David Zeuthen]

On Fri, 2005-07-08 at 12:35 +0200, Steffen Winterfeldt wrote:
> 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.

Would be much better (or possible, realistically) to have shared code.

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

All I'm saying is that the only thing the config tool should do is
calling Rescan() and we'll have bits in the hal tree (responding to
Rescan()) that detects your devices.

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

It's not, and if it is missing, the kernel really ought to be telling us
about it. If the kernel doesn't tell us we need to fix the kernel, not
play silly games in user space if it can be avoided. Specifically, what
bus (e.g. pci or isapnp) or class (e.g. serial) are you missing? 

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

It really matters very little whether the properties/capabilities sits
on separate device objects. Ideally, we'll have separate objects but it
doesn't really matter.

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

Right now hal models what the kernel exports which is mostly bus and
class devices. If we want separate objects for e.g. modems and other
devices that the kernel doesn't really know about we at least ought to
be consistent and e.g. also give gphoto2 and other userspace drives a
separate device object. But again, it really matters very little whether
the properties/capabilities sits on separate device objects.

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

No, of course not. I'd expect the kernel to export e.g. /sys/block/sda
for the disk and /sys/class/printer/lp0 for the printer. Then I create
device objects for these and hang them of the parallel port.

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

I'm also looking for a way to let HAL do exactly this but just feeding
whatever Yast may give you into HAL is just not the right solution; it's
a hack. 

(note, I'm *guessing* this is what you want to do - it would be very
helpful if you could be more specific on exactly what you want to
achieve more than just saying "we want to create arbitrary device
objects in the hal device store").

The right solution, in my view, includes things like letting people
(ISV's or third party open source projects) put in code that
participates in the detection process for e.g. serial ports (one
specific example of this is the GPS code from Eric Raymond). This also
encourages modularity and, no, I don't think this is a lot of work. (I
can expand on this if you want)

I don't really see the difference with the proposal I've made. The
difference here is that all detection code lives in the HAL tree (shared
by all) and can be invoked by UI apps through a single Rescan() method
[1]. This would also make the UI much simpler which is also good. What's
wrong with this?

Cheers,
David


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