Roland McGrath <[EMAIL PROTECTED]> writes:
>> In boot, we incorrectly setup the default kernel_command_line.
>
> Eh? Isn't the kernel's name part of a real kernel command line?
This is correct. Thus, we are looking at a different bug; in the
general case, we only pass options to init when usin
> There was a problem with the output.
Well then you should have described it in your bug report!
> I think that the problem what I was seeing is that the strings are
> generally longer than 80 characters. Thus, they wrap onto the next
> line. In fact, the first module that is loaded on my sys
>> This patch also corrects the output: I have no clue what the padding with
>> spaces was all about, however, it seems to me to be completely
>> superfluous; the output is now consistent with other messages.
>
> Was there a problem with the output, or is this an aesthetic change?
There was a p
> In boot, we incorrectly setup the default kernel_command_line.
Eh? Isn't the kernel's name part of a real kernel command line?
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
> I have confirmed that the following combinations, first with your code
> and then, with my new patches, work:
Thanks!
> > [subhurd] new hurd's boot -> old boot script -> old hurd
>
> Check. However, I fail to see why we even want to be compatible here;
My rationale was that one might want t
I have confirmed that the following combinations, first with your code
and then, with my new patches, work:
> new gnumach -> new hurd's serverboot -> new hurd
Check.
> new gnumach -> old hurd's serverboot -> old hurd
Check.
> old gnumach -> new hurd's serverboot -> new hurd
Check.
> new gnu