Admittedly, I don't know very much about it myself but I seem to
remember that there are other vendors now shipping similar technology.
Even in the Thinkpad case I don't *know* that all relevant models have
HD and optical drives on seperate ports although I'm willing to believe
it if somebody tells me so.

Anyway, I've added Henrique to the Cc: list since he knows far more

There is a lot to be said for the per-port solution as far as libata is
concerned. For the sake of consistency I tried to mimic the same

Right, I'll try to give a concise statement of the problem. First
though, I absolutely agree that with regard to the suspend / hibernate
problem, an in kernel solution would ultimately be the safest option.
However, the way I see it, we would need a module with the following
characteristics:

- Policy: logic to decide when to park / unpark disks and an interface
  to export tunables to user space.
- Input: capability to recognise and register with acceleration sensors
  in the system and to gather data in an efficient manner. Since this is
  kernel space, we have to make it bulletproof and account for the
  possibility that there may be more than one such sensor installed in
  the system (think: plug and play).
- Action: find all rotating media in the system and decide which of them
  to protect how. Probably, some tunables for the user to fiddle with
  are required here too. Remember that we have docking stations and the
  like so more than one HD may show up on the bus.

All these corner cases that most users don't care or even tink about
won't hurt anyone as long as the daemon is in user space. This way, we
have a very simple solution for all of them: The user decides for each
instance of the daemon which accelerometer it gets its data from and
which HD it is supposed to protect. I don't like giving impressively
high percentages when all I'm doing is intelligent guess work, but the
vast majority of users will have only one daemon running, getting its
data from one ...
[ message continues ]

Not only that, IIRC there were some concerns regarding having bigger

We may attack the problem from the different angle in which we won't
have to worry about any odd corner cases at all:

- Add disk_shock module with the needed logic, keeping track of "system
  accelerometer" & "system disk" objects, responsible for polling and also
  (optionally) exporting tunables.

- When ATA devices are initialized check if they support UNLOAD
  command and if yes advertise such capability to the block layer
  (like we do it with flush cache currently).  We can also solve
  the problem of forcing UNLOAD support with using kernel parameters.

- Add [un]register_system_accelerometer() interface to disk_shock
  and make accelerometer drivers decide whether to use it (currently
  only hdaps driver will use it).  Also add some standard methods for
  obtaining data from accelerometer drivers.  We may even glue the
  new disk_shock with hdaps for now.

- Simlarly add [un]register_system_disk() interface (getting us a
  access to disk queue) and make storage drivers decide whether to
  use it (it is actually easier than in case of system accelerometer
  devices since an extra UNLOAD command on shock is not a problem,
  while false shock alert is).

- On shock disk_shock will queue the special REQ_PARK_HEADS request
  and later it will queue REQ_UNPARK_HEADS one (this may need minor
  tweaks in block layer as we needed for PM support in ide, which is
  done in very similar way).

Given that at the moment we need to only handle _1_ accelerometer
we may start _really_ small and get things working.  Later we can
extend the functionality and interfaces as needed (like allowing
user to specify arbitrary system accelerometer(s)/disk(s) mappings).

[ It is also entirely possible that we will never need to extend it! ]

It may sound as we would need to start from scratch and throw out
the current solution.  This is not true, majority of code can be
nicely-recycled (i.e. logic from daemon, ...
[ message continues ]

First of all, I'm rather adverse to the idea that block layer is the
right place to interface with storage devices for in this particular
case. The only arguments for such a decision are that libata and ide
look the same on that level and that we have solved the issue of
serialisation. Nonetheless, we really are talking about an ATA specific
feature here and since I have had no luck with any suggestion to sneak
REQ_TYPE_LINUX_BLOCK requests past the scsi midlayer, I'd very much like
to avoid going down this route again. Instead, I'd probably suggest

I'm not convinced that putting all this directly into the hdaps module
is the right thing to do or would be accepted by the maintainers, for
that matter. In fact, since the mainline implementation of hdaps is
known to be broken and a lot of people (and distros) use the externally
maintained tp_smapi version instead, I think we should change that code
as little as possible. Which means that we will have to write a seperate

Still, it'll take time to add the missing bits and I'm going to have
less time to spare for the next few months than I had during the last
weeks. I wonder whether, from a user's POV, it is more valuable to have
a solution *now* which doesn't require recompiling the kernel but some
configuration in user space, or whether a complete solution with choice
between all-in-kernel or mixed-user-kernel-space some time in the future
is what they are waiting for. Arguably, this all is going to be obsolete
in the not so distant future since HDs with everything onboard are on
the market already. Then, of course, a software solution is more

Yes, I appreciate that. It's just that I have tried to get this thing
upstream somehow for quite some time now and I really have no idea how
long it is going to take me to figure out how to write this disk_shock
module and to get it past the maintainers (whoever that might be in this
case). Obviously, me getting impatient isn't a technical (or any good)
argument in favour of the current ...
[ message continues ]

I know Apple does it, and they need exactly the same queue freeze + ATA
unload immediate to have APS working.  But they will want both a kernel
interface (just using the firmware) and the userspace interface (to use

Frankly?  I doubt anybody really cares about the old ide driver for this
particular functionality.

How many systems have an accelerometer, are portable enough to need APS, and
have a SATA or PATA bridge that is not better driven by libata instead of

Choice is good here.  A really good imminent-shock predictor needs to do
some fairly decent ammount of digital signal processing (in 2d or 3d,
depending on the sensor).  That stuff is a lot easier to do if you have
floating point math available to you, for example.  That means userspace.

And some firmware can tell you "please do APS NOW!", so, for those you want
a kernel interface.

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

[ message continues ]

HP typically put the CD drive and hard drive on the same channel.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]