| Message ID | 20210301143857.541050724@goodmis.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | trace-cmd: Fixes for trace-cmd restore | expand |
On Mon, Mar 1, 2021 at 4:38 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > From: "Steven Rostedt (VMware)" <rostedt@goodmis.org> > > Now that the input and output handles know the state they are at in reading > or writing, the tracecmd_copy() has to set the state of the output handle it > creates. > > Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> > --- > lib/trace-cmd/trace-output.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/lib/trace-cmd/trace-output.c b/lib/trace-cmd/trace-output.c > index 6d504cbaf133..1156899a85d3 100644 > --- a/lib/trace-cmd/trace-output.c > +++ b/lib/trace-cmd/trace-output.c > @@ -1656,6 +1656,8 @@ struct tracecmd_output *tracecmd_copy(struct tracecmd_input *ihandle, > if (tracecmd_copy_headers(ihandle, handle->fd) < 0) > goto out_free; > > + handle->file_state = TRACECMD_FILE_CMD_LINES; Why is the state overwritten here, isn't it more logical to be set in tracecmd_copy_headers(), by each function that copies a header to set the relevant state. The last call in tracecmd_copy_headers() is copy_command_lines(), which should set state to TRACECMD_FILE_CMD_LINES in case of success. The state is already TRACECMD_FILE_CMD_LINES in tracecmd_copy_headers(), but right before its exit it is overwritten to the old file state. And here again it is overwritten back to TRACECMD_FILE_CMD_LINES. May be I miss something here, cannot understand the logic. > + > /* The file is all ready to have cpu data attached */ > return handle; > > -- > 2.30.0 > >
On Tue, 2 Mar 2021 10:10:24 +0200 Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote: > On Mon, Mar 1, 2021 at 4:38 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > > > From: "Steven Rostedt (VMware)" <rostedt@goodmis.org> > > > > Now that the input and output handles know the state they are at in reading > > or writing, the tracecmd_copy() has to set the state of the output handle it > > creates. > > > > Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> > > --- > > lib/trace-cmd/trace-output.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/lib/trace-cmd/trace-output.c b/lib/trace-cmd/trace-output.c > > index 6d504cbaf133..1156899a85d3 100644 > > --- a/lib/trace-cmd/trace-output.c > > +++ b/lib/trace-cmd/trace-output.c > > @@ -1656,6 +1656,8 @@ struct tracecmd_output *tracecmd_copy(struct tracecmd_input *ihandle, > > if (tracecmd_copy_headers(ihandle, handle->fd) < 0) > > goto out_free; > > > > + handle->file_state = TRACECMD_FILE_CMD_LINES; > > Why is the state overwritten here, isn't it more logical to be set in > tracecmd_copy_headers(), by each function that copies a header to set That's because the handle is not passed into tracecmd_copy_headers. And because the handle is a struct tracecmd_output, the tracecmd_copy_headers() which is in trace-input.c doesn't have access to this structure, and I prefer to keep it that way. That said, we could modify tracecmd_copy_header() to return the state that it copied up to, or negative on error. state = tracecmd_copy_headers(ihandle, handle->fd); if (state < 0) goto out_free; handle->file_state = state; That would be more robust! -- Steve > the relevant state. The last call in tracecmd_copy_headers() > is copy_command_lines(), which should set state to > TRACECMD_FILE_CMD_LINES in case of success. > The state is already TRACECMD_FILE_CMD_LINES > in tracecmd_copy_headers(), but right before its exit it > is overwritten to the old file state. And here again it is > overwritten back to TRACECMD_FILE_CMD_LINES. > May be I miss something here, cannot understand the logic. > > > + > > /* The file is all ready to have cpu data attached */ > > return handle; > > > > -- > > 2.30.0 > > > > > >
On Tue, 2 Mar 2021 10:10:24 +0200 Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote: > Why is the state overwritten here, isn't it more logical to be set in > tracecmd_copy_headers(), by each function that copies a header to set > the relevant state. The last call in tracecmd_copy_headers() > is copy_command_lines(), which should set state to > TRACECMD_FILE_CMD_LINES in case of success. > The state is already TRACECMD_FILE_CMD_LINES > in tracecmd_copy_headers(), but right before its exit it > is overwritten to the old file state. And here again it is > overwritten back to TRACECMD_FILE_CMD_LINES. > May be I miss something here, cannot understand the logic. Also, as I believe you noticed, I saved the state in tracecmd_copy_headers() and restored it. But thinking about this more, I'm not sure I like that, and was thinking of just leaving the state of the input handle in the last state that it was updated in. In other words, I wasn't sure the best way to handle this, and reset the state because the original version didn't modify the state, and I was just keeping that the same. But since the fd is now different, it may be a good idea to change the state of the handle. This was something that I wanted to discuss with you, and I'm glad you brought it up, because I forgot about it ;-) -- Steve
On Tue, Mar 2, 2021 at 4:19 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > On Tue, 2 Mar 2021 10:10:24 +0200 > Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote: > > > On Mon, Mar 1, 2021 at 4:38 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > > > > > From: "Steven Rostedt (VMware)" <rostedt@goodmis.org> > > > > > > Now that the input and output handles know the state they are at in reading > > > or writing, the tracecmd_copy() has to set the state of the output handle it > > > creates. > > > > > > Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> > > > --- > > > lib/trace-cmd/trace-output.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/lib/trace-cmd/trace-output.c b/lib/trace-cmd/trace-output.c > > > index 6d504cbaf133..1156899a85d3 100644 > > > --- a/lib/trace-cmd/trace-output.c > > > +++ b/lib/trace-cmd/trace-output.c > > > @@ -1656,6 +1656,8 @@ struct tracecmd_output *tracecmd_copy(struct tracecmd_input *ihandle, > > > if (tracecmd_copy_headers(ihandle, handle->fd) < 0) > > > goto out_free; > > > > > > + handle->file_state = TRACECMD_FILE_CMD_LINES; > > > > Why is the state overwritten here, isn't it more logical to be set in > > tracecmd_copy_headers(), by each function that copies a header to set > > That's because the handle is not passed into tracecmd_copy_headers. > > And because the handle is a struct tracecmd_output, the > tracecmd_copy_headers() which is in trace-input.c doesn't have access to > this structure, and I prefer to keep it that way. > > That said, we could modify tracecmd_copy_header() to return the state that > it copied up to, or negative on error. > > state = tracecmd_copy_headers(ihandle, handle->fd); > if (state < 0) > goto out_free; > > handle->file_state = state; The output handle should have the same state as the input handle, so we can just have: handle->file_state = tracecmd_get_file_state(ihandle); There is exactly the same use case in tracecmd_get_output_handle_fd(), where the out handle is built on a partially written file. > > That would be more robust! > > -- Steve > > > > the relevant state. The last call in tracecmd_copy_headers() > > is copy_command_lines(), which should set state to > > TRACECMD_FILE_CMD_LINES in case of success. > > The state is already TRACECMD_FILE_CMD_LINES > > in tracecmd_copy_headers(), but right before its exit it > > is overwritten to the old file state. And here again it is > > overwritten back to TRACECMD_FILE_CMD_LINES. > > May be I miss something here, cannot understand the logic. > > > > > + > > > /* The file is all ready to have cpu data attached */ > > > return handle; > > > > > > -- > > > 2.30.0 > > > > > > > > > > >
On Tue, 2 Mar 2021 16:51:56 +0200 Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote: > > handle->file_state = state; > > The output handle should have the same state as the input handle, > so we can just have: > > handle->file_state = tracecmd_get_file_state(ihandle); > > There is exactly the same use case in tracecmd_get_output_handle_fd(), > where the out handle is built on a partially written file. The above is pretty much exactly what I did, but it eliminates error checking. Should there be a file_state = TRACECMD_FILE_ERROR ? -- Steve
On Tue, Mar 2, 2021 at 5:48 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > On Tue, 2 Mar 2021 16:51:56 +0200 > Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote: > > > > handle->file_state = state; > > > > The output handle should have the same state as the input handle, > > so we can just have: > > > > handle->file_state = tracecmd_get_file_state(ihandle); > > > > There is exactly the same use case in tracecmd_get_output_handle_fd(), > > where the out handle is built on a partially written file. > > The above is pretty much exactly what I did, but it eliminates error There is an error checking, if tracecmd_copy_headers() returns 0 then the ihandle state must be valid and we can use it safely. The tracecmd_get_file_state() could fail only in case of a NULL ihandle pointer. > checking. Should there be a file_state = TRACECMD_FILE_ERROR ? file_state should point to the last valid file read / write state, in case of read / write broken section of the file, the state should not be updated. The use case for invalid state can be an initial state, before TRACECMD_FILE_INIT. May be TRACECMD_FILE_UKOWN, but I cannot find a use case for it in the current implementation. > > -- Steve
On Tue, 2 Mar 2021 19:35:11 +0200 Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote: > On Tue, Mar 2, 2021 at 5:48 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > > > On Tue, 2 Mar 2021 16:51:56 +0200 > > Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote: > > > > > > handle->file_state = state; > > > > > > The output handle should have the same state as the input handle, > > > so we can just have: > > > > > > handle->file_state = tracecmd_get_file_state(ihandle); > > > > > > There is exactly the same use case in tracecmd_get_output_handle_fd(), > > > where the out handle is built on a partially written file. > > > > The above is pretty much exactly what I did, but it eliminates error > > There is an error checking, if tracecmd_copy_headers() returns 0 then > the ihandle state must be valid and we can use it safely. > The tracecmd_get_file_state() could fail only in case of a NULL > ihandle pointer. Nevermind, I mistaken the "tracecmd_get_file_state()" as "tracecmd_copy_headers()", I didn't notice that you introduced another API. Sure something like this would work too. -- Steve
diff --git a/lib/trace-cmd/trace-output.c b/lib/trace-cmd/trace-output.c index 6d504cbaf133..1156899a85d3 100644 --- a/lib/trace-cmd/trace-output.c +++ b/lib/trace-cmd/trace-output.c @@ -1656,6 +1656,8 @@ struct tracecmd_output *tracecmd_copy(struct tracecmd_input *ihandle, if (tracecmd_copy_headers(ihandle, handle->fd) < 0) goto out_free; + handle->file_state = TRACECMD_FILE_CMD_LINES; + /* The file is all ready to have cpu data attached */ return handle;