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

[Daniel Golle]

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)

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

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

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

Anyone?


Cheers


Daniel

> 
> -- ynezz

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel