On Tue, Mar 18, 2014 at 07:33:30AM +1100, Benjamin Herrenschmidt wrote: > 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 ? :-) No you can't, sorry. And this seems like a huge abuse of sysfs, you better be using binary sysfs files for your log data... Do you have a pointer to where you document this sysfs api in Documentation/ABI/ ? > 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. I'll look to see if we can do that, let me dig it up out of my tree... thanks, greg k-h -- 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
