[ patch for 5.12 ] mark get_arena() as Maychange

[Jim Cromie]

this patch fixes get-arenas param names to reflect actual use,
and marks call with 'M' for maychange.
it needs make regen.

I checked in proto.h - git let me, cuz its not in .gitignore,
this surprised me mildly, since its generated output,
but its also a tracked file.

wrt submitted patches, I presume you prefer such files to be included
in commits,
as reflective of at least some testing ? ;-)

wrt May Change
The change I envision is adding a NN void* reqid,
which would allow get_arena to track individual consumers of
the arenas it serves up.

ATM those consumers are just the ~16 svtype bodies.

[Jesse]

On Mon, Nov 23, 2009 at 01:35:38PM -0700, Jim Cromie wrote:
> this patch fixes get-arenas param names to reflect actual use,

Can you send along the patch?

> and marks call with 'M' for maychange.
> it needs make regen.
>
> I checked in proto.h - git let me, cuz its not in .gitignore,
> this surprised me mildly, since its generated output,
> but its also a tracked file.
>
> wrt submitted patches, I presume you prefer such files to be included
> in commits,
> as reflective of at least some testing ? ;-)

I'd actually prefer the patch to be minimal but with a note saying that
the generated file needs to be regenerated.

> wrt May Change
> The change I envision is adding a NN void* reqid,
> which would allow get_arena to track individual consumers of
> the arenas it serves up.
>
> ATM those consumers are just the ~16 svtype bodies.
>

--

[Jim Cromie]

On Mon, Nov 23, 2009 at 2:10 PM, jesse <je...@fsck.com> wrote:
>
>
>
> On Mon, Nov 23, 2009 at 01:35:38PM -0700, Jim Cromie wrote:
>> this patch fixes get-arenas param names to reflect actual use,
>
> Can you send along the patch?

oof. I hate it when I do that.

>
>> and marks call with 'M' for maychange.
>> it needs make regen.
>>
>> I checked in proto.h - git let me, cuz its not in .gitignore,
>> this surprised me mildly, since its generated output,
>> but its also a tracked file.
>>
>> wrt submitted patches, I presume you prefer such files to be included
>> in commits,
>> as reflective of at least some testing ? ;-)
>
> I'd actually prefer the patch to be minimal but with a note saying that
> the generated file needs to be regenerated.

uhm, Im now having trouble removing it from my commit.
sending old patch in meantime.

[Jim Cromie]

heres a clean one, without proto.h
git help rebase and /SPLITTING COMMITS/ clarified it,

it does however mention adding reqid param,
which might be over-selling ;-)

[Rafael Garcia-Suarez]

2009/11/23 Jim Cromie <jim.c...@gmail.com>:

Thanks, applied.