On Thu, Dec 16, 2010 at 10:28 PM, Tony Luck <tony.luck@xxxxxxxxx> wrote:
>> The _only_ valid reason for persistent storage is for things like
>> oopses that kill the machine.
>
> Maybe I misunderstood what "KMSG_DUMP_OOPS" meant ... it
> looked to me like this code is used for non-fatal OOPsen - ones
> that will be logged to /var/log/messages.
Thinking about this a bit more I see my experiments with
this were hopelessly naive. There is no way to know at
"oops" time whether the problem is going to turn out to
be minor or fatal. So the right thing to do here is assume
the worst and squirrel the data away safely just in case
death is imminent.
This means that I need to re-think this part too:
+/*
+ * Call platform driver to write a record to the
+ * persistent store. We don't worry about making
+ * this visible in the pstore filesystem as the
+ * presumption is that we only save things to the
+ * store in the dying moments of OS failure. Hence
+ * nobody will see the entries in the filesystem.
+ */
Since rumors of the death of the kernel may be greatly
exaggerated ... I *do* need to make the newly added
records visible in the pstore file system so that we
don't run into the situation where persistent store
has been filled with a series of minor oops reports
(which are in any case also logged elsewhere) with
no space left to log the fatal message. Adding
them to the file system would give the user a handle
to look at them and erase them.
> So in the end, I really don't see any point at all to this thing.
So does fixing this stupidity provide a useful point for this?
The point I see, is providing a generic layer that any platform
persistent store driver can use by just writing simple
read/write/erase functions ... rather than everyone
having to roll their own, slightly different, versions of
what could be a common interface. There was a
recent attempt to do exactly this with:
drivers/staging/dream/pmem.c
which has currently been dropped - but it may come
back (and my version doesn't have, or need, "ioctl"
operations :-).
-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
