You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Covener <co...@gmail.com> on 2014/01/24 22:02:43 UTC
Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c
> -#if APR_VERSION_AT_LEAST(1,5,1)
> +#ifdef APR_EOPNOTSUPP
> && rv != APR_EOPNOTSUPP
> #endif
> ) {
>
As Jeff said in the other thread, this doesn't work if there's a lower
APR fix level at runtime, which is against the APR contract.
--
Eric Covener
covener@gmail.com
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Yann Ylavic <yl...@gmail.com>.
Those who use ftok(, 1) externally like httpd will face the bug soon or
later too (unless they use the same filenames each time).
I think some (at least) will like this to be fixed, so the current code is
fine for me.
On Sat, Jan 25, 2014 at 12:50 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> I think it could be debated on whether or not ftok(...,1) is
> part of the ABI or not. The more I think about it,
> it's not. But the fact that both slotmem and mod_fcgid, which
> are *our* projects, "use" that knowledge, makes me wonder
> who else makes that assumption.
>
> What do others think...? It would be easy to make our
> generation of a shmkey more robust by "breaking" that
> agreement, and to handle slotmem we add apr_shm_perms()
> to APR 1.5.1 and have httpd 2.4.8 require 1.5.1 or later...
>
> Or we just consider it all a limitation of SysV based
> shm and just keep things as is.
>
> On Jan 24, 2014, at 6:40 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> > Why couldn't APR document on using ftok(filename,
> filename[strlen(filename)-1]) for released versions, and do the right thing
> in trunk?
> > Is ftok(filename, 1) part of the ABI since the change would break
> existing consumers?
> > I can't see any solution if that's the case.
> >
> >
> > On Sat, Jan 25, 2014 at 12:20 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> > It's easy to generate something unique... the problem is that
> > external APR users (such as mod_fcgid, etc) occasionally need
> > to adjust the segment resources, and thus call ftok(...). Unless
> > both APR *and* the users use the same proj_id, then they won't
> > get the right segment (if at all).
> >
> > I just couldn't think of an easy way to get around that
> > except for having 1.5.1 break ABI.
> >
> > What we need is apr_shm_ftok() that replaces ftok, both
> > internally to unix/shmem.c as well as to users. We still
> > would need to worry about versioning there as well since
> > APR consumers would need to be aware if that function
> > exists or not.
> >
> > On Jan 24, 2014, at 6:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
> >
> > > According to the man (
> http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html),
> ftok() uses only the low-order 8-bits of the id.
> > > Maybe the APR could use the last char of the filename instead, so that
> the users knows and can choose it.
> > > For APR's internal/choosen filenames (if any), this byte could be
> generated randomly.
> > >
> > >
> > > On Fri, Jan 24, 2014 at 10:57 PM, Jim Jagielski <ji...@jagunet.com>
> wrote:
> > > On httpd there was a discussion regarding versioning, and
> > > this got me thinking...
> > >
> > > Included in the APR 1.5.1 changes is an internal change
> > > to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
> > > calculates the key (via ftok())...
> > >
> > > The problem (see the Bugz report) was that using the constant
> > > 1 would cause collisions, so I adjusted it to use a hash
> > > of the filename. The problem there is that any external
> > > APR users that needed to also determine the key needs to
> > > be aware of that. And from what I can see, there is no
> > > easy way to do that.
> > >
> > > So I will be pulling that from 2.0-dev and 1.5-dev until
> > > we can figure out a better way. Ideas appreciated.
> > >
> >
> >
>
>
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Yann Ylavic <yl...@gmail.com>.
Those who use ftok(, 1) externally like httpd will face the bug soon or
later too (unless they use the same filenames each time).
I think some (at least) will like this to be fixed, so the current code is
fine for me.
On Sat, Jan 25, 2014 at 12:50 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> I think it could be debated on whether or not ftok(...,1) is
> part of the ABI or not. The more I think about it,
> it's not. But the fact that both slotmem and mod_fcgid, which
> are *our* projects, "use" that knowledge, makes me wonder
> who else makes that assumption.
>
> What do others think...? It would be easy to make our
> generation of a shmkey more robust by "breaking" that
> agreement, and to handle slotmem we add apr_shm_perms()
> to APR 1.5.1 and have httpd 2.4.8 require 1.5.1 or later...
>
> Or we just consider it all a limitation of SysV based
> shm and just keep things as is.
>
> On Jan 24, 2014, at 6:40 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> > Why couldn't APR document on using ftok(filename,
> filename[strlen(filename)-1]) for released versions, and do the right thing
> in trunk?
> > Is ftok(filename, 1) part of the ABI since the change would break
> existing consumers?
> > I can't see any solution if that's the case.
> >
> >
> > On Sat, Jan 25, 2014 at 12:20 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> > It's easy to generate something unique... the problem is that
> > external APR users (such as mod_fcgid, etc) occasionally need
> > to adjust the segment resources, and thus call ftok(...). Unless
> > both APR *and* the users use the same proj_id, then they won't
> > get the right segment (if at all).
> >
> > I just couldn't think of an easy way to get around that
> > except for having 1.5.1 break ABI.
> >
> > What we need is apr_shm_ftok() that replaces ftok, both
> > internally to unix/shmem.c as well as to users. We still
> > would need to worry about versioning there as well since
> > APR consumers would need to be aware if that function
> > exists or not.
> >
> > On Jan 24, 2014, at 6:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
> >
> > > According to the man (
> http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html),
> ftok() uses only the low-order 8-bits of the id.
> > > Maybe the APR could use the last char of the filename instead, so that
> the users knows and can choose it.
> > > For APR's internal/choosen filenames (if any), this byte could be
> generated randomly.
> > >
> > >
> > > On Fri, Jan 24, 2014 at 10:57 PM, Jim Jagielski <ji...@jagunet.com>
> wrote:
> > > On httpd there was a discussion regarding versioning, and
> > > this got me thinking...
> > >
> > > Included in the APR 1.5.1 changes is an internal change
> > > to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
> > > calculates the key (via ftok())...
> > >
> > > The problem (see the Bugz report) was that using the constant
> > > 1 would cause collisions, so I adjusted it to use a hash
> > > of the filename. The problem there is that any external
> > > APR users that needed to also determine the key needs to
> > > be aware of that. And from what I can see, there is no
> > > easy way to do that.
> > >
> > > So I will be pulling that from 2.0-dev and 1.5-dev until
> > > we can figure out a better way. Ideas appreciated.
> > >
> >
> >
>
>
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Jim Jagielski <ji...@jaguNET.com>.
I think it could be debated on whether or not ftok(...,1) is
part of the ABI or not. The more I think about it,
it's not. But the fact that both slotmem and mod_fcgid, which
are *our* projects, "use" that knowledge, makes me wonder
who else makes that assumption.
What do others think...? It would be easy to make our
generation of a shmkey more robust by "breaking" that
agreement, and to handle slotmem we add apr_shm_perms()
to APR 1.5.1 and have httpd 2.4.8 require 1.5.1 or later...
Or we just consider it all a limitation of SysV based
shm and just keep things as is.
On Jan 24, 2014, at 6:40 PM, Yann Ylavic <yl...@gmail.com> wrote:
> Why couldn't APR document on using ftok(filename, filename[strlen(filename)-1]) for released versions, and do the right thing in trunk?
> Is ftok(filename, 1) part of the ABI since the change would break existing consumers?
> I can't see any solution if that's the case.
>
>
> On Sat, Jan 25, 2014 at 12:20 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> It's easy to generate something unique... the problem is that
> external APR users (such as mod_fcgid, etc) occasionally need
> to adjust the segment resources, and thus call ftok(...). Unless
> both APR *and* the users use the same proj_id, then they won't
> get the right segment (if at all).
>
> I just couldn't think of an easy way to get around that
> except for having 1.5.1 break ABI.
>
> What we need is apr_shm_ftok() that replaces ftok, both
> internally to unix/shmem.c as well as to users. We still
> would need to worry about versioning there as well since
> APR consumers would need to be aware if that function
> exists or not.
>
> On Jan 24, 2014, at 6:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> > According to the man (http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html), ftok() uses only the low-order 8-bits of the id.
> > Maybe the APR could use the last char of the filename instead, so that the users knows and can choose it.
> > For APR's internal/choosen filenames (if any), this byte could be generated randomly.
> >
> >
> > On Fri, Jan 24, 2014 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> > On httpd there was a discussion regarding versioning, and
> > this got me thinking...
> >
> > Included in the APR 1.5.1 changes is an internal change
> > to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
> > calculates the key (via ftok())...
> >
> > The problem (see the Bugz report) was that using the constant
> > 1 would cause collisions, so I adjusted it to use a hash
> > of the filename. The problem there is that any external
> > APR users that needed to also determine the key needs to
> > be aware of that. And from what I can see, there is no
> > easy way to do that.
> >
> > So I will be pulling that from 2.0-dev and 1.5-dev until
> > we can figure out a better way. Ideas appreciated.
> >
>
>
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Jan 25, 2014 at 12:40 AM, Yann Ylavic <yl...@gmail.com> wrote:
> Why couldn't APR document on using ftok(filename,
> filename[strlen(filename)-1]) for released versions, and do the right thing
> in trunk?
>
ftok(filename, hash(filename)) is much better of course, I misread
"external" as being something not using APR.
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Jan 25, 2014 at 12:40 AM, Yann Ylavic <yl...@gmail.com> wrote:
> Why couldn't APR document on using ftok(filename,
> filename[strlen(filename)-1]) for released versions, and do the right thing
> in trunk?
>
ftok(filename, hash(filename)) is much better of course, I misread
"external" as being something not using APR.
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Jim Jagielski <ji...@jaguNET.com>.
I think it could be debated on whether or not ftok(...,1) is
part of the ABI or not. The more I think about it,
it's not. But the fact that both slotmem and mod_fcgid, which
are *our* projects, "use" that knowledge, makes me wonder
who else makes that assumption.
What do others think...? It would be easy to make our
generation of a shmkey more robust by "breaking" that
agreement, and to handle slotmem we add apr_shm_perms()
to APR 1.5.1 and have httpd 2.4.8 require 1.5.1 or later...
Or we just consider it all a limitation of SysV based
shm and just keep things as is.
On Jan 24, 2014, at 6:40 PM, Yann Ylavic <yl...@gmail.com> wrote:
> Why couldn't APR document on using ftok(filename, filename[strlen(filename)-1]) for released versions, and do the right thing in trunk?
> Is ftok(filename, 1) part of the ABI since the change would break existing consumers?
> I can't see any solution if that's the case.
>
>
> On Sat, Jan 25, 2014 at 12:20 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> It's easy to generate something unique... the problem is that
> external APR users (such as mod_fcgid, etc) occasionally need
> to adjust the segment resources, and thus call ftok(...). Unless
> both APR *and* the users use the same proj_id, then they won't
> get the right segment (if at all).
>
> I just couldn't think of an easy way to get around that
> except for having 1.5.1 break ABI.
>
> What we need is apr_shm_ftok() that replaces ftok, both
> internally to unix/shmem.c as well as to users. We still
> would need to worry about versioning there as well since
> APR consumers would need to be aware if that function
> exists or not.
>
> On Jan 24, 2014, at 6:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> > According to the man (http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html), ftok() uses only the low-order 8-bits of the id.
> > Maybe the APR could use the last char of the filename instead, so that the users knows and can choose it.
> > For APR's internal/choosen filenames (if any), this byte could be generated randomly.
> >
> >
> > On Fri, Jan 24, 2014 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> > On httpd there was a discussion regarding versioning, and
> > this got me thinking...
> >
> > Included in the APR 1.5.1 changes is an internal change
> > to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
> > calculates the key (via ftok())...
> >
> > The problem (see the Bugz report) was that using the constant
> > 1 would cause collisions, so I adjusted it to use a hash
> > of the filename. The problem there is that any external
> > APR users that needed to also determine the key needs to
> > be aware of that. And from what I can see, there is no
> > easy way to do that.
> >
> > So I will be pulling that from 2.0-dev and 1.5-dev until
> > we can figure out a better way. Ideas appreciated.
> >
>
>
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Yann Ylavic <yl...@gmail.com>.
Why couldn't APR document on using ftok(filename,
filename[strlen(filename)-1]) for released versions, and do the right thing
in trunk?
Is ftok(filename, 1) part of the ABI since the change would break existing
consumers?
I can't see any solution if that's the case.
On Sat, Jan 25, 2014 at 12:20 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> It's easy to generate something unique... the problem is that
> external APR users (such as mod_fcgid, etc) occasionally need
> to adjust the segment resources, and thus call ftok(...). Unless
> both APR *and* the users use the same proj_id, then they won't
> get the right segment (if at all).
>
> I just couldn't think of an easy way to get around that
> except for having 1.5.1 break ABI.
>
> What we need is apr_shm_ftok() that replaces ftok, both
> internally to unix/shmem.c as well as to users. We still
> would need to worry about versioning there as well since
> APR consumers would need to be aware if that function
> exists or not.
>
> On Jan 24, 2014, at 6:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> > According to the man (
> http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html),
> ftok() uses only the low-order 8-bits of the id.
> > Maybe the APR could use the last char of the filename instead, so that
> the users knows and can choose it.
> > For APR's internal/choosen filenames (if any), this byte could be
> generated randomly.
> >
> >
> > On Fri, Jan 24, 2014 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> > On httpd there was a discussion regarding versioning, and
> > this got me thinking...
> >
> > Included in the APR 1.5.1 changes is an internal change
> > to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
> > calculates the key (via ftok())...
> >
> > The problem (see the Bugz report) was that using the constant
> > 1 would cause collisions, so I adjusted it to use a hash
> > of the filename. The problem there is that any external
> > APR users that needed to also determine the key needs to
> > be aware of that. And from what I can see, there is no
> > easy way to do that.
> >
> > So I will be pulling that from 2.0-dev and 1.5-dev until
> > we can figure out a better way. Ideas appreciated.
> >
>
>
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Yann Ylavic <yl...@gmail.com>.
Why couldn't APR document on using ftok(filename,
filename[strlen(filename)-1]) for released versions, and do the right thing
in trunk?
Is ftok(filename, 1) part of the ABI since the change would break existing
consumers?
I can't see any solution if that's the case.
On Sat, Jan 25, 2014 at 12:20 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> It's easy to generate something unique... the problem is that
> external APR users (such as mod_fcgid, etc) occasionally need
> to adjust the segment resources, and thus call ftok(...). Unless
> both APR *and* the users use the same proj_id, then they won't
> get the right segment (if at all).
>
> I just couldn't think of an easy way to get around that
> except for having 1.5.1 break ABI.
>
> What we need is apr_shm_ftok() that replaces ftok, both
> internally to unix/shmem.c as well as to users. We still
> would need to worry about versioning there as well since
> APR consumers would need to be aware if that function
> exists or not.
>
> On Jan 24, 2014, at 6:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> > According to the man (
> http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html),
> ftok() uses only the low-order 8-bits of the id.
> > Maybe the APR could use the last char of the filename instead, so that
> the users knows and can choose it.
> > For APR's internal/choosen filenames (if any), this byte could be
> generated randomly.
> >
> >
> > On Fri, Jan 24, 2014 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> > On httpd there was a discussion regarding versioning, and
> > this got me thinking...
> >
> > Included in the APR 1.5.1 changes is an internal change
> > to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
> > calculates the key (via ftok())...
> >
> > The problem (see the Bugz report) was that using the constant
> > 1 would cause collisions, so I adjusted it to use a hash
> > of the filename. The problem there is that any external
> > APR users that needed to also determine the key needs to
> > be aware of that. And from what I can see, there is no
> > easy way to do that.
> >
> > So I will be pulling that from 2.0-dev and 1.5-dev until
> > we can figure out a better way. Ideas appreciated.
> >
>
>
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Jim Jagielski <ji...@jaguNET.com>.
OK... how about this:
1. We fix the FIXME in unix/shm.c which sez that the
shm permission should be 0600. We instead set
it to 0644 ala the rest of the shared-mem permissions
instead of the super-permissive perms we use now
(for SysV shm). [1]
2. We re-add the robustness fix for ftok to both 1.5-dev
and 2.0.
Neither of these are, from what I can see, ABI
guarantees. We document these none-the-less so
people who *might* be affected have some info.
Comments?
1. #elif APR_USE_SHMEM_SHMGET
new_m->realsize = reqsize;
/* FIXME: APR_OS_DEFAULT is too permissive, switch to 600 I think. */
status = apr_file_open(&file, filename,
APR_FOPEN_WRITE | APR_FOPEN_CREATE | APR_FOPEN_EXCL,
APR_OS_DEFAULT, pool);
On Jan 24, 2014, at 6:51 PM, Branko Čibej <br...@apache.org> wrote:
> On 25.01.2014 00:41, Jim Jagielski wrote:
>> Of course, one could also say that anyone who uses internal
>> APR implementation knowledge is doing something wrong...
>>
>> And they would have a point.
>>
>> But it still begs the question what to do w/ slotmem
>> which must set shmem permissions. I would guess what
>> we should really do is provide apr_shmem_perms(). We
>> could then have httpd 2.4 require APR 1.5.1 or later
>> and let those who choose to use ftok know the risks.
>
> It would be APR 1.6, according to our API compat rules.
>
> -- Brane
>
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Branko Čibej <br...@apache.org>.
On 25.01.2014 00:41, Jim Jagielski wrote:
> Of course, one could also say that anyone who uses internal
> APR implementation knowledge is doing something wrong...
>
> And they would have a point.
>
> But it still begs the question what to do w/ slotmem
> which must set shmem permissions. I would guess what
> we should really do is provide apr_shmem_perms(). We
> could then have httpd 2.4 require APR 1.5.1 or later
> and let those who choose to use ftok know the risks.
It would be APR 1.6, according to our API compat rules.
-- Brane
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Jim Jagielski <ji...@jaguNET.com>.
Of course, one could also say that anyone who uses internal
APR implementation knowledge is doing something wrong...
And they would have a point.
But it still begs the question what to do w/ slotmem
which must set shmem permissions. I would guess what
we should really do is provide apr_shmem_perms(). We
could then have httpd 2.4 require APR 1.5.1 or later
and let those who choose to use ftok know the risks.
On Jan 24, 2014, at 6:20 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> It's easy to generate something unique... the problem is that
> external APR users (such as mod_fcgid, etc) occasionally need
> to adjust the segment resources, and thus call ftok(...). Unless
> both APR *and* the users use the same proj_id, then they won't
> get the right segment (if at all).
>
> I just couldn't think of an easy way to get around that
> except for having 1.5.1 break ABI.
>
> What we need is apr_shm_ftok() that replaces ftok, both
> internally to unix/shmem.c as well as to users. We still
> would need to worry about versioning there as well since
> APR consumers would need to be aware if that function
> exists or not.
>
> On Jan 24, 2014, at 6:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
>> According to the man (http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html), ftok() uses only the low-order 8-bits of the id.
>> Maybe the APR could use the last char of the filename instead, so that the users knows and can choose it.
>> For APR's internal/choosen filenames (if any), this byte could be generated randomly.
>>
>>
>> On Fri, Jan 24, 2014 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>> On httpd there was a discussion regarding versioning, and
>> this got me thinking...
>>
>> Included in the APR 1.5.1 changes is an internal change
>> to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
>> calculates the key (via ftok())...
>>
>> The problem (see the Bugz report) was that using the constant
>> 1 would cause collisions, so I adjusted it to use a hash
>> of the filename. The problem there is that any external
>> APR users that needed to also determine the key needs to
>> be aware of that. And from what I can see, there is no
>> easy way to do that.
>>
>> So I will be pulling that from 2.0-dev and 1.5-dev until
>> we can figure out a better way. Ideas appreciated.
>>
>
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Jim Jagielski <ji...@jaguNET.com>.
Of course, one could also say that anyone who uses internal
APR implementation knowledge is doing something wrong...
And they would have a point.
But it still begs the question what to do w/ slotmem
which must set shmem permissions. I would guess what
we should really do is provide apr_shmem_perms(). We
could then have httpd 2.4 require APR 1.5.1 or later
and let those who choose to use ftok know the risks.
On Jan 24, 2014, at 6:20 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> It's easy to generate something unique... the problem is that
> external APR users (such as mod_fcgid, etc) occasionally need
> to adjust the segment resources, and thus call ftok(...). Unless
> both APR *and* the users use the same proj_id, then they won't
> get the right segment (if at all).
>
> I just couldn't think of an easy way to get around that
> except for having 1.5.1 break ABI.
>
> What we need is apr_shm_ftok() that replaces ftok, both
> internally to unix/shmem.c as well as to users. We still
> would need to worry about versioning there as well since
> APR consumers would need to be aware if that function
> exists or not.
>
> On Jan 24, 2014, at 6:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
>> According to the man (http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html), ftok() uses only the low-order 8-bits of the id.
>> Maybe the APR could use the last char of the filename instead, so that the users knows and can choose it.
>> For APR's internal/choosen filenames (if any), this byte could be generated randomly.
>>
>>
>> On Fri, Jan 24, 2014 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>> On httpd there was a discussion regarding versioning, and
>> this got me thinking...
>>
>> Included in the APR 1.5.1 changes is an internal change
>> to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
>> calculates the key (via ftok())...
>>
>> The problem (see the Bugz report) was that using the constant
>> 1 would cause collisions, so I adjusted it to use a hash
>> of the filename. The problem there is that any external
>> APR users that needed to also determine the key needs to
>> be aware of that. And from what I can see, there is no
>> easy way to do that.
>>
>> So I will be pulling that from 2.0-dev and 1.5-dev until
>> we can figure out a better way. Ideas appreciated.
>>
>
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Jim Jagielski <ji...@jaguNET.com>.
It's easy to generate something unique... the problem is that
external APR users (such as mod_fcgid, etc) occasionally need
to adjust the segment resources, and thus call ftok(...). Unless
both APR *and* the users use the same proj_id, then they won't
get the right segment (if at all).
I just couldn't think of an easy way to get around that
except for having 1.5.1 break ABI.
What we need is apr_shm_ftok() that replaces ftok, both
internally to unix/shmem.c as well as to users. We still
would need to worry about versioning there as well since
APR consumers would need to be aware if that function
exists or not.
On Jan 24, 2014, at 6:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
> According to the man (http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html), ftok() uses only the low-order 8-bits of the id.
> Maybe the APR could use the last char of the filename instead, so that the users knows and can choose it.
> For APR's internal/choosen filenames (if any), this byte could be generated randomly.
>
>
> On Fri, Jan 24, 2014 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> On httpd there was a discussion regarding versioning, and
> this got me thinking...
>
> Included in the APR 1.5.1 changes is an internal change
> to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
> calculates the key (via ftok())...
>
> The problem (see the Bugz report) was that using the constant
> 1 would cause collisions, so I adjusted it to use a hash
> of the filename. The problem there is that any external
> APR users that needed to also determine the key needs to
> be aware of that. And from what I can see, there is no
> easy way to do that.
>
> So I will be pulling that from 2.0-dev and 1.5-dev until
> we can figure out a better way. Ideas appreciated.
>
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Jim Jagielski <ji...@jaguNET.com>.
It's easy to generate something unique... the problem is that
external APR users (such as mod_fcgid, etc) occasionally need
to adjust the segment resources, and thus call ftok(...). Unless
both APR *and* the users use the same proj_id, then they won't
get the right segment (if at all).
I just couldn't think of an easy way to get around that
except for having 1.5.1 break ABI.
What we need is apr_shm_ftok() that replaces ftok, both
internally to unix/shmem.c as well as to users. We still
would need to worry about versioning there as well since
APR consumers would need to be aware if that function
exists or not.
On Jan 24, 2014, at 6:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
> According to the man (http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html), ftok() uses only the low-order 8-bits of the id.
> Maybe the APR could use the last char of the filename instead, so that the users knows and can choose it.
> For APR's internal/choosen filenames (if any), this byte could be generated randomly.
>
>
> On Fri, Jan 24, 2014 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> On httpd there was a discussion regarding versioning, and
> this got me thinking...
>
> Included in the APR 1.5.1 changes is an internal change
> to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
> calculates the key (via ftok())...
>
> The problem (see the Bugz report) was that using the constant
> 1 would cause collisions, so I adjusted it to use a hash
> of the filename. The problem there is that any external
> APR users that needed to also determine the key needs to
> be aware of that. And from what I can see, there is no
> easy way to do that.
>
> So I will be pulling that from 2.0-dev and 1.5-dev until
> we can figure out a better way. Ideas appreciated.
>
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Yann Ylavic <yl...@gmail.com>.
According to the man (
http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html), ftok()
uses only the low-order 8-bits of the id.
Maybe the APR could use the last char of the filename instead, so that the
users knows and can choose it.
For APR's internal/choosen filenames (if any), this byte could be generated
randomly.
On Fri, Jan 24, 2014 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> On httpd there was a discussion regarding versioning, and
> this got me thinking...
>
> Included in the APR 1.5.1 changes is an internal change
> to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
> calculates the key (via ftok())...
>
> The problem (see the Bugz report) was that using the constant
> 1 would cause collisions, so I adjusted it to use a hash
> of the filename. The problem there is that any external
> APR users that needed to also determine the key needs to
> be aware of that. And from what I can see, there is no
> easy way to do that.
>
> So I will be pulling that from 2.0-dev and 1.5-dev until
> we can figure out a better way. Ideas appreciated.
>
Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Yann Ylavic <yl...@gmail.com>.
According to the man (
http://pubs.opengroup.org/onlinepubs/009696899/functions/ftok.html), ftok()
uses only the low-order 8-bits of the id.
Maybe the APR could use the last char of the filename instead, so that the
users knows and can choose it.
For APR's internal/choosen filenames (if any), this byte could be generated
randomly.
On Fri, Jan 24, 2014 at 10:57 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> On httpd there was a discussion regarding versioning, and
> this got me thinking...
>
> Included in the APR 1.5.1 changes is an internal change
> to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
> calculates the key (via ftok())...
>
> The problem (see the Bugz report) was that using the constant
> 1 would cause collisions, so I adjusted it to use a hash
> of the filename. The problem there is that any external
> APR users that needed to also determine the key needs to
> be aware of that. And from what I can see, there is no
> easy way to do that.
>
> So I will be pulling that from 2.0-dev and 1.5-dev until
> we can figure out a better way. Ideas appreciated.
>
ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Jim Jagielski <ji...@jaguNET.com>.
On httpd there was a discussion regarding versioning, and
this got me thinking...
Included in the APR 1.5.1 changes is an internal change
to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
calculates the key (via ftok())...
The problem (see the Bugz report) was that using the constant
1 would cause collisions, so I adjusted it to use a hash
of the filename. The problem there is that any external
APR users that needed to also determine the key needs to
be aware of that. And from what I can see, there is no
easy way to do that.
So I will be pulling that from 2.0-dev and 1.5-dev until
we can figure out a better way. Ideas appreciated.
ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Posted by Jim Jagielski <ji...@jaguNET.com>.
On httpd there was a discussion regarding versioning, and
this got me thinking...
Included in the APR 1.5.1 changes is an internal change
to how apr_shm_create(), when using APR_USE_SHMEM_SHMGET,
calculates the key (via ftok())...
The problem (see the Bugz report) was that using the constant
1 would cause collisions, so I adjusted it to use a hash
of the filename. The problem there is that any external
APR users that needed to also determine the key needs to
be aware of that. And from what I can see, there is no
easy way to do that.
So I will be pulling that from 2.0-dev and 1.5-dev until
we can figure out a better way. Ideas appreciated.
Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c
Posted by Eric Covener <co...@gmail.com>.
On Fri, Jan 24, 2014 at 4:21 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Fri, Jan 24, 2014 at 4:02 PM, Eric Covener <co...@gmail.com> wrote:
>>
>> > -#if APR_VERSION_AT_LEAST(1,5,1)
>> > +#ifdef APR_EOPNOTSUPP
>> > && rv != APR_EOPNOTSUPP
>> > #endif
>> > ) {
>> >
>>
>> As Jeff said in the other thread, this doesn't work if there's a lower
>> APR fix level at runtime, which is against the APR contract.
>
>
> It doesn't actually need any part of "APR runtime", does it?
doh
Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jan 24, 2014 at 4:02 PM, Eric Covener <co...@gmail.com> wrote:
> > -#if APR_VERSION_AT_LEAST(1,5,1)
> > +#ifdef APR_EOPNOTSUPP
> > && rv != APR_EOPNOTSUPP
> > #endif
> > ) {
> >
>
> As Jeff said in the other thread, this doesn't work if there's a lower
> APR fix level at runtime, which is against the APR contract.
>
It doesn't actually need any part of "APR runtime", does it?
>
>
>
> --
> Eric Covener
> covener@gmail.com
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/