On Mon, 7 Jan 2019 at 14:21, Daniel Golle <dan...@makrotopia.org> wrote: > > On Mon, Jan 07, 2019 at 01:17:34PM +0000, Jonas Gorski wrote: > > On Mon, 7 Jan 2019 at 11:42, Petr Štetiar <yn...@true.cz> wrote: > > > > > > Daniel Golle <dan...@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 > ...
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. > > > > > 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. > 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. Please do so especially on low end devices. Maybe something like routing throughput with/without. Regards Jonas _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
