* [Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory @ 2019-03-18 16:30 Norbert Lange 2019-03-18 17:44 ` Yann E. MORIN 0 siblings, 1 reply; 7+ messages in thread From: Norbert Lange @ 2019-03-18 16:30 UTC (permalink / raw) To: buildroot For read-only root file systems, the kernel-modules will be mounted over this directory. This directory should always exist for this reason, just as /mnt and /opt are in the skeleton. Signed-off-by: Norbert Lange <norbert.lange@andritz.com> --- package/skeleton-init-common/skeleton-init-common.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/package/skeleton-init-common/skeleton-init-common.mk b/package/skeleton-init-common/skeleton-init-common.mk index e429b13d78..b39794eddc 100644 --- a/package/skeleton-init-common/skeleton-init-common.mk +++ b/package/skeleton-init-common/skeleton-init-common.mk @@ -20,6 +20,7 @@ define SKELETON_INIT_COMMON_INSTALL_TARGET_CMDS $(call SYSTEM_RSYNC,$(SKELETON_INIT_COMMON_PATH),$(TARGET_DIR)) $(call SYSTEM_USR_SYMLINKS_OR_DIRS,$(TARGET_DIR)) $(call SYSTEM_LIB_SYMLINK,$(TARGET_DIR)) + $(INSTALL) -d -m 0755 $(TARGET_DIR)/lib/modules $(SED) 's, at PATH@,$(BR2_SYSTEM_DEFAULT_PATH),' $(TARGET_DIR)/etc/profile $(INSTALL) -m 0644 support/misc/target-dir-warning.txt \ $(TARGET_DIR_WARNING_FILE) -- 2.20.1 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory 2019-03-18 16:30 [Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory Norbert Lange @ 2019-03-18 17:44 ` Yann E. MORIN 2019-03-18 18:11 ` Norbert Lange 0 siblings, 1 reply; 7+ messages in thread From: Yann E. MORIN @ 2019-03-18 17:44 UTC (permalink / raw) To: buildroot On 2019-03-18 17:30 +0100, Norbert Lange spake thusly: > For read-only root file systems, the kernel-modules > will be mounted over this directory. This does not mean anything. Either you build your kernel with Buildroot, and the kernel does the installation of modules in /lib/modules, and thus you do not need to create it, or you build your kernel outside of Buildroot and you install the modules at build time in there. So, having a read-only filesystem is of no consequence here. Also, I don;t see how "the kernel-modules will be mounted over this directory", which imply this is done at runtime. If your system uses special means to store the kernel modules, then it's your duty to provide it on your own, like as an overlay (or a specific package) that install those files/direcoties. > This directory should always exist for this reason, This is wrong: one can have a no-module kernel, in which case /lib/modules is useless. > just as /mnt and /opt are in the skeleton. Those are madanted by the FHS [0]. [0] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard. Regards, Yann E. MORIN. > Signed-off-by: Norbert Lange <norbert.lange@andritz.com> > --- > package/skeleton-init-common/skeleton-init-common.mk | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/package/skeleton-init-common/skeleton-init-common.mk b/package/skeleton-init-common/skeleton-init-common.mk > index e429b13d78..b39794eddc 100644 > --- a/package/skeleton-init-common/skeleton-init-common.mk > +++ b/package/skeleton-init-common/skeleton-init-common.mk > @@ -20,6 +20,7 @@ define SKELETON_INIT_COMMON_INSTALL_TARGET_CMDS > $(call SYSTEM_RSYNC,$(SKELETON_INIT_COMMON_PATH),$(TARGET_DIR)) > $(call SYSTEM_USR_SYMLINKS_OR_DIRS,$(TARGET_DIR)) > $(call SYSTEM_LIB_SYMLINK,$(TARGET_DIR)) > + $(INSTALL) -d -m 0755 $(TARGET_DIR)/lib/modules > $(SED) 's, at PATH@,$(BR2_SYSTEM_DEFAULT_PATH),' $(TARGET_DIR)/etc/profile > $(INSTALL) -m 0644 support/misc/target-dir-warning.txt \ > $(TARGET_DIR_WARNING_FILE) > -- > 2.20.1 > > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot -- .-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory 2019-03-18 17:44 ` Yann E. MORIN @ 2019-03-18 18:11 ` Norbert Lange 2019-03-18 19:03 ` Yann E. MORIN 0 siblings, 1 reply; 7+ messages in thread From: Norbert Lange @ 2019-03-18 18:11 UTC (permalink / raw) To: buildroot Am Mo., 18. M?rz 2019 um 18:44 Uhr schrieb Yann E. MORIN <yann.morin.1998@free.fr>: > > On 2019-03-18 17:30 +0100, Norbert Lange spake thusly: > > For read-only root file systems, the kernel-modules > > will be mounted over this directory. > > This does not mean anything. > > Either you build your kernel with Buildroot, and the kernel does the > installation of modules in /lib/modules, and thus you do not need to > create it, or you build your kernel outside of Buildroot and you install > the modules at build time in there. > > So, having a read-only filesystem is of no consequence here. > > Also, I don;t see how "the kernel-modules will be mounted over this > directory", which imply this is done at runtime. If your system uses > special means to store the kernel modules, then it's your duty to > provide it on your own, like as an overlay (or a specific package) that > install those files/direcoties. If you prepare a kernel with an builtin initramfs containing the modules and an initscript to mount those over /lib/modules, then you wont have to touch the root fs. (can be replaced independently of each other). > > > This directory should always exist for this reason, > > This is wrong: one can have a no-module kernel, in which case > /lib/modules is useless. One could also have nothing to use with /mnt, /media and /opt. > > just as /mnt and /opt are in the skeleton. > > Those are madanted by the FHS [0]. Ok, if I red that right, then /boot and /srv would be required/mandated aswell? I guess I wont get the change up-streamed, and thats fine (minor annoyance that I cant use verbatim buildroot's with such kernels). But this seems to be pretty arbitrary given that buildroot seems rather lenient otherwise (for good reasons). Norbert. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory 2019-03-18 18:11 ` Norbert Lange @ 2019-03-18 19:03 ` Yann E. MORIN 2019-03-18 20:43 ` Norbert Lange 0 siblings, 1 reply; 7+ messages in thread From: Yann E. MORIN @ 2019-03-18 19:03 UTC (permalink / raw) To: buildroot Norbert, All, On 2019-03-18 19:11 +0100, Norbert Lange spake thusly: > Am Mo., 18. M?rz 2019 um 18:44 Uhr schrieb Yann E. MORIN > <yann.morin.1998@free.fr>: > > On 2019-03-18 17:30 +0100, Norbert Lange spake thusly: > > > For read-only root file systems, the kernel-modules > > > will be mounted over this directory. > > > > This does not mean anything. > > > > Either you build your kernel with Buildroot, and the kernel does the > > installation of modules in /lib/modules, and thus you do not need to > > create it, or you build your kernel outside of Buildroot and you install > > the modules at build time in there. > > > > So, having a read-only filesystem is of no consequence here. > > > > Also, I don;t see how "the kernel-modules will be mounted over this > > directory", which imply this is done at runtime. If your system uses > > special means to store the kernel modules, then it's your duty to > > provide it on your own, like as an overlay (or a specific package) that > > install those files/direcoties. > > If you prepare a kernel with an builtin initramfs containing > the modules and an initscript to mount those over /lib/modules, > then you wont have to touch the root fs. > (can be replaced independently of each other). *That* is the real reason, and that's what you should have explained in your commit log. (Incidentally, I knew where this was coming from; I just wanted it to be explained by you, not I.) > > > This directory should always exist for this reason, > > This is wrong: one can have a no-module kernel, in which case > > /lib/modules is useless. > One could also have nothing to use with /mnt, /media and /opt. > > > > just as /mnt and /opt are in the skeleton. > > Those are madanted by the FHS [0]. > Ok, if I red that right, then /boot and /srv would be required/mandated aswell? "red"? But who am I for pointing at others typoes? Hehe! ;-) And sorry, I wrote "mandated" (with typoes, at that), when I should have written "documented". So, I was just pointing out that /mnt and /opt do have some standard backing them, while /lib/modules does not, and thus /lib/modules does not have to "always exist like /mnt/ or /opt" as you wrote. Additionally, if one is building a filesystem (possibly readonly) to run in a container, they'd probably have no use for /lib/modules either. So, again, /lib/modules does not *have* to always exist. > I guess I wont get the change up-streamed, and thats fine (minor annoyance > that I cant use verbatim buildroot's with such kernels). As I said, you need not do that in skeleton. You can do it in an overlay, or as a custom package, or even as a custom skeleton. And if you do not want to "pollute" your Buildroot tree with your custom stuff, you can host it in a br2-external tree, for example. My professional alter-ego gave a talk about that some time ago: https://elinux.org/images/8/8e/2017-10-24_-_ELCE-Buildroot.pdf And Arnout wrote a nice summary of the presentation: https://mindlinux.wordpress.com/2017/10/24/buildroot-making-embedded-linux-easy-a-real-life-example-yann-morin-orange/ > But this seems > to be pretty arbitrary given that buildroot seems rather lenient > otherwise (for good reasons). Given the proper explanations for a change, we'd consider it, yes. But I just pointed out that your explanations were not correct/accurate, as the conditions you *described* did not *require* that change. The explanations above is the real reason, and that is what you have said in your commit log instead, and that would have given it a better chance to get applied. And yes, drawing the boundary line is arbitrary at times. 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. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory 2019-03-18 19:03 ` Yann E. MORIN @ 2019-03-18 20:43 ` Norbert Lange 2019-03-19 17:57 ` Arnout Vandecappelle 0 siblings, 1 reply; 7+ messages in thread From: Norbert Lange @ 2019-03-18 20:43 UTC (permalink / raw) To: buildroot Am Mo., 18. M?rz 2019 um 20:03 Uhr schrieb Yann E. MORIN <yann.morin.1998@free.fr>: > > Norbert, All, > > On 2019-03-18 19:11 +0100, Norbert Lange spake thusly: > > Am Mo., 18. M?rz 2019 um 18:44 Uhr schrieb Yann E. MORIN > > <yann.morin.1998@free.fr>: > > > On 2019-03-18 17:30 +0100, Norbert Lange spake thusly: > > > > For read-only root file systems, the kernel-modules > > > > will be mounted over this directory. > > > > > > This does not mean anything. > > > > > > Either you build your kernel with Buildroot, and the kernel does the > > > installation of modules in /lib/modules, and thus you do not need to > > > create it, or you build your kernel outside of Buildroot and you install > > > the modules at build time in there. > > > > > > So, having a read-only filesystem is of no consequence here. > > > > > > Also, I don;t see how "the kernel-modules will be mounted over this > > > directory", which imply this is done at runtime. If your system uses > > > special means to store the kernel modules, then it's your duty to > > > provide it on your own, like as an overlay (or a specific package) that > > > install those files/direcoties. > > > > If you prepare a kernel with an builtin initramfs containing > > the modules and an initscript to mount those over /lib/modules, > > then you wont have to touch the root fs. > > (can be replaced independently of each other). > > *That* is the real reason, and that's what you should have explained in > your commit log. > > (Incidentally, I knew where this was coming from; I just wanted it to be > explained by you, not I.) I did not want to be too specific, but the basic idea is to separate the lowlevel stuff (kernel, -modules and initramfs) from a read-only OS-image. My usecase is the above, primary because I have to stick the lowlevel stuff into onboard storage, then load the rootfs. Doing some small maintainance scripts in intramfs is preferable than having to mess with the rootfs all time. Next thing would be "UsrMerge" and OS-as-usr-subdirectory. the kernel modules in /lib/modules (/usr/lib/modules) is in the way there too. > > > > This directory should always exist for this reason, > > > This is wrong: one can have a no-module kernel, in which case > > > /lib/modules is useless. > > One could also have nothing to use with /mnt, /media and /opt. > > > > > > just as /mnt and /opt are in the skeleton. > > > Those are madanted by the FHS [0]. > > Ok, if I red that right, then /boot and /srv would be required/mandated aswell? > > "red"? But who am I for pointing at others typoes? Hehe! ;-) yeah, by making me explain things thoroughly, your evil scheme for more tiptoes worked ;) > > And sorry, I wrote "mandated" (with typoes, at that), when I should have > written "documented". So, I was just pointing out that /mnt and /opt do > have some standard backing them, while /lib/modules does not, and thus > /lib/modules does not have to "always exist like /mnt/ or /opt" as you > wrote. err.. look at FHS Section 3.9.3. > Additionally, if one is building a filesystem (possibly readonly) to run > in a container, they'd probably have no use for /lib/modules either. So, > again, /lib/modules does not *have* to always exist. nope, there's just the question of how-much-it-helps vs how-much-it-hurts. building everything static would make /lib empty and unused as well, the cost of having it around always is reasonably low. > > I guess I wont get the change up-streamed, and thats fine (minor annoyance > > that I cant use verbatim buildroot's with such kernels). > > As I said, you need not do that in skeleton. You can do it in an > overlay, or as a custom package, or even as a custom skeleton. And if > you do not want to "pollute" your Buildroot tree with your custom stuff, > you can host it in a br2-external tree, for example. My professional > alter-ego gave a talk about that some time ago: > https://elinux.org/images/8/8e/2017-10-24_-_ELCE-Buildroot.pdf > > And Arnout wrote a nice summary of the presentation: > https://mindlinux.wordpress.com/2017/10/24/buildroot-making-embedded-linux-easy-a-real-life-example-yann-morin-orange/ sure, getting it upstream is still the best bet. > > But this seems > > to be pretty arbitrary given that buildroot seems rather lenient > > otherwise (for good reasons). > > Given the proper explanations for a change, we'd consider it, yes. But I > just pointed out that your explanations were not correct/accurate, as > the conditions you *described* did not *require* that change. The > explanations above is the real reason, and that is what you have said in > your commit log instead, and that would have given it a better chance to > get applied. > > And yes, drawing the boundary line is arbitrary at times. No problem with that. Should I re-roll the patch next, or can we continue this discussion until you decide on whether you will include the change. Norbert ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory 2019-03-18 20:43 ` Norbert Lange @ 2019-03-19 17:57 ` Arnout Vandecappelle 2019-03-19 20:57 ` Peter Korsgaard 0 siblings, 1 reply; 7+ messages in thread From: Arnout Vandecappelle @ 2019-03-19 17:57 UTC (permalink / raw) To: buildroot On 18/03/2019 21:43, Norbert Lange wrote: > Should I re-roll the patch next, or can we continue this discussion > until you decide on whether you will include the change. For me as well, the direction should be to remove things from the skeleton rather than adding to it. So if you would get rid of /media etc. I'd maybe be in favour of it, but I'm certainly not going to defend adding yet another directory. I'll add Peter in Cc to draw a line in the sand. Regards, Arnout ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory 2019-03-19 17:57 ` Arnout Vandecappelle @ 2019-03-19 20:57 ` Peter Korsgaard 0 siblings, 0 replies; 7+ messages in thread From: Peter Korsgaard @ 2019-03-19 20:57 UTC (permalink / raw) To: buildroot >>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: > On 18/03/2019 21:43, Norbert Lange wrote: >> Should I re-roll the patch next, or can we continue this discussion >> until you decide on whether you will include the change. > For me as well, the direction should be to remove things from the skeleton > rather than adding to it. So if you would get rid of /media etc. I'd maybe be in > favour of it, but I'm certainly not going to defend adding yet another directory. > I'll add Peter in Cc to draw a line in the sand. I'm with Arnout here. Buildroot has always been about minimalism, so having extra things just-in-case isn't really nice. If you really want to, you can create extra directories in the target without any buildroot customizations, just call mkdir as a post-build script: BR2_ROOTFS_POST_BUILD_SCRIPT="mkdir" BR2_ROOTFS_POST_SCRIPT_ARGS="-p $(TARGET_DIR)/path/to/somewhere" -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-03-19 20:57 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-18 16:30 [Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory Norbert Lange 2019-03-18 17:44 ` Yann E. MORIN 2019-03-18 18:11 ` Norbert Lange 2019-03-18 19:03 ` Yann E. MORIN 2019-03-18 20:43 ` Norbert Lange 2019-03-19 17:57 ` Arnout Vandecappelle 2019-03-19 20:57 ` Peter Korsgaard
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.