Hi Jonas,
On Mon, Jan 07, 2019 at 03:48:29PM +0100, Daniel Golle wrote:
> On Mon, Jan 07, 2019 at 02:39:26PM +, Jonas Gorski wrote:
> > On Mon, 7 Jan 2019 at 14:21, Daniel Golle wrote:
> > >
> > > On Mon, Jan 07, 2019 at 01:17:34PM +, Jonas Gorski wrote:
> > > > On Mon, 7 Jan 2019 at 11:42, Petr Štetiar wrote:
> > > > >
> > > > > Daniel Golle [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
> > > ...
> >
> > Most of these option only influence the size of the kernel, and have
> > no further runtime side effects. Also small_flash has impact on the
> > compression options used.
>
> They sure do, cache size on small CPUs is a very finite resource
> and having a kernel with debug symbols will make things slower, of
> course. SWAP also makes every single malloc call more expensive and
> is just as well only useful on devices with block storage (ok, and
> zramswap, but lets not talk about that).
>
> >
> > >
> > > >
> > > > 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.
> >
> > "Full kernel" really has no real meaning and would describe
> > everything. The name should clearly describe the (non-default) feature
> > set it enables.
>
> But they are not even necessarily related, just closer to the vanilla
> default config which is used eg. by Debian and most other Linux distros
> so projects like LVM2 started to rely on them.
> My goal here is to bring modern generic kernel features into OpenWrt,
> they are quite unrelated apart from being left out for space reasons
> and because for a
