On 2019-01-07 4:03 a.m., Daniel Golle wrote: > On Tue, Jan 01, 2019 at 08:46:25PM +0100, Petr Štetiar wrote: >> Daniel Golle <dan...@makrotopia.org> [2019-01-01 17:56:25]: >> >> Hi, >> >>> On Sun, Dec 30, 2018 at 11:26:58AM +0100, Petr Štetiar wrote: >>>> Daniel Golle <dan...@makrotopia.org> [2018-12-29 06:51:32]: >>>> >>>>> config KERNEL_AIO >>>>> config KERNEL_FHANDLE >>>>> config KERNEL_FANOTIFY >>>>> + default y if !SMALL_FLASH >>>> What about `FEATURES += nas` to make it clear and don't abuse SMALL_FLASH. >>> This is not necessarily only used on NAS devices. systemd requires >>> FHANDLE and FANOTIFY (eg. when running inside LXC container), lvm2 >>> needs AIO. Both could well run on a modern router or SBC having USB or >>> an SDCARD slot. >> to me it's still just NAS and container use cases. I'm afraid, that adding >> more bloat to kernels for devices with USB and MMC/SD card slots would be >> rejected also. > Well, most modern routers come with USB and/or MMC/SD and Samba > installed in their stock-rom. Apart from that, a lot of useful things > can be done with network namespaces -- we are just not implementing > them because the kernel doesn't have that feature enabled. > (think: have some service connect over VPN, others directly over WAN) > I think really small devices are rare now...and that's what SMALL_FLASH is for (perhaps quantify SMALL would be better though).
>>>>> config KERNEL_CGROUPS >>>>> config KERNEL_CPUSETS >>>>> config KERNEL_CGROUP_CPUACCT >>>>> config KERNEL_RESOURCE_COUNTERS >>>>> config KERNEL_MEMCG >>>>> config KERNEL_MEMCG_KMEM >>>>> menuconfig KERNEL_CGROUP_SCHED >>>>> config KERNEL_FAIR_GROUP_SCHED >>>>> config KERNEL_RT_GROUP_SCHED >>>>> config KERNEL_NAMESPACES >>>>> config KERNEL_LXC_MISC >>>>> config KERNEL_SECCOMP_FILTER >>>>> config KERNEL_SECCOMP >>>>> - default n >>>>> + default y if !SMALL_FLASH >>>> What about `FEATURES += containers` ? >>> From what I understood FEATURES is supposed to reflect hardware >>> capabilities >> Well, almost. I've found `squashfs` and `ext4` in there also. > True, and I don't think those two symbols make sense when talking > about FEATURES -- all devices do support squashfs without exception, > ext4 can only work on block-type storage, ie. devices booting from > (e)MMC or a SATA drive. So imho we could drop the squashfs symbol > and replace ext4 with a 'block_root' feature which imho would be > more meaningful. +1 >>> -- all the above are generic software features useful on any device having >>> the capacity (ie. flash and RAM) to make use of them. >> But as other Daniel already suggested, !SMALL_FLASH isn't proper group >> selection either. Speaking about the capacity, did you measured how much >> those >> features add to the kernel images? >> >>>> Daniel Engberg <daniel.engberg.li...@pyret.net> [2018-12-30 10:21:46]: >>>> >>>>> however KERNEL_CGROUPS, config KERNEL_NAMESPACES, config KERNEL_LXC_MISC, >>>>> KERNEL_SECCOMP_FILTER are very limited use cases to my knowledge and more >>>>> or >>>>> less only used on x86*? >>>> There are other quite powerful platforms like mvebu, imx6, ipq etc. where >>>> you >>>> could use this as well. >>> I use LXC on oxnas/ox820 (ARM11mpcore) and ramips/mt7621 (MIPS1004Kc), >> Ok, looking at IMAGE_SIZE values for mt7621 yields following results: >> >> IMAGE_SIZE := 6016k TP-LINK RE350 v1 >> IMAGE_SIZE := 7798784 I-O DATA WN-GX300GR >> IMAGE_SIZE := $(ralink_default_fw_size_4M) MT7621 EVB >> IMAGE_SIZE := $(ralink_default_fw_size_8M) AP-MT7621A-V60 EVB >> >> So it wouldn't be wise to add more bloat into kernels for those devices. > I don't think adding ~ 100kb to devices with 8MB of flash or more is a > problem. Regarding that evaluation board with only 4MB of NOR flash: > this is not a real-world device but rather an evalution platform, so > I wouldn't care much about users having to build their own stripped- > down version for that, because it's probably only a few hundred of > those EVBs ever made and most of them are by now collecting dust on > a shelf and will never be used for anything again. +1 >>> running Debian inside LXC containers (and it's annoying that I can't >>> use regular OpenWrt releases or buildbot-generated snapshots on the). >> I would like to do the same, but on the other hand I also understand, why >> your >> patch as it is wouldn't be accepted. Our containers/NAS use cases are still >> very rare, thus it makes no sense to enable those features by default to >> every >> other !SMALL_FLASH target. As you can see on mt7621, it's not marked as >> SMALL_FLASH, yet there are devices which might be considered SMALL_FLASH. > One. The MT7621 EVB. The TP-LINK RE350 v1 can probably be converted to > a more sane flash partition layout to gain another megabyte or so. > >> Now I realize, that it couldn't be handled with FEATURES anyway, as this is >> always too broad group selection and ideally you want to enable those >> features >> for specific devices only, meaning different kernels, images etc. > Why specific devices? Wouldn't all devices with the resources (which > boils down to !SMALL_FLASH) be potentially more useful with those > kernel features enabled? And as a side-effect: the OpenWrt kernel > also becoming useful for non-OpenWrt userland... > > But I'd really like to hear some more opinions on that and find a > solution which would allow using LVM2 and LXC with our release- > binaries -- containers with network-functions are becoming more > common and I know first hand that this is a reason for businesses > I have been working for to switch over to OpenEmbedded instead > of OpenWrt (and then hire people like me to port all the OpenWrt > stuff they need into their OE build...). I am definitely agreement and I can point to https://github.com/openwrt/openwrt/pull/1713#issuecomment-451359902 (and other comments in that PR) where there is a new contributor who definitely echos the sentiment expressed here. Regards, Daniel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
