Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Jesper Juhl
On Fri, 13 Jul 2012, Linus Torvalds wrote:

> So this has long been one of my pet configuration peeves: as a user I
> am perfectly happy answering the questions about what kinds of
> hardware I want the kernel to support (I kind of know that), but many
> of the "support infrastructure" questions are very opaque, and I have
> no idea which of the them any particular distribution actually depends
> on.
> 
> And it tends to change over time. For example, F14 (iirc) started
> using TMPFS and TMPFS_POSIX_ACL/XATTR for /dev. And starting in F16,
> the initrd setup requires DEVTMPFS and DEVTMPFS_MOUNT. There's been
> several times when I started with my old minimal config, and the
> resulting kernel would boot, but something wouldn't quite work right,
> and it can be very subtle indeed.
> 
> Similarly, the distro ends up having very particular requirements for
> exactly *which* security models it uses and needs, and they tend to
> change over time. And now with systemd, CGROUPS suddenly aren't just
> esoteric things that no normal person would want to use, but are used
> for basic infrastructure. And I remember being surprised by OpenSUSE
> suddenly needing the RAW table support for netfilter, because it had a
> NOTRACK rule or something.
> 
> The point I'm slowly getting to is that I would actually love to have
> *distro* Kconfig-files, where the distribution would be able to say
> "These are the minimums I *require* to work". So we'd have a "Distro"
> submenu, where you could pick the distro(s) you use, and then pick
> which release, and we'd have something like
> 
>  - distro/Kconfig:
> 
> config DISTRO_REQUIREMENTS
> bool "Pick minimal distribution requirements"
> 
> choice DISTRO
> prompt "Distribution"
> depends on DISTRO_REQUIREMENTS
> 
> config FEDORA
> config OPENSUSE
> config UBUNTU
> ...
> 
> endchoice
> 
[...]

We are going to end up with a million+ (or something like that) "config 
" options that are going to have to be kept up-to-date 
regularly...
Do we really want that?
Maybe we do, maybe we don't - I'm not saying anything either way - just 
pointing it out.

I like the general idea - let a user pick the "make my distro work" option 
and then tweak from there. But, with hundreds (thousands?) of distroes out 
there, is it realy doable? Will we be able to keep things updated 
properly?

Perhaps a better aproach (and this is going to be controversial, so I'll 
put on my flame-repelling underwear now) would be to severely limit the 
number of available options.
KConfig is a mess (IMHO) - there's no telling what a given Linux kernel 
will support on any given distro on any given arch - there's no known 
mimimum.
How about we start cutting down on the options and start saying "a Linux 
system will provide feature x and y - always ...".
Stuff like (and I'm just pulling random stuff out here) - ASLR, seccomp, 
250HZ minimum etc etc.. We could cut the KConfig options down to 10% of 
what they are now if we just made a few (hard) choices about some things 
that would always be there that everyone could count on.  If people want 
to deviate from the default minimum, sure, let them, but put it under 
*custom*, *embedded*, *specialized distro*, *you know what you are doing* 
menu options.
Configurabillity is good, but only to a certain degree - I think we could 
bennefit from removing a *lot* of options and instead just decreeing that 
"a linux system has this"..


-- 
Jesper Juhlhttp://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.lnx.2.00.1207140014070.10...@swampdragon.chaosbits.net



Bug#329354: [patch] x86_64: fix tss limit (was Re: CAN-2005-0204 and 2.4)

2005-09-23 Thread Jesper Juhl
On 9/24/05, Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 24, 2005 at 12:55:41AM +0200, Jesper Juhl wrote:
> > On 9/24/05, Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> > > set_tssldt_descriptor(&cpu_gdt_table[cpu][GDT_ENTRY_TSS], 
> > > (unsigned long)addr,
> > >   DESC_TSS,
> > > - sizeof(struct tss_struct) - 1);
> > > + IO_BITMAP_OFFSET + IO_BITMAP_BYTES + 7);
> > >  }
> > >
> > [snip]
> >
> > Is it just me, or would it be nice with a symbolic name for this "7" ?
> > For someone reading the code for the first time it seems to me that
> > it's non-obvious why the 7 is there, and why it's 7 exactely - a
> > define would make it clearer as I see it.
>
> Andrew please apply this updated patch. Thanks.
>
[snip]

That change makes me happy :)

--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html



Bug#329354: [patch] x86_64: fix tss limit (was Re: CAN-2005-0204 and 2.4)

2005-09-23 Thread Jesper Juhl
On 9/24/05, Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
[snip]
>
> Fix the x86_64 TSS limit in TSS descriptor.
>
> Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
>
> --- linux-2.6.14-rc1/include/asm-x86_64/desc.h.orig 2005-09-12 
> 20:12:09.0 -0700
> +++ linux-2.6.14-rc1/include/asm-x86_64/desc.h  2005-09-23 12:50:58.210135128 
> -0700
> @@ -129,7 +129,7 @@ static inline void set_tss_desc(unsigned
>  {
> set_tssldt_descriptor(&cpu_gdt_table[cpu][GDT_ENTRY_TSS], (unsigned 
> long)addr,
>   DESC_TSS,
> - sizeof(struct tss_struct) - 1);
> + IO_BITMAP_OFFSET + IO_BITMAP_BYTES + 7);
>  }
>
[snip]

Is it just me, or would it be nice with a symbolic name for this "7" ?
For someone reading the code for the first time it seems to me that
it's non-obvious why the 7 is there, and why it's 7 exactely - a
define would make it clearer as I see it.


--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html