Thank you all for your quick responses!
I want to add some of my comments.
1. Kernel parameters is a great mechanism to control how the kernel
behaves without modifying any file in kernel,
putting options in a file maybe seems a good solution... but it lower
the power of the boot loader,
which can be used to control the kernel externally.
So I think we should solve the 256 limitation... And not adding a new
mechanism.
2. As I understand initramfs gradually replaces initrd, since all the
user space applications needs initramfs,
So modifying the initramfs to be different at each machine is not good
for maintenance, and not easy to
control as editing its contents as in the boot loader approach.
3. Adding the maximum limit as configuration option is needed since the
kernel allocates a static memory buffer,
As such, it should be determined... I think the default should be at
least 1024... But I don't like
hard coded constants to be written in source.
4. "The concept of a command-line works for passing simple state but for
more complex things it's too cumbersome."
I don't agree with that... the term "simple" is user defined...
For example, I use the command-line to do the following:
a. Report kernel of my root partition.
b. Report kernel of my root partition type.
c. Report my initramfs of my swap partition, boot partition, root partition.
d. Report my initramfs of where to find decryption key.
e. Report kernel+initramfs of which bootsplash to use and what resolution.
f. Set my initramfs debug level.
g. Set silent console output tty.
h. Set initial loop device number for decryption.
This all must happen at boot, and I needed to squeeze the names of the
arguments in
order them to feet 256 limitation...
Does it fall in the "simple definition"?
5. In order for Lilo and Grub to implement the 2.02+ protocol without
truncating the command line,
I need a definite response that they should not do that... Can you
please provide it...?
It would be best if you update the boot.txt document.
Since without boot loader support, we cannot break this limitation for
ordinary users.
6. A minor issue... Why the COMMAND_LINE_SIZE is defined in two files?
Is there a specific reason?
Best Regards,
Alon Bar-Lev.
H. Peter Anvin wrote:
Jesper Juhl wrote:
Well, it wouldn't have to be initrd specifically. Generally what's
needed is *some* way to tell the kernel "please read more options from
location <foo>". The interresting bit is what <foo>'s supposed to be.
This is what initramfs (as opposed to initrd) does quite well.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |