[OpenWrt-Devel] [PATCH 2/3] build: use options to add kernels/dtbs in rootfs
Felix Fietkau
nbd at openwrt.org
Tue Aug 12 12:25:22 EDT 2014
On 2014-08-12 13:48, Luka Perkov wrote:
> On Tue, Aug 12, 2014 at 01:12:50PM +0200, Jonas Gorski wrote:
>> On Mon, Aug 11, 2014 at 10:48 PM, Luka Perkov <luka at openwrt.org> wrote:
>> > On Mon, Aug 11, 2014 at 10:06:27PM +0200, Felix Fietkau wrote:
>> >> On 2014-08-11 10:47, Luka Perkov wrote:
>> >> > Use support for options to enable targets and profiles select kernel or dtb
>> >> > inclusion by default.
>> >> >
>> >> > Signed-off-by: Luka Perkov <luka at openwrt.org>
>> >> What's the rationale for having this stuff as config options in the
>> >> first place? It seems to me that it makes a lot more sense to control
>> >> this from the target's image/Makefile.
>> >
>> > Here are the reasons:
>> >
>> > * Simplified image/Makefile for targets, no extra ifdefs
>>
>> .. which makes it impossible to build images for both a device needing
>> it and a device not needing it at the same time.
>
> ... but that is how build system works now.
That's not a valid reason for carrying forward bad design decisions.
> This patch series is not a
> stopper for the the fix of the problem you are pointing out here. If you
> have better way to deal with this feel free to send a patch. And don't
> forget to take in account third point below.
I refuse to make problem worse just for the sake of working around the
consequences of earlier bad decision making and a few other questionable
decisions.
>> > * Users can select if they want to include kernel/dtb or not - it is not
>> > hardcoded in the image/Makefile. For example, if one is building ramdisk
>> > image only no need to include kernel in rootfs.
>>
>> As a user, I would not want to have to make that decision. Either the
>> device needs the kernel in the rootfs, then it should be automatically
>> included, or it does not, then it shoudn't be there. If it isn't
>> needed for initramfs kernels, then selection state shouldn't have any
>> effect on the ramdisk contents.
>
> Then as a user don't touch default settings ;)
It does not make sense to have options for stuff that the user shouldn't
change anyway. Configuration bloat should be avoided.
>> > * Introduces ground work for including other options which can not be
>> > built as modules. Such as lxc/kexec support by default.
>>
>> As I said on 1/3, lxc/kexec is a bad example. An IB built with profile
>> A selected and an IB built with profile B selected should be able to
>> create identical* images, regardless of which profile was selected
>> while building the IB.
>
> As explained in the other email lxc/kexec would be set at target level
> and not on the profile level. That said, the point you are making does
> not make any sense to me.
I consider LXC something that explicitly should not be enabled by the
target itself. It should be enabled by the user, a use-case specific
defconfig or a disabled-by-default meta-package. For kexec it should
probably be the same.
Profiles should not be allowed to define build options that cannot be
processed by something like the image builder. That's also the reason
why we rejected the idea of having profiles affect the kernel config.
- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list