# [PATCH] mru: Replace mru.[ch] with list.h implementation 6 messages from 2017-11-11 to 2017-12-12. Participants: Gargi Sharma, Jeff King, Оля Тележная. Thread: https://gitlist.dev/t/47171 ## Gargi Sharma, 2017-11-11 18:06 Subject: [PATCH] mru: Replace mru.[ch] with list.h implementation Message-ID: <1510423606-9616-1-git-send-email-gs051095@gmail.com> URL: https://gitlist.dev/e/1510423606-9616-1-git-send-email-gs051095%40gmail.com ``` Replace custom allocation in mru.[ch] with generic calls to list.h API. Signed-off-by: Gargi Sharma --- builtin/pack-objects.c | 14 ++++++++------ cache.h | 9 +++++---- mru.c | 27 --------------------------- mru.h | 40 ---------------------------------------- packfile.c | 28 +++++++++++++++++++--------- 5 files changed, 32 insertions(+), 86 deletions(-) delete mode 100644 mru.c delete mode 100644 mru.h diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index ba81234..26717c5 100644 --- a/builtin/pack-objects.c +++ b/builtin/pack-objects.c @@ -24,7 +24,7 @@ #include "reachable.h" #include "sha1-array.h" #include "argv-array.h" -#include "mru.h" +#include "list.h" #include "packfile.h" static const char *pack_usage[] = { @@ -1012,9 +1012,9 @@ static int want_object_in_pack(const unsigned char *sha1, return want; } - list_for_each(pos, &packed_git_mru.list) { - struct mru *entry = list_entry(pos, struct mru, list); - struct packed_git *p = entry->item; + list_for_each(pos, &packed_git_mru) { + struct packed_git *p = list_entry(pos, struct packed_git, mru); + struct list_head *entry = &(p->mru); off_t offset; if (p == *found_pack) @@ -1030,8 +1030,10 @@ static int want_object_in_pack(const unsigned char *sha1, *found_pack = p; } want = want_found_object(exclude, p); - if (!exclude && want > 0) - mru_mark(&packed_git_mru, entry); + if (!exclude && want > 0) { + list_del(entry); + list_add(entry, &packed_git_mru); + } if (want != -1) return want; } diff --git a/cache.h b/cache.h index 49b083e..1a275ae 100644 --- a/cache.h +++ b/cache.h @@ -4,7 +4,7 @@ #include "git-compat-util.h" #include "strbuf.h" #include "hashmap.h" -#include "mru.h" +#include "list.h" #include "advice.h" #include "gettext.h" #include "convert.h" @@ -1566,6 +1566,7 @@ struct pack_window { extern struct packed_git { struct packed_git *next; + struct list_head mru; struct pack_window *windows; off_t pack_size; const void *index_data; @@ -1587,10 +1588,10 @@ extern struct packed_git { } *packed_git; /* - * A most-recently-used ordered version of the packed_git list, which can - * be iterated instead of packed_git (and marked via mru_mark). + * A most-recently-used ordered version of the packed_git list. */ -extern struct mru packed_git_mru; +extern struct list_head packed_git_mru; + struct pack_entry { off_t offset; diff --git a/mru.c b/mru.c deleted file mode 100644 index 8f3f34c..0000000 --- a/mru.c +++ /dev/null @@ -1,27 +0,0 @@ -#include "cache.h" -#include "mru.h" - -void mru_append(struct mru *head, void *item) -{ - struct mru *cur = xmalloc(sizeof(*cur)); - cur->item = item; - list_add_tail(&cur->list, &head->list); -} - -void mru_mark(struct mru *head, struct mru *entry) -{ - /* To mark means to put at the front of the list. */ - list_del(&entry->list); - list_add(&entry->list, &head->list); -} - -void mru_clear(struct mru *head) -{ - struct list_head *pos; - struct list_head *tmp; - - list_for_each_safe(pos, tmp, &head->list) { - free(list_entry(pos, struct mru, list)); - } - INIT_LIST_HEAD(&head->list); -} diff --git a/mru.h b/mru.h deleted file mode 100644 index 80a589e..0000000 --- a/mru.h +++ /dev/null @@ -1,40 +0,0 @@ -#ifndef MRU_H -#define MRU_H - -#include "list.h" - -/** - * A simple most-recently-used cache, backed by a doubly-linked list. - * - * Usage is roughly: - * - * // Create a list. Zero-initialization is required. - * static struct mru cache; - * INIT_LIST_HEAD(&cache.list); - * - * // Add new item to the end of the list. - * void *item; - * ... - * mru_append(&cache, item); - * - * // Mark an item as used, moving it to the front of the list. - * mru_mark(&cache, item); - * - * // Reset the list to empty, cleaning up all resources. - * mru_clear(&cache); - * - * Note that you SHOULD NOT call mru_mark() and then continue traversing the - * list; it reorders the marked item to the front of the list, and therefore - * you will begin traversing the whole list again. - */ - -struct mru { - struct list_head list; - void *item; -}; - -void mru_append(struct mru *head, void *item); -void mru_mark(struct mru *head, struct mru *entry); -void mru_clear(struct mru *head); - -#endif /* MRU_H */ diff --git a/packfile.c b/packfile.c index 502d915..3882d0b 100644 --- a/packfile.c +++ b/packfile.c @@ -1,5 +1,5 @@ #include "cache.h" -#include "mru.h" +#include "list.h" #include "pack.h" #include "dir.h" #include "mergesort.h" @@ -40,7 +40,7 @@ static unsigned int pack_max_fds; static size_t peak_pack_mapped; static size_t pack_mapped; struct packed_git *packed_git; -struct mru packed_git_mru = {{&packed_git_mru.list, &packed_git_mru.list}}; +LIST_HEAD(packed_git_mru); #define SZ_FMT PRIuMAX static inline uintmax_t sz_fmt(size_t s) { return s; } @@ -859,9 +859,18 @@ static void prepare_packed_git_mru(void) { struct packed_git *p; - mru_clear(&packed_git_mru); - for (p = packed_git; p; p = p->next) - mru_append(&packed_git_mru, p); + struct list_head *pos; + struct list_head *tmp; + list_for_each_safe(pos, tmp, &packed_git_mru) + list_del_init(pos); + + INIT_LIST_HEAD(&packed_git_mru); + + for (p = packed_git; p; p = p->next) { + struct packed_git *cur = xmalloc(sizeof(*packed_git)); + cur = p; + list_add_tail(&cur->mru, &packed_git_mru); + } } static int prepare_packed_git_run_once = 0; @@ -1830,10 +1839,11 @@ int find_pack_entry(const unsigned char *sha1, struct pack_entry *e) if (!packed_git) return 0; - list_for_each(pos, &packed_git_mru.list) { - struct mru *p = list_entry(pos, struct mru, list); - if (fill_pack_entry(sha1, e, p->item)) { - mru_mark(&packed_git_mru, p); + list_for_each(pos, &packed_git_mru) { + struct packed_git *p = list_entry(pos, struct packed_git, mru); + if (fill_pack_entry(sha1, e, p)) { + list_del(&p->mru); + list_add(&p->mru, &packed_git_mru); return 1; } } -- 2.7.4 ``` ## Jeff King, 2017-11-12 09:54 Subject: Re: [PATCH] mru: Replace mru.[ch] with list.h implementation Message-ID: <20171112095435.f4o662ygtt2taf5y@sigill.intra.peff.net> URL: https://gitlist.dev/e/20171112095435.f4o662ygtt2taf5y%40sigill.intra.peff.net In-Reply-To: <1510423606-9616-1-git-send-email-gs051095@gmail.com> ``` On Sat, Nov 11, 2017 at 01:06:46PM -0500, Gargi Sharma wrote: > Replace custom allocation in mru.[ch] with generic calls > to list.h API. > > Signed-off-by: Gargi Sharma Thanks, and welcome to the git list. :) This looks like a good start on the topic, but I have a few comments. It's a good idea to explain in the commit message not just what we're doing, but why we want to do it, to help later readers of "git log". I know that you picked this up from the discussion in the thread at: https://public-inbox.org/git/xmqq8tgz13x7.fsf@gitster.mtv.corp.google.com/ so it might be a good idea to summarize the ideas there (and add your own thoughts, of course). > --- > builtin/pack-objects.c | 14 ++++++++------ > cache.h | 9 +++++---- > mru.c | 27 --------------------------- > mru.h | 40 ---------------------------------------- > packfile.c | 28 +++++++++++++++++++--------- > 5 files changed, 32 insertions(+), 86 deletions(-) > delete mode 100644 mru.c > delete mode 100644 mru.h After the "---" line, you can put any information that people on the list might want to know but that doesn't need to go into the commit message. The big thing the maintainer would want to know here is that your patch is prepared on top of the ot/mru-on-list topic, so he knows where to apply it. The diffstat is certainly encouraging so far. :) > @@ -1012,9 +1012,9 @@ static int want_object_in_pack(const unsigned char *sha1, > return want; > } > > - list_for_each(pos, &packed_git_mru.list) { > - struct mru *entry = list_entry(pos, struct mru, list); > - struct packed_git *p = entry->item; > + list_for_each(pos, &packed_git_mru) { > + struct packed_git *p = list_entry(pos, struct packed_git, mru); > + struct list_head *entry = &(p->mru); > off_t offset; > > if (p == *found_pack) I think "entry" here is going to be the same as "pos". That said, I think it's only use is in bumping us to the front of the mru list later: > @@ -1030,8 +1030,10 @@ static int want_object_in_pack(const unsigned char *sha1, > *found_pack = p; > } > want = want_found_object(exclude, p); > - if (!exclude && want > 0) > - mru_mark(&packed_git_mru, entry); > + if (!exclude && want > 0) { > + list_del(entry); > + list_add(entry, &packed_git_mru); > + } And I think this might be more obvious if we drop "entry" entirely and just do: list_del(&p->mru); list_add(&p->mru, &packed_git_mru); It might merit a comment like "/* bump to the front of the mru list */" or similar to make it clear what's going on (or even adding a list_move_to_front() helper). > @@ -1566,6 +1566,7 @@ struct pack_window { > > extern struct packed_git { > struct packed_git *next; > + struct list_head mru; > struct pack_window *windows; > off_t pack_size; > const void *index_data; Sort of a side note, but seeing these two list pointers together makes me wonder what we should do with the list created by the "next" pointer. It seems like there are three options: 1. Convert it to "struct list_head", too, for consistency. 2. Leave it as-is. We never delete from the list nor do any fancy manipulation, so it doesn't benefit from the reusable code. 3. I wonder if we could drop it entirely, and just keep a single list of packs, ordered by mru. I'm not sure if anybody actually cares about accessing them in the "original" order. That order is reverse-chronological (by prepare_packed_git()), but I think that was mostly out of a sense that recent packs would be accessed more than older ones (but having a real mru strategy replaces that anyway). What do you think? > diff --git a/mru.c b/mru.c > deleted file mode 100644 > index 8f3f34c..0000000 Yay, this hunk (and the one for mru.h) is satisfying. > @@ -40,7 +40,7 @@ static unsigned int pack_max_fds; > static size_t peak_pack_mapped; > static size_t pack_mapped; > struct packed_git *packed_git; > -struct mru packed_git_mru = {{&packed_git_mru.list, &packed_git_mru.list}}; > +LIST_HEAD(packed_git_mru); Much nicer. > @@ -859,9 +859,18 @@ static void prepare_packed_git_mru(void) > { > struct packed_git *p; > > - mru_clear(&packed_git_mru); > - for (p = packed_git; p; p = p->next) > - mru_append(&packed_git_mru, p); > + struct list_head *pos; > + struct list_head *tmp; > + list_for_each_safe(pos, tmp, &packed_git_mru) > + list_del_init(pos); This matches the original code, which did the clear/re-create, resetting the mru to the "original" pack order. But I do wonder if that's actually necessary. Could we skip that and just add any new packs to the list? That goes hand-in-hand with the idea of dropping the "next" pointer that I mentioned above. > + INIT_LIST_HEAD(&packed_git_mru); I think this INIT_LIST_HEAD() isn't necessary anymore. In the original code, we just freed each of the mru_entry structs, which meant we had to forcibly reset the list head to be empty. But here you've used list_del_init(), so after deleting everything, packed_git_mru should already be empty. > + for (p = packed_git; p; p = p->next) { > + struct packed_git *cur = xmalloc(sizeof(*packed_git)); > + cur = p; > + list_add_tail(&cur->mru, &packed_git_mru); > + } This malloc can go away. The original mru code kept a separate entry, but now we don't need that. So here you're just leaking it when you assign "cur = p" (in fact, I think you can get rid of cur entirely). > @@ -1830,10 +1839,11 @@ int find_pack_entry(const unsigned char *sha1, struct pack_entry *e) > if (!packed_git) > return 0; > > - list_for_each(pos, &packed_git_mru.list) { > - struct mru *p = list_entry(pos, struct mru, list); > - if (fill_pack_entry(sha1, e, p->item)) { > - mru_mark(&packed_git_mru, p); > + list_for_each(pos, &packed_git_mru) { > + struct packed_git *p = list_entry(pos, struct packed_git, mru); > + if (fill_pack_entry(sha1, e, p)) { > + list_del(&p->mru); > + list_add(&p->mru, &packed_git_mru); > return 1; > } > } And this hunk looks pretty good (though if we added a move-to-front helper, it could be used here, too). -Peff ``` ## Jeff King, 2017-11-12 09:59 Subject: Re: [PATCH] mru: Replace mru.[ch] with list.h implementation Message-ID: <20171112095910.xwz43bzfbr5hz3tq@sigill.intra.peff.net> URL: https://gitlist.dev/e/20171112095910.xwz43bzfbr5hz3tq%40sigill.intra.peff.net In-Reply-To: <20171112095435.f4o662ygtt2taf5y@sigill.intra.peff.net> ``` On Sun, Nov 12, 2017 at 09:54:35AM +0000, Jeff King wrote: > > @@ -1566,6 +1566,7 @@ struct pack_window { > > > > extern struct packed_git { > > struct packed_git *next; > > + struct list_head mru; > > struct pack_window *windows; > > off_t pack_size; > > const void *index_data; > > Sort of a side note, but seeing these two list pointers together makes > me wonder what we should do with the list created by the "next" pointer. > It seems like there are three options: > > 1. Convert it to "struct list_head", too, for consistency. > > 2. Leave it as-is. We never delete from the list nor do any fancy > manipulation, so it doesn't benefit from the reusable code. > > 3. I wonder if we could drop it entirely, and just keep a single list > of packs, ordered by mru. I'm not sure if anybody actually cares > about accessing them in the "original" order. That order is > reverse-chronological (by prepare_packed_git()), but I think that > was mostly out of a sense that recent packs would be accessed more > than older ones (but having a real mru strategy replaces that > anyway). > > What do you think? Thinking on this a bit more, even if we want to go down any road except (2), it probably ought to come as a separate patch on top anyway. The changes you're making here are quite obviously a noop for visible behavior. But dropping the "next" pointer (and the matching "don't clear the list" I mentioned later) would potentially mean examining the packs in a slightly different order. I _think_ that's fine, but it's possible there could be a subtle fallout. So it's better to keep it separate from the more pure refactoring in your patch. -Peff ``` ## Gargi Sharma, 2017-11-12 12:49 Subject: Re: [PATCH] mru: Replace mru.[ch] with list.h implementation Message-ID: URL: https://gitlist.dev/e/CAOCi2DGYQr4jFf5ObY2buyhNJeaAPQKF8tbojn2W0b18Eo%2BWgw%40mail.gmail.com In-Reply-To: <20171112095435.f4o662ygtt2taf5y@sigill.intra.peff.net> ``` On Sun, Nov 12, 2017 at 9:54 AM, Jeff King wrote: > On Sat, Nov 11, 2017 at 01:06:46PM -0500, Gargi Sharma wrote: > >> Replace custom allocation in mru.[ch] with generic calls >> to list.h API. >> >> Signed-off-by: Gargi Sharma > > Thanks, and welcome to the git list. :) > > This looks like a good start on the topic, but I have a few comments. > > It's a good idea to explain in the commit message not just what we're > doing, but why we want to do it, to help later readers of "git log". I > know that you picked this up from the discussion in the thread at: > > https://public-inbox.org/git/xmqq8tgz13x7.fsf@gitster.mtv.corp.google.com/ > > so it might be a good idea to summarize the ideas there (and add your > own thoughts, of course). > >> --- >> builtin/pack-objects.c | 14 ++++++++------ >> cache.h | 9 +++++---- >> mru.c | 27 --------------------------- >> mru.h | 40 ---------------------------------------- >> packfile.c | 28 +++++++++++++++++++--------- >> 5 files changed, 32 insertions(+), 86 deletions(-) >> delete mode 100644 mru.c >> delete mode 100644 mru.h > > After the "---" line, you can put any information that people on the > list might want to know but that doesn't need to go into the commit > message. The big thing the maintainer would want to know here is that > your patch is prepared on top of the ot/mru-on-list topic, so he knows > where to apply it. > > The diffstat is certainly encouraging so far. :) > >> @@ -1012,9 +1012,9 @@ static int want_object_in_pack(const unsigned char *sha1, >> return want; >> } >> >> - list_for_each(pos, &packed_git_mru.list) { >> - struct mru *entry = list_entry(pos, struct mru, list); >> - struct packed_git *p = entry->item; >> + list_for_each(pos, &packed_git_mru) { >> + struct packed_git *p = list_entry(pos, struct packed_git, mru); >> + struct list_head *entry = &(p->mru); >> off_t offset; >> >> if (p == *found_pack) > > I think "entry" here is going to be the same as "pos". That said, I > think it's only use is in bumping us to the front of the mru list later: > >> @@ -1030,8 +1030,10 @@ static int want_object_in_pack(const unsigned char *sha1, >> *found_pack = p; >> } >> want = want_found_object(exclude, p); >> - if (!exclude && want > 0) >> - mru_mark(&packed_git_mru, entry); >> + if (!exclude && want > 0) { >> + list_del(entry); >> + list_add(entry, &packed_git_mru); >> + } > > And I think this might be more obvious if we drop "entry" entirely and > just do: > > list_del(&p->mru); > list_add(&p->mru, &packed_git_mru); > > It might merit a comment like "/* bump to the front of the mru list */" > or similar to make it clear what's going on (or even adding a > list_move_to_front() helper). I will add a helper to list.h, for doing this :) > >> @@ -1566,6 +1566,7 @@ struct pack_window { >> >> extern struct packed_git { >> struct packed_git *next; >> + struct list_head mru; >> struct pack_window *windows; >> off_t pack_size; >> const void *index_data; > > Sort of a side note, but seeing these two list pointers together makes > me wonder what we should do with the list created by the "next" pointer. > It seems like there are three options: > > 1. Convert it to "struct list_head", too, for consistency. > > 2. Leave it as-is. We never delete from the list nor do any fancy > manipulation, so it doesn't benefit from the reusable code. > > 3. I wonder if we could drop it entirely, and just keep a single list > of packs, ordered by mru. I'm not sure if anybody actually cares > about accessing them in the "original" order. That order is > reverse-chronological (by prepare_packed_git()), but I think that > was mostly out of a sense that recent packs would be accessed more > than older ones (but having a real mru strategy replaces that > anyway). > > What do you think? I think in the long run, it'll be easier if there is only a single list of packs given that no one needs to access the list in order. If we go down road 1/3, would it be better if I sent an entirely different patch or a patch series with patch 1 as removing mru[.ch] and patch 2 as removing next pointer from the struct? > >> diff --git a/mru.c b/mru.c >> deleted file mode 100644 >> index 8f3f34c..0000000 > > Yay, this hunk (and the one for mru.h) is satisfying. > >> @@ -40,7 +40,7 @@ static unsigned int pack_max_fds; >> static size_t peak_pack_mapped; >> static size_t pack_mapped; >> struct packed_git *packed_git; >> -struct mru packed_git_mru = {{&packed_git_mru.list, &packed_git_mru.list}}; >> +LIST_HEAD(packed_git_mru); > > Much nicer. > >> @@ -859,9 +859,18 @@ static void prepare_packed_git_mru(void) >> { >> struct packed_git *p; >> >> - mru_clear(&packed_git_mru); >> - for (p = packed_git; p; p = p->next) >> - mru_append(&packed_git_mru, p); >> + struct list_head *pos; >> + struct list_head *tmp; >> + list_for_each_safe(pos, tmp, &packed_git_mru) >> + list_del_init(pos); > > This matches the original code, which did the clear/re-create, resetting > the mru to the "original" pack order. But I do wonder if that's actually > necessary. Could we skip that and just add any new packs to the list? But if we do not clear the older entries from the list, wouldn't there be a problem when you access packed_git_mru->next, since that will be populated instead of being empty? Or am I misunderstanding something here? > > That goes hand-in-hand with the idea of dropping the "next" pointer that > I mentioned above. > >> + INIT_LIST_HEAD(&packed_git_mru); > > I think this INIT_LIST_HEAD() isn't necessary anymore. In the original > code, we just freed each of the mru_entry structs, which meant we had to > forcibly reset the list head to be empty. But here you've used > list_del_init(), so after deleting everything, packed_git_mru should > already be empty. > >> + for (p = packed_git; p; p = p->next) { >> + struct packed_git *cur = xmalloc(sizeof(*packed_git)); >> + cur = p; >> + list_add_tail(&cur->mru, &packed_git_mru); >> + } > > This malloc can go away. The original mru code kept a separate entry, > but now we don't need that. So here you're just leaking it when you > assign "cur = p" (in fact, I think you can get rid of cur entirely). Ah yes, I'll fix this. > >> @@ -1830,10 +1839,11 @@ int find_pack_entry(const unsigned char *sha1, struct pack_entry *e) >> if (!packed_git) >> return 0; >> >> - list_for_each(pos, &packed_git_mru.list) { >> - struct mru *p = list_entry(pos, struct mru, list); >> - if (fill_pack_entry(sha1, e, p->item)) { >> - mru_mark(&packed_git_mru, p); >> + list_for_each(pos, &packed_git_mru) { >> + struct packed_git *p = list_entry(pos, struct packed_git, mru); >> + if (fill_pack_entry(sha1, e, p)) { >> + list_del(&p->mru); >> + list_add(&p->mru, &packed_git_mru); >> return 1; >> } >> } > > And this hunk looks pretty good (though if we added a move-to-front > helper, it could be used here, too). Thanks! gargi > > -Peff ``` ## Jeff King, 2017-11-12 16:16 Subject: Re: [PATCH] mru: Replace mru.[ch] with list.h implementation Message-ID: <20171112161617.fhysws3idztguu23@sigill.intra.peff.net> URL: https://gitlist.dev/e/20171112161617.fhysws3idztguu23%40sigill.intra.peff.net In-Reply-To: ``` On Sun, Nov 12, 2017 at 12:49:17PM +0000, Gargi Sharma wrote: > > Sort of a side note, but seeing these two list pointers together makes > > me wonder what we should do with the list created by the "next" pointer. > > It seems like there are three options: > > > > 1. Convert it to "struct list_head", too, for consistency. > > > > 2. Leave it as-is. We never delete from the list nor do any fancy > > manipulation, so it doesn't benefit from the reusable code. > > > > 3. I wonder if we could drop it entirely, and just keep a single list > > of packs, ordered by mru. I'm not sure if anybody actually cares > > about accessing them in the "original" order. That order is > > reverse-chronological (by prepare_packed_git()), but I think that > > was mostly out of a sense that recent packs would be accessed more > > than older ones (but having a real mru strategy replaces that > > anyway). > > > > What do you think? > I think in the long run, it'll be easier if there is only a single > list of packs given > that no one needs to access the list in order. Yeah, it's that "given..." that makes me just a little nervous that I'm missing something. > If we go down road 1/3, would it be better if I sent an entirely > different patch or > a patch series with patch 1 as removing mru[.ch] and patch 2 as removing > next pointer from the struct? I think you could do it as a 2-patch series like that, or you could send the first patch now (since I think it stands on its own merits) and do the other one later on top. > > This matches the original code, which did the clear/re-create, resetting > > the mru to the "original" pack order. But I do wonder if that's actually > > necessary. Could we skip that and just add any new packs to the list? > > But if we do not clear the older entries from the list, wouldn't there be a > problem when you access packed_git_mru->next, since that will be populated > instead of being empty? Or am I misunderstanding something here? What I mean is that instead of clearing and re-adding all of the packs (including any new ones we picked up by rescanning the directory), we would _just_ add new ones to the list. So I think we'd scrap this whole "set up the mru" preparation here and just teach install_packed_git() to add the new pack to the MRU list. -Peff ``` ## Оля Тележная, 2017-12-12 14:07 Subject: Re: [PATCH] mru: Replace mru.[ch] with list.h implementation Message-ID: URL: https://gitlist.dev/e/CAL21BmmF2%3D%2BUVnuVZprn0vKh%2BPP%3Dwz3QpH_%3DAOfUsY9K0AfWzA%40mail.gmail.com In-Reply-To: <20171112161617.fhysws3idztguu23@sigill.intra.peff.net> ``` Gargi, If you have some difficulties - please feel free to ask questions (here or you can write me directly). I will be happy to help you. As I understand, you are super close to finish your first patch. Olga ```