Re: [Buildroot] [PATCH 3/3] fs/dracut: new fs type

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Arnout, Thierry, All,

On 2021-12-17 19:05 +0100, Arnout Vandecappelle spake thusly:
> >>>+if BR2_TARGET_ROOTFS_DRACUT
> >>>+config BR2_TARGET_ROOTFS_DRACUT_CONF_FILE
> >>>+    string "configuration file"
> >> Is there a possibility for a default configuration file?
> >Would that really make sense ? What would be default the expected packages
> >in the ram disk ?
>  Yeah, OK, good point...

Agreed, there can't be a reasonable default.

> >Notice that the content of the config file strongly depends on the init
> >system (dracut being mostly
> >thought for systemd, but I use it with busybox/init.d in my case).
> >But I agree that I must add an error in the .mk when the file is not
> >specified/does not exist

Yes, catching that nicely would be better. What we usually do is:

    ifeq ($(BR_DUILDING).$(BR2_TARGET_ROOTFS_DRACUT_CONF_FILE),y.)
    $(error No file specified in BR2_TARGET_ROOTFS_DRACUT_CONF_FILE)
    endif

And if the file is missing, then presumably dracut will exit in error,
which is sufficient for me.

> [snip]
> >>>+# devtmpfs does not get automounted when initramfs is used.
> >>>+# Add a pre-init script to mount it before running init
> >>>+# We must have /dev/console very early, even before /init runs,
> >>>+# for stdin/stdout/stderr
> >>>+define ROOTFS_DRACUT_ADD_INIT
> >>>+    if [ ! -e $(TARGET_DIR)/init ]; then \
> >>>+        $(INSTALL) -m 0755 fs/cpio/init $(TARGET_DIR)/init; \
> >>>+    fi
> >>>+    mkdir -p $(TARGET_DIR)/dev
> >>>+    mknod -m 0622 $(TARGET_DIR)/dev/console c 5 1
> >>>+endef
> >>>+
> >>>+endif # BR2_ROOTFS_DEVICE_CREATION_STATIC
> >>
> >> The above is the same logic as in cpio.mk. It would be better if we
> >>could refactor that to a common place.
> >
> >I definitively agree, that is what I said myself. But what is the most
> >appropriate place to put it ?
> 
>  I wouldn't be opposed to putting it in fs/common.mk. Yann, what do you think?

Not sure. Usually, we try not to comonalise things until we have at
least a few users.

In  this case, it is very improbably that we have enough users to
warrant common code, so duplication is still OK in my opinion.

However...

>  I am, however, thinking something else as well. What does the dracut fs
> produce? Is it a cpio image? If so, then it might be a good idea to instead
> make this a suboption of cpio. This, in turn, would make it possible to use
> dracut for an initramfs.

This was to be my proposal too: extends the existing fs/cpio to
optionally use dracut to prepare the file list.

I was wondering why we did not just hand over such a list to cpio
(replacing the existing 'find'). But dracut is more than jsut a file
list: it presumably knows how to handle library dependencies (NEEDED)
and follows recursively, and similarly for kernel modules. Otherwise,
dracut would be of very little interest...

(I see that Thierry also replied, but I was not on Cc so I nearly missed
it... I'll reply further to Thierry message in a moment...)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot