Re: [RFC] tools lib traceevent: How to do library versioning being in the Linux kernel source?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [RFC] tools lib traceevent: How to do library versioning being in the Linux kernel source?
- From: Namhyung Kim <namhyung@xxxxxxxxxx>
- Date: Tue, 7 Jan 2020 22:15:01 +0900
- Cc: Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>, Jiri Olsa <jolsa@xxxxxxxxxx>, Masami Hiramatsu <mhiramat@xxxxxxxxxx>, Linux Trace Devel <linux-trace-devel@xxxxxxxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
- In-reply-to: <20200103181921.3858c90a@gandalf.local.home>
- References: <20200102122004.216c85da@gandalf.local.home> <CADVatmO8mvhtgZ=CNv8uxhVkh2nqg5bjCLzTxyA9UDerRox8Ug@mail.gmail.com> <20200103181921.3858c90a@gandalf.local.home>
Hello Steve,
Happy new year!
On Sat, Jan 4, 2020 at 8:19 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> BTW, while doing some minor fixes, I realized I still have generic
> names for "warning", "pr_stat" and "vpr_stat" and thought they should
> be changed to "tep_warning", "tep_pr_stat" and "tep_vpr_stat" for
> namespace reasons even though they are weak functions. Would this
> require a major version change, or perhaps its early enough to get this
> in with a minor version change as the libraries are probably not being
> used yet?
Hmm.. I don't think it requires a major version change as they are not
public APIs actually. They are internal functions but can be overridden
by external ones, right?
I guess it's because there was a concern with printing messages in
a library. What about adding a mechanism to register callbacks
(and maybe defaults to discard all messages)?
Thanks
Namhyung
[Index of Archives]
[Linux USB Development]
[Linux USB Development]
[Linux Audio Users]
[Yosemite Hiking]
[Linux Kernel]
[Linux SCSI]