On Fri, Nov 11, 2016 at 12:50:03AM +0200, Michael S. Tsirkin wrote:
On Fri, Sep 16, 2016 at 07:05:47PM +0900, Namhyung Kim wrote:
quoted
On Tue, Sep 13, 2016 at 06:57:10PM +0300, Michael S. Tsirkin wrote:
quoted
On Sat, Aug 20, 2016 at 05:07:43PM +0900, Namhyung Kim wrote:
quoted
+
+/* the index should match to the type value */
+static const char *virtio_pstore_file_prefix[] = {
+ "unknown-", /* VIRTIO_PSTORE_TYPE_UNKNOWN */
Is there value in treating everything unexpected as "unknown"
and rotating them as if they were logs?
It might be better to treat everything that's not known
as guest error.
I was thinking about the version mismatch between the kernel and qemu.
I'd like to make the device can deal with a new kernel version which
might implement a new pstore message type. It will be saved as
unknown but the kernel can read it properly later.
Well it'll have a different prefix. E.g. if kernel has
two different types they will end up in the same
file, hardly what was wanted.
Right, I think it needs to add 'type' info to the filename for unknown
type.
Thanks,
Namhyung
On Tue, Nov 15, 2016 at 03:23:36PM +0900, Namhyung Kim wrote:
On Fri, Nov 11, 2016 at 12:50:03AM +0200, Michael S. Tsirkin wrote:
quoted
On Fri, Sep 16, 2016 at 07:05:47PM +0900, Namhyung Kim wrote:
quoted
On Tue, Sep 13, 2016 at 06:57:10PM +0300, Michael S. Tsirkin wrote:
quoted
On Sat, Aug 20, 2016 at 05:07:43PM +0900, Namhyung Kim wrote:
quoted
+
+/* the index should match to the type value */
+static const char *virtio_pstore_file_prefix[] = {
+ "unknown-", /* VIRTIO_PSTORE_TYPE_UNKNOWN */
Is there value in treating everything unexpected as "unknown"
and rotating them as if they were logs?
It might be better to treat everything that's not known
as guest error.
I was thinking about the version mismatch between the kernel and qemu.
I'd like to make the device can deal with a new kernel version which
might implement a new pstore message type. It will be saved as
unknown but the kernel can read it properly later.
Well it'll have a different prefix. E.g. if kernel has
two different types they will end up in the same
file, hardly what was wanted.
Right, I think it needs to add 'type' info to the filename for unknown
type.
Thanks,
Namhyung
And that opens all kind of resource management issues as guest
might be able to open a ton of these unexpected types.
So don't try to predict the future, if you add a new type
you add a feature flag. Ignore or error on things you can
not handle.
--
MST