[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCHv2] Fix virtio-serial migration on bi-endian targ
From: |
Amit Shah |
Subject: |
Re: [Qemu-devel] [PATCHv2] Fix virtio-serial migration on bi-endian targets |
Date: |
Tue, 16 Dec 2014 11:37:23 +0530 |
On (Tue) 16 Dec 2014 [16:38:15], David Gibson wrote:
> On Tue, Dec 16, 2014 at 10:08:49AM +0530, Amit Shah wrote:
> > On (Tue) 16 Dec 2014 [15:33:54], David Gibson wrote:
> > > On Tue, Dec 16, 2014 at 09:43:30AM +0530, Amit Shah wrote:
> > > > Can you split this patch so the config change and the max_nr_ports
> > > > change are separate? The max_nr_ports could similarly be ignored by
> > > > dest, right?
> > >
> > > Um.. I'm not exactly sure where you're drawing the distinction between
> > > the two parts. Are you thinking
> > > patch 1) make config.max_nr_ports unused, by using
> > > max_virtserial_ports instead
> > > patch 2) eliminate the config field entirely
> >
> > For this patch, I'm just suggesting to only touch cols and rows, and
> > lines that touch the max_nr_ports can be put in 2/2. Eliminating
> > config entirely may not be desirable, but if you want to do that, and
> > mark all fields as 'unused' in the savevm/loadvm functions, go for
> > it :-)
>
> That division really doesn't make sense to me. If rows and cols are
> removed, but max_nr_ports stays, then get_config has to become a
> weird hybrid where it copies some stuff directly from ->config and
> other bits from elsewhere.
>
> I really don't see any reason keeping config would be a desirable
> thing: it's a cache of information that doesn't need to be cached, and
> just adds complexity because of the endian issues.
Oh please go ahead and do it -- my only point here is to split the
patchset into logical units, not wrt the total intent of the series.
Amit