Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp5940336imb; Fri, 8 Mar 2019 06:00:29 -0800 (PST) X-Google-Smtp-Source: APXvYqxNrYwr/OI/MzDU0q6NQtsRK7k8Jmy7wRckzJxDxvues38Ux8ddNJPYUnfUQdFZ4ACkuyLV X-Received: by 2002:a62:3890:: with SMTP id f138mr19019085pfa.148.1552053628939; Fri, 08 Mar 2019 06:00:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1552053628; cv=none; d=google.com; s=arc-20160816; b=WDU6WfjWBMpYUIs1NZW2L7Lw5UGzHChP5Uu8be2yb7zmRwQoMXO7qXJ3EDtn2QexTQ o1WQkZd28B9U/YDYXL62ABjd7wYCO8AIjvhbxoxQGZqkJMdoE1bX9lBd0yxWgZXcZgvd ZCj6AL8+gCR9VLM4m9W6/hpgBj/9A/qhSV++r3JxDDhLcfxsRJQwsUa8lP6DXggu/0RP 3OWtonJoUbRbmh5GhuvCPhaaUWBTqCI2Eaqh2oLwVm9w9lO4c8FE1fUiCzOsi1IlHvW7 n3SSQ1v3QO/EQ+8QV/bSfdqgdfItQjSr/tj2sDHQW7/QH8uDCPJb8jcwk949SRGG9vl4 F0NQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=3pyIfVt94nMnM9leoDWIpciosei+T5cKSk6+9dtEfU8=; b=wv6JIku1edpqilSB2aIoO4ATDO+gWnxgBbu89KVGbSPkhZpztkb6DrQdkVJbs0laq4 BoVrrmnaFFDESXwlSaIJLcpaqZN1YnxIl/Zsrba/ypjrKllp/3m8ER1T1bkJGfpXkDDm 5awsqxLaLmS6x9Ty/vK6ThlNOKDhSZ9nCnZ5h/DBGF4shcf6oWjYRg5YArQJQcpVl4+K NuFGuzL7SmZuCbQHeXvcIERxNWbP2yNYX8MG2v+aBNxtFLV24z0ibe11jaoP1UcgONML KvESiomnfHG7xZSn+vh4VLLSYXcyCPsNYyKd4svOFgY4AQCQOSgqXBwemyl/33vDiKVo pV8w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p9si6806572pls.151.2019.03.08.06.00.13; Fri, 08 Mar 2019 06:00:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726844AbfCHN6g (ORCPT + 99 others); Fri, 8 Mar 2019 08:58:36 -0500 Received: from mout.kundenserver.de ([212.227.126.135]:43301 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726613AbfCHN6g (ORCPT ); Fri, 8 Mar 2019 08:58:36 -0500 Received: from [192.168.1.110] ([95.117.97.241]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MI5Dj-1hGEFK20Hf-00F7vX; Fri, 08 Mar 2019 14:57:29 +0100 Subject: Re: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel To: Joel Fernandes , Geert Uytterhoeven Cc: LKML , Andrew Morton , Alexei Starovoitov , atish patra , Daniel Colascione , Dan Williams , Dietmar Eggemann , Greg KH , Guenter Roeck , Jonathan Corbet , Karim Yaghmour , Kees Cook , Android Kernel Team , "open list:DOCUMENTATION" , "open list:KERNEL SELFTEST FRAMEWORK" , linux-trace-devel@vger.kernel.org, Manoj Rao , Masahiro Yamada , Masami Hiramatsu , Qais Yousef , Randy Dunlap , Steven Rostedt , Shuah Khan , Yonghong Song References: <20190301160856.129678-1-joel@joelfernandes.org> <20190307150343.GB258852@google.com> From: "Enrico Weigelt, metux IT consult" Organization: metux IT consult Message-ID: <05942dfd-b05d-0a26-f8e4-85e2a73b8feb@metux.net> Date: Fri, 8 Mar 2019 14:57:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:2vZUapQY62LzxQIv2azTdMjatX+RspFAoH+I9f/VwU+9Oy45DZw IdzRFwmMxw2XlX/yCTRLR3fVyw3KKVAFe2poEyG+anw49/m49tzSl29xRfbUrEWkNdLAdCS S3jS668IVRLDu8a34PY5hPHUcL4YfrX7x0814DEbmIvAJm6KoKXeNSQd9Zak0mHIQwZFalf V8yYGwbIGpiYnGsyPBiYA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:ewfJ7fN90DI=:w4MjO0df0JnP1eSpJXr4RG QnYrYAyzLAschlet8asvYWGt/F2ygLTFRjRSF+mqh46jzfTpOhjOBTOyBLVe8zanMpvjsAy8A vETqngOPlPSj05RfJU7YnuniwKc5jWCXcLbmKSnOhigKpWtbn6ierlbd+apJrMxeVrXJisc6c 0KqewOIJt/B49zl49Fl3hKs25ppthrVeZD/il+FfXnSmfS35DlcWCwR+kc8ae8CQxKcCxXGOE 1S3PgOEkEUlMOl3bPefaK/9Z6FCNCJye5Dh9yMjIUqcMqUL9G0GfQffy3peo0+SG++Y6bD5s0 07BYpKSDlpA5hyZW9s6XPo7aVgWyRTF2P/4qQczZSZA89HYg/4/+WhtsgM6rRerjpu3feY6o0 93W464420Ur2s7FNVmXyk8ibsHh9cq4+Tnx/+WB8smaSbsyzHDlLpWShy3o5Gm68nrNzBoR6P aqx27BzXRJ3lpgalpDuZnrshWOrs77n0Xj4Fa/yRj+xSCuUXanez5puZxzQkNLQ/yIjqEZOHe PyO7NqNC/tbPnI5lmjN9pEcem+9Q/cikRFNqCUToZCp9SaVav2M6rHG1NUkpRPGHq3uH2c606 NM1i4/C/1BGSxem3wJ8YKT1n7hYpzaZIUUCK0iRT86MfjPx8VodCDg5rysDT1rdO2q9ftwAt8 UKp6Ks1qJP/m/ZZuf6jTDdPTMpV2b1RW/mR1W8CuLlSwhe/bFIQcGhQoM7hDR5kOKC6shuPWQ xAjMmZUyC9d1J51Fx/JIyC2+1FjJiAuNYpTL1INcwI6tgm95Cp8TPnDwQug= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08.03.19 14:42, Joel Fernandes wrote: Hi folks, > That sounds like it could be useful. I don't see any reason off the > top why that would not be possible to add to the list of archived > files in the future. The patch allows populating the list of files > from Kbuild using ikh_file_list variable. It seems the whole thing's going into a direction where a whole own subtopic is coming up: compressed built-in filesystem. Haven't had a deeper thought about it yet, whether or not existing filesystems like squashfs, initramfs, etc are the right thing for that, or something new should be invented, but a generic mechanism for compiled-in compressed (ro) filesystems could also be interesting for very small devices, that perhaps even dont need any persistence. Some requirements coming up in mind: 1. it shall be possible to have any number of instances - possibly by separate modules. 2. it shall be possible to use an bootloader/firmware provided image (so it can serve as initrd) 2. data should stay compressed as long as possible, but uncompressed data might be cached - do decompression on-demand 3. only needs to be ro (write access could be done via unionfs+friends) 4. it shall be swappable (if swap is enabled) In that scenario, these in-kernel headers would just one consumer, I can imagine lots of others. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287