Hi Alain,
Are you planning to submit an updated patch any time soon? If so,
please separate the ARM, x86, library and generic portions into separate
patches. It looks like at least some of them already went into ARM,
which makes it impractical to include this as a monolithic patch, which
it really shouldn't have to be, anyway.
-hpa
H. Peter Anvin wrote:
> Hi Alain,
>
> Are you planning to submit an updated patch any time soon? If so,
> please separate the ARM, x86, library and generic portions into separate
> patches. It looks like at least some of them already went into ARM,
> which makes it impractical to include this as a monolithic patch, which
> it really shouldn't have to be, anyway.
>
> -hpa
I'll look into it (the split) this weekend, if I'll find the time.
Should each part be compilable on its own? If so, it might be difficult
to do the split along the lines outlined above.
Alain
Alain Knaff wrote:
> H. Peter Anvin wrote:
>> Hi Alain,
>>
>> Are you planning to submit an updated patch any time soon? If so,
>> please separate the ARM, x86, library and generic portions into separate
>> patches. It looks like at least some of them already went into ARM,
>> which makes it impractical to include this as a monolithic patch, which
>> it really shouldn't have to be, anyway.
>>
>> -hpa
>
> I'll look into it (the split) this weekend, if I'll find the time.
> Should each part be compilable on its own? If so, it might be difficult
> to do the split along the lines outlined above.
>
Not individually, but part 1 should compile, as should parts 1+2, etc.
This pretty much means the order should be:
1. add library functions
2. generic functionality
3. x86 functionality
4. ARM functionality
Soem of these may be obsolete; I noticed collisions with the ARM tree.
-hpa
H. Peter Anvin wrote:
> Alain Knaff wrote:
>> H. Peter Anvin wrote:
>>> Hi Alain,
>>>
>>> Are you planning to submit an updated patch any time soon? If so,
>>> please separate the ARM, x86, library and generic portions into separate
>>> patches. It looks like at least some of them already went into ARM,
>>> which makes it impractical to include this as a monolithic patch, which
>>> it really shouldn't have to be, anyway.
>>>
>>> -hpa
>>
>> I'll look into it (the split) this weekend, if I'll find the time.
>> Should each part be compilable on its own? If so, it might be difficult
>> to do the split along the lines outlined above.
>>
>
> Not individually, but part 1 should compile, as should parts 1+2, etc.
>
> This pretty much means the order should be:
>
> 1. add library functions
> 2. generic functionality
> 3. x86 functionality
> 4. ARM functionality
Unfortunately, due to the nature of the patch, it will be hard to
separate out "x86 functionality" from changes in lib/inflate.c . Indeed,
a large part of the patch consists in moving some gzip-specific headers
and internal variable declarations from the callers:
arch/x86/boot/compressed/misc.c on one hand, and init/do_mounts_rd.c and
init/initramfs.c on the other hand into lib/inflate.c
So, leaving out the x86-specific change
(arch/x86/boot/compressed/misc.c) in the first change, would force to
leave that change out of lib/inflate.c as well (or else, the
above-listed items would be doubly defined). But, if I left out these
changes of lib/inflate.c, I'd need to leave them out of and
init/do_mounts_rd.c and init/initramfs.c too (or else the above-listed
items would not be defined at all in that situation). Can you suggest a
solution? I could theoretically break that dependency chain using an
#ifdef (as was the case until patch 3), but apparently #ifdef's are
highly frowned upon. Or was it just the name of the ifdef ("NEW_CODE")
that you objected to? Another option would be to (temporarily) keep 2
copies of lib/inflate.c around, but somehow that doesn't feel right.
So can you suggest some way out of the situation?
>
> Soem of these may be obsolete; I noticed collisions with the ARM tree.
>
> -hpa
Great! Could you tell me where to download the ARM tree from, so that I
can have a look?
Thanks,
Alain
Alain Knaff wrote:
>
> So, leaving out the x86-specific change
> (arch/x86/boot/compressed/misc.c) in the first change, would force to
> leave that change out of lib/inflate.c as well (or else, the
> above-listed items would be doubly defined). But, if I left out these
> changes of lib/inflate.c, I'd need to leave them out of and
> init/do_mounts_rd.c and init/initramfs.c too (or else the above-listed
> items would not be defined at all in that situation). Can you suggest a
> solution? I could theoretically break that dependency chain using an
> #ifdef (as was the case until patch 3), but apparently #ifdef's are
> highly frowned upon. Or was it just the name of the ifdef ("NEW_CODE")
> that you objected to? Another option would be to (temporarily) keep 2
> copies of lib/inflate.c around, but somehow that doesn't feel right.
>
> So can you suggest some way out of the situation?
>
Temporarily leaving two copies would work, as would be leaving in an
#ifdef as long as it is gone by the end of the patch series.
-hpa
Alain Knaff wrote:
> Great! Could you tell me where to download the ARM tree from, so that I
> can have a look?
>
> Thanks,
>
> Alain
Anybody can help here?
Thanks
Alain