qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 0/4] libcacard-standalone (glib compat & libcacar


From: Michael Tokarev
Subject: Re: [Qemu-devel] [PULL 0/4] libcacard-standalone (glib compat & libcacard) series for 2014-05-08
Date: Sun, 11 May 2014 15:06:04 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

09.05.2014 18:53, Peter Maydell пишет:
> On 8 May 2014 09:30, Michael Tokarev <address@hidden> wrote:
>> Here's a pull request for glib pre-2.31 compatibility layer and libcacard
>> cleanups on top of it.  It has been submitted for review previously:
>>
>> v1: http://thread.gmane.org/gmane.comp.emulators.qemu/269432
>> v2: http://thread.gmane.org/gmane.comp.emulators.qemu/270259
>>
>> Previous attempt of adding glib compat layer by Stefan Hajnoczi:
>>     http://thread.gmane.org/gmane.comp.emulators.qemu/253830
>>
>> Changes since v2 submission:
>>
>>  - dropped 3 trivial changes which were applied meantime
>>  - fixed coding style (identation/spacing) in first patch
>>    alevy: I hope these tiny spacing changes are okay for
>>    you to keep your reviewed-by ;)
>>
>> Please consider applying.  Since this touches several areas of
>> qemu, there's no clear maintainer so I'm not really sure which
>> maintainer tree should pick this up.  And it isn't very suitable
>> for -trival either :)
> 
> I'm still a bit dubious about the approach this patchset
> takes to glib back-compatibility (ie using #defines etc
> to fake up the new glib API on older glib versions, rather
> than defining wrappers), and it sounded from the conversation
> on IRC today as if Stefan was also not completely convinced.
> So I don't think there's enough consensus to apply this
> yet, and I'd rather we had more discussion/review first.

This whole thing is almost moot really.  It is an old glib
API, and no one cares about it anymore except redhat, because
it is the only distribution nowadays which is relevant and
ships that old glib.  We're discussing adding compat layer
in qemu for thing which is almost irrelevant for everyone else
who moved on to the new API and don't care about old crap.
I tried to make old redhat glib API to be almost compatible
with current glib, _just_ to not introduce additional
version requiriment.  For an API which is frozen and wont
change anymore, and which is almost unused in whole qemu
too.  The layer which I provided actually works and is
actually tested on several different platforms.

For me, I don't care a damn about this old crap.  New glib
API works on all relevant versions of Debian for example,
so I can just clean up crap in libcacard using new API
directly - ofcourse it wont be upstreamable due to that
old glib api which is still relevant, but at least we'll
have a proper libcacard in Debian.

I just wanted to do the dirty work for everyone's benefit
without adding new complexity.  If that's not needed, no
worries from me.  The 2 remaining libcacard patches are
small and trivial enough to keep in debian tree.

Thanks,

/mjt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]