On Wed, Jun 3, 2015 at 2:24 AM, Ingo Molnar wrote:
> It's all pretty non-trivial, so it has to be finegrained, perfectly
> bisectable,
> etc.
Yeah. I'm not really going to be able to justify the time for that -
this is code that dates back a long way, there's undoubtedly
subtleties throughout an
* Matthew Garrett wrote:
> >> + while (c) {
> >> + set_fs(new_cmdline_ptr >> 4);
> >> + wrfs8(c, nptr++);
> >> + set_fs(cmdline_ptr >> 4);
> >> + c = rdfs8(cptr++);
> >> + }
> >> +
On Wed, May 20, 2015 at 12:42 AM, Ingo Molnar wrote:
> * Matthew Garrett wrote:
> Overall structure looks better now.
>
> One problem is that it's such a huge patch: is there a way to split
> this up into smaller, more obvious, easier to bisect to patches?
Ought to be possible.
> So could we pl
* Matthew Garrett wrote:
> The kernel supports having a command line built into it. Unfortunately
> this doesn't work in all cases - the built-in command line is only
> appended after we've jumped to the kernel proper, but various parts of
> the early boot process also pay attention to the comma
On Tue, May 12, 2015 at 07:46:11PM -0700, H. Peter Anvin wrote:
> On 05/12/2015 04:53 PM, Matthew Garrett wrote:
> > On Tue, May 12, 2015 at 04:41:22PM -0700, Yinghai Lu wrote:
> >
> >> You can not assume that you can use buffer after cmd_line from bootloader
> >> blindly.
> >
> > Are there any b
On 05/12/2015 04:53 PM, Matthew Garrett wrote:
> On Tue, May 12, 2015 at 04:41:22PM -0700, Yinghai Lu wrote:
>
>> You can not assume that you can use buffer after cmd_line from bootloader
>> blindly.
>
> Are there any bootloaders that don't allocate a buffer of the maximum
> command line size?
>
On Tue, May 12, 2015 at 04:41:22PM -0700, Yinghai Lu wrote:
> You can not assume that you can use buffer after cmd_line from bootloader
> blindly.
Are there any bootloaders that don't allocate a buffer of the maximum
command line size?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe
On Tue, May 12, 2015 at 11:42 AM, Matthew Garrett
wrote:
> Ok, maybe something more like this? It even gets rid of some of the
> #ifdefs in setup.c.
>
> diff --git a/arch/x86/boot/cmdline.c b/arch/x86/boot/cmdline.c
> index 625d21b..9ddffd0 100644
> --- a/arch/x86/boot/cmdline.c
> +++ b/arch/x86/b
Ok, maybe something more like this? It even gets rid of some of the
#ifdefs in setup.c.
diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
index 82fbdbc..22eaecf 100644
--- a/Documentation/x86/zero-page.txt
+++ b/Documentation/x86/zero-page.txt
@@ -12,6 +12,7 @@ Offset
On Tue, May 12, 2015 at 2:28 AM, Ingo Molnar wrote:
>
> * Matthew Garrett wrote:
>
>> Any feedback on this?
>
> So I worry about:
>
> - the fragmented nature of it: lots of non-obvious pieces of code
>will now be scattered all around arch/x86/.
We've got four different entry points and they
* Matthew Garrett wrote:
> Any feedback on this?
So I worry about:
- the fragmented nature of it: lots of non-obvious pieces of code
will now be scattered all around arch/x86/.
- the crazy #ifdefs scattered around
- the various pieces of data scattered around
... so while I don't min
Any feedback on this?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
12 matches
Mail list logo
