Add two small functions:
efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
calls them instead of embedding two long for loop.
Signed-off-by: Dave Young <[email protected]>
---
arch/x86/platform/efi/efi.c | 83 +++++++++++++++++++++++++++-----------------
1 file changed, 52 insertions(+), 31 deletions(-)
--- efi.orig/arch/x86/platform/efi/efi.c
+++ efi/arch/x86/platform/efi/efi.c
@@ -789,35 +789,13 @@ void __init old_map_region(efi_memory_de
pr_err("ioremap of 0x%llX failed!\n",
(unsigned long long)md->phys_addr);
}
-/*
- * This function will switch the EFI runtime services to virtual mode.
- * Essentially, look through the EFI memmap and map every region that
- * has the runtime attribute bit set in its memory descriptor and update
- * that memory descriptor with the virtual address obtained from ioremap().
- * This enables the runtime services to be called without having to
- * thunk back into physical mode for every invocation.
- */
-void __init efi_enter_virtual_mode(void)
-{
- efi_memory_desc_t *md, *prev_md = NULL;
- void *p, *new_memmap = NULL;
- unsigned long size;
- efi_status_t status;
- u64 end, systab;
- int count = 0;
- efi.systab = NULL;
-
- /*
- * We don't do virtual mode, since we don't do runtime services, on
- * non-native EFI
- */
- if (!efi_is_native()) {
- efi_unmap_memmap();
- return;
- }
+/* Merge contiguous regions of the same type and attribute */
+static void efi_merge_regions(void)
+{
+ void *p;
+ efi_memory_desc_t *md, *prev_md = NULL;
- /* Merge contiguous regions of the same type and attribute */
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
u64 prev_size;
md = p;
@@ -844,6 +822,19 @@ void __init efi_enter_virtual_mode(void)
prev_md = md;
}
+}
+
+/*
+ * Map efi memory ranges for runtime serivce
+ * Return the new memmap with updated virtual addrresses.
+ */
+void efi_map_regions(void **new_memmap, int *count)
+{
+ efi_memory_desc_t *md, *prev_md = NULL;
+ void *p;
+ unsigned long size;
+ efi_status_t status;
+ u64 end, systab;
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
@@ -862,14 +853,44 @@ void __init efi_enter_virtual_mode(void)
systab += md->virt_addr - md->phys_addr;
efi.systab = (efi_system_table_t *) (unsigned long) systab;
}
- new_memmap = krealloc(new_memmap,
- (count + 1) * memmap.desc_size,
+ *new_memmap = krealloc(*new_memmap,
+ (*count + 1) * memmap.desc_size,
GFP_KERNEL);
- memcpy(new_memmap + (count * memmap.desc_size), md,
+ memcpy(*new_memmap + (*count * memmap.desc_size), md,
memmap.desc_size);
- count++;
+ (*count)++;
+ }
+}
+
+/*
+ * This function will switch the EFI runtime services to virtual mode.
+ * Essentially, look through the EFI memmap and map every region that
+ * has the runtime attribute bit set in its memory descriptor and update
+ * that memory descriptor with the virtual address obtained from ioremap().
+ * This enables the runtime services to be called without having to
+ * thunk back into physical mode for every invocation.
+ */
+void __init efi_enter_virtual_mode(void)
+{
+ efi_status_t status;
+ void *p, *new_memmap = NULL;
+ int count = 0;
+
+ efi.systab = NULL;
+
+ /*
+ * We don't do virtual mode, since we don't do runtime services, on
+ * non-native EFI
+ */
+ if (!efi_is_native()) {
+ efi_unmap_memmap();
+ return;
}
+ efi_merge_regions();
+
+ efi_map_regions(&new_memmap, &count);
+
#ifdef CONFIG_X86_64
efi_scratch.efi_pgt = (pgd_t *)(unsigned long)real_mode_header->trampoline_pgd;
On Sun, Oct 27, 2013 at 11:47:16AM +0800, [email protected] wrote:
> Add two small functions:
> efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
> calls them instead of embedding two long for loop.
>
> Signed-off-by: Dave Young <[email protected]>
> ---
> arch/x86/platform/efi/efi.c | 83 +++++++++++++++++++++++++++-----------------
> 1 file changed, 52 insertions(+), 31 deletions(-)
>
> --- efi.orig/arch/x86/platform/efi/efi.c
> +++ efi/arch/x86/platform/efi/efi.c
> @@ -789,35 +789,13 @@ void __init old_map_region(efi_memory_de
> pr_err("ioremap of 0x%llX failed!\n",
> (unsigned long long)md->phys_addr);
> }
> -/*
> - * This function will switch the EFI runtime services to virtual mode.
> - * Essentially, look through the EFI memmap and map every region that
> - * has the runtime attribute bit set in its memory descriptor and update
> - * that memory descriptor with the virtual address obtained from ioremap().
> - * This enables the runtime services to be called without having to
> - * thunk back into physical mode for every invocation.
> - */
> -void __init efi_enter_virtual_mode(void)
> -{
> - efi_memory_desc_t *md, *prev_md = NULL;
> - void *p, *new_memmap = NULL;
> - unsigned long size;
> - efi_status_t status;
> - u64 end, systab;
> - int count = 0;
>
> - efi.systab = NULL;
> -
> - /*
> - * We don't do virtual mode, since we don't do runtime services, on
> - * non-native EFI
> - */
> - if (!efi_is_native()) {
> - efi_unmap_memmap();
> - return;
> - }
> +/* Merge contiguous regions of the same type and attribute */
> +static void efi_merge_regions(void)
> +{
> + void *p;
> + efi_memory_desc_t *md, *prev_md = NULL;
>
> - /* Merge contiguous regions of the same type and attribute */
> for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> u64 prev_size;
> md = p;
> @@ -844,6 +822,19 @@ void __init efi_enter_virtual_mode(void)
> prev_md = md;
>
> }
> +}
> +
> +/*
> + * Map efi memory ranges for runtime serivce
> + * Return the new memmap with updated virtual addrresses.
> + */
> +void efi_map_regions(void **new_memmap, int *count)
> +{
> + efi_memory_desc_t *md, *prev_md = NULL;
Applying: Cleanup efi_enter_virtual_mode function
/home/boris/kernel/linux-2.6/.git/rebase-apply/patch:42: space before tab in indent.
efi_memory_desc_t *md, *prev_md = NULL;
error: patch failed: arch/x86/platform/efi/efi.c:862
error: arch/x86/platform/efi/efi.c: patch does not apply
Patch failed at 0001 Cleanup efi_enter_virtual_mode function
And I know git can be a bit pickier than patch but it doesn't apply with patch
either:
$ patch -p1 --dry-run -i .git/rebase-apply/patch
checking file arch/x86/platform/efi/efi.c
Hunk #3 FAILED at 853.
1 out of 3 hunks FAILED
For some reason, this patch doesn't apply and the .rej looks funny.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 10/28/13 at 10:32am, Borislav Petkov wrote:
> On Sun, Oct 27, 2013 at 11:47:16AM +0800, [email protected] wrote:
> > Add two small functions:
> > efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
> > calls them instead of embedding two long for loop.
> >
> > Signed-off-by: Dave Young <[email protected]>
> > ---
> > arch/x86/platform/efi/efi.c | 83 +++++++++++++++++++++++++++-----------------
> > 1 file changed, 52 insertions(+), 31 deletions(-)
> >
> > --- efi.orig/arch/x86/platform/efi/efi.c
> > +++ efi/arch/x86/platform/efi/efi.c
> > @@ -789,35 +789,13 @@ void __init old_map_region(efi_memory_de
> > pr_err("ioremap of 0x%llX failed!\n",
> > (unsigned long long)md->phys_addr);
> > }
> > -/*
> > - * This function will switch the EFI runtime services to virtual mode.
> > - * Essentially, look through the EFI memmap and map every region that
> > - * has the runtime attribute bit set in its memory descriptor and update
> > - * that memory descriptor with the virtual address obtained from ioremap().
> > - * This enables the runtime services to be called without having to
> > - * thunk back into physical mode for every invocation.
> > - */
> > -void __init efi_enter_virtual_mode(void)
> > -{
> > - efi_memory_desc_t *md, *prev_md = NULL;
> > - void *p, *new_memmap = NULL;
> > - unsigned long size;
> > - efi_status_t status;
> > - u64 end, systab;
> > - int count = 0;
> >
> > - efi.systab = NULL;
> > -
> > - /*
> > - * We don't do virtual mode, since we don't do runtime services, on
> > - * non-native EFI
> > - */
> > - if (!efi_is_native()) {
> > - efi_unmap_memmap();
> > - return;
> > - }
> > +/* Merge contiguous regions of the same type and attribute */
> > +static void efi_merge_regions(void)
> > +{
> > + void *p;
> > + efi_memory_desc_t *md, *prev_md = NULL;
> >
> > - /* Merge contiguous regions of the same type and attribute */
> > for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> > u64 prev_size;
> > md = p;
> > @@ -844,6 +822,19 @@ void __init efi_enter_virtual_mode(void)
> > prev_md = md;
> >
> > }
> > +}
> > +
> > +/*
> > + * Map efi memory ranges for runtime serivce
> > + * Return the new memmap with updated virtual addrresses.
> > + */
> > +void efi_map_regions(void **new_memmap, int *count)
> > +{
> > + efi_memory_desc_t *md, *prev_md = NULL;
>
> Applying: Cleanup efi_enter_virtual_mode function
> /home/boris/kernel/linux-2.6/.git/rebase-apply/patch:42: space before tab in indent.
> efi_memory_desc_t *md, *prev_md = NULL;
> error: patch failed: arch/x86/platform/efi/efi.c:862
> error: arch/x86/platform/efi/efi.c: patch does not apply
> Patch failed at 0001 Cleanup efi_enter_virtual_mode function
>
> And I know git can be a bit pickier than patch but it doesn't apply with patch
> either:
>
> $ patch -p1 --dry-run -i .git/rebase-apply/patch
> checking file arch/x86/platform/efi/efi.c
> Hunk #3 FAILED at 853.
> 1 out of 3 hunks FAILED
>
> For some reason, this patch doesn't apply and the .rej looks funny.
It's stange, but I did use git to generate patch, I use quilt instead.
Will have a try with git.
On 10/28/13 at 05:40pm, Dave Young wrote:
> On 10/28/13 at 10:32am, Borislav Petkov wrote:
> > On Sun, Oct 27, 2013 at 11:47:16AM +0800, [email protected] wrote:
> > > Add two small functions:
> > > efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
> > > calls them instead of embedding two long for loop.
> > >
> > > Signed-off-by: Dave Young <[email protected]>
> > > ---
> > > arch/x86/platform/efi/efi.c | 83 +++++++++++++++++++++++++++-----------------
> > > 1 file changed, 52 insertions(+), 31 deletions(-)
> > >
> > > --- efi.orig/arch/x86/platform/efi/efi.c
> > > +++ efi/arch/x86/platform/efi/efi.c
> > > @@ -789,35 +789,13 @@ void __init old_map_region(efi_memory_de
> > > pr_err("ioremap of 0x%llX failed!\n",
> > > (unsigned long long)md->phys_addr);
> > > }
> > > -/*
> > > - * This function will switch the EFI runtime services to virtual mode.
> > > - * Essentially, look through the EFI memmap and map every region that
> > > - * has the runtime attribute bit set in its memory descriptor and update
> > > - * that memory descriptor with the virtual address obtained from ioremap().
> > > - * This enables the runtime services to be called without having to
> > > - * thunk back into physical mode for every invocation.
> > > - */
> > > -void __init efi_enter_virtual_mode(void)
> > > -{
> > > - efi_memory_desc_t *md, *prev_md = NULL;
> > > - void *p, *new_memmap = NULL;
> > > - unsigned long size;
> > > - efi_status_t status;
> > > - u64 end, systab;
> > > - int count = 0;
> > >
> > > - efi.systab = NULL;
> > > -
> > > - /*
> > > - * We don't do virtual mode, since we don't do runtime services, on
> > > - * non-native EFI
> > > - */
> > > - if (!efi_is_native()) {
> > > - efi_unmap_memmap();
> > > - return;
> > > - }
> > > +/* Merge contiguous regions of the same type and attribute */
> > > +static void efi_merge_regions(void)
> > > +{
> > > + void *p;
> > > + efi_memory_desc_t *md, *prev_md = NULL;
> > >
> > > - /* Merge contiguous regions of the same type and attribute */
> > > for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
> > > u64 prev_size;
> > > md = p;
> > > @@ -844,6 +822,19 @@ void __init efi_enter_virtual_mode(void)
> > > prev_md = md;
> > >
> > > }
> > > +}
> > > +
> > > +/*
> > > + * Map efi memory ranges for runtime serivce
> > > + * Return the new memmap with updated virtual addrresses.
> > > + */
> > > +void efi_map_regions(void **new_memmap, int *count)
> > > +{
> > > + efi_memory_desc_t *md, *prev_md = NULL;
> >
> > Applying: Cleanup efi_enter_virtual_mode function
> > /home/boris/kernel/linux-2.6/.git/rebase-apply/patch:42: space before tab in indent.
> > efi_memory_desc_t *md, *prev_md = NULL;
> > error: patch failed: arch/x86/platform/efi/efi.c:862
> > error: arch/x86/platform/efi/efi.c: patch does not apply
> > Patch failed at 0001 Cleanup efi_enter_virtual_mode function
> >
> > And I know git can be a bit pickier than patch but it doesn't apply with patch
> > either:
> >
> > $ patch -p1 --dry-run -i .git/rebase-apply/patch
> > checking file arch/x86/platform/efi/efi.c
> > Hunk #3 FAILED at 853.
> > 1 out of 3 hunks FAILED
> >
> > For some reason, this patch doesn't apply and the .rej looks funny.
>
> It's stange, but I did use git to generate patch, I use quilt instead.
> Will have a try with git.
It does have a warning, but it applied successfully, no idea though:
patches/02-efi-enter-virtual-mode-cleanup.patch
Applying: Cleanup efi_enter_virtual_mode function
/home/dave/git/efi/.git/rebase-apply/patch:42: space before tab in indent.
efi_memory_desc_t *md, *prev_md = NULL;
warning: 1 line adds whitespace errors.
On Mon, Oct 28, 2013 at 05:51:17PM +0800, Dave Young wrote:
> It does have a warning, but it applied successfully, no idea though:
> patches/02-efi-enter-virtual-mode-cleanup.patch
> Applying: Cleanup efi_enter_virtual_mode function
> /home/dave/git/efi/.git/rebase-apply/patch:42: space before tab in indent.
> efi_memory_desc_t *md, *prev_md = NULL;
> warning: 1 line adds whitespace errors.
Hmm, ok, can you upload the patches somewhere so that I can pull them?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 10/28/13 at 11:04am, Borislav Petkov wrote:
> On Mon, Oct 28, 2013 at 05:51:17PM +0800, Dave Young wrote:
> > It does have a warning, but it applied successfully, no idea though:
> > patches/02-efi-enter-virtual-mode-cleanup.patch
> > Applying: Cleanup efi_enter_virtual_mode function
> > /home/dave/git/efi/.git/rebase-apply/patch:42: space before tab in indent.
> > efi_memory_desc_t *md, *prev_md = NULL;
> > warning: 1 line adds whitespace errors.
>
> Hmm, ok, can you upload the patches somewhere so that I can pull them?
Sorry, I have not any public git account. Attached the patch I applied with git
>
> Thanks.
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
On 10/28/13 at 06:10pm, Dave Young wrote:
> On 10/28/13 at 11:04am, Borislav Petkov wrote:
> > On Mon, Oct 28, 2013 at 05:51:17PM +0800, Dave Young wrote:
> > > It does have a warning, but it applied successfully, no idea though:
> > > patches/02-efi-enter-virtual-mode-cleanup.patch
> > > Applying: Cleanup efi_enter_virtual_mode function
> > > /home/dave/git/efi/.git/rebase-apply/patch:42: space before tab in indent.
> > > efi_memory_desc_t *md, *prev_md = NULL;
> > > warning: 1 line adds whitespace errors.
> >
> > Hmm, ok, can you upload the patches somewhere so that I can pull them?
>
> Sorry, I have not any public git account. Attached the patch I applied with git
Here is the kernel patche files if you would like to try,
I have not got time to update them based on comments.
https://people.redhat.com/ruyang/kexec-efi/for-bp/kernel-patches/
On Mon, Oct 28, 2013 at 06:10:11PM +0800, Dave Young wrote:
> Sorry, I have not any public git account. Attached the patch I applied
> with git
Still doesn't work:
$ patch -p1 --dry-run -i /tmp/02-efi-enter-virtual-mode-cleanup-1.patch.new
checking file arch/x86/platform/efi/efi.c
Hunk #1 succeeded at 788 (offset -1 lines).
Hunk #2 succeeded at 821 (offset -1 lines).
Hunk #3 FAILED at 853.
1 out of 3 hunks FAILED
I'm using Matt's next branch + my efi runtime branch. What are you
basing your stuff ontop?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 10/28/13 at 12:20pm, Borislav Petkov wrote:
> On Mon, Oct 28, 2013 at 06:10:11PM +0800, Dave Young wrote:
> > Sorry, I have not any public git account. Attached the patch I applied
> > with git
>
> Still doesn't work:
>
> $ patch -p1 --dry-run -i /tmp/02-efi-enter-virtual-mode-cleanup-1.patch.new
> checking file arch/x86/platform/efi/efi.c
> Hunk #1 succeeded at 788 (offset -1 lines).
> Hunk #2 succeeded at 821 (offset -1 lines).
> Hunk #3 FAILED at 853.
> 1 out of 3 hunks FAILED
>
> I'm using Matt's next branch + my efi runtime branch. What are you
> basing your stuff ontop?
I use linus tree, git pull Matt's efi-next tree, then apply your 12 patches
and my patches. I applied your previous 11 patches + the last update patch
12/12, but the last one does not apply, I manually shift a hunk to make it
apply.
On Mon, Oct 28, 2013 at 07:24:58PM +0800, Dave Young wrote:
> I use linus tree, git pull Matt's efi-next tree, then apply your 12
> patches and my patches. I applied your previous 11 patches + the last
> update patch 12/12, but the last one does not apply, I manually shift
> a hunk to make it apply.
Nope, still doesn't apply.
patch -p1 --dry-run -i ~/efi/dy/03-efi-enter-virtual-mode-cleanup.patch
checking file arch/x86/platform/efi/efi.c
Hunk #1 succeeded at 788 (offset -1 lines).
Hunk #2 succeeded at 821 (offset -1 lines).
Hunk #3 FAILED at 853.
1 out of 3 hunks FAILED
and this time I took your patches from here: https://people.redhat.com/ruyang/kexec-efi/for-bp/kernel-patches/
What I did is:
1. I took Linus' tree from today
2. Merged the 'next' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git. Mind
you, not the 'efi-next' tag!
3. Then I merged the 'efi' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git ontop.
It gave a simple merge conflict which is trivial to resolve:
http://paste.debian.net/62579/
Here I started applying your patches and the 3rd one still fails.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 10/28/13 at 03:58pm, Borislav Petkov wrote:
> On Mon, Oct 28, 2013 at 07:24:58PM +0800, Dave Young wrote:
> > I use linus tree, git pull Matt's efi-next tree, then apply your 12
> > patches and my patches. I applied your previous 11 patches + the last
> > update patch 12/12, but the last one does not apply, I manually shift
> > a hunk to make it apply.
>
> Nope, still doesn't apply.
>
> patch -p1 --dry-run -i ~/efi/dy/03-efi-enter-virtual-mode-cleanup.patch
> checking file arch/x86/platform/efi/efi.c
> Hunk #1 succeeded at 788 (offset -1 lines).
> Hunk #2 succeeded at 821 (offset -1 lines).
> Hunk #3 FAILED at 853.
> 1 out of 3 hunks FAILED
>
> and this time I took your patches from here: https://people.redhat.com/ruyang/kexec-efi/for-bp/kernel-patches/
>
> What I did is:
>
> 1. I took Linus' tree from today
>
> 2. Merged the 'next' branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git. Mind
> you, not the 'efi-next' tag!
I used the above tree origin/next branch
>
> 3. Then I merged the 'efi' branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git ontop.
I used the patches from mailbox directly.
Fixed an conflict and merge them one by one.
> It gave a simple merge conflict which is trivial to resolve:
> http://paste.debian.net/62579/
Looks like I can not access above link.
>
> Here I started applying your patches and the 3rd one still fails.
>
It's strange to me. There must be something wrong in the steps
But sorry, it's time to sleep for me, will track this tommrrow.
Thanks
Dave
> >
> > 3. Then I merged the 'efi' branch of
> > git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git ontop.
>
> I used the patches from mailbox directly.
> Fixed an conflict and merge them one by one.
I remember I tried your efi branch, but the code is different
from what you sent to list, thus I turned to use the mbox patches.
--
Thanks
Dave
On Tue, Oct 29, 2013 at 10:32:03AM +0800, Dave Young wrote:
> I remember I tried your efi branch, but the code is different from
> what you sent to list, thus I turned to use the mbox patches.
Yeah, please use the #efi branch as I keep refreshing it with the newest
changes. They're hopefully not serious changes but minor stuff here and
there so basing stuff ontop should be ok.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 10/29/13 at 02:43pm, Borislav Petkov wrote:
> On Tue, Oct 29, 2013 at 10:32:03AM +0800, Dave Young wrote:
> > I remember I tried your efi branch, but the code is different from
> > what you sent to list, thus I turned to use the mbox patches.
>
> Yeah, please use the #efi branch as I keep refreshing it with the newest
> changes. They're hopefully not serious changes but minor stuff here and
> there so basing stuff ontop should be ok.
Will try, but please keep the posted patches in mailing list up-to-date,
I'm an old-fashioned person, do not tend to depend on git.
Thanks in advance.
Dave
On Wed, Oct 30, 2013 at 10:03:49AM +0800, Dave Young wrote:
> Will try, but please keep the posted patches in mailing list up-to-date,
Would you like me to send them to you privately?
> I'm an old-fashioned person, do not tend to depend on git.
Really? You should change that - you're missing out on so much by not
using git. :)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 10/30/13 at 11:47am, Borislav Petkov wrote:
> On Wed, Oct 30, 2013 at 10:03:49AM +0800, Dave Young wrote:
> > Will try, but please keep the posted patches in mailing list up-to-date,
>
> Would you like me to send them to you privately?
Thanks, do not bother to send me privately I can get it from your git tree.
But Frankly I'd like to see them in list instead even with only small fixes
beacuse in this way there might be more people to review it carefully.
--
Thanks
Dave
On 10/31/13 at 10:04am, Dave Young wrote:
> On 10/30/13 at 11:47am, Borislav Petkov wrote:
> > On Wed, Oct 30, 2013 at 10:03:49AM +0800, Dave Young wrote:
> > > Will try, but please keep the posted patches in mailing list up-to-date,
> >
> > Would you like me to send them to you privately?
>
> Thanks, do not bother to send me privately I can get it from your git tree.
>
> But Frankly I'd like to see them in list instead even with only small fixes
> beacuse in this way there might be more people to review it carefully.
There's another shorcoming for keeping new patches in git is that nobody know
when you push it and when is the proper date to pull from your git. I think
it's better to use git only for the patches which have already been accepted
and is waiting for maintainer to pull.
>
> --
> Thanks
> Dave
On 10/30/2013 07:07 PM, Dave Young wrote:
> On 10/31/13 at 10:04am, Dave Young wrote:
>> On 10/30/13 at 11:47am, Borislav Petkov wrote:
>>> On Wed, Oct 30, 2013 at 10:03:49AM +0800, Dave Young wrote:
>>>> Will try, but please keep the posted patches in mailing list up-to-date,
>>>
>>> Would you like me to send them to you privately?
>>
>> Thanks, do not bother to send me privately I can get it from your git tree.
>>
>> But Frankly I'd like to see them in list instead even with only small fixes
>> beacuse in this way there might be more people to review it carefully.
>
> There's another shorcoming for keeping new patches in git is that nobody know
> when you push it and when is the proper date to pull from your git. I think
> it's better to use git only for the patches which have already been accepted
> and is waiting for maintainer to pull.
>
You can use git for your own purposes, still.
-hpa
Dear Mr. Young,
On Thu, Oct 31, 2013 at 10:07:14AM +0800, Dave Young wrote:
> > But Frankly I'd like to see them in list instead even with only small fixes
> > beacuse in this way there might be more people to review it carefully.
>
> There's another shorcoming for keeping new patches in git is that nobody know
> when you push it and when is the proper date to pull from your git. I think
> it's better to use git only for the patches which have already been accepted
> and is waiting for maintainer to pull.
thank you for teaching me how to do kernel development!
The actual and real reason why I didn't send them yet is because I
didn't want to be that kaffeine-inflated dork who spams the lists every
other day with a new version of his patches.
I am running build smoketests now and will send the latest version of
the patchset later today so don't worry, the world will see them :)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Wed, Oct 30, 2013 at 08:07:45PM -0700, H. Peter Anvin wrote:
> You can use git for your own purposes, still.
git mk-coffee --refill --now
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 10/31/13 at 11:45am, Borislav Petkov wrote:
> On Wed, Oct 30, 2013 at 08:07:45PM -0700, H. Peter Anvin wrote:
> > You can use git for your own purposes, still.
>
> git mk-coffee --refill --now
Ccing Jonathan Corbet ;)
On 10/31/13 at 11:44am, Borislav Petkov wrote:
> Dear Mr. Young,
>
> On Thu, Oct 31, 2013 at 10:07:14AM +0800, Dave Young wrote:
> > > But Frankly I'd like to see them in list instead even with only small fixes
> > > beacuse in this way there might be more people to review it carefully.
> >
> > There's another shorcoming for keeping new patches in git is that nobody know
> > when you push it and when is the proper date to pull from your git. I think
> > it's better to use git only for the patches which have already been accepted
> > and is waiting for maintainer to pull.
>
> thank you for teaching me how to do kernel development!
>
> The actual and real reason why I didn't send them yet is because I
> didn't want to be that kaffeine-inflated dork who spams the lists every
> other day with a new version of his patches.
I need remind myself about careless patch, I used to do that before :(
>
> I am running build smoketests now and will send the latest version of
> the patchset later today so don't worry, the world will see them :)
Great, thank you. BTW, I have managed to test original patch set on a
Macboot Air of my friend with usb boot, it works ok.
--
Thanks
Dave