bumping library major on release branch?
Emmanuel Dreyfus
I would like to backport extended attribute support in libpuffs from
-current to netbsd-5. Unfortunately a structure grew, which means that
it would require bumping library major on the release branch.
Is that something reasonable?
The goal is to support glusterfs volume elasticity on netbsd-5. It
requires handling extended attribute on a FUSE mount.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
ma...@netbsd.org
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Manuel Bouyer
> Hi
>
> I would like to backport extended attribute support in libpuffs from
> -current to netbsd-5. Unfortunately a structure grew, which means that
> it would require bumping library major on the release branch.
>
> Is that something reasonable?
It's really something we want to avoid as much as possible.
library major change in X11 has delayed the 5.1 release for example.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
Emmanuel Dreyfus
> > I would like to backport extended attribute support in libpuffs from
> > -current to netbsd-5. Unfortunately a structure grew, which means that
> > it would require bumping library major on the release branch.
>
> It's really something we want to avoid as much as possible.
> library major change in X11 has delayed the 5.1 release for example.
Another approach is to introduce an alternate structure and associated
calls in -current, and pullup that to netbsd-5
The offending structure is struct puffs_ops, it is used in
PUFFSOP_INIT()
_puffs_init()
puffs_null_setops()
I can add struct puffs_ops52, and associated calls:
PUFFSOP_INIT52()
_puffs_init52()
puffs_null_setops52()
I understand it is not very appealing. If anyone has a better idea...
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
ma...@netbsd.org
--
Manuel Bouyer
[...]
> >I understand it is not very appealing. If anyone has a better idea...
>
> you are at it, why not make it opaque?
If libpuffs is linked directly in packages, we really don't want to change
its major number on the branch.
Christos Zoulas
Manuel Bouyer <bou...@antioche.eu.org> wrote:
>On Wed, Jun 22, 2011 at 02:28:32AM +0000, Christos Zoulas wrote:
>[...]
>> >I understand it is not very appealing. If anyone has a better idea...
>>
>> I think that libpuffs use is limited so it is acceptable to bump it. While
>> you are at it, why not make it opaque?
>
>If libpuffs is linked directly in packages, we really don't want to change
>its major number on the branch.
But is it? Can't we grep for it?
christos
David Holland
> > > I would like to backport extended attribute support in libpuffs from
> > > -current to netbsd-5. Unfortunately a structure grew, which means that
> > > it would require bumping library major on the release branch.
> >
> > library major change in X11 has delayed the 5.1 release for example.
>
> calls in -current, and pullup that to netbsd-5
Since -current has a different major number from -5 (because of this
and other changes) introducing these into current would serve no real
purpose and potentially make a mess.
Introducing them just into -5 seems fine though, assuming you intend
the usual __RENAME method.
(Also remember that since PUFFSOP_INIT is a macro you don't have to
change or version it.)
I'd suggest doing the patch to enable puffs_ops_spare[] separately
from the feature patch.
--
David A. Holland
dhol...@netbsd.org
Emmanuel Dreyfus
> Since -current has a different major number from -5 (because of this
> and other changes) introducing these into current would serve no real
> purpose and potentially make a mess.
>
> Introducing them just into -5 seems fine though, assuming you intend
> the usual __RENAME method.
Attached is a first attempt at it. I am not sure of how to use __RENAME()
here. Any comment?
--
Emmanuel Dreyfus
ma...@netbsd.org
Christos Zoulas
David Holland <dholla...@netbsd.org> wrote:
>On Wed, Jun 22, 2011 at 03:44:44AM +0200, Emmanuel Dreyfus wrote:
> > > > I would like to backport extended attribute support in libpuffs from
> > > > -current to netbsd-5. Unfortunately a structure grew, which means that
> > > > it would require bumping library major on the release branch.
> > >
> > > It's really something we want to avoid as much as possible.
> > > library major change in X11 has delayed the 5.1 release for example.
> >
> > Another approach is to introduce an alternate structure and associated
> > calls in -current, and pullup that to netbsd-5
> > [...]
>
>Since -current has a different major number from -5 (because of this
>and other changes) introducing these into current would serve no real
>purpose and potentially make a mess.
>
>Introducing them just into -5 seems fine though, assuming you intend
>the usual __RENAME method.
>
>(Also remember that since PUFFSOP_INIT is a macro you don't have to
>change or version it.)
>
>I'd suggest doing the patch to enable puffs_ops_spare[] separately
>from the feature patch.
That's the best idea.
christos
Christos Zoulas
Emmanuel Dreyfus <ma...@netbsd.org> wrote:
>Manuel Bouyer <bou...@antioche.eu.org> wrote:
>
>> > I would like to backport extended attribute support in libpuffs from
>> > -current to netbsd-5. Unfortunately a structure grew, which means that
>> > it would require bumping library major on the release branch.
>>
>> library major change in X11 has delayed the 5.1 release for example.
>
>calls in -current, and pullup that to netbsd-5
>
>The offending structure is struct puffs_ops, it is used in
>PUFFSOP_INIT()
>_puffs_init()
>puffs_null_setops()
>
>I can add struct puffs_ops52, and associated calls:
>PUFFSOP_INIT52()
>_puffs_init52()
>puffs_null_setops52()
>
>I understand it is not very appealing. If anyone has a better idea...
I think that libpuffs use is limited so it is acceptable to bump it. While
you are at it, why not make it opaque?
christos
David Holland
> >If libpuffs is linked directly in packages, we really don't want to change
> >its major number on the branch.
>
It's probably used in those fuse packages...
--
David A. Holland
dhol...@netbsd.org
--
Emmanuel Dreyfus
> Attached is a first attempt at it. I am not sure of how to use __RENAME()
> here. Any comment?
Hello
Nobody comented on this patch. Is it acceptable for a netbsd-5 pullup?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
ma...@netbsd.org
--
Emmanuel Dreyfus
> Nobody comented on this patch. Is it acceptable for a netbsd-5 pullup?
Here is it again, for a more convenient reference
http://ftp.espci.fr/shadow/manu/puffs_ea_lib.patch
--
Emmanuel Dreyfus
Manuel Bouyer
> On Mon, Jul 04, 2011 at 12:58:47PM +0200, Emmanuel Dreyfus wrote:
> > Nobody comented on this patch. Is it acceptable for a netbsd-5 pullup?
>
> Here is it again, for a more convenient reference
> http://ftp.espci.fr/shadow/manu/puffs_ea_lib.patch
why _puffs_init52 and puffs_ops51 ?
shouldn't PUFFS_DEVEL_LIBVERSION also be changed ?
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
--
Emmanuel Dreyfus
> why _puffs_init52 and puffs_ops51 ?
_puffs_init52 because binaries from 5.1 are linked to used _puffs_init,
so the old _puffs_init should keep its old name, and I have to change
the newer one.
puffs_ops51 because when building a binary on 5.2, we will use puffs_ops
and we do not want to use the 5.1 structure. Therefore I have to change
the older structure name.
It also looks odd to me, I suspect I am missing something.
> shouldn't PUFFS_DEVEL_LIBVERSION also be changed ?
Not sure: when are we supposed to do that?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
ma...@netbsd.org
--
Emmanuel Dreyfus
> OK, it's because one refers to the new function, and the other to the old
> structure.
It there a prefered way to do it?
> > > shouldn't PUFFS_DEVEL_LIBVERSION also be changed ?
> > Not sure: when are we supposed to do that?
> Dunno, but the author can probably tell :)
Um, PUFFS_DEVEL_LIBVERSION was dropped in -current. That suggests it is
not that important :-)
Manuel Bouyer
> Manuel Bouyer <bou...@antioche.eu.org> wrote:
>
> > OK, it's because one refers to the new function, and the other to the old
> > structure.
>
> It there a prefered way to do it?
I depends on how it's used in the API I guess.
>
> > > > shouldn't PUFFS_DEVEL_LIBVERSION also be changed ?
> > > Not sure: when are we supposed to do that?
> > Dunno, but the author can probably tell :)
>
> Um, PUFFS_DEVEL_LIBVERSION was dropped in -current. That suggests it is
> not that important :-)
OK, no need to touch it then.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
--
Emmanuel Dreyfus
> OK, no need to touch it then.
I submitted a pullup with a combined patch with all extended attribute
stuff. It is huge, but the different changes sets depend on each other.
And at least the combined patch matches the code I have been testing.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
ma...@netbsd.org
--
Manuel Bouyer
> Manuel Bouyer <bou...@antioche.eu.org> wrote:
>
>
> so the old _puffs_init should keep its old name, and I have to change
> the newer one.
>
> puffs_ops51 because when building a binary on 5.2, we will use puffs_ops
> and we do not want to use the 5.1 structure. Therefore I have to change
> the older structure name.
OK, it's because one refers to the new function, and the other to the old
structure.
>
> It also looks odd to me, I suspect I am missing something.
>
> > shouldn't PUFFS_DEVEL_LIBVERSION also be changed ?
>
> Not sure: when are we supposed to do that?
Dunno, but the author can probably tell :)
--