On Thu, Dec 2, 2010 at 2:12 AM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > One thing which does leap out of the v2 implementation is the hardwired > assumption that there is one store kernel-wide. I suppose that's OK as > a version-1 implementation detail thing, but we should avoid hardwiring > that assumption into the presentation of v1's userspace interfaces. I think that user space should be able to survive the change to multiple storage devices. We can just read all the records from all the devices and present each one as a file. We just need to remember where they came from so we cal call the right erase function when the user unlinks the file. Unless there is some reason why we'd want to make it visible to the user which storage was being used? But even then, the user interface wouldn't change we could just have each device register a string to be included in the filename. Users could look at it if they cared, or ignore it if they don't care. The "type" of the data should stay at the front of the name so userspace can do "for f in dmesg*" to look at al the saved console logs, and it wouldn't matter if the files were "dmesg-0", "dmesg-1" or "dmesg-erst-0", "dmesg-erst-1". I can't quite see why anyone would care which device was used, but the option to provide it would be there without breaking apps that used the v1 interface. The tricky part of multiple devices is the write side ... how to decide which records should be stored in which device. I can imagine lots of possibilities (store by type, round-robin, use one until full then move on, look at the size of the data to be stored and save in the device with the smallest record size that could hold the data, ...) but I'm just making stuff up - I don't know how someone with two or more devices would actually want to assign them ... hence I'm leaving this as an exercise to someone with more than one device :-) -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
