[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200106155232.4061d755@gandalf.local.home>
Date: Mon, 6 Jan 2020 15:52:32 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>,
Jiri Olsa <jolsa@...hat.com>,
Sudip Mukherjee <sudipm.mukherjee@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Linux Trace Devel <linux-trace-devel@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
users@...ux.kernel.org
Subject: Re: [kernel.org users] [RFC] tools lib traceevent: How to do
library versioning being in the Linux kernel source?
On Mon, 6 Jan 2020 16:47:15 -0400
Jason Gunthorpe <jgg@...pe.ca> wrote:
> If it is not tightly linked to the kernel and is just a normal
Well, it's used by perf, trace-cmd, power-top and rasdaemon (and
perhaps even more). It lives in the kernel tree mainly because of perf.
> library, you might consider using github. This is what we do for the
> rdma user space and it works well. We still take patches from the
> mailing list flow, but do use a fair amount of the github stuff too:
>
> https://github.com/linux-rdma/rdma-core
>
> With github actions now able to provide a quite good CI it covers a
> lot of required stuff for a library in one place, in a way that
> doesn't silo all the build infrastucture.
Github has ways to help with libraries? I'm totally clueless about
this. I'm interested in hearing more.
Thanks,
-- Steve
>
> If you are interested in how we set it up I can write a longer email.
Powered by blists - more mailing lists