Home
last modified time | relevance | path

Searched hist:bc1a72afdc4a91844928831cac85731566e03bc6 (Results 1 – 4 of 4) sorted by relevance

/openbmc/linux/include/linux/
H A Dring_buffer.hdiff bc1a72afdc4a91844928831cac85731566e03bc6 Tue Mar 17 16:32:25 CDT 2020 Steven Rostedt (VMware) <rostedt@goodmis.org> ring-buffer: Rename ring_buffer_read() to read_buffer_iter_advance()

When the ring buffer was first created, the iterator followed the normal
producer/consumer operations where it had both a peek() operation, that just
returned the event at the current location, and a read(), that would return
the event at the current location and also increment the iterator such that
the next peek() or read() will return the next event.

The only use of the ring_buffer_read() is currently to move the iterator to
the next location and nothing now actually reads the event it returns.
Rename this function to its actual use case to ring_buffer_iter_advance(),
which also adds the "iter" part to the name, which is more meaningful. As
the timestamp returned by ring_buffer_read() was never used, there's no
reason that this new version should bother having returning it. It will also
become a void function.

Link: http://lkml.kernel.org/r/20200317213416.018928618@goodmis.org

Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
/openbmc/linux/kernel/trace/
H A Dtrace_functions_graph.cdiff bc1a72afdc4a91844928831cac85731566e03bc6 Tue Mar 17 16:32:25 CDT 2020 Steven Rostedt (VMware) <rostedt@goodmis.org> ring-buffer: Rename ring_buffer_read() to read_buffer_iter_advance()

When the ring buffer was first created, the iterator followed the normal
producer/consumer operations where it had both a peek() operation, that just
returned the event at the current location, and a read(), that would return
the event at the current location and also increment the iterator such that
the next peek() or read() will return the next event.

The only use of the ring_buffer_read() is currently to move the iterator to
the next location and nothing now actually reads the event it returns.
Rename this function to its actual use case to ring_buffer_iter_advance(),
which also adds the "iter" part to the name, which is more meaningful. As
the timestamp returned by ring_buffer_read() was never used, there's no
reason that this new version should bother having returning it. It will also
become a void function.

Link: http://lkml.kernel.org/r/20200317213416.018928618@goodmis.org

Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
H A Dring_buffer.cdiff bc1a72afdc4a91844928831cac85731566e03bc6 Tue Mar 17 16:32:25 CDT 2020 Steven Rostedt (VMware) <rostedt@goodmis.org> ring-buffer: Rename ring_buffer_read() to read_buffer_iter_advance()

When the ring buffer was first created, the iterator followed the normal
producer/consumer operations where it had both a peek() operation, that just
returned the event at the current location, and a read(), that would return
the event at the current location and also increment the iterator such that
the next peek() or read() will return the next event.

The only use of the ring_buffer_read() is currently to move the iterator to
the next location and nothing now actually reads the event it returns.
Rename this function to its actual use case to ring_buffer_iter_advance(),
which also adds the "iter" part to the name, which is more meaningful. As
the timestamp returned by ring_buffer_read() was never used, there's no
reason that this new version should bother having returning it. It will also
become a void function.

Link: http://lkml.kernel.org/r/20200317213416.018928618@goodmis.org

Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
H A Dtrace.cdiff bc1a72afdc4a91844928831cac85731566e03bc6 Tue Mar 17 16:32:25 CDT 2020 Steven Rostedt (VMware) <rostedt@goodmis.org> ring-buffer: Rename ring_buffer_read() to read_buffer_iter_advance()

When the ring buffer was first created, the iterator followed the normal
producer/consumer operations where it had both a peek() operation, that just
returned the event at the current location, and a read(), that would return
the event at the current location and also increment the iterator such that
the next peek() or read() will return the next event.

The only use of the ring_buffer_read() is currently to move the iterator to
the next location and nothing now actually reads the event it returns.
Rename this function to its actual use case to ring_buffer_iter_advance(),
which also adds the "iter" part to the name, which is more meaningful. As
the timestamp returned by ring_buffer_read() was never used, there's no
reason that this new version should bother having returning it. It will also
become a void function.

Link: http://lkml.kernel.org/r/20200317213416.018928618@goodmis.org

Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>