Hi all, at the moment I'm having another go at trying to make the disk shock protection patch fit for upstream submission. However, there are still some fundamental issues I'd like to discuss in order to make sure that I'm heading in the right direction. The general idea: A daemon running in user space monitors input data from an accelerometer. When the daemon detects a critical condition, i.e., a sudden acceleration (for instance, laptop slides off the desk), it signals the kernel so the hard disk may be put into a (more) safe state. To this end, the kernel has to issue an idle immediate command with unload feature and stop the block layer queue afterwards. Once the daemon tells us that the imminent danger is over, the most important task for the kernel is to restart the block layer queue. See below for more details. This project is (and I personally am) mainly concerned with laptops equipped with an accelerometer and an (S)ATA hard drive that supports the unload feature of the idle immediate command. Jens Axboe, however, suggested right from the beginning that there might be more general applications for the block layer queue freezing part of the story. The question is now to what extent are the requirements for a disk shock protection facility (specific to ATA devices) and a general block layer queue freezing facility compatible and in what way should they be exposed to user space. Probably, the major problem is that I don't really know what kind of applications (apart from shock protection) I should be thinking of that might want to have a queue freezing facility at hand. Still, one thing seems obvious to me: For disk shock protection, time is of the essence, whereas in the more general case of simple block layer queue freezing, the situation is different as far as lower levels are concerned. In particular, I'm inclined to believe that in the context of such a general application it would be desirable to be able to freeze the queue of an ATA device *without* issuing an idle immediate command first. Obviously, the interface exposed to userspace would have to provide for these diverging needs. The disk-protect patch in it's current form [1] got stuck somewhere between trying to provide a general queue freezing facility and accommodating the needs of a disk shock protection setup. The sysfs attributes required to request immediate disk parking from user space are exported under /sys/block/. This is very convenient from the user's point of view because the hierarchy is intuitive and you can easily find the subdirectory associated to your hard disk. Conceptually, though, it doesn't feel right. That is, for simple queue freezing, it is perfectly alright, of course, but I don't see why and, indeed, how an ATA specific feature like immediate disk parking could be controlled from the block layer in a straight forward way. Besides, Jens, quite understandably, objects to the introduction of yet another queue hook which is the current way of telling ATA and non-ATA devices apart. Instead, he suggests to implement generic block layer notification requests like REQ_LB_OP_FREEZE of type REQ_TYPE_LINUX_BLOCK and let low level drivers act upon it as they see fit. But then we would still need a way to configure the way libata / ide actuaaly does respond to those block layer messages. As explained above, the user might want to choose whether or idle immediate is to be issued or simple queue freezing is enough for his / her purposes. Besides, some drives that actually support the unload feature of the idle immediate command don't report that capability in the IDENTIFY data, so userspace needs a way to tell the driver that the feature is available after all. So, roughly my questions are these: 1. Who is to be in charge for the shock protection application? Should userspace speak to libata / ide directly (through sysfs) and the low level drivers will notify block layer to stop the queeue or should userspace always talk to the block layer, regardless whether we want to park an ATA disk or just freeze the queue? In the latter case we'd still need the option to configure the exact behaviour for ATA devices. 2. Depending on the answer to the previous question, by what mechanism should block layer and lld interact? Special requests, queue hooks or something in some way similar to power management functions (once suggested by James Bottomley)? 3. What is the preferred way to pass device specific configuration options to libata (preferrably at runtime, i.e., after module loading)? Please let me know if you need any further information. Also, I will certainly have more questions once I try to my hand at any of your suggestions. Thanks in advance, Elias [1] http://article.gmane.org/gmane.linux.drivers.hdaps.devel/1094 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
