linux-kernel - Re: Laptop shock detection and harddisk protection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Sep 2008 20:36:07 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Tejun Heo <tj@...nel.org>
Cc:	Shem Multinymous <multinymous@...il.com>,
	Elias Oltmanns <eo@...ensachen.de>,
	Thomas Renninger <trenn@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	IDE/ATA development list <linux-ide@...r.kernel.org>
Subject: Re: Laptop shock detection and harddisk protection

On Thu, 11 Sep 2008, Tejun Heo wrote:
> > Using the input device interface for the accelerometer (as done by
> > tp_smapi's hdaps + latest hdapsd) greatly reduces the number of
> > accelerometer-related timer interrupts on tickless kernels, as
> > measured by powertop. With syscall polling you have the kernal polling
> > the hardware at ~50Hz and then the userspace hdapsd polling the kernel
> > at ~50Hz. When they're out of phase so you can get up to 100
> > interrupts/sec. With an input device you're always at 50Hz. The phase
> > difference also induces a small extra delay in the shock handling
> > response.
> 
> That reduction comes because input device supports poll and
> sysfs_notify_event() does about the same thing.  The uesrland daemon
> can just poll on a node and read data nodes when poll event on the
> node triggeres.

If you guys are going to bother with the accelerometer interface (which is
a completely separate issue from the "queue-freeze-and-park-heads" APIs and
sysfs interface), you better be aware that there IS an accelerometer class
in the works, that cathers for directly-attached devices.

I'd look there first.  And a generic sysfs interface for accelerometers IS a
reasonably hard problem, so I would have it well separate from the disk-park
side of things and while it gets sorted out, I'd leave it for userspace to
deal with the issue (it is not like there is much userspace to worry about
right now, just hdapsd which is only interested on the hdaps accel
interface.  Everyone else can do it in-kernel, because their firmware
already does the imminent-fall detection).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/