Re: Laptop shock detection and harddisk protection

[Tejun Heo <tj@kernel.org>]

Austin Zhang 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?

Yeah, it's time sensitive but it seems latency of tens of millisecs is
good enough and with mlocked user process, it's really not a problem.

>> 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.

Again, it doesn't have to be that fast and the judgement part involves
complex floating arithmetics + user usage patterns (has the user typed
something recently, is lid closed kind of stuff).  I don't think it
fits in kernel.

Thanks.

-- 
tejun