[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161115163735-mutt-send-email-mst@kernel.org>
Date: Tue, 15 Nov 2016 16:38:45 +0200
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Namhyung Kim <namhyung@...nel.org>
Cc: virtio-dev@...ts.oasis-open.org, kvm@...r.kernel.org,
qemu-devel@...gnu.org, virtualization@...ts.linux-foundation.org,
LKML <linux-kernel@...r.kernel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Anthony Liguori <aliguori@...zon.com>,
Anton Vorontsov <anton@...msg.org>,
Colin Cross <ccross@...roid.com>,
Kees Cook <keescook@...omium.org>,
Tony Luck <tony.luck@...el.com>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...nel.org>,
Minchan Kim <minchan@...nel.org>,
"Daniel P . Berrange" <berrange@...hat.com>
Subject: Re: [PATCH 2/3] qemu: Implement virtio-pstore device
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:
> > On Fri, Sep 16, 2016 at 07:05:47PM +0900, Namhyung Kim wrote:
> > > On Tue, Sep 13, 2016 at 06:57:10PM +0300, Michael S. Tsirkin wrote:
> > > > On Sat, Aug 20, 2016 at 05:07:43PM +0900, Namhyung Kim wrote:
> > > > > +
> > > > > +/* 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
Powered by blists - more mailing lists