Re: list of 2.6-related migration issues for embedded programmers?

In message [off-list ref] you wrote:

But you don't have to. What ever you can do with the good-old initrd
image you can do with the new initramfs (really cpio archive)
image. The main difference is the creation: genext2fs vs cpio.

How do I populate a  initramfs  with  custom  device  nodes?  Without
having root permission, I mean.

And how can I tell a Linux kernel where to find  the  initramfs  data
when they are not linked together?

I just happen to use zImage.initrd (where ramdisk.image.gz is a cpio
archive) in our project because it's the most appropriate for our
situation.

That's OK. Other projects may have different requirements, though.

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
You cannot propel yourself forward by patting yourself on the back.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On 20 Jul 2004, wd@denx.de wrote:

In message [off-list ref] you wrote:

quoted

But you don't have to. What ever you can do with the good-old
initrd image you can do with the new initramfs (really cpio
archive) image. The main difference is the creation: genext2fs vs
cpio.

How do I populate a initramfs with custom device nodes?  Without
having root permission, I mean.

You have a point here, I guess with initramfs you have to:

 - use devfs (which was deprecated in 2.6)
 - use udev
 - grok-sysfs-yourself (which is pretty easy)

And how can I tell a Linux kernel where to find the initramfs data
when they are not linked together?

Well, the same way as with the good old-initrd. the initramfs root-fs
IS an INITRD in compressed-cpio format (instead of fs format such as
ext2).


me think I'm still missing something about initrd.


Regards

--
L.D.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/