[OpenWrt-Devel] [PATCH] config: enable some useful features on !SMALL_FLASH devices

Mon Jan 7 05:51:41 EST 2019

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 <daniel at makrotopia.org> [2019-01-01 17:56:25]:
>>
>> Hi,
>>
>>> On Sun, Dec 30, 2018 at 11:26:58AM +0100, Petr Štetiar wrote:
>>>> Daniel Golle <daniel at 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.lists at 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 at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel