From: Austin Zhang <austin_zhang@linux.intel.com>
To: Tejun Heo <tj@kernel.org>
Cc: multinymous@gmail.com, Elias Oltmanns <eo@nebensachen.de>,
Thomas Renninger <trenn@suse.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: Laptop shock detection and harddisk protection
Date: Thu, 11 Sep 2008 06:26:37 -0400 [thread overview]
Message-ID: <1221128797.30437.4.camel@azhang.bj.intel.com> (raw)
In-Reply-To: <48C7FCEE.8060404@kernel.org>
On Wed, 2008-09-10 at 18:59 +0200, Tejun Heo wrote:
> 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)?
Shock protection should be time-sensitive, if we put the whole polling
into userland, will it be possible that the damage had happened before
userland app can signal ATA idle command timely?
> 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.
Can this process "acceleration-detect --> inform ATA shock protect -->
issue idle command" be done totally in kernel, avoiding to consume too
many time for "acceleration-detect --> sysfs --> userland app --> sysfs
--> inform ATA shock protect --> issue idle command" before HD was damaged?
The userland daemon should be just a indicator (but of course it can pass
params to driver) for the protection status rather than a judge.
next prev parent reply other threads:[~2008-09-11 10:30 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-10 16:59 Tejun Heo
2008-09-10 19:43 ` Renato S. Yamane
2008-09-11 10:26 ` Austin Zhang [this message]
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=1221128797.30437.4.camel@azhang.bj.intel.com \
--to=austin_zhang@linux.intel.com \
--cc=eo@nebensachen.de \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=multinymous@gmail.com \
--cc=tj@kernel.org \
--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
Powered by JetHome