[Nut-upsuser] Nut-upsuser Digest, Vol 36, Issue 8

[Alex Peyser]

On Tuesday 10 June 2008 08:00:39 am 
nut-upsuser-request at lists.alioth.debian.org wrote:

> Message: 2
> Date: Tue, 10 Jun 2008 10:58:11 +0200 (CEST)
> From: "Arjen de Korte" <nut+users at de-korte.org>
> Subject: Re: [Nut-upsuser] Nut-upsuser Digest, Vol 36, Issue 5
> To: "Alex Peyser" <a.peyser at umiami.edu>
> Cc: nut-upsuser at lists.alioth.debian.org
> Message-ID:
> 	<1545.193.67.155.121.1213088291.squirrel at mail.de-korte.org>
> Content-Type: text/plain;charset=iso-8859-1
>
> > It is possible at least on linux to get the port associated with a device
> > from userspace - I'd assume that on each platform it's possible, just
> > that libusb is incomplete (on top of being undocumented).
> >
> > Here's a patch for matching portnum on linux, with a few pieces pulled
> > from libusb. It lacks autoconf macros to isolate it -- but it does appear
> > to work.
>
> I appreciate the effort you took here. Before investing lots of time in
> cleaning up this patch, consider the following.

Yup, it was just a hack I put together for my own use --- if any one else has 
the same problem, now it's available on the mailing list.

>
> Besides some (easy to fix) coding style issues (see 'docs/developers.txt')
> your patch breaks the existing behaviour of hotplugging devices in a
> different (physical) port. Note that on reconnection (with the exact
> matcher), we don't match on the 'Bus' parameter so that it is possible to
> move a UPS to a different (physical) port. Likewise, you shouldn't match
> on the 'Port' by default either. Probably the cleanest way to fix this, is
> by only adding these to the exact matcher, if they are specified in
> 'ups.conf'.
>

That's the same thing I thought -- but my since I'll be using it just for 
fixed ups's, it solves my problem. No need to solve problems no one will ever 
have (given your movement to HAL)!

> Having said this, I'm uncertain how portable this mechanism would be in
> the first place. What we definitly don't want, is that changes in the
> USB_DEVFS_PATH propagate into the drivers (and I'm really not sure that
> this isn't the case now).

USB_DEVFS_PATH does propagate indirectly into your drivers via libusb now, but 
it does appear to be the wrong environmental variable for this purpose --- 
what I'm searching for is the mount point for usbfs which is normally 
in /proc/bus, not the devfs normally under /dev/bus. The "device" file 
appears to be a stable kernel feature from the 2.6.22 docs --- I have no idea 
if there are similar devices under the bsds and darwin, so I can't opine on 
the generality of the solution outside of the linux world. It really should 
be in libusb. USB under linux does appear to be woefully underdocumented 
(that's what lead me on this chase --- trying to find out what would actually 
lead to re-enumeration of devices).

>
> The above will be a moot issue, once the device matching code from the USB
> drivers is removed and replaced by a useable HAL interface (and let the
> kernel handle the (re)connection of drivers). As such, the existing
> matching mechanism is a gross hack at best and your patch will only add to
> the mess we already have. Therefor, I'm not in favor of entering this
> patch into the mainstream development code.

If that's the direction y'all are going in --- what I have now is good enough 
for me, so I'll save myself the effort of cleanup. I've never been a fan of 
the complexity of HAL (I'd rather know what was going on in my boxes, rather 
than depend on often incorrect general distribution configuration), but I see 
the attraction of abstracting away at that level.

>
> Best regards, Arjen

Regards,
Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20080610/96a80a15/attachment.pgp