Very lengthy discussion, apologies if I repeat something in one of the
various threads but I read lots of these discussions and I'm somewhat
confused still of what this is all about...
On Wed, Nov 25, 2009 at 04:09:55PM +0200, Michael S. Tsirkin wrote:
We were discussing features that are
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
A device already supports load for a range
of versions between X and Y. We want to support
saving to a range of versions.
Which versions to use is a separate decision
which should be
On Wed, Nov 25, 2009 at 10:30:47AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
A device already supports load for a range
of versions between X and Y. We want to support
saving to a range of
On 11/24/09 15:05, Michael S. Tsirkin wrote:
On Mon, Nov 23, 2009 at 03:13:59PM +0100, Juan Quintela wrote:
But this would only kick in when using pc-0.11 or something, right?
Yeap.
At this point, pc-0.10 is just:
static QEMUMachine pc_machine_v0_10 = {
.name = pc-0.10,
.desc =
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 25, 2009 at 10:30:47AM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
A device already supports load for a range
of versions between X and Y. We
And this is also the trivial part to describe: I want a
machine like the one in qemu-0.11.
Yes, but there might be a ton of reasons to want a
machine like the one in qemu 0.11.
The need to migrate to old qemu is very rare,
it is a completely separate decision
one might take long after
On Wed, Nov 25, 2009 at 02:36:49PM +0100, Gerd Hoffmann wrote:
On 11/24/09 15:05, Michael S. Tsirkin wrote:
On Mon, Nov 23, 2009 at 03:13:59PM +0100, Juan Quintela wrote:
But this would only kick in when using pc-0.11 or something, right?
Yeap.
At this point, pc-0.10 is just:
static
On 11/25/09 14:40, Michael S. Tsirkin wrote:
We could add a DeviceState-savevm field and make that available as
property for devices which need to support multiple versions. Then you
we can use the compat properties to switch back to the older format with
-M pc-0.10.
I'm confused sorry. Of
On Wed, Nov 25, 2009 at 03:10:16PM +0100, Gerd Hoffmann wrote:
Hi,
Doesn't work. If you have a qemu 0.11 machine, a virtio nic and your
guest uses MSI-X you simply can't migrate to qemu 0.10. End of story.
If you want to be able to migrate to 0.10 you have to start in 0.10
compat mode
On 11/25/09 15:09, Michael S. Tsirkin wrote:
We were discussing features that are (mostly) not user-visible.
It is clear that if you have a user-visible change you have
a different machine, so you can not migrate.
Now if you fix a bug by changing savevm format, without user visible
changes you
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 25, 2009 at 02:59:58PM +0100, Gerd Hoffmann wrote:
On 11/25/09 14:40, Michael S. Tsirkin wrote:
We could add a DeviceState-savevm field and make that available as
property for devices which need to support multiple versions. Then you
we
On Wed, Nov 25, 2009 at 03:53:40PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Nov 25, 2009 at 02:59:58PM +0100, Gerd Hoffmann wrote:
On 11/25/09 14:40, Michael S. Tsirkin wrote:
We could add a DeviceState-savevm field and make that available as
On Wed, Nov 25, 2009 at 04:10:34PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 24, 2009 at 08:33:11AM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
It's very easy: if their guest runs fine on the old qemu,
it should be safe to migrate there.
On 11/23/2009 02:15 PM, Juan Quintela wrote:
Dor Laordl...@redhat.com wrote:
In the last couple of days we discovered some issues regarding stable
ABI and the robustness of the live migration protocol. Let's just jump
right into it, ordered by complexity:
1. Control*every* feature
On 11/23/2009 08:28 PM, Anthony Liguori wrote:
Eduardo Habkost wrote:
That may be good enough for upstream Qemu, but IMO for RHEL it is not a
realistic policy. If the definition of guest visible state is buggy on
the current implementation, we can't drop entirely the possibility of
fixing it on
On Sun, Nov 22, 2009 at 09:49:26AM -0600, Anthony Liguori wrote:
We cannot even create a new 'hack section' for new code since the
sections are ordered and expected to be exact match on the
destination.
The result is that new-old migration cannot work. This is not cross
On Mon, Nov 23, 2009 at 02:36:40PM +0200, Gleb Natapov wrote:
My problem implementing optional features/sections/... is not the
savevm/VMState bits. At the end, implementing that is easy. What is
more dificult is once that a device have 5 features, what are the valid
combinations. i.e.
On Mon, Nov 23, 2009 at 08:49:23AM -0600, Anthony Liguori wrote:
Juan Quintela wrote:
Anthony Liguori anth...@codemonkey.ws wrote:
Juan Quintela wrote:
I'm not at all convinced that you can downgrade the version of a
device without exposing a functional change to a guest. In
Michael S. Tsirkin wrote:
On Sun, Nov 22, 2009 at 09:49:26AM -0600, Anthony Liguori wrote:
We cannot even create a new 'hack section' for new code since the
sections are ordered and expected to be exact match on the
destination.
The result is that new-old migration cannot work.
On Tue, Nov 24, 2009 at 07:45:13AM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On Sun, Nov 22, 2009 at 09:49:26AM -0600, Anthony Liguori wrote:
We cannot even create a new 'hack section' for new code since the
sections are ordered and expected to be exact match on the
Reading in old state files is a whole lot easier (to write
maintain, and stay sane) than producing state that is bug-compatible with
previous versions.
It seems to me that old-new and new-old migrations are
of about the same level of difficulty.
Supporting one of these but not the other
On Mon, Nov 23, 2009 at 01:15:01PM +0100, Juan Quintela wrote:
Dor Laor dl...@redhat.com wrote:
In the last couple of days we discovered some issues regarding stable
ABI and the robustness of the live migration protocol. Let's just jump
right into it, ordered by complexity:
1. Control
On Tue, Nov 24, 2009 at 12:39:50PM +0200, Dor Laor wrote:
On 11/23/2009 02:15 PM, Juan Quintela wrote:
Dor Laordl...@redhat.com wrote:
In the last couple of days we discovered some issues regarding stable
ABI and the robustness of the live migration protocol. Let's just jump
right into
On Mon, Nov 23, 2009 at 03:13:59PM +0100, Juan Quintela wrote:
Anthony Liguori anth...@codemonkey.ws wrote:
Juan Quintela wrote:
Dor Laor dl...@redhat.com wrote:
My idea here is that we need to have further use of machine
descriptions, once that is done, we need something like a
Michael S. Tsirkin m...@redhat.com wrote:
But to really make it work, we need to take a list of each savevm format
change and put it here. Notice that several changes are needed:
- savevm infrastructure save functions don't know about version id
- devices don't know to behave as other
On Tue, Nov 24, 2009 at 01:59:49PM +, Paul Brook wrote:
Reading in old state files is a whole lot easier (to write
maintain, and stay sane) than producing state that is bug-compatible with
previous versions.
It seems to me that old-new and new-old migrations are
of about the
Michael S. Tsirkin wrote:
It's very easy: if their guest runs fine on the old qemu,
it should be safe to migrate there.
Runs fine is a qualitative statement. There is no way for qemu to
know whether a guest runs fine or not. There is no way that we can make
that statement either. It
On Tue, Nov 24, 2009 at 03:20:47PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
But to really make it work, we need to take a list of each savevm format
change and put it here. Notice that several changes are needed:
- savevm infrastructure save functions don't
On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 24, 2009 at 12:39:50PM +0200, Dor Laor wrote:
On 11/23/2009 02:15 PM, Juan Quintela wrote:
Dor Laordl...@redhat.com wrote:
In the last couple of days we discovered some
On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 24, 2009 at 12:39:50PM +0200, Dor Laor wrote:
On 11/23/2009 02:15 PM, Juan Quintela wrote:
Dor Laordl...@redhat.com wrote:
In the last couple of days we discovered some
On Tue, Nov 24, 2009 at 08:33:11AM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
It's very easy: if their guest runs fine on the old qemu,
it should be safe to migrate there.
Runs fine is a qualitative statement. There is no way for qemu to
know whether a guest runs fine or
On Tue, Nov 24, 2009 at 4:21 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 24, 2009 at 01:59:49PM +, Paul Brook wrote:
Reading in old state files is a whole lot easier (to write
maintain, and stay sane) than producing state that is bug-compatible with
previous versions.
On Tue, Nov 24, 2009 at 07:06:01PM +0200, Blue Swirl wrote:
On Tue, Nov 24, 2009 at 4:21 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 24, 2009 at 01:59:49PM +, Paul Brook wrote:
Reading in old state files is a whole lot easier (to write
maintain, and stay sane) than
On 11/24/2009 03:30 PM, Juan Quintela wrote:
No, new - old is way, way more difficult.
New-old is way more difficult with the current migration file format.
The current migration file format is not at all designed to be read by
an older version.
Or for that matter a tool that only cares
On 11/24/2009 06:08 PM, Michael S. Tsirkin wrote:
The external version translator tool could support arbitrary
conversion between the whole NxN matrix of versions (including distro
hacks), or just those that RHEL happens to use. The tool would not be
limited to QEMU development
Paolo Bonzini wrote:
On 11/24/2009 06:08 PM, Michael S. Tsirkin wrote:
The external version translator tool could support arbitrary
conversion between the whole NxN matrix of versions (including
distro
hacks), or just those that RHEL happens to use. The tool would
not be
limited to
On Tue, Nov 24, 2009 at 8:51 PM, Anthony Liguori anth...@codemonkey.ws wrote:
Paolo Bonzini wrote:
On 11/24/2009 06:08 PM, Michael S. Tsirkin wrote:
The external version translator tool could support arbitrary
conversion between the whole NxN matrix of versions (including distro
On 11/24/2009 07:51 PM, Anthony Liguori wrote:
to make the primary representation of state an XML document
Since my brain is not working well today, I'll just point out that of
course I meant the primary representation of _schemas_ an XML document
or anything like that.
or anything like
Blue Swirl wrote:
But the complexity would be a problem only for the transformation
matrix project. For QEMU the gain would be simplified design, maybe at
the expense of some CPP magic.
I don't think it's always a matter of just transforming state. There
will be certain features that need
Paolo Bonzini wrote:
On 11/24/2009 07:51 PM, Anthony Liguori wrote:
to make the primary representation of state an XML document
Since my brain is not working well today, I'll just point out that of
course I meant the primary representation of _schemas_ an XML
document or anything like that.
On Tue, Nov 24, 2009 at 01:29:09PM -0600, Anthony Liguori wrote:
Paolo Bonzini wrote:
On 11/24/2009 07:51 PM, Anthony Liguori wrote:
to make the primary representation of state an XML document
Since my brain is not working well today, I'll just point out that of
course I meant the primary
On 11/23/2009 03:17 AM, Anthony Liguori wrote:
You mean, each device would have multiple sections? We already use
chunks for each device state.
If they want to, yes.
We only migrate things that are guest visible. Everything else is left
to the user to configure. We wouldn't migrate the
On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
Paolo Bonzini wrote:
I don't see how this fixes anything. If you used feature bits, how do
you migrate from a version that has a feature bit that an older version
doesn't know about? Do you just ignore it?
I'd go with chunk
On 11/23/2009 09:26 AM, Gleb Natapov wrote:
I'd go with chunk instead of feature bits, specifying them like in
the PNG specification:
You mean, each device would have multiple sections? We already use
chunks for each device state.
Each device can send device info in multiple formats
On Mon, Nov 23, 2009 at 10:29:12AM +0100, Paolo Bonzini wrote:
On 11/23/2009 09:26 AM, Gleb Natapov wrote:
I'd go with chunk instead of feature bits, specifying them like in
the PNG specification:
You mean, each device would have multiple sections? We already use
chunks for each
Dor Laor dl...@redhat.com wrote:
In the last couple of days we discovered some issues regarding stable
ABI and the robustness of the live migration protocol. Let's just jump
right into it, ordered by complexity:
1. Control *every* feature exposed to the guest by qemu cmdline:
While
On Mon, Nov 23, 2009 at 01:25:32PM +0100, Juan Quintela wrote:
Gleb Natapov g...@redhat.com wrote:
On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
Paolo Bonzini wrote:
I don't see how this fixes anything. If you used feature bits, how do
you migrate from a version that
On Mon, Nov 23, 2009 at 01:29:11PM +0100, Juan Quintela wrote:
Gleb Natapov g...@redhat.com wrote:
On Mon, Nov 23, 2009 at 10:29:12AM +0100, Paolo Bonzini wrote:
On 11/23/2009 09:26 AM, Gleb Natapov wrote:
I'd go with chunk instead of feature bits, specifying them like in
the PNG
Juan Quintela wrote:
Gleb Natapov g...@redhat.com wrote:
On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
Paolo Bonzini wrote:
I don't see how this fixes anything. If you used feature bits, how do
you migrate from a version that has a feature bit that an older
Juan Quintela wrote:
Dor Laor dl...@redhat.com wrote:
I will go further, and think that this kind of issues should be put into
the machine type.
I agree.
If you start qemu with -M pc-0.10, it should save the state in a 0.10
compatible way (that don't happens at the moment, but it
Paolo Bonzini wrote:
On 11/23/2009 03:17 AM, Anthony Liguori wrote:
You mean, each device would have multiple sections? We already use
chunks for each device state.
If they want to, yes.
We only migrate things that are guest visible. Everything else is left
to the user to configure. We
Excerpts from Anthony Liguori's message of Mon Nov 23 00:17:46 -0200 2009:
Paolo Bonzini wrote:
I don't see how this fixes anything. If you used feature bits, how do
you migrate from a version that has a feature bit that an older version
doesn't know about? Do you just ignore it?
I'd
Anthony Liguori anth...@codemonkey.ws wrote:
Juan Quintela wrote:
Dor Laor dl...@redhat.com wrote:
My idea here is that we need to have further use of machine
descriptions, once that is done, we need something like a new property
for qdev (version?). Once there, each device could do:
On 11/23/2009 02:51 PM, Eduardo Habkost wrote:
Right, but I wouldn't be surprised if a user complains that I know that
my guest don't use that VM feature, so I want to be able to migrate to
an older version anyway.
That's a bit more tricky. What if the older version doesn't support
sound
On Mon, Nov 23, 2009 at 03:09:35PM +0100, Juan Quintela wrote:
Gleb Natapov g...@redhat.com wrote:
On Mon, Nov 23, 2009 at 01:25:32PM +0100, Juan Quintela wrote:
Gleb Natapov g...@redhat.com wrote:
On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
Yes, I proposed to send
Juan Quintela wrote:
Anthony Liguori anth...@codemonkey.ws wrote:
Juan Quintela wrote:
I'm not at all convinced that you can downgrade the version of a
device without exposing a functional change to a guest. In fact, I'm
pretty certain that it's provably impossible. Please give
Gleb Natapov wrote:
My problem implementing optional features/sections/... is not the
savevm/VMState bits. At the end, implementing that is easy. What is
more dificult is once that a device have 5 features, what are the valid
combinations. i.e. if you have pci and msix features, msix requires
Eduardo Habkost wrote:
Migration needs to be conservative. There should be only two possible
outcomes: 1) a successful live migration or 2) graceful failure with the
source VM still running correctly. Silently ignoring things that could
affect the guests behavior means that it's possible that
On Mon, Nov 23, 2009 at 08:51:17AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
My problem implementing optional features/sections/... is not the
savevm/VMState bits. At the end, implementing that is easy. What is
more dificult is once that a device have 5 features, what are the valid
Paolo Bonzini wrote:
On 11/23/2009 02:51 PM, Eduardo Habkost wrote:
Right, but I wouldn't be surprised if a user complains that I know that
my guest don't use that VM feature, so I want to be able to migrate to
an older version anyway.
That's a bit more tricky. What if the older version
On Mon, Nov 23, 2009 at 03:21:24PM +0100, Paolo Bonzini wrote:
On 11/23/2009 02:51 PM, Eduardo Habkost wrote:
Right, but I wouldn't be surprised if a user complains that I know that
my guest don't use that VM feature, so I want to be able to migrate to
an older version anyway.
That's a bit
Gleb Natapov wrote:
Then I don't see why Juan claims what he claims.
Live migration is unidirectional. As long as qemu can send out all of
the data without the stream closing, it will succeed on the source.
While this may sound like a bug, it's an impossible problem to solve as
it's
Eduardo Habkost wrote:
The pvclock MSRs are an example: if the guest is not using pvclock, not
restoring the MSRs won't make any difference. Strictly speaking, not
migrating them is wrong, but the user may argue that they know it won't
impact their guest OS, and that they want to take the risk.
On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
Then I don't see why Juan claims what he claims.
Live migration is unidirectional. As long as qemu can send out all
of the data without the stream closing, it will succeed on the
source. While this may
Excerpts from Anthony Liguori's message of Mon Nov 23 12:49:23 -0200 2009:
Juan Quintela wrote:
But if you know substitute qemu-0.11 and qemu-0.12 for RHEL5.4 and
RHEL5.4.1, you will see that the code bases are going to be really,
really similar. And if any savevm format is changed, it is
On 11/23/2009 04:22 PM, Gleb Natapov wrote:
As far as I remember the two general's problem talks about unreliable
channel, not unreliable nodes. Why not having destination send ACK/NACK
to the source when it knows that migration succeeded/failed. If source
gets NACK it continues, if it gets ACK
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
Then I don't see why Juan claims what he claims.
Live migration is unidirectional. As long as qemu can send out all
of the data without the stream closing, it will succeed
On Mon, Nov 23, 2009 at 09:00:05AM -0600, Anthony Liguori wrote:
snip
I think the problem is that you shouldn't be changing the guest visible
state in a stable update of qemu. If you change the guest visible state
in a stable update, then you won't be able to support live migration
On Mon, Nov 23, 2009 at 09:32:48AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
Then I don't see why Juan claims what he claims.
Live migration is unidirectional. As long as qemu can send out all
of
On Mon, Nov 23, 2009 at 05:01:58PM +0100, Juan Quintela wrote:
Anthony Liguori anth...@codemonkey.ws wrote:
Gleb Natapov wrote:
My problem implementing optional features/sections/... is not the
savevm/VMState bits. At the end, implementing that is easy. What is
more dificult is once
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 09:32:48AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
Then I don't see why Juan claims what he claims.
Live migration is
Gleb Natapov wrote:
According to Anthony this is not a bug. Management has all the means to
resolve this situation properly. The bug would be if dst and src both
run or both exit.
Yup. And they do. If you do the same migration with libvirt, it will
fail gracefully with a -1 in the
On Mon, Nov 23, 2009 at 10:09:15AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 09:32:48AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 09:05:58AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
Then I don't see why Juan claims what
Eduardo Habkost wrote:
Excerpts from Anthony Liguori's message of Mon Nov 23 12:49:23 -0200 2009:
Juan Quintela wrote:
But if you know substitute qemu-0.11 and qemu-0.12 for RHEL5.4 and
RHEL5.4.1, you will see that the code bases are going to be really,
really similar. And if any
Gleb Natapov wrote:
I am OK with management being responsible to sort things out. Juan
said that destination can't abort migration in the middle, so I pointed
out easy solution that will work in 99.999% cases.
I think there's something elegant about doing migration in a
unidirectional
Juan Quintela wrote:
you can weasel the way you want (I can also do it).
Customer had: 5.4 - 5.4 migration working (suboptimally)
Now appears 5.4.1 that works best with migration. But he want to do the
migration in two steps:
migrate from qemu 5.4 - 5.4.1, and be able to migrate back if he
Excerpts from Anthony Liguori's message of Mon Nov 23 14:16:39 -0200 2009:
Eduardo Habkost wrote:
Excerpts from Anthony Liguori's message of Mon Nov 23 12:49:23 -0200 2009:
snip
In our own stable branch, we do not introduce any savevm changes. I
would recommend the same policy
Eduardo Habkost wrote:
That may be good enough for upstream Qemu, but IMO for RHEL it is not a
realistic policy. If the definition of guest visible state is buggy on
the current implementation, we can't drop entirely the possibility of
fixing it on our stable branch.
After mulling over it a
Juan Quintela wrote:
The problem here isn't migration, it's what you've decided to backport
into your stable branch.
No. the problem is that I made a mistake in the past. And didn't add a
field to the state that I should. It just happens to work without that
field in several use cases.
On Mon, Nov 23, 2009 at 12:28:16PM -0600, Anthony Liguori wrote:
Eduardo Habkost wrote:
That may be good enough for upstream Qemu, but IMO for RHEL it is not a
realistic policy. If the definition of guest visible state is buggy on
the current implementation, we can't drop entirely the
Eduardo Habkost wrote:
On Mon, Nov 23, 2009 at 12:28:16PM -0600, Anthony Liguori wrote:
Eduardo Habkost wrote:
That may be good enough for upstream Qemu, but IMO for RHEL it is not a
realistic policy. If the definition of guest visible state is buggy on
the current implementation, we
Excerpts from Anthony Liguori's message of Mon Nov 23 14:44:04 -0200 2009:
I don't want to transparently migrate from 5.4.1 to 5.4.0 and have my
guest's time start drifting. I specifically want that to fail.
If you migrate from 5.4.0 to 5.4.0 or from 5.4.0 to 5.4.1, the guest
will also
On Mon, Nov 23, 2009 at 01:49:09PM -0600, Anthony Liguori wrote:
Eduardo Habkost wrote:
On Mon, Nov 23, 2009 at 12:28:16PM -0600, Anthony Liguori wrote:
snip
After mulling over it a bit, here's what I'd suggest:
1) Integrate VMstate with qdev
2) Introduce a bitmap blacklist for
I don't see how this fixes anything. If you used feature bits, how do
you migrate from a version that has a feature bit that an older version
doesn't know about? Do you just ignore it?
I'd go with chunk instead of feature bits, specifying them like in the
PNG specification:
Each
Paolo Bonzini wrote:
I don't see how this fixes anything. If you used feature bits, how do
you migrate from a version that has a feature bit that an older version
doesn't know about? Do you just ignore it?
I'd go with chunk instead of feature bits, specifying them like in the
PNG
85 matches
Mail list logo
