devil-linux-develop

[Devil-linux-develop] initramfs

[Serge L. <fi...@in...>]

Hello,

I've implemented initramfs support for DL (only for syslinux yet). This feature
is optional and breaks nothing but I'd like to have a tiny round of testing
before checking in.

So, volunteers are wanted!

--
Serge

Re: [Devil-linux-develop] initramfs

[Bruce S. <br...@ar...>]

> I've implemented initramfs support for DL (only for syslinux yet). This feature
> is optional and breaks nothing but I'd like to have a tiny round of testing
> before checking in.

I'm not familiar with initramfs.  Explain?

 - BS

Re: [Devil-linux-develop] initramfs

[Bruce S. <br...@ar...>]

> >> I've implemented initramfs support for DL (only for syslinux yet). This feature
> >> is optional and breaks nothing but I'd like to have a tiny round of testing
> >> before checking in.
> > 
> > I'm not familiar with initramfs.  Explain?
> I'm sure you are familiar ;-) because all current Linux distributions uses it.

Just because someone uses something, they are not necessarily familiar
with the technology.  :-)

I could state tons of examples of how people use technology every day,
but are not familiar with the technology.  Looking at my desk, I'm using
a flat panel monitor and an optical mouse right now.  I know how to buy
them, connect them to my computer, and USE them, but I have now idea how
they actually work internally.  ;-)

> To not confuse you my poor English, I copied the information from the wiki page:
> 
> http://en.wikipedia.org/wiki/Initrd

Hum, I wonder if wikipedia explains how flat panel monitors and optical
mice work ...  Thanks!  ;-)

BTW, if your system boots and runs fine with initramfs, I'm OK if you
check in the changes.  We can work through any bugs that come up.
(that's what I did with aufs! :)  1.3 is still a development release.

 - BS

Re: [Devil-linux-develop] initramfs

[Serge L. <fi...@in...>]

Bruce Smith wrote:

> Just because someone uses something, they are not necessarily familiar
> with the technology.  :-)
 Yes, you are right. :-) There are a lot of habitual things about which
internals I know nothing....

> I could state tons of examples of how people use technology every day,
> but are not familiar with the technology.  Looking at my desk, I'm using
> a flat panel monitor and an optical mouse right now.  I know how to buy
> them, connect them to my computer, and USE them, but I have now idea how
> they actually work internally.  ;-)
If I have a chance to invite you for several pints of beer and you still be
interested in theoretical basis of LCD panel and optical mouse operation I'll be
happy to share my knowledge!  :-)))


> BTW, if your system boots and runs fine with initramfs, I'm OK if you
> check in the changes.  We can work through any bugs that come up.
> (that's what I did with aufs! :)  1.3 is still a development release.
Certainly. My system boots correctly. The current realization is a bit more
complicated than could be, but it's the result of backward compatibility with
initrd.

Well, if nobody has objections I'll check in the initramfs support patch.

--
Serge

Re: [Devil-linux-develop] initramfs

[Serge L. <fi...@in...>]

Bruce Smith wrote:
>> I've implemented initramfs support for DL (only for syslinux yet). This feature
>> is optional and breaks nothing but I'd like to have a tiny round of testing
>> before checking in.
> 
> I'm not familiar with initramfs.  Explain?
I'm sure you are familiar ;-) because all current Linux distributions uses it.
To not confuse you my poor English, I copied the information from the wiki page:

http://en.wikipedia.org/wiki/Initrd

Initramfs in comparison with initrd

initramfs is an alternative, simpler method of having files available at boot
time without having them in a persistent mountable filesystem.

With initrd, the kernel creates a memory-backed block device, loads it with data
from a file, then mounts the device to create a filesystem image. With
initramfs, the kernel creates a filesystem image directly from a file, without
involving any block device. [2]

With initrd, the file contains a filesystem in on-disk format, while with
initramfs, the file contains a compressed cpio archive. That means it is more
convenient for a system builder to create and modify the contents of the
filesystem with initramfs. With initramfs, there is no mounting, unmounting, and
loop device involved. There is no privileged system operation at all.

With initramfs, the filesystem is typically a tmpfs, shmfs, or ramfs filesystem.
These filesystem types did not exist when initrd became popular, and that
history is usually the reason that initrd is used instead of initramfs.

The boot-time operation of initrd is slightly simpler than that of initramfs.
With initrd, the boot loader copies the filesystem directly from the file to the
memory that backs a ramdisk, then the kernel need only define a ramdisk over
that same memory and do a standard filesystem mount. With initramfs, there are
equivalent steps to get the cpio archive into memory and create a filesystem
image, plus an additional procedure to unpack the cpio archive into the new
filesystem image. The kernel must know the cpio archive format. Some of the
computation that happens at build time with initrd happens at boot time with
initramfs.

--
Serge