You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Orton <jo...@redhat.com> on 2020/12/01 14:33:29 UTC
APLOGNO number range for vendors?
Very occasionally we backport patches to RHEL's httpd package in a way
that introduces new or different logging output from 2.4/trunk. I'm
wondering if there is any opinion about vendors asking for for a small
(say, 100?) reserved range of APLOGNO() space to use for such cases?
Basically I'd just commit "next-number += 100" and use that range within
downstream patches since they are then reserved upstream.
1) No, we should discourage vendors from such divergence.
2) Yes, they are just numbers, I don't care.
3) Yes, but commit to maintaining a public URL with documentation for
each log message used or something similar.
Thoughts?
Regards, Joe
Re: APLOGNO number range for vendors?
Posted by Nick Kew <ni...@apache.org>.
On Tue, 1 Dec 2020 14:33:29 +0000
Joe Orton <jo...@redhat.com> wrote:
> Very occasionally we backport patches to RHEL's httpd package in a
> way that introduces new or different logging output from 2.4/trunk.
> I'm wondering if there is any opinion about vendors asking for for a
> small (say, 100?) reserved range of APLOGNO() space to use for such
> cases? Basically I'd just commit "next-number += 100" and use that
> range within downstream patches since they are then reserved upstream.
Is there any possibility that a vendor-RH message leaking
upstream to us - i.e. you introduce something RH and later
commit it to trunk? If so, would you want to preserve the
vendor number or just reassign a new one?
No strong views, but if pressed I'd +1 to Stefan's suggestion.
Simple, and something you can do without touching our repos.
--
Nick Kew
Re: APLOGNO number range for vendors?
Posted by Eric Covener <co...@gmail.com>.
On Fri, Dec 4, 2020 at 9:56 AM Yann Ylavic <yl...@gmail.com> wrote:
>
> On Fri, Dec 4, 2020 at 3:05 PM Ruediger Pluem <rp...@apache.org> wrote:
> >
> > On 12/4/20 1:54 PM, Joe Orton wrote:
> > > On Tue, Dec 01, 2020 at 08:44:46PM +0100, Rüdiger Plüm wrote:
> > >> On 12/1/20 4:02 PM, Yehuda Katz wrote:
> > >>> Would a crazy option 4 be to add VENDOR_APLOGNO() which could add a prefix to the log number to be used in any patches?
> > >>>
> > >>> For example, V_APLOGNO('R', 123) could produce AHR123
> > >>>
> > >>> This would make it clear that the error comes from a patch from another distribution.
> > >>
> > >> Sounds like a good idea, as this would allow each vendor to manage its
> > >> own number range independently from each other and us and it would be
> > >> easy to spot such vendor specific error numbers in any kind of
> > >> reports.
> > >
> > > I dunno, this seems a bit over-engineering, upstream we'd have to
> > > maintain somewhere a registry of the special vendor prefixes as well as
> >
> > I don't think that we need this registry as long as the V_APLOGNO does not allow '' as first parameter.
> > How likely will it be that multiple vendors will work on the same distribution of HTTP server?
> > We could even have a static macro V_APLOGNO(123) that would produce AHV123 to mark this as a vendor specific number.
> > I think the registry would be only needed if V_APLOGNO would be used in 3rd party modules, where we could have
> > modules from different vendors loaded. But even then you could argue that it is not needed as you have the module
> > that created the log message in the log file and hence you can tell from which vendor this message is created.
>
> This upstream:
>
> Index: include/http_log.h
> ===================================================================
> --- include/http_log.h (revision 1883808)
> +++ include/http_log.h (working copy)
> @@ -116,6 +116,11 @@ extern "C" {
> */
> #define APLOGNO(n) "AH" #n ": "
>
> +#ifndef V_APLOGNO_PREFIX
> +#define V_APLOGNO_PREFIX "?"
> +#endif
> +#define V_APLOGNO(x) (V_APLOGNO_PREFIX APLOGNO(x))
> +
> /**
> * APLOG_NO_MODULE may be passed as module_index to ap_log_error() and related
> * functions if the module causing the log message is not known. Normally this
> --
>
> And then each vendor could -DV_APLOGNO_PREFIX=\"BL\" at build time,
> and use V_APLOGNO(x) wherever it deems fit?
>
>
> Regards;
> Yann.
>
> PS: what does our "AH" mean by the way?
[A]pache [H]TTPD i think.
Re: APLOGNO number range for vendors?
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Dec 4, 2020 at 3:05 PM Ruediger Pluem <rp...@apache.org> wrote:
>
> On 12/4/20 1:54 PM, Joe Orton wrote:
> > On Tue, Dec 01, 2020 at 08:44:46PM +0100, Rüdiger Plüm wrote:
> >> On 12/1/20 4:02 PM, Yehuda Katz wrote:
> >>> Would a crazy option 4 be to add VENDOR_APLOGNO() which could add a prefix to the log number to be used in any patches?
> >>>
> >>> For example, V_APLOGNO('R', 123) could produce AHR123
> >>>
> >>> This would make it clear that the error comes from a patch from another distribution.
> >>
> >> Sounds like a good idea, as this would allow each vendor to manage its
> >> own number range independently from each other and us and it would be
> >> easy to spot such vendor specific error numbers in any kind of
> >> reports.
> >
> > I dunno, this seems a bit over-engineering, upstream we'd have to
> > maintain somewhere a registry of the special vendor prefixes as well as
>
> I don't think that we need this registry as long as the V_APLOGNO does not allow '' as first parameter.
> How likely will it be that multiple vendors will work on the same distribution of HTTP server?
> We could even have a static macro V_APLOGNO(123) that would produce AHV123 to mark this as a vendor specific number.
> I think the registry would be only needed if V_APLOGNO would be used in 3rd party modules, where we could have
> modules from different vendors loaded. But even then you could argue that it is not needed as you have the module
> that created the log message in the log file and hence you can tell from which vendor this message is created.
This upstream:
Index: include/http_log.h
===================================================================
--- include/http_log.h (revision 1883808)
+++ include/http_log.h (working copy)
@@ -116,6 +116,11 @@ extern "C" {
*/
#define APLOGNO(n) "AH" #n ": "
+#ifndef V_APLOGNO_PREFIX
+#define V_APLOGNO_PREFIX "?"
+#endif
+#define V_APLOGNO(x) (V_APLOGNO_PREFIX APLOGNO(x))
+
/**
* APLOG_NO_MODULE may be passed as module_index to ap_log_error() and related
* functions if the module causing the log message is not known. Normally this
--
And then each vendor could -DV_APLOGNO_PREFIX=\"BL\" at build time,
and use V_APLOGNO(x) wherever it deems fit?
Regards;
Yann.
PS: what does our "AH" mean by the way?
Re: APLOGNO number range for vendors?
Posted by Ruediger Pluem <rp...@apache.org>.
On 12/4/20 1:54 PM, Joe Orton wrote:
> On Tue, Dec 01, 2020 at 08:44:46PM +0100, Rüdiger Plüm wrote:
>> On 12/1/20 4:02 PM, Yehuda Katz wrote:
>>> Would a crazy option 4 be to add VENDOR_APLOGNO() which could add a prefix to the log number to be used in any patches?
>>>
>>> For example, V_APLOGNO('R', 123) could produce AHR123
>>>
>>> This would make it clear that the error comes from a patch from another distribution.
>>
>> Sounds like a good idea, as this would allow each vendor to manage its
>> own number range independently from each other and us and it would be
>> easy to spot such vendor specific error numbers in any kind of
>> reports.
>
> I dunno, this seems a bit over-engineering, upstream we'd have to
> maintain somewhere a registry of the special vendor prefixes as well as
I don't think that we need this registry as long as the V_APLOGNO does not allow '' as first parameter.
How likely will it be that multiple vendors will work on the same distribution of HTTP server?
We could even have a static macro V_APLOGNO(123) that would produce AHV123 to mark this as a vendor specific number.
I think the registry would be only needed if V_APLOGNO would be used in 3rd party modules, where we could have
modules from different vendors loaded. But even then you could argue that it is not needed as you have the module
that created the log message in the log file and hence you can tell from which vendor this message is created.
Regards
Rüdiger
Re: APLOGNO number range for vendors?
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Dec 01, 2020 at 08:44:46PM +0100, Rüdiger Plüm wrote:
> On 12/1/20 4:02 PM, Yehuda Katz wrote:
> > Would a crazy option 4 be to add VENDOR_APLOGNO() which could add a prefix to the log number to be used in any patches?
> >
> > For example, V_APLOGNO('R', 123) could produce AHR123
> >
> > This would make it clear that the error comes from a patch from another distribution.
>
> Sounds like a good idea, as this would allow each vendor to manage its
> own number range independently from each other and us and it would be
> easy to spot such vendor specific error numbers in any kind of
> reports.
I dunno, this seems a bit over-engineering, upstream we'd have to
maintain somewhere a registry of the special vendor prefixes as well as
a new macro? I really just want to be able to use APLOGNO() as-is in
backports. If there's no appetite for allocating vendor ranges, we'll
just omit the APLOGNO() altogether in "vendor"ed log messages, it's not
really a big deal.
Regards, Joe
Re: APLOGNO number range for vendors?
Posted by Rüdiger Plüm <r....@gmx.de>.
On 12/1/20 4:02 PM, Yehuda Katz wrote:
> Would a crazy option 4 be to add VENDOR_APLOGNO() which could add a prefix to the log number to be used in any patches?
>
> For example, V_APLOGNO('R', 123) could produce AHR123
>
> This would make it clear that the error comes from a patch from another distribution.
Sounds like a good idea, as this would allow each vendor to manage its own number range independently from each other and us
and it would be easy to spot such vendor specific error numbers in any kind of reports.
Regards
Rüdiger
Re: APLOGNO number range for vendors?
Posted by Eric Covener <co...@gmail.com>.
On Tue, Dec 1, 2020 at 10:03 AM Yehuda Katz <ye...@ymkatz.net> wrote:
>
> Would a crazy option 4 be to add VENDOR_APLOGNO() which could add a prefix to the log number to be used in any patches?
>
> For example, V_APLOGNO('R', 123) could produce AHR123
I think something like this is a good compromise but my 2c I think i
would not want the 'R' inline here but stashed away in e.g.
ap_release.h
I currently only use an alternate macro/prefix for proprietary modules
in the distribution I work on, but I think a substantially different
existing AHxxxx just hasn't come up yet.
Re: APLOGNO number range for vendors?
Posted by Yehuda Katz <ye...@ymkatz.net>.
Would a crazy option 4 be to add VENDOR_APLOGNO() which could add a prefix
to the log number to be used in any patches?
For example, V_APLOGNO('R', 123) could produce AHR123
This would make it clear that the error comes from a patch from another
distribution.
- Y
Sent from a device with a very small keyboard and hyperactive autocorrect.
On Tue, Dec 1, 2020, 9:33 AM Joe Orton <jo...@redhat.com> wrote:
> Very occasionally we backport patches to RHEL's httpd package in a way
> that introduces new or different logging output from 2.4/trunk. I'm
> wondering if there is any opinion about vendors asking for for a small
> (say, 100?) reserved range of APLOGNO() space to use for such cases?
> Basically I'd just commit "next-number += 100" and use that range within
> downstream patches since they are then reserved upstream.
>
> 1) No, we should discourage vendors from such divergence.
>
> 2) Yes, they are just numbers, I don't care.
>
> 3) Yes, but commit to maintaining a public URL with documentation for
> each log message used or something similar.
>
> Thoughts?
>
> Regards, Joe
>
>
Re: APLOGNO number range for vendors?
Posted by Stefan Eissing <st...@greenbytes.de>.
#define RHLOGNO(n) "RH" #n ": "
and have your own number space?
> Am 01.12.2020 um 15:33 schrieb Joe Orton <jo...@redhat.com>:
>
> Very occasionally we backport patches to RHEL's httpd package in a way
> that introduces new or different logging output from 2.4/trunk. I'm
> wondering if there is any opinion about vendors asking for for a small
> (say, 100?) reserved range of APLOGNO() space to use for such cases?
> Basically I'd just commit "next-number += 100" and use that range within
> downstream patches since they are then reserved upstream.
>
> 1) No, we should discourage vendors from such divergence.
>
> 2) Yes, they are just numbers, I don't care.
>
> 3) Yes, but commit to maintaining a public URL with documentation for
> each log message used or something similar.
>
> Thoughts?
>
> Regards, Joe
>