On Mon, 2014-03-17 at 11:33 -0700, Greg KH wrote: > There were only 3 (or 4), users of this api, and no new ones had been > added in _years_, it's a very obscure thing, and odds are, it wouldn't > ever be added again, especially as it was just removed entirely not > being needed anymore. And I'd argue, it's something that you shouldn't > have even been doing in the first place, so why a new user of it was > added now is quite strange to me. Actually that's a good question. Is there a better way for us than to use this API ? Essentially we use that because it's our understanding that it is what is needed for a sysfs file that can remove its parent directory from within a write() op. We followed the driver "remove" implementation as an example. The reason the opal elog and dump patches use it is that those two patches add sysfs interface that represent the error logs (and platform dumps but you can treat the latter as some kind of special case of error logs) from the service processor in sysfs. So for each log we create a dir (kobject) which we populate with a few things like the log unique ID, raw data, etc.... and a file that can be used to "ack" the log with the service processor. The latter has the effect of removing it. This is done by the collection daemon after it has confirmed that the error log has been stored to disk and properly flushed. Is there a better interface ? Can we implement for example unlink() on the kobject itself ? IE. Do the ack by essentially having userspace rm the directory ? :-) Now regarding the practicals of sorting out our trees, Stephen suggested that rather than doing anything on my side (heh, I like that !), you should revert the last patch of the series, the one removing the old API, in your tree. It can then be re-applied later around rc1. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
