Dan Williams <dan.j.williams@xxxxxxxxx> writes: >> The sentiment is that programs shouldn't have to grovel around in sysfs >> to do stuff related to an open file descriptor or mapping. I don't take >> issue with the name. I do worry that something like 'wpq_drain' may be >> too platform specific, though. The NVM Programming Model specification >> is going to call this "deep flush", so maybe that will give you >> some inspiration if you do want to change the name. > > I'll change to "deep_flush", and I quibble that this is related to a > single open file descriptor or mapping. It really is a "region flush" > for giving extra protection for global metadata, but the persistence > of individual fds or mappings is handled by ADR. I think an ioctl > might give the false impression that every time you flush a cacheline > to persistence you need to call the ioctl. fsync, for example, may affect more than one fd--all data in the drive write cache will be flushed. I don't see how this is so different. I think a sysfs file is awkward because it requires an application to chase down the correct file in the sysfs hierarchy. If the application already has an open fd or a mapping, it should be able to operate on that. As for confusion on when to use the interface, I think that's inevitable no matter how it's implemented. We're introducing a flush type that has never been exposed before, and we're not giving any information on how likely an ADR failure is, or how expensive this flush will be. Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
