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
