On Friday 27 November 2015 18:55:43 Aya Mahfouz wrote:
> >
> > My first idea would be to split the key_preparsed_payload changes from
> > the struct key changes. Have you tried that? What problems did you run into?
> >
> Yes, the problem is that the assignments to key->expiry come from
> key_preparsed_payload-> expiry. I tried the following division:
>
> patch 1
> include/linux/key.h
> security/keys/keyring.c
> security/keys/permission.c
> security/keys/process_keys.c
> security/keys/gc.c
> security/keys/internal.h
>
> patch 2
> include/linux/key-type.h
> security/keys/key.c
>
>
> But key.c manipulates structures of type key and key_preparsed_payload.
Ok, so splitting the patch by files won't work, but that's rarely
possible. It takes a little practice to split up multi-file patches,
but it's not hard once you've done it a few times. Here are two methods
that I tend to use:
a) 'git reset HEAD^' to undo a commit but leave the changes in place,
then do 'git add -p' to selectively add changes I want in one patch,
using the 'edit' subcommand when I need to split up changes within
a single line.
b) 'git revert HEAD', followed by 'git show HEAD^ | patch -p1' to keep
the original patch in place, then undo changes individually until
you have a simpler patch to apply. Then do 'git diff HEAD^^ | patch -Rp1'
to get back the changes from the original patch in a second commit.
Repeat as necessary, then use 'git rebase -i' to reorder the patches
as needed and clean out the extra commits.
If there are not too many instances where the two patches clash, I would
probably add explicit conversions between time_t and time64_t using
a cast to annotate where the first patch is incomplete.
Arnd
_______________________________________________
Y2038 mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/y2038
