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

Daniel Golle daniel at makrotopia.org
Mon Jan 7 09:20:51 EST 2019


On Mon, Jan 07, 2019 at 01:17:34PM +0000, Jonas Gorski wrote:
> On Mon, 7 Jan 2019 at 11:42, Petr Štetiar <ynezz at true.cz> wrote:
> >
> > Daniel Golle <daniel at makrotopia.org> [2019-01-07 10:03:09]:
> >
> > Hi,
> >
> > > 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.
> >
> > I've looked only at mt7621, so this was just example from one subtarget of
> > ramips target. So I tend to believe, that there's quite more such cases hidden
> > in the tree. Please correct me if I'm wrong.
> >
> > > 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?
> >
> > You currently can't use !SMALL_FLASH, because this is target/subtarget
> > specific feature, not per device feature. I think, that in order to use this
> > feature, you would need to convert/fix all devices like that TP-Link RE350
> > from all (sub)targets into tiny subtarget and then you could freely use
> > !SMALL_FLASH.
> 
> I agree with not abusing small_flash for that. It has a clear defined
> meaning, and shouldn't have unrelated side effects.

So what else would the SMALL_FLASH symbol be used for then?
A quick grep reveals that currently already quite a few kernel config
defaults are set according to SMALL_FLASH, see

origin/master:Config-kernel.in-
origin/master:Config-kernel.in-config KERNEL_SWAP
origin/master:Config-kernel.in- bool "Support for paging of anonymous memory (swap)"
origin/master:Config-kernel.in: default y if !SMALL_FLASH
--
origin/master:Config-kernel.in-
origin/master:Config-kernel.in-config KERNEL_KALLSYMS
origin/master:Config-kernel.in- bool "Compile the kernel with symbol table information"
origin/master:Config-kernel.in: default y if !SMALL_FLASH
--
origin/master:Config-kernel.in-
origin/master:Config-kernel.in-config KERNEL_DEBUG_INFO
origin/master:Config-kernel.in- bool "Compile the kernel with debug information"
origin/master:Config-kernel.in: default y if !SMALL_FLASH
--
origin/master:Config-kernel.in-config KERNEL_ELF_CORE
origin/master:Config-kernel.in- bool "Enable process core dump support"
origin/master:Config-kernel.in- select KERNEL_COREDUMP
origin/master:Config-kernel.in: default y if !SMALL_FLASH
...

> 
> I think a new opt-in symbol for those targets with hardware
> virtualization support and/or beefy enough cpus would make more sense.
> Those virtualization options (probably) don't come for free, they will
> have also a memory and performance impact even when not actively used.
> How much that is (and if this assumption is true) would be nice to
> have in the PR/patch for it.

This is not about virtualization and none of the features selected
requires any special hardware support apart from the few extra
kilobytes of flash and memory. You are still right, it doesn't come
all for free at runtime in terms of CPU cycles, but the impact is
hardly measurable.

But sure, I understand that this can be opt-in, so lets call it
'full_kernel' or something like that and have target maintainers
decide themselves. In the picture I get after browsing through
all targets, it would still end up such that
full_kernel == !small_flash is true for all cases.


And sure, I can carry out some size measurements and compare memory
allocation after boot. I'm sure the run-time CPU impact is hardly
measurable at all.

> 
> 
> Regards
> Jonas

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


More information about the openwrt-devel mailing list