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

Arnout, Thierry, All,

On 2021-12-17 19:05 +0100, Arnout Vandecappelle spake thusly:

quoted

quoted

quoted

+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.

quoted

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]

quoted

quoted

quoted

+# 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