linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: multinymous@gmail.com, Elias Oltmanns <eo@nebensachen.de>,
	Thomas Renninger <trenn@suse.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Laptop shock detection and harddisk protection
Date: Wed, 10 Sep 2008 18:59:26 +0200	[thread overview]
Message-ID: <48C7FCEE.8060404@kernel.org> (raw)

Hello, all.

Elias has been sending libata/ide shock protection patches[1] and for
libata I think it's only one or two iterations from being included.
The interface is pretty simple, it only has to write timeout values to
sysfs nodes for all disks.

Thomas is now working on implementing shock detection for HP laptops
where the interface is much simpler than the HDAPS one.  Interrupts
for danger imminent and danger over plus control for warning LED.

I browsed a little bit for HDAPS one and it seems all the pieces are
there but scattered.  The latest effort seems tp_smapi which Shem
Multinymous is working on.

So, overall, all the pieces are falling into places but many pieces
are not upstream yet and there also are interface differences for
different detection drivers.  The original hdaps uses polling on sysfs
nodes, the HP thing Thomas is working on is likely to use sysfs +
sysfs_notify_event() and probably another node to control LED.  The
tp_smapi seems to use joystick input device to transfer the data along
all the axises.

So, I think it's about time to decide how to proceed on this
acceleration detection and shock protection thing.

1. How should the shock interface look like?  As we're gonna need
   userland daemon one way or the other, we can use the userland
   daemon to glue all the interfaces but it would be much better to
   have a unified interface.  Although there seem to be several
   different variants, they don't differ all that much and creating a
   new interface every time is painful.  I think we can get by with a
   sysfs interface with notification.

2. If we're gonna unify interface, how much can we unify the backend?
   Some devices are based on polling, others interrupt.  For polling,
   is it better to delegate the whole polling to userland or is it
   better to do some of it in kernel (tp_smapi seems to be doing
   this)?

3. What about the userland daemon?  It would be best to have a unified
   daemon which can handle all instead of one for hdaps and another
   for hp (and so on).  If we can unify the interface, this will be
   much easier.

Thanks.

-- 
tejun

[1] http://thread.gmane.org/gmane.linux.ide/34103

             reply	other threads:[~2008-09-10 17:01 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-10 16:59 Tejun Heo [this message]
2008-09-10 19:43 ` Laptop shock detection and harddisk protection Renato S. Yamane
2008-09-11 10:26 ` Austin Zhang
2008-09-11 11:18   ` Tejun Heo
2008-09-11 16:08 ` Shem Multinymous
2008-09-11 16:34   ` Tejun Heo
2008-08-17 19:48     ` Pavel Machek
2008-09-11 20:00     ` Elias Oltmanns
2008-08-17 19:51       ` Pavel Machek
2008-09-17 15:21         ` Elias Oltmanns
2008-09-17 19:36           ` Shem Multinymous
2008-09-11 20:25     ` Shem Multinymous
2008-08-17 19:30       ` Pavel Machek
2008-09-11 23:35       ` Tejun Heo
2008-09-12 16:59         ` Greg KH
2008-08-17 19:45           ` Pavel Machek
2008-09-17 18:04             ` Greg KH
2008-09-18 11:18               ` Pavel Machek
2008-09-19  9:03                 ` Thomas Renninger
2008-09-24  5:14                   ` Greg KH
2008-10-07 20:40                     ` Pavel Machek
2008-10-07 21:19                       ` Greg KH
2008-10-07 21:40                         ` Pavel Machek
2008-10-07 22:03                           ` Greg KH
2008-10-07 23:03                             ` Pavel Machek
2008-10-07 22:55                         ` Shem Multinymous
2008-09-15  8:29           ` Tejun Heo
2008-09-15 18:09             ` Shem Multinymous
2008-09-15 20:10               ` Tejun Heo
2008-09-14  4:41       ` Jeremy Fitzhardinge
2008-09-11 23:36     ` Henrique de Moraes Holschuh
     [not found] <baBmH-48R-17@gated-at.bofh.it>
2008-09-12 13:28 ` Bodo Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48C7FCEE.8060404@kernel.org \
    --to=tj@kernel.org \
    --cc=eo@nebensachen.de \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=multinymous@gmail.com \
    --cc=trenn@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).