| index : archi486 | |
| Archlinux32 i486 tools | gitolite user |
| summaryrefslogtreecommitdiff |
| -rw-r--r-- | floppy/doc/lwn.net_Articles_672587.txt | 240 |
diff --git a/floppy/doc/lwn.net_Articles_672587.txt b/floppy/doc/lwn.net_Articles_672587.txt new file mode 100644 index 0000000..32a6a4e --- /dev/null +++ b/floppy/doc/lwn.net_Articles_672587.txt @@ -0,0 +1,240 @@ + #[1]LWN.net headlines [2]Comments posted to this article + + [3]LWN.net Logo LWN + .net News from the source [4]LWN + * [5]Content + + [6]Weekly Edition + + [7]Archives + + [8]Search + + [9]Kernel + + [10]Security + + [11]Distributions + + [12]Events calendar + + [13]Unread comments + + + _________________________________________________________ + + + [14]LWN FAQ + + [15]Write for us + + User: ________ Password: ________ Log in + | Subscribe + | Register + [16]Subscribe / [17]Log in / [18]New account + +[RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH] x86/kconfig: +Sanity-check config file during oldconfig) + + [Posted January 20, 2016 by corbet] + + From: Ingo Molnar <mingo-AT-kernel.org> + To: Borislav Petkov <bp-AT-suse.de>, Linus Torvalds + <torvalds-AT-linux-foundation.org>, Greg Kroah-Hartman + <gregkh-AT-linuxfoundation.org>, Andrew Morton + <akpm-AT-linux-foundation.org> + Subject: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC + PATCH] x86/kconfig: Sanity-check config file during oldconfig) + Date: Tue, 19 Jan 2016 09:20:22 +0100 + Message-ID: <20160119082022.GB18237@gmail.com> + Cc: Michal Marek <mmarek-AT-suse.cz>, + =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= <mans-AT-mansr.com>, Markus + Trippelsdorf <markus-AT-trippelsdorf.de>, Thomas Voegtle + <tv-AT-lio96.de>, linux-kernel-AT-vger.kernel.org, x86-ml + <x86-AT-kernel.org>, Peter Zijlstra <a.p.zijlstra-AT-chello.nl>, Thomas + Gleixner <tglx-AT-linutronix.de>, Andrew Morton + <akpm-AT-linux-foundation.org>, Linus Torvalds + <torvalds-AT-linux-foundation.org>, Jiri Olsa <jolsa-AT-redhat.com>, + Arnaldo Carvalho de Melo <acme-AT-infradead.org>, + =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker <fweisbec-AT-gmail.com> + Archive-link: [19]Article, [20]Thread + + +( I've Cc:-ed Linus, Greg and Andrew, to see whether doing something like what I + + suggest below in the x86 architecture would be acceptable. ) + +* Borislav Petkov <bp@suse.de> wrote: + +> From: Borislav Petkov <bp@suse.de> +> +> Thomas Voegtle reported that doing oldconfig with a .config which has +> CONFIG_MICROCODE enabled but BLK_DEV_INITRD disabled prevents the +> microcode loading mechanism from being built. +> +> Add a short script which hooks into the "make oldconfig" handling and +> sanity-checks the config file for that discrepancy. It issues a message +> which should hopefully sensitize the user to that issue and point her +> into the right direction. + +So it would be much better to just do such things automatically, and only allow +'safe' combination of options - without the user having to do anything. + +The guiding principle is: kernel configuration is (still...) our worst barrier o +f +entry for new users/developers, and kernel configuration still sucks very much +from a UI point of view. + +In fact our kernel configuration UI and workflow is still so bad that it's an +effort to stay current even with a standalone and working .config, even for +experienced kernel developers... + +Adding a (somewhat hacky) post processing script and forcing users to read +something 99% of them does not have a clue about is a step in the wrong directio +n, +IMHO. + +So can we do something more intelligent instead, such as modifying the Kconfigs +in +a way that it's not possible to have CONFIG_MICROCODE enabled while BLK_DEV_INIT +RD +is disabled? + +I'd be fine with a 'select BLK_DEV_INITRD' for example. If people doing super +specialized setups disagree because they really need that nonsensical combinatio +n +of config options, they can complain and provide a better solution. + +In fact on x86 I'd suggest we go farther than that and add a core set of selects + +that can be disabled only through a sufficiently scary "I really know I'm doing +something utmost weird" (and default disabled) config option. + +From my own randconfig testing I can give a core list of must-have kernel option +s, +without which most distros (Fedora, RHEL, Ubuntu, SuSE) won't boot properly: + ++config FORCE_MINIMALLY_SANE_CONFIG ++ bool ++ default y ++ ++ # so that capset() works (sudo, etc.): ++ select SECURITY ++ select SECURITY_CAPABILITIES ++ select BINFMT_ELF ++ ++ select SYSFS ++ select SYSFS_DEPRECATED ++ select PROC_FS ++ select FUTEX ++ ++ # newer systemd silently relies on the presence of the epoll system call +: ++ select EPOLL ++ select ANON_INODES ++ ++ # newer systemd silently hangs durig early init without these: ++ select PROC_SYSCTL ++ select SYSCTL ++ select POSIX_MQUEUE ++ select POSIX_MQUEUE_SYSCTL ++ ++ # systemd needs this syscall: ++ select FHANDLE ++ ++ # systemd needs devtmpfs: "systemd[1]: Failed to mount devtmpfs at /dev: + No such device" ++ select DEVTMPFS ++ ++ # systemd needs tmpfs: "systemd[1]: Failed to mount tmpfs at /sys/fs/cgr +oup: No such file or +directory" ++ select SHMEM ++ select TMPFS ++ ++ # systemd needs timerfd syscalls: "[ 8.198625] systemd[1]: Failed to +create timerfd: Function +not implemented^" ++ select TIMERFD ++ ++ # systemd needs signalfd support: "[ 45.536725] systemd[1]: Failed to +allocate manager object: +Function not implemented" ++ select SIGNALFD ++ ++ # systemd hangs during bootup without cgroup support: ++ select CGROUPS ++ ++ # systemd fails during bootup without this option, with a nonsensical me +ssage: "[DEPEND] +Dependency failed for File System Check on /dev/sda1." ++ select FILE_LOCKING ++ ++ # systemd fails during bootup without this option: ++ select FSNOTIFY ++ select INOTIFY_USER ++ ++ # won't boot otherwise: ++ select RD_GZIP ++ select BLK_DEV_INITRD ++ ++ # old F6 userspace needs vsyscalls: ++ select X86_VSYSCALL_EMULATION if X86_64 ++ select IA32_EMULATION if X86_64 + +And yes, many of these options are members of the 'SystemD debuggability Hall Of + +Shame'... It cost me many, many days of painful config-bisection to figure the +often obscure dependencies out, so we might as well upstream this information. + +Many braincells died to bring us this information! + +Note that some of these have sub-dependencies (and super-dependencies) so the li +st +isn't complete from a Kconfig language POV - but it lists most of the 'must have +' +leaf features and would form a good starting point. + +The idea is that if you have this option enabled, the rest of kernel config shou +ld +be 'fool proof' - or at least failures should be a lot more obvious (such as a +missing hardware driver or a missing filesystem driver). + +I'd keep this option x86-only at least initially, because that's still the space + +where most of our newbie testers come from, and because I'd like to see how this + +evolves before trying to generalize it to 44 architectures... + +Also, I'd not try to be per distro, I'd use a single superset of such config +options: from a usability POV it's _much_ better to have a few more options +enabled in a .config of thousands of entries, than to accidentally have the one +option not enabled that your user-space somehow critically depends on ... + +Thoughs? + +Thanks, + + Ingo + + + __________________________________________ + + ([21]Log in to post comments) + + Copyright © 2016, Eklektix, Inc. + Comments and public postings are copyrighted by their creators. + Linux is a registered trademark of Linus Torvalds + +References + + 1. https://lwn.net/headlines/newrss + 2. https://lwn.net/headlines/672587/ + 3. https://lwn.net/ + 4. https://lwn.net/ + 5. https://lwn.net/Articles/672587/#t + 6. https://lwn.net/current/ + 7. https://lwn.net/Archives/ + 8. https://lwn.net/Search/ + 9. https://lwn.net/Kernel/ + 10. https://lwn.net/Security/ + 11. https://lwn.net/Distributions/ + 12. https://lwn.net/Calendar/ + 13. https://lwn.net/Comments/unread + 14. https://lwn.net/op/FAQ.lwn + 15. https://lwn.net/op/AuthorGuide.lwn + 16. https://lwn.net/subscribe/ + 17. https://lwn.net/Login/ + 18. https://lwn.net/Login/newaccount + 19. http://article.gmane.org/gmane.linux.kernel/2129528 + 20. http://thread.gmane.org/gmane.linux.kernel/2129528 + 21. https://lwn.net/Login/?target=/Articles/672587/ |