#4785 HIGH Future : hal should not poll usb storage devices every 2s

[Zarro Boogs per Child]

#4785: hal should not poll usb storage devices every 2s
-----------------------+----------------------------------------------------
  Reporter:  dilinger  |       Owner:  jg            
      Type:  defect    |      Status:  new           
  Priority:  high      |   Milestone:  Future Release
 Component:  distro    |     Version:                
Resolution:            |    Keywords:  power         
  Verified:  0         |  
-----------------------+----------------------------------------------------

Comment(by dilinger):

 Replying to [comment:3 davidz]:
 > > Yikes, talk about a waste.. Hald currently polls usb-storage
 > > devices every 2 seconds to see if they still exist. This
 > > seems completely unnecessary, as we can send an event from the
 > > kernel when a device disappears.
 >
 > This is completely inaccurate and linking to random rants won't make it
 more true. May I recommend reading the manual page for hal-disable-
 polling(1)? If you don't have it on your system here's a semi-readable
 copy

 How is it inaccurate?  Enable CONFIG_USB_STORAGE_DEBUG in the kernel and
 watch as hal polls a usb stick every 2s.  I see nowhere below where you
 say that isn't the case.


 >
 >
 http://gitweb.freedesktop.org/?p=hal.git;a=blob;h=53f55b476dcef6ff44ed27f12ba96568b1a026d3;hb=534735f7844300fec22cfebcf515ca46c9b91879;f=doc/man
 /hal-disable-polling.1.in
 >
 > As for your specific complaint: If the kernel says the storage device
 supports removable media (cf. /sys/block/sda/removable) the only viable
 option to detect _media removal_ is to poll the device (see below for how
 this can be avoided with SATA). Note the emphasis on _media removal_ as
 compared to _device removal_. For the latter no polling is necessary. Also
 if the kernel says that /sys/block/sda/removable is 0 hal won't poll.

 Ok, no need to argue about usb storage devices, then; hal should obviously
 *not* be polling them, as their removal will trigger block device removal.
 The scenario that hal is working around (cdrom devices) is where block
 device stick around even when the media is removed.  The course of action
 that *I* would take would be to add some sort of userspace callback to
 cdrom_media_changed in the kernel, or to one of its friends.  However,
 assuming we don't want to change the kernel (or we want to maintain
 compatibility w/ older kernels), is there really no way to distinguish
 between a cdrom and every other usb device?  When hal first sees the
 device, doing an ioctl to see if one of the CDROM ioctls (ie,
 CDROM_DRIVE_STATUS) are supported seems like a fairly reliable check.


 >
 > Unfortunately a lot of USB storage devices claim to support removable
 media even when they in fact don't. This is mostly the case for USB sticks
 (close to 100%; I've only seen one expensive IBM USB stick that didn't lie
 about it) and a few (close to 0%) hard disk enclosures also lies.


 So if doing this check is pointless due to the majority of usb hardware
 out there.. Why are we doing the check?  Why don't we switch to a check
 that actually makes sense?  Hacking around crappy hardware is what Hal and
 the kernel are supposed to be doing..


 >
 > Some newer SATA optical drives supports Asynchronous Notification and
 the Linux kernel is gaining support on the driver side to expose this to
 user space. There is support in HAL to honor this and avoid polling. Won't
 help for USB though.
 >
 > If you really want to disable polling and don't care about media removal
 (it's possible to design an user interface where this is possible) simply
 drop an XML file
 >
 > <deviceinfo version="0.2">
 >   <device>
 >     <match key="info.capabilities" contains=storage">
 >       <merge key="storage.media_check_enabled" type="bool">false</merge>
 >     </match>
 >   </device>
 > </deviceinfo>
 >
 > into /usr/share/hal/fdi/policy/10osvendor/00-no-polling.fdi and there
 will be no polling.
 >
 > Hope this helps.

 Thanks for the explanation.  Unfortunately, I'm not convinced that XML
 blob is granular enough for OLPC; I can look into a kernel-side solution,
 or can come up w/ a better test of removable media.

-- 
Ticket URL: <http://dev.laptop.org/ticket/4785#comment:6>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system