On Thu, 29 Apr 2021 06:43:54 +0300 Tzvetomir Stoyanov <tz.stoyanov@xxxxxxxxx> wrote: > On Thu, Apr 29, 2021 at 4:19 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > On Thu, 22 Apr 2021 10:17:13 +0300 > > "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@xxxxxxxxx> wrote: > > > > > Adding a compression of the trace.dat file will change its structure. > > > These changes are not backward compatible, the old trace-cmd binaries > > > will not be able to read compressed trace files. Bumping the version to > > > 7 will prevent old trace-cmd to read such files. > > > > But this series doesn't add anything to the file that breaks the > > version. The version should be updated with the patch that breaks the > > backward compatibility. of the file, not before. > > > I need the new version before the compression changes, because there > is logic which relies on the new version. There is a check whether to > read / write compression data based on the new file version. I was > wondering if to put all changes into a single patchset, version + > compression. Decided to split in two, although there is no sense to > bump the version without adding a compression. The file should stay at version 6 unless it has something that old trace-cmd can not read. Right now, with this patch, if I record a trace.dat file, and I port the version check to older trace-cmd, it will think it can not read this file, even though there's nothing in this file. In fact, it should write version 6 until it writes something that is not supported by version 6. It will still need to be able to write version 6 files. In fact that's one of the requirements here. That we allow trace-cmd to create older versions if it does not use the features of the the new version. -- Steve
|