Re: [PATCH 2/2] arc770: move arc patches to taregt/linux/generic
> "Felix" == Felix Fietkau writes: >>> OpenWrt works just fine without DEVTMPFS - doesn't matter if initramfs >>> is enabled or not. >> >> The discussion is about adding a patch to up upstream ARC kernel, not >> specific to >> openwrt. > Right. I belive that the upstream kernel should not arbitrarily force > DEVTMPFS support for some architectures, as long as there are user space > implementations (such as OpenWrt) that can do without it. Agreed, only the options absolutely needed should be forced on. >> BTW if openwrt builds for initramfs, it has to enable DEVTMPFS under the >> hood. >> Perhaps there are dependencies in openwrt build system which take care of >> that >> already - o/w it just won't work (assuming dynamic dev nodes). > Incorrect. OpenWrt does not use DEVTMPFS, it does not even get compiled > into the image. We would like to keep it that way. > Our user space takes care of creating all required device nodes very > early during boot. Out of interest, why is that? Devtmpfs got added 7 years ago (2.6.32) - And is easy to backport if really needed, is easier and more flexible than a bunch of static mknods, and probably smaller as well. We changed to devtmpfs by default in Buildroot quite some time ago, and I'm pretty happy with it. -- Venlig hilsen, Peter Korsgaard ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/2] arc770: move arc patches to taregt/linux/generic
On 2016-01-16 11:35, Peter Korsgaard wrote: >> "Felix" == Felix Fietkau writes: > > >>> OpenWrt works just fine without DEVTMPFS - doesn't matter if initramfs > >>> is enabled or not. > >> > >> The discussion is about adding a patch to up upstream ARC kernel, not > specific to > >> openwrt. > > Right. I belive that the upstream kernel should not arbitrarily force > > DEVTMPFS support for some architectures, as long as there are user space > > implementations (such as OpenWrt) that can do without it. > > Agreed, only the options absolutely needed should be forced on. > > >> BTW if openwrt builds for initramfs, it has to enable DEVTMPFS under the > hood. > >> Perhaps there are dependencies in openwrt build system which take care of > that > >> already - o/w it just won't work (assuming dynamic dev nodes). > > Incorrect. OpenWrt does not use DEVTMPFS, it does not even get compiled > > into the image. We would like to keep it that way. > > Our user space takes care of creating all required device nodes very > > early during boot. > > Out of interest, why is that? Devtmpfs got added 7 years ago (2.6.32) - > And is easy to backport if really needed, is easier and more flexible > than a bunch of static mknods, and probably smaller as well. We don't need to backport anything. Our oldest kernel is 3.18, and we're going to move everything to 4.4 soon ;) > We changed to devtmpfs by default in Buildroot quite some time ago, and > I'm pretty happy with it. We need to have dynamically created device nodes anyway - for managing permissions, being able to change names, etc. Because of that, devtmpfs is not enough to provide a full /dev. Since it's not enough, and creating the initial device nodes from our custom init is easy, we see little value in keeping it. So we got rid of the extra bloat :) - Felix ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/2] arc770: move arc patches to taregt/linux/generic
> "Felix" == Felix Fietkau writes: Hi, >> Out of interest, why is that? Devtmpfs got added 7 years ago (2.6.32) - >> And is easy to backport if really needed, is easier and more flexible >> than a bunch of static mknods, and probably smaller as well. > We don't need to backport anything. Our oldest kernel is 3.18, and we're > going to move everything to 4.4 soon ;) Good! >> We changed to devtmpfs by default in Buildroot quite some time ago, and >> I'm pretty happy with it. > We need to have dynamically created device nodes anyway - for managing > permissions, being able to change names, etc. Because of that, devtmpfs > is not enough to provide a full /dev. Since it's not enough, and > creating the initial device nodes from our custom init is easy, we see > little value in keeping it. So we got rid of the extra bloat :) Heh, "bloat": arm-none-eabi-size drivers/base/devtmpfs.o textdata bss dec hex filename 1568 64 41636 664 drivers/base/devtmpfs.o Compared to the extra inodes and/or the busybox mknod applet + script, it isn't too bad. In Buildroot we support pure devtmpfs, mdev or udev (both with devtmpfs) or static /dev for legacy setups. -- Venlig hilsen, Peter Korsgaard ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/2] arc770: move arc patches to taregt/linux/generic
On 2016-01-16 12:00, Peter Korsgaard wrote: > >> We changed to devtmpfs by default in Buildroot quite some time ago, and > >> I'm pretty happy with it. > > We need to have dynamically created device nodes anyway - for managing > > permissions, being able to change names, etc. Because of that, devtmpfs > > is not enough to provide a full /dev. Since it's not enough, and > > creating the initial device nodes from our custom init is easy, we see > > little value in keeping it. So we got rid of the extra bloat :) > > Heh, "bloat": > > arm-none-eabi-size drivers/base/devtmpfs.o >textdata bss dec hex filename >1568 64 41636 664 drivers/base/devtmpfs.o > > Compared to the extra inodes and/or the busybox mknod applet + script, > it isn't too bad. I know it's not much, but we do like to disable anything that's completely useless for our purposes. :) Our code doesn't use busybox mknod. The stuff that creates the device nodes is written in C. > In Buildroot we support pure devtmpfs, mdev or udev (both with devtmpfs) > or static /dev for legacy setups. Yeah, for Buildroot devtmpfs makes sense. We don't use or support mdev, udev or static /dev. We also got rid of hotplug2 a while back ;) - Felix ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
