[RFC] Packaging libtraceevent.so

[RFC] Packaging libtraceevent.so

[Steven Rostedt]

Hi all!

The question has recently come up in Fedora about packaging the
libtraceevent.so library. Currently there's 4 users of it:

 1) perf
 2) trace-cmd
 3) powertop
 4) rasdaemon

But each have their own copy of the code.

Both perf and trace-cmd are the major developers of the package, and I
would recommend that they continue using the *.a version, but for those
tools that are simple users of the library, it would probably make
sense to have them use libtraceevent.so and remove their copies from
the code (powertop and rasdaemon).

The question that I'm posing here is, what currently needs to be done
to have this happen?

Is the API stable enough for a release?

We probably should have a dot versioning with the .so (ie.
libtraceevent.so.1)

So what are people's thoughts on this topic?

-- Steve

Re: [RFC] Packaging libtraceevent.so

[Arjan van de Ven]

On 12/2/2013 11:03 AM, Steven Rostedt wrote:
> Hi all!
>
> The question has recently come up in Fedora about packaging the
> libtraceevent.so library. Currently there's 4 users of it:
>
>   1) perf
>   2) trace-cmd
>   3) powertop
>   4) rasdaemon
>
> But each have their own copy of the code.
>
> Both perf and trace-cmd are the major developers of the package, and I
> would recommend that they continue using the *.a version, but for those
> tools that are simple users of the library, it would probably make
> sense to have them use libtraceevent.so and remove their copies from
> the code (powertop and rasdaemon).
>
> The question that I'm posing here is, what currently needs to be done
> to have this happen?
>
> Is the API stable enough for a release?
>
> We probably should have a dot versioning with the .so (ie.
> libtraceevent.so.1)
>
> So what are people's thoughts on this topic?
>

powertop would much rather use a system copy than our own...
but if it's not there in common distros we need to carry our own obviously

Re: [RFC] Packaging libtraceevent.so

[Namhyung Kim]

Hi Steve,

(also add Jiri to CC list, hi!)

On Mon, 2 Dec 2013 14:03:22 -0500, Steven Rostedt wrote:
> Hi all!
>
> The question has recently come up in Fedora about packaging the
> libtraceevent.so library. Currently there's 4 users of it:
>
>  1) perf
>  2) trace-cmd
>  3) powertop
>  4) rasdaemon
>
> But each have their own copy of the code.
>
> Both perf and trace-cmd are the major developers of the package, and I
> would recommend that they continue using the *.a version, but for those
> tools that are simple users of the library, it would probably make
> sense to have them use libtraceevent.so and remove their copies from
> the code (powertop and rasdaemon).
>
> The question that I'm posing here is, what currently needs to be done
> to have this happen?

I think the most important thing is error handling.  The filter parser
code still has some calls to die().  It should be converted to return
error and appropriate error messages IMHO.  But I didn't check it'd
affect to the end-user APIs though.

And it needs to add plugin APIs before the public release.

>
> Is the API stable enough for a release?

Well, afaics the plugin unregister API should pass pevent as an argument
so that it can unregister individual event/function handlers in it.

Other than that I think it's pretty stable. :)

Thanks,
Namhyung

>
> We probably should have a dot versioning with the .so (ie.
> libtraceevent.so.1)
>
> So what are people's thoughts on this topic?
>
> -- Steve

Re: [RFC] Packaging libtraceevent.so

[Josh Boyer]

On Tue, Dec 3, 2013 at 1:02 AM, Namhyung Kim <namhyung@kernel.org> wrote:
> Hi Steve,
>
> (also add Jiri to CC list, hi!)
>
> On Mon, 2 Dec 2013 14:03:22 -0500, Steven Rostedt wrote:
>> Hi all!
>>
>> The question has recently come up in Fedora about packaging the
>> libtraceevent.so library. Currently there's 4 users of it:
>>
>>  1) perf
>>  2) trace-cmd
>>  3) powertop
>>  4) rasdaemon
>>
>> But each have their own copy of the code.
>>
>> Both perf and trace-cmd are the major developers of the package, and I
>> would recommend that they continue using the *.a version, but for those
>> tools that are simple users of the library, it would probably make
>> sense to have them use libtraceevent.so and remove their copies from
>> the code (powertop and rasdaemon).
>>
>> The question that I'm posing here is, what currently needs to be done
>> to have this happen?
>
> I think the most important thing is error handling.  The filter parser
> code still has some calls to die().  It should be converted to return
> error and appropriate error messages IMHO.  But I didn't check it'd
> affect to the end-user APIs though.
>
> And it needs to add plugin APIs before the public release.
>
>>
>> Is the API stable enough for a release?
>
> Well, afaics the plugin unregister API should pass pevent as an argument
> so that it can unregister individual event/function handlers in it.
>
> Other than that I think it's pretty stable. :)

So the level of stable I think would be needed is basically being able
to ship a new libtraceevent.so and have it not break a powertop that
was linked against a previous version.  E.g. libtraceevent.so provided
with the 3.15 kernel release can be used as an update to the
libtraceevent.so from the 3.13 release and powertop doesn't need to be
rebuilt.

That's typically done with soname and/or symbol versioning.  Clearly
applications wishing to use new libtraceevent features would need to
be rebuilt to take advantage of those, but basic functionality should
be pretty stable.  Changing soname/ABI happens elsewhere in userspace
libs and isn't a big deal for development, but those bumps typically
aren't done in the middle of a released distro version.  There are
several distros that do major kernel version updates during the
lifetime of a release so anything coming from those needs to be
handled carefully.

josh

Re: [RFC] Packaging libtraceevent.so

[Steven Rostedt]

On Tue, 3 Dec 2013 08:56:33 -0500
Josh Boyer <jwboyer@fedoraproject.org> wrote:


> So the level of stable I think would be needed is basically being able
> to ship a new libtraceevent.so and have it not break a powertop that
> was linked against a previous version.  E.g. libtraceevent.so provided
> with the 3.15 kernel release can be used as an update to the
> libtraceevent.so from the 3.13 release and powertop doesn't need to be
> rebuilt.
> 
> That's typically done with soname and/or symbol versioning.  Clearly
> applications wishing to use new libtraceevent features would need to
> be rebuilt to take advantage of those, but basic functionality should
> be pretty stable.  Changing soname/ABI happens elsewhere in userspace
> libs and isn't a big deal for development, but those bumps typically
> aren't done in the middle of a released distro version.  There are
> several distros that do major kernel version updates during the
> lifetime of a release so anything coming from those needs to be
> handled carefully.

There's a couple of things that need to be cleaned up first, that will
affect current users. But they are minor. I think we can work on this
soon and get something out by the next release.

-- Steve

Re: [RFC] Packaging libtraceevent.so

[Steven Rostedt]

On Tue, 03 Dec 2013 15:02:18 +0900
Namhyung Kim <namhyung@kernel.org> wrote:

> Hi Steve,
> 
> (also add Jiri to CC list, hi!)

Ug, I thought I added him, but looking at my email, I must have thought
I did but did not. :-/

> 
> On Mon, 2 Dec 2013 14:03:22 -0500, Steven Rostedt wrote:
> > Hi all!
> >
> > The question has recently come up in Fedora about packaging the
> > libtraceevent.so library. Currently there's 4 users of it:
> >
> >  1) perf
> >  2) trace-cmd
> >  3) powertop
> >  4) rasdaemon
> >
> > But each have their own copy of the code.
> >
> > Both perf and trace-cmd are the major developers of the package, and I
> > would recommend that they continue using the *.a version, but for those
> > tools that are simple users of the library, it would probably make
> > sense to have them use libtraceevent.so and remove their copies from
> > the code (powertop and rasdaemon).
> >
> > The question that I'm posing here is, what currently needs to be done
> > to have this happen?
> 
> I think the most important thing is error handling.  The filter parser
> code still has some calls to die().  It should be converted to return
> error and appropriate error messages IMHO.  But I didn't check it'd
> affect to the end-user APIs though.

Yep that should be cleaned up as well.

> 
> And it needs to add plugin APIs before the public release.

I agree with that too.

> 
> >
> > Is the API stable enough for a release?
> 
> Well, afaics the plugin unregister API should pass pevent as an argument
> so that it can unregister individual event/function handlers in it.
> 
> Other than that I think it's pretty stable. :)

OK, lets work on getting these minor things fixed and get it ready for
a public library.

-- Steve