In message [off-list ref] you wrote:
quoted
initramfs is convenient. you don't need root access nor special tools
to create the root-fs. it very easy when you want to
version-controlled you root-fs.
ah, that would be convenient since, as it is, i'm using a hacked
version of "genext2fs" that allows me to create the initial root fs as
a regular user. i *definitely* have to look into initramfs, then.
What do you mean with "hacked"? Standard "genext2fs" will do this
just fine.
And as usual, there is two sides to initramfs. It may be convenient
for some cases, where you can use the very same root filesystem image
bundled with the kernel image, but exactly thsi convenience may hurt
you in other cases where it's much better when you have separated
images which can be updated independently of each other.
Speaking for myself: I don't see advantages in it. None.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
I used to be indecisive, now I'm not sure.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Mon, 19 Jul 2004, Wolfgang Denk wrote:
In message [off-list ref] you wrote:
quoted
quoted
initramfs is convenient. you don't need root access nor special tools
to create the root-fs. it very easy when you want to
version-controlled you root-fs.
ah, that would be convenient since, as it is, i'm using a hacked
version of "genext2fs" that allows me to create the initial root fs as
a regular user. i *definitely* have to look into initramfs, then.
What do you mean with "hacked"? Standard "genext2fs" will do this
just fine.
sadly for me, the version floating around doesn't build FIFOs (even
though the command-line options suggest it does). and i need FIFOs to
support minit. so i merged a couple different versions to get one
that handles the extended device file format (erik andersen's??), and
a small patch to handle FIFOs.
And as usual, there is two sides to initramfs. It may be convenient
for some cases, where you can use the very same root filesystem image
bundled with the kernel image, but exactly thsi convenience may hurt
you in other cases where it's much better when you have separated
images which can be updated independently of each other.
Speaking for myself: I don't see advantages in it. None.
i most likely wouldn't use it for the final build, but it would still
be more efficient for testing, rather than reflashing the root
filesystem on the unit every time. once the image is finalized, then
i can flash the kernel and rootFS separately.
rday
p.s. of course, this assumes GNU cpio can handle FIFOs. oops, better
check that.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On 19 Jul 2004, wd@denx.de wrote:
And as usual, there is two sides to initramfs. It may be convenient
for some cases, where you can use the very same root filesystem
image bundled with the kernel image, but exactly thsi convenience
may hurt you in other cases where it's much better when you have
separated images which can be updated independently of each other.
Maybe I missed some thing but:
- I'm using initramfs in my current project (2.6.7)
- I failed to see what in initramfs mechanism would prevent
one from having "separated images which can be updated
independently of each other."
Regards
--
L.D.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/