date:20120713

2012/7/13 Martin-Éric Racine :
> 2012/7/13 Martin-Éric Racine :
>> Package: dpkg
>> Version: 1.16.4.3
>> Followup-For: Bug #617299
>>
>> I also encounter the same bug when trying to build kernel 3.2.21 from 
>> upstream tarball:
>>
>> $ LOCALVERSION=-git-686-pae make deb-pkg
>> [...]
>> dpkg-deb: building package `firmware-linux' in 
>> `../firmware-linux_3.2.21-git-686-pae-1_i386.deb'.
>> dpkg-deb: building package `linux-headers-3.2.21-git-686-pae' in 
>> `../linux-headers-3.2.21-git-686-pae_3.2.21-git-686-pae-1_i386.deb'.
>> dpkg-deb: building package `linux-libc-dev' in 
>> `../linux-libc-dev_3.2.21-git-686-pae-1_i386.deb'.
>> dpkg-deb: building package `linux-image-3.2.21-git-686-pae' in 
>> `../linux-image-3.2.21-git-686-pae_3.2.21-git-686-pae-1_i386.deb'.
>> dpkg-deb (subprocess): data member: internal gzip write error: 'File not 
>> found'
>> dpkg-deb: error: subprocess  from tar -cf returned error exit 
>> status 2
>> make[1]: *** [deb-pkg] Error 2
>> make: *** [deb-pkg] Error 2
>
> This seems to be caused by either 'tar' or 'gzip' using /tmp to build
> the package. Since recent Debian systems default to using tmpfs for
> /tmp, systems with insufficient memory or with another process using
> all available memory resources will make the build fail. Would there
> perhaps be a way to make this process use /var/tmp or some other
> normal storage space to avoid these nonsensical failures?

Actually, this feels like an upstream kernel 3.2 bug: as a test, I
purposely disabled TMPFS for /tmp just to see if the kernel package
would finally build as expected. It did, except that the resulting DEB
is a whopping 488MB in size, compared to 22MB for the stock Debian
linux-image-3.2.0-3-686-pae built using the exact same .config file.

When I built another kernel using the 3.5-rc6 tree instead, the build
produced a kernel package similar in size to the stock Debian one, so
I suspect that the issue lies in kernel 3.2's build scripts and was
evidently fixed recently.

Would the people on debian-kernel@l.d.o perhaps know more about this?

Martin-Éric


--
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/capzxpqcu33y9-+6dho9wbvvbjk0chgnkqjg8jbr0qvhknys...@mail.gmail.com

Processed: Re: /boot/vmlinuz-2.6.33-2-amd64: impi oops on intel motherboard

2012-07-13 Thread Debian Bug Tracking System

Processing commands for cont...@bugs.debian.org:

> found 571980 linux-2.6/2.6.32-45
Bug #571980 [linux-2.6] linux-image-2.6.32-trunk-686: Kernel oops when ipmi 
modules loaded on ibm 326m
Marked as found in versions linux-2.6/2.6.32-45.
> fixed 571980 linux/3.2.21-3
Bug #571980 [linux-2.6] linux-image-2.6.32-trunk-686: Kernel oops when ipmi 
modules loaded on ibm 326m
Marked as fixed in versions linux/3.2.21-3; no longer marked as fixed in 
versions linux/3.2.21-3.
> severity 571980 important
Bug #571980 [linux-2.6] linux-image-2.6.32-trunk-686: Kernel oops when ipmi 
modules loaded on ibm 326m
Severity set to 'important' from 'normal'
> # not fixed in stable
> tags 571980 - fixed-upstream
Bug #571980 [linux-2.6] linux-image-2.6.32-trunk-686: Kernel oops when ipmi 
modules loaded on ibm 326m
Removed tag(s) fixed-upstream.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
571980: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571980
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
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/handler.s.c.134220443024729.transcr...@bugs.debian.org

Re: dpkg-deb: should give a hint when it fails due to filling /tmp

Hi,

Martin-Éric Racine wrote:

> Actually, this feels like an upstream kernel 3.2 bug: as a test, I
> purposely disabled TMPFS for /tmp just to see if the kernel package
> would finally build as expected. It did, except that the resulting DEB
> is a whopping 488MB in size, compared to 22MB for the stock Debian
> linux-image-3.2.0-3-686-pae built using the exact same .config file.

That's because the Debian packaging strips debugging symbols into a
separate -dbg package.

If you use "scripts/config --disable DEBUG_INFO" (or manually make the
same setting in "make nconfig"), both the build tree and the resulting
deb will be much smaller.

Hope that helps,
Jonathan

--
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/20120713194129.GB30693@burratino

Re: dpkg-deb: should give a hint when it fails due to filling /tmp

(dropping dpkg maintainers from cc)
Martin-Éric Racine wrote:
> 2012/7/13 Jonathan Nieder :
>> Martin-Éric Racine wrote:

>>>  the resulting DEB
>>> is a whopping 488MB in size, compared to 22MB for the stock Debian
>>> linux-image-3.2.0-3-686-pae built using the exact same .config file.
>>
>> That's because the Debian packaging strips debugging symbols into a
>> separate -dbg package.
>
> I'm already aware of the effects of stripping binaries. However, you
> gotta admit that 488MB compared to 22MB is just ridiculous; something
> is definitely broken in those 3.2 build scripts.

Are the build scripts responsible for the size of debugging symbols?
I don't follow.

Or do you mean that the size of the kernel -dbg packages is
ridiculous?  In that case, you are barking up the wrong tree --- the
"make deb-pkg" code is not what determines that, and all that changed
between 2.6.32 and 3.2 is that the stock Debian configuration started
enabling debug symbols for the sake of systemtap et al.

Jonathan

--
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/20120713195154.GC30693@burratino

Re: dpkg-deb: should give a hint when it fails due to filling /tmp

2012/7/13 Jonathan Nieder :
> Hi,
>
> Martin-Éric Racine wrote:
>
>> Actually, this feels like an upstream kernel 3.2 bug: as a test, I
>> purposely disabled TMPFS for /tmp just to see if the kernel package
>> would finally build as expected. It did, except that the resulting DEB
>> is a whopping 488MB in size, compared to 22MB for the stock Debian
>> linux-image-3.2.0-3-686-pae built using the exact same .config file.
>
> That's because the Debian packaging strips debugging symbols into a
> separate -dbg package.

I'm already aware of the effects of stripping binaries. However, you
gotta admit that 488MB compared to 22MB is just ridiculous; something
is definitely broken in those 3.2 build scripts.

Martin-Éric


--
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/CAPZXPQfyGSscLOx3xeORxz3rH4YbRjQt_hZaz-b6i2tRr+n=9...@mail.gmail.com

Re: dpkg-deb: should give a hint when it fails due to filling /tmp

Martin-Éric Racine wrote:
> (putting back the CC to the bug, which will probably need to be
> reassigned to 'linux')
> 2012/7/13 Jonathan Nieder :
>> (dropping dpkg maintainers from cc)
>> Martin-Éric Racine wrote:

>>> I'm already aware of the effects of stripping binaries. However, you
>>> gotta admit that 488MB compared to 22MB is just ridiculous; something
>>> is definitely broken in those 3.2 build scripts.
>>
>> Are the build scripts responsible for the size of debugging symbols?
>> I don't follow.
>>
>> Or do you mean that the size of the kernel -dbg packages is
>> ridiculous?
>
> I mean that the size of the kernel package produced by 'make deb-pkg'
> from the 3.2 vanilla tree, even after disabling debug symbols, is
> highly suspicious, compared to the stock Debian kernel with the same
> source.

Ok, I missed that.  What is that size?

Just to confirm, are you certain CONFIG_DEBUG_INFO is disabled?


--
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/20120713200721.GD30693@burratino

Re: dpkg-deb: should give a hint when it fails due to filling /tmp

(putting back the CC to the bug, which will probably need to be
reassigned to 'linux')
2012/7/13 Jonathan Nieder :
> (dropping dpkg maintainers from cc)
> Martin-Éric Racine wrote:
>> 2012/7/13 Jonathan Nieder :
>>> Martin-Éric Racine wrote:
>
  the resulting DEB
 is a whopping 488MB in size, compared to 22MB for the stock Debian
 linux-image-3.2.0-3-686-pae built using the exact same .config file.
>>>
>>> That's because the Debian packaging strips debugging symbols into a
>>> separate -dbg package.
>>
>> I'm already aware of the effects of stripping binaries. However, you
>> gotta admit that 488MB compared to 22MB is just ridiculous; something
>> is definitely broken in those 3.2 build scripts.
>
> Are the build scripts responsible for the size of debugging symbols?
> I don't follow.
>
> Or do you mean that the size of the kernel -dbg packages is
> ridiculous?

I mean that the size of the kernel package produced by 'make deb-pkg'
from the 3.2 vanilla tree, even after disabling debug symbols, is
highly suspicious, compared to the stock Debian kernel with the same
source.

Martin-Éric


--
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/CAPZXPQcBC4=zf5syjndvrwjdshyufokmjhc8urqcbhwbzje...@mail.gmail.com

Re: dpkg-deb: should give a hint when it fails due to filling /tmp

Martin-Éric Racine wrote:
> 2012/7/13 Jonathan Nieder :

>> Just to confirm, are you certain CONFIG_DEBUG_INFO is disabled?
>
> Yup.

Ok.  Please attach your .config so we can reproduce this.


--
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/20120713202956.GA31387@burratino

Re: dpkg-deb: should give a hint when it fails due to filling /tmp

Martin-Éric Racine wrote:

> I have already stated that the .config is copied as-is from the stock
> Debian 3.2 kernel's config.

Oh, interesting.

May we have a debdiff of the binary packages, too?


--
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/20120713203758.GA31432@burratino

Re: dpkg-deb: should give a hint when it fails due to filling /tmp

2012/7/13 Jonathan Nieder :
> Martin-Éric Racine wrote:
>> (putting back the CC to the bug, which will probably need to be
>> reassigned to 'linux')
>> 2012/7/13 Jonathan Nieder :
>>> (dropping dpkg maintainers from cc)
>>> Martin-Éric Racine wrote:
>
 I'm already aware of the effects of stripping binaries. However, you
 gotta admit that 488MB compared to 22MB is just ridiculous; something
 is definitely broken in those 3.2 build scripts.
>>>
>>> Are the build scripts responsible for the size of debugging symbols?
>>> I don't follow.
>>>
>>> Or do you mean that the size of the kernel -dbg packages is
>>> ridiculous?
>>
>> I mean that the size of the kernel package produced by 'make deb-pkg'
>> from the 3.2 vanilla tree, even after disabling debug symbols, is
>> highly suspicious, compared to the stock Debian kernel with the same
>> source.
>
> Ok, I missed that.  What is that size?

As written above, the custom package came out to 488MB compared to
22MB for linux-image-3.2.0-3-686-pae from Wheezy.

> Just to confirm, are you certain CONFIG_DEBUG_INFO is disabled?

Yup.

Martin-Éric


--
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/CAPZXPQe76THt-3mn=uuo9gfx85ovdgbjux+6v1jphbtlyax...@mail.gmail.com

Re: dpkg-deb: should give a hint when it fails due to filling /tmp

On Fri, Jul 13, 2012 at 11:02:57PM +0300, Martin-Éric Racine wrote:
> (putting back the CC to the bug, which will probably need to be
> reassigned to 'linux')
> 2012/7/13 Jonathan Nieder :
> > (dropping dpkg maintainers from cc)
> > Martin-Éric Racine wrote:
> >> 2012/7/13 Jonathan Nieder :
> >>> Martin-Éric Racine wrote:
> >
>   the resulting DEB
>  is a whopping 488MB in size, compared to 22MB for the stock Debian
>  linux-image-3.2.0-3-686-pae built using the exact same .config file.
> >>>
> >>> That's because the Debian packaging strips debugging symbols into a
> >>> separate -dbg package.
> >>
> >> I'm already aware of the effects of stripping binaries. However, you
> >> gotta admit that 488MB compared to 22MB is just ridiculous; something
> >> is definitely broken in those 3.2 build scripts.
> >
> > Are the build scripts responsible for the size of debugging symbols?
> > I don't follow.
> >
> > Or do you mean that the size of the kernel -dbg packages is
> > ridiculous?
> 
> I mean that the size of the kernel package produced by 'make deb-pkg'
> from the 3.2 vanilla tree, even after disabling debug symbols, is
> highly suspicious, compared to the stock Debian kernel with the same
> source.

Did you actually rebuild with CONFIG_DEBUG_INFO off, or did you
only re-run 'make deb-pkg'?

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20120713204622.gq1...@decadent.org.uk

Re: dpkg-deb: should give a hint when it fails due to filling /tmp

2012/7/13 Jonathan Nieder :
> Martin-Éric Racine wrote:
>> 2012/7/13 Jonathan Nieder :
>
>>> Just to confirm, are you certain CONFIG_DEBUG_INFO is disabled?
>>
>> Yup.
>
> Ok.  Please attach your .config so we can reproduce this.

I have already stated that the .config is copied as-is from the stock
Debian 3.2 kernel's config. The only change I made was to disable
debug symbols, as above, and to patch one gspca C file as asked by
upstream for a test.

Martin-Éric

--
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/capzxpqck1ppo+q3cydfdyzgr9rc1jjcu1d1b4wrxarqpctg...@mail.gmail.com

[RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Linus Torvalds

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

and then depending on the DISTRO config, we'd include one of the
distro-specific ones with lists of supported distro versions and then
the random config settings for that version:

- distro/Kconfig.suse:

config OPENSUSE_121
select OPENSUSE_11
select IP_NF_RAW # ..

- distro/Kconfig.Fedora:

config FEDORA_16
select FEDORA_15
select DEVTMPFS # F16 initrd needs this
select DEVTMPFS_MOUNT # .. and expects the kernel to mount
DEVTMPFS automatically
...

config FEDORA_17
select FEDORA_16
select CGROUP_xyzzy
...

and the point would be that it would make it much easier for a normal
user (and quite frankly, I want to put myself in that group too) to
make a kernel config that "just works".

Sure, you can copy the config file that came with the distro, but it
has tons of stuff that really isn't required. Not just in hardware,
but all the debug choices etc that are really a user choice. And it's
really hard to figure out - even for somebody like me - what a minimal
usable kernel is.

And yes, I know about "make localmodconfig". That's missing the point
for the same reason the distro config is missing the point.

Comments? It doesn't have to start out perfect, but I think it would
*really* help make the kernel configuration much easier for people.

In addition to the "minimal distro settings", we might also have a few
"common platform" settings, so that you could basically do a "hey, I
have a modern PC laptop, make it pick the obvious stuff that a normal
person needs, like USB storage, FAT/VFAT support, the core power
management etc". The silly stuff that you need, and that
"localyesconfig" actually misses because if you haven't inserted a USB
thumb drive, you won't necessarily have the FAT module loaded, but we
all know you do want it in real life. But that's really independent
issue, so let's keep it to just distro core things at first, ok?

Would something like this make sense to people? I really think that
"How do I generate a kernel config file" is one of those things that
keeps normal people from compiling their own kernel. And we *want*
people to compile their own kernel so that they can help with things
like bisecting etc. The more, the merrier.

Linus

--
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/CA+55aFxw8pY1KMjobp=dkjd+g4b9kghe4+fsfspa3ofcgvh...@mail.gmail.com

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Dave Jones

On Fri, Jul 13, 2012 at 01:37:41PM -0700, Linus Torvalds wrote:

 > 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".

As long as you don't mind these being added after the fact, I suppose
it would be workable.  The reason I say that is sometimes, it even catches *us*
by surprise.  We recently found out our virtualisation guys started
using sch_htb for example, and we inadvertantly broke it when we moved
its module to a 'not always installed' kernel subpackage. (and before that, 
9PFS..)

People don't tell us anything, but somehow expect things to keep working.

 > In addition to the "minimal distro settings", we might also have a few
 > "common platform" settings, so that you could basically do a "hey, I
 > have a modern PC laptop, make it pick the obvious stuff that a normal
 > person needs, like USB storage, FAT/VFAT support, the core power
 > management etc".

I wish defconfig was actually something useful like this, instead of..
what the hell is it exactly ? No-one even seems to agree, other than
"random selection of options, many of which were removed n years ago"

Dave

-- 
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/20120713210240.gg1...@redhat.com

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Myklebust, Trond

On Fri, 2012-07-13 at 13:37 -0700, 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
> 
> and then depending on the DISTRO config, we'd include one of the
> distro-specific ones with lists of supported distro versions and then
> the random config settings for that version:
> 
>  - distro/Kconfig.suse:
> 
> config OPENSUSE_121
> select OPENSUSE_11
> select IP_NF_RAW  # ..
> 
>  - distro/Kconfig.Fedora:
> 
> config FEDORA_16
> select FEDORA_15
> select DEVTMPFS   # F16 initrd needs this
> select DEVTMPFS_MOUNT  # .. and expects the kernel to mount
> DEVTMPFS automatically
> ...
> 
> config FEDORA_17
> select FEDORA_16
> select CGROUP_xyzzy
> ...
> 
> and the point would be that it would make it much easier for a normal
> user (and quite frankly, I want to put myself in that group too) to
> make a kernel config that "just works".
> 
> Sure, you can copy the config file that came with the distro, but it
> has tons of stuff that really isn't required. Not just in hardware,
> but all the debug choices etc that are really a user choice. And it's
> really hard to figure out - even for somebody like me - what a minimal
> usable kernel is.
> 
> And yes, I know about "make localmodconfig". That's missing the point
> for the same reason the distro config is missing the point.
> 
> Comments? It doesn't have to start out perfect, but I think it would
> *really* help make the kernel configuration much easier for people.
> 
> In addition to the "minimal distro settings", we might also have a few
> "common platform" settings, so that you could basically do a "hey, I
> have a modern PC laptop, make it pick the obvious stuff that a normal
> person needs, like USB storage, FAT/VFAT support, the core power
> management etc". The silly stuff that you need, and that
> "localyesconfig" actually misses because if you haven't inserted a USB
> thumb drive, you won't necessarily have the FAT module loaded, but we
> all know you do want it in real life. But that's really independent
> issue, so let's keep it to just distro core things at first, ok?
> 
> Would something like this make sense to people? I really think that
> "How do I generate a kernel config file" is one of those things that
> keeps normal people from compiling their own kernel. And we *want*
> people to compile their own kernel so that they can help with things
> like bisecting etc. The more, the merrier.
> 
> Linus

We could at least make selection of a minimal set of drivers for the
more common virtualised platforms a lot easier.
Right now, you need to hunt through 30+ different menus in order to find
what you need to run in a basic KVM virtual machine...

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
trond.mykleb...@netapp.com
www.netapp.com

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Geert Uytterhoeven

On Fri, Jul 13, 2012 at 11:02 PM, Dave Jones  wrote:
> I wish defconfig was actually something useful like this, instead of..
> what the hell is it exactly ? No-one even seems to agree, other than
> "random selection of options, many of which were removed n years ago"

It's just to difficult to update them in a sane way.

I mean, I have my own set of defconfigs for all supported m68k-platforms,
but getting them in sync and ready for submitting an update seems to be a
multi-year project, and there are always more important (and more fun) things
to do. So that's why I haven't gotten to updating them since the defconfig
reduction.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-- 
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/camuhmduaksrexgxwdzmzs3ji7fcf8p-hhqbz-zuznkwfz2+...@mail.gmail.com

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Khalid Aziz


On 07/13/2012 02:37 PM, Linus Torvalds wrote:



Would something like this make sense to people? I really think that
"How do I generate a kernel config file" is one of those things that
keeps normal people from compiling their own kernel. And we *want*
people to compile their own kernel so that they can help with things
like bisecting etc. The more, the merrier.


This is a great idea. 7-8 years ago I used to be able to create a
minimally configured kernel from upstream and run my Debian/Ubuntu/...
install with it. It got much harder in a hurry and now it takes too much
work to figure out how to configure upstream kernel to make it work with
distro. It is a 3-5 hour compile to start with distro config file and that
is just too painful. I will help with testing configs or helping sort
through the config options.

--
Khalid Aziz
khalid.a...@hp.com


--
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/50008dbd.2030...@hp.com

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Linus Torvalds

On Fri, Jul 13, 2012 at 2:02 PM, Dave Jones  wrote:
>
> As long as you don't mind these being added after the fact, I suppose
> it would be workable.  The reason I say that is sometimes, it even catches 
> *us*
> by surprise.  We recently found out our virtualisation guys started
> using sch_htb for example, and we inadvertantly broke it when we moved
> its module to a 'not always installed' kernel subpackage. (and before that, 
> 9PFS..)
>
> People don't tell us anything, but somehow expect things to keep working.

I think even a "educated guess" config file is better than what we have now.

The *two* requirements (and they're really the same theme) I
personally think we should have for this are

 -  I think every single "select" for these things should come with a
comment about what it is about and why the distro needs it (to show
there was some thought involved and not just a blind "took it from the
distro config")

 - It should be about *minimal* settings. I'd rather have too few
things and the occasional complaint about "oh, it didn't work because
it missed XYZ" than have it grow to contain all the options just
because somebody decided to just add random things until things
worked.

Other than that, even if it only gets you *closer* to a kernel that
works with that distro, I think it doesn't have to be all that
perfect. Because the alternative is what we have now.

   Linus


-- 
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/CA+55aFz_Vv899eXz6F0jtFH=ht4qpb0_2xus8hyspjhc6s+...@mail.gmail.com

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Casey Schaufler

On 7/13/2012 1:37 PM, 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".

Oh dear. I would expect Fedora to say that they require SELinux,
thereby making it unusable by anyone doing LSM development. It
would also make it more difficult for the people who don't want
any LSM (e.g. everyone sane) to configure the kernel they want.

This is the example that I see because of my particular biases.
I expect that there are similar things that distros do in other
areas that will have the same effect. The distro developers may
have decided that a feature is too cool to live without and
include it in their configuration even when it's not really
necessary. Plus, do you really think that they're going to
clean things out of their configuration when they decide that
they no longer need them?


>  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
>
> and then depending on the DISTRO config, we'd include one of the
> distro-specific ones with lists of supported distro versions and then
> the random config settings for that version:
>
>  - distro/Kconfig.suse:
>
> config OPENSUSE_121
> select OPENSUSE_11
> select IP_NF_RAW  # ..
>
>  - distro/Kconfig.Fedora:
>
> config FEDORA_16
> select FEDORA_15
> select DEVTMPFS   # F16 initrd needs this
> select DEVTMPFS_MOUNT  # .. and expects the kernel to mount
> DEVTMPFS automatically
> ...
>
> config FEDORA_17
> select FEDORA_16
> select CGROUP_xyzzy
> ...
>
> and the point would be that it would make it much easier for a normal
> user (and quite frankly, I want to put myself in that group too) to
> make a kernel config that "just works".
>
> Sure, you can copy the config file that came with the distro, but it
> has tons of stuff that really isn't required. Not just in hardware,
> but all the debug choices etc that are really a user choice. And it's
> really hard to figure out - even for somebody like me - what a minimal
> usable kernel is.
>
> And yes, I know about "make localmodconfig". That's missing the point
> for the same reason the distro config is missing the point.
>
> Comments? It doesn't have to start out perfect, but I think it would
> *really* help make the kernel configuration much easier for people.
>
> In addition to the "minimal distro settings", we might also have a few
> "common platform" settings, so that you could basically do a "hey, I
> have a modern PC laptop, make it pick the obvious stuff that a normal
> person needs, like USB storage, FAT/VFAT support, the core power
> management etc". The silly stuff that you need, and that
> "localyesconfig" actually misses because if you haven't inserted a USB
> thumb drive, you won't necessarily have the FAT module loaded, but we
> all know you do want it in real life. But that's really independent
> issue, so let's keep it to just distro core things at first, ok?
>
> Would something like this make sense to people? I really think that
> "How do I generate a kernel config file" is one of those things that
> keeps normal people from compiling their own kernel. And we *want*
> people to compile their own kernel so that they can help with things
> like bisecting etc. The more, the merrier.
>
>

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Linus Torvalds

On Fri, Jul 13, 2012 at 2:17 PM, Casey Schaufler  wrote:
>
> Oh dear. I would expect Fedora to say that they require SELinux,
> thereby making it unusable by anyone doing LSM development.

Oh, *absolutely*.

These options would *not* be meant for people doing odd things and
experienting with configs.

If you do that, then you might *start* by saying "I want this distro"
to get the initial guesstimate of the config file you want, but then
edit the .config by hand later (and remove the "I want all the Fedora
requirements" option, of course).

This is explicitly and exclusively for normal users. The whole point
of "expert configurator for special cases" should not be given any
thought at all - those kinds of people should simply answer "No" to
the "Do you want the distro basic kconfig requirements" question.

Linus

-- 
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/CA+55aFyD_=amoykbocwfxxz7rypwhzemolyqc4p7oqfdrin...@mail.gmail.com

Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread richard -rw- weinberger

On Fri, Jul 13, 2012 at 10:54 PM, Myklebust, Trond
 wrote:
> We could at least make selection of a minimal set of drivers for the
> more common virtualised platforms a lot easier.
> Right now, you need to hunt through 30+ different menus in order to find
> what you need to run in a basic KVM virtual machine...

Yes, every time I build a kernel to be used on KVM I forget something. :-\

We could introduce a section in Kconfig which contains selections for
common use cases.
E.g. as Linus requested for minimal distro requirements but also
selections for various common
guest configurations.

-- 
Thanks,
//richard

-- 
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/CAFLxGvxxWodD97=78218wc+tuigafsnk_pdrodfb4bwtzox...@mail.gmail.com

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Dave Jones

On Fri, Jul 13, 2012 at 11:50:25PM +0200, Paul Bolle wrote:

 > But just removing all the certainly unused macros probably wouldn't have
 > made a noticeable difference to anyone using those defconfig files
 > anyway.

My point is that I don't think there's many people actually using them.
(maybe more on the niche platforms, but x86[64] ? I'm sceptical they're used at 
all)

Dave
 


-- 
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/20120713215546.gh1...@redhat.com

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Paul Bolle

On Fri, 2012-07-13 at 17:02 -0400, Dave Jones wrote:
> I wish defconfig was actually something useful like this, instead of..
> what the hell is it exactly ? No-one even seems to agree, other than
> "random selection of options, many of which were removed n years ago"

As for the "many of which were removed n years ago" part: in
https://lkml.org/lkml/2011/11/18/211 I suggested to delete
almost 2000 lines from over 400 defconfig files. That would have deleted
all certainly unused macros from all defconfig files. Nothing happened
after that. My fault, I'm afraid.

But just removing all the certainly unused macros probably wouldn't have
made a noticeable difference to anyone using those defconfig files
anyway.

Paul Bolle

-- 
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/1342216225.15453.15.camel@x61.thuisdomein

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Tony Luck

I always thought that the x86 defconfig file was the one that Linus
used for his primary machine.

-Tony


-- 
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/ca+8mbbl9mrxsw8o376bpatzn2xvkoaiwiohxkcjnx9_j8sj...@mail.gmail.com

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Paul Bolle

On Fri, 2012-07-13 at 17:55 -0400, Dave Jones wrote:
> My point is that I don't think there's many people actually using them.
> (maybe more on the niche platforms, but x86[64] ? I'm sceptical they're used 
> at all)

I guess you're right. Personally, I tend to start my journeys in self
compiled kernel land by using something I know that works as a starting
point. Ie, I use some distribution's kernel, notice that things seem to
mostly work, and use the .config of that kernel to start exploring
whatever it is I'm interested in. I can't remember ever feeling the urge
to use some defconfig to start these journeys. 

Paul Bolle

-- 
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/1342218034.15453.28.camel@x61.thuisdomein

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread david


On Fri, 13 Jul 2012, Linus Torvalds wrote:


On Fri, Jul 13, 2012 at 2:17 PM, Casey Schaufler  wrote:


Oh dear. I would expect Fedora to say that they require SELinux,
thereby making it unusable by anyone doing LSM development.


Oh, *absolutely*.

These options would *not* be meant for people doing odd things and
experienting with configs.

If you do that, then you might *start* by saying "I want this distro"
to get the initial guesstimate of the config file you want, but then
edit the .config by hand later (and remove the "I want all the Fedora
requirements" option, of course).

This is explicitly and exclusively for normal users. The whole point
of "expert configurator for special cases" should not be given any
thought at all - those kinds of people should simply answer "No" to
the "Do you want the distro basic kconfig requirements" question.


hopefully this can be made a little easier.

more of a 'enable anything set in this file, then give me control again so 
I can turn things off' rather than having to manually edit the .config 
file.


If this is done as a hard set of dependancy settings, it will be very 
annoying for people who for any reason want to disable something that the 
distro considers 'essential'.


I also _really_ like the idea of being able to have a vmware option that 
enables the minimum devices that are needed to run.


Having these be hard dependancies also seems like it would make 
interactions between these sorts of things much more likely to cause 
problems.


If however they are one-shot "go through this file and enable anything 
that it says to turn on" things that then let you turn anything off, it 
seems much less likely to cause problems.


and if we can then get some of the big hardware vendors to create such 
files to enable all the drivers needed for their hardware (the big 
things are easy, it's when you get into the internal monitoring busses and 
so on that things get messy)


David Lang


--
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.deb.2.02.1207131507530.32...@asgard.lang.hm

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Josh Boyer

On Fri, Jul 13, 2012 at 02:17:30PM -0700, Linus Torvalds wrote:
> On Fri, Jul 13, 2012 at 2:02 PM, Dave Jones  wrote:
> >
> > As long as you don't mind these being added after the fact, I suppose
> > it would be workable.  The reason I say that is sometimes, it even catches 
> > *us*
> > by surprise.  We recently found out our virtualisation guys started
> > using sch_htb for example, and we inadvertantly broke it when we moved
> > its module to a 'not always installed' kernel subpackage. (and before that, 
> > 9PFS..)
> >
> > People don't tell us anything, but somehow expect things to keep working.
> 
> I think even a "educated guess" config file is better than what we have now.
> 
> The *two* requirements (and they're really the same theme) I
> personally think we should have for this are
> 
>  -  I think every single "select" for these things should come with a
> comment about what it is about and why the distro needs it (to show
> there was some thought involved and not just a blind "took it from the
> distro config")
> 
>  - It should be about *minimal* settings. I'd rather have too few
> things and the occasional complaint about "oh, it didn't work because
> it missed XYZ" than have it grow to contain all the options just
> because somebody decided to just add random things until things
> worked.

I'd agree that should be the goal.  It seems like something worth at
least trying to get to.  Even if we don't wind up merging them into the
kernel, it will at least lead to a better documented distro config for
every one that tries it.

josh


-- 
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/20120713222616.ga2...@zod.bos.redhat.com

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Hans de Bruin


On 07/13/2012 10:37 PM, 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
>
> and then depending on the DISTRO config, we'd include one of the
> distro-specific ones with lists of supported distro versions and then
> the random config settings for that version:
>
>   - distro/Kconfig.suse:
>
>  config OPENSUSE_121
>  select OPENSUSE_11
>  select IP_NF_RAW  # ..
>
>   - distro/Kconfig.Fedora:
>
>  config FEDORA_16
>  select FEDORA_15
>  select DEVTMPFS   # F16 initrd needs this
>  select DEVTMPFS_MOUNT  # .. and expects the kernel to mount
> DEVTMPFS automatically
>  ...
>
>  config FEDORA_17
>  select FEDORA_16
>  select CGROUP_xyzzy
>  ...

Could this be made more dynamic? I would like to download a minimal 
config file from my distro's website and perhaps add my own minimal 
config for the hardware I own and put both downloads somewhere in my 
local tree, or have makemenuconfig ask me for a location of my minimal 
config files?


--
Hans


--
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/50009a57.7000...@xmsnet.nl

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

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread david


On Sat, 14 Jul 2012, Jesper Juhl wrote:


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?


this needs to be more like 'make install' where the build system doesn't 
have specifics for every distro, but instead refrences a separate file 
that's provided in the same place by every distro, ideally separate from 
the kernel itself.


David Lang


--
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.deb.2.02.1207131544370.32...@asgard.lang.hm

Re: [RFC] Simplifying kernel configuration for distro issues

2012-07-13 Thread Frank Rowand

On 07/13/12 14:55, Dave Jones wrote:
> On Fri, Jul 13, 2012 at 11:50:25PM +0200, Paul Bolle wrote:
> 
>  > But just removing all the certainly unused macros probably wouldn't have
>  > made a noticeable difference to anyone using those defconfig files
>  > anyway.
> 
> My point is that I don't think there's many people actually using them.
> (maybe more on the niche platforms, but x86[64] ? I'm sceptical they're used 
> at all)

I'm one of those people who use default configs.  I build a given kernel 
version for
many different embedded boards and expect the default config to work for them.  
It
makes life much easier.

I also share Linus' pain when building for my host x86 system and try to
remove the cruft from my distro config.

-Frank

-- 
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/5000aa38.5010...@am.sony.com

Re: [RFC] Simplifying kernel configuration for distro issues

On Fri, 2012-07-13 at 13:37 -0700, 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.
[...]
> 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

I like this idea in principle.

[...]
>  - 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
> 
> and then depending on the DISTRO config, we'd include one of the
> distro-specific ones with lists of supported distro versions and then
> the random config settings for that version:

You might also want to *un*select some options like
CONFIG_SYSFS_DEPRECATED and CONFIG_SYSFS_DEPRECATED_V2 that need to be
set one way or the other depending on the version of udev.  (I think
it's possible to kluge this with the addition of a hidden negative
config option.)

How about stuff like NET and INET, that every distro will need and yet
is configurable even without EXPERT?

[...]
> Sure, you can copy the config file that came with the distro, but it
> has tons of stuff that really isn't required. Not just in hardware,
> but all the debug choices etc that are really a user choice. And it's
> really hard to figure out - even for somebody like me - what a minimal
> usable kernel is.
[...]

And it's still hard for me as kernel packager: just because an option
was requested and enabled to support some bit of userland, doesn't mean
I know what's using or depending on it now.  (I think Dave Jones made
this point already.)  I'm not usually concerned with *minimal* config.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou


signature.asc
Description: This is a digitally signed message part

Re: dpkg-deb: should give a hint when it fails due to filling /tmp

On Sat, 2012-07-14 at 07:51 +0300, Martin-Éric Racine wrote:
> 2012/7/13 Ben Hutchings :
[...]
> If I disable CONFIG_DEBUG_INFO again just before building, the kernel
> indeed is MUCH smaller (I had probably forgotten to disable it before
> attempting a new build; sorry for the confusion) and it easily builds
> within the space allocated for /tmp using sysfs via initscripts.
> However, it still comes out at about 8MB larger than the equivalent
> stock Debian kernel:
> 
> -rw-r--r-- 1 perkelix perkelix 22M Jun 28 15:03
> linux-image-3.2.0-3-686-pae_3.2.21-3_i386.deb
> -rw-r--r-- 1 perkelix perkelix 30M Jul 14 01:31
> linux-image-3.2.21-vanilla-686-pae_3.2.21-vanilla-686-pae-1_i386.deb

Official packages are now compressed with xz whereas deb-pkg uses gzip.

> This is of course a minor issue at this point and something that can
> be discussed separately from this bug. :)
> 
> As for bug #617299, the actual cause is three-folds:
> 
> 1) Starting with Wheezy, /tmp is mounted as a tmpfs whose size is
> determined by initscripts to 20% of available memory. On my laptop
> with a modest 1GB of RAM, this meant a /tmp sized at 200MB.
[...]

This was reverted in version of 2.88dsf-26 of initscripts, due to issues
like this.  I'm not sure all systems will get automatically changed back
though.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou


signature.asc
Description: This is a digitally signed message part

Bug#681354: linux-image-2.6.32: Complaint from firewire driver at system startup.

On Thu, 2012-07-12 at 08:20 -0800, peasth...@shaw.ca wrote:
> Package: linux-2.6
> Version: 2.6.32-45
> File: linux-image-2.6.32
> Severity: normal
> Tags: upstream
> 
> *** Please type your report below this line ***
> 
> A firewire driver produces this complaint at system startup.
> Loading, please wait...
> [1.3380093] firewire_ohci: failed to set phy reg bits.
> 
> After a few seconds, startup continues normally; but IEEE 1394 should work 
> properly.  If instructed, I'm happy to investigate further.
[...]

Does the IEEE 1394 port work properly after this or not?  It isn't clear
from what you've said.  If not, can you test Linux 3.2 from testing,
unstable or squeeze-backports?

(The error message indicates a timeout while configuring the IEEE 1394
port.  The time limit for this has been increased in later versions of
the driver, and it may be that this would fix the problem.)

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou

signature.asc
Description: This is a digitally signed message part

Re: dpkg-deb: should give a hint when it fails due to filling /tmp

2012/7/13 Ben Hutchings :
> On Fri, Jul 13, 2012 at 11:02:57PM +0300, Martin-Éric Racine wrote:
>> (putting back the CC to the bug, which will probably need to be
>> reassigned to 'linux')
>> 2012/7/13 Jonathan Nieder :
>> > (dropping dpkg maintainers from cc)
>> > Martin-Éric Racine wrote:
>> >> 2012/7/13 Jonathan Nieder :
>> >>> Martin-Éric Racine wrote:
>> >
>>   the resulting DEB
>>  is a whopping 488MB in size, compared to 22MB for the stock Debian
>>  linux-image-3.2.0-3-686-pae built using the exact same .config file.
>> >>>
>> >>> That's because the Debian packaging strips debugging symbols into a
>> >>> separate -dbg package.
>> >>
>> >> I'm already aware of the effects of stripping binaries. However, you
>> >> gotta admit that 488MB compared to 22MB is just ridiculous; something
>> >> is definitely broken in those 3.2 build scripts.
>> >
>> > Are the build scripts responsible for the size of debugging symbols?
>> > I don't follow.
>> >
>> > Or do you mean that the size of the kernel -dbg packages is
>> > ridiculous?
>>
>> I mean that the size of the kernel package produced by 'make deb-pkg'
>> from the 3.2 vanilla tree, even after disabling debug symbols, is
>> highly suspicious, compared to the stock Debian kernel with the same
>> source.
>
> Did you actually rebuild with CONFIG_DEBUG_INFO off, or did you
> only re-run 'make deb-pkg'?

The plot thickens:

If I disable CONFIG_DEBUG_INFO again just before building, the kernel
indeed is MUCH smaller (I had probably forgotten to disable it before
attempting a new build; sorry for the confusion) and it easily builds
within the space allocated for /tmp using sysfs via initscripts.
However, it still comes out at about 8MB larger than the equivalent
stock Debian kernel:

-rw-r--r-- 1 perkelix perkelix 22M Jun 28 15:03
linux-image-3.2.0-3-686-pae_3.2.21-3_i386.deb
-rw-r--r-- 1 perkelix perkelix 30M Jul 14 01:31
linux-image-3.2.21-vanilla-686-pae_3.2.21-vanilla-686-pae-1_i386.deb

This is of course a minor issue at this point and something that can
be discussed separately from this bug. :)

As for bug #617299, the actual cause is three-folds:

1) Starting with Wheezy, /tmp is mounted as a tmpfs whose size is
determined by initscripts to 20% of available memory. On my laptop
with a modest 1GB of RAM, this meant a /tmp sized at 200MB.

2) As it happens, 'dpkg-deb -b' uses /tmp (unless somewhere else is
specified using TMPDIR) as temporary space to compress packages while
building them.

3) Whenever building a kernel using 'make deb-pkg' without first
having disabled CONFIG_DEBUG_INFO, the resulting *.deb can easily near
500MB in size using the stock .config on x86. This obviously exceeds
the available /tmp space allocated as tmpfs via initscripts, which is
how gzip ends up outputing the above error message about "No space
left on device" or "File not found" despite plenty of hard-disk space
being available.

The solution to bug #617299 is therefore to either define TMPDIR to
some actual hard-disk with sufficient storage space via a commandline
environment e.g. 'TMPDIR=/var/tmp make deb-pkg' whenever using
commands that require an unusually large amount of /tmp space, or to
completely disable the usage of a tmpfs for /tmp via initscripts
defaults in /etc/defaults/rcS and /etc/defaults/tmpfs, as appropriate.

Martin-Éric

--
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/CAPZXPQeEwHVNjSRJc_zO7i+EMh5LWZ7a=cw3hals6pahm98...@mail.gmail.com

Re: dpkg-deb: should give a hint when it fails due to filling /tmp

clone 617299 -1
retitle -1 kernel-handbook: encourage disabling DEBUG_INFO and setting TMPDIR
submitter -1 !
reassign -1 debian-kernel-handbook 1.0.13
quit

Martin-Éric Racine wrote:

> The solution to bug #617299 is therefore to either define TMPDIR to
> some actual hard-disk with sufficient storage space via a commandline
> environment e.g. 'TMPDIR=/var/tmp make deb-pkg' whenever using
> commands that require an unusually large amount of /tmp space, or to
> completely disable the usage of a tmpfs for /tmp via initscripts
> defaults in /etc/defaults/rcS and /etc/defaults/tmpfs, as appropriate.

Sort of.  It's still a dpkg (wishlist?) bug.  I would even think it
might be possible for dpkg-deb to write its output directly to the
expected target path or another file in the same directory.

Cloning as a reminder to recommend setting TMPDIR in the kernel
handbook.

Thanks,
Jonathan


--
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/20120714050923.GB3693@burratino

Processed: Re: dpkg-deb: should give a hint when it fails due to filling /tmp

2012-07-13 Thread Debian Bug Tracking System

Processing commands for cont...@bugs.debian.org:

> clone 617299 -1
Bug #617299 [dpkg] dpkg-deb: should give a hint when it fails due to filling 
/tmp
Bug 617299 cloned as bug 681550
> retitle -1 kernel-handbook: encourage disabling DEBUG_INFO and setting TMPDIR
Bug #681550 [dpkg] dpkg-deb: should give a hint when it fails due to filling 
/tmp
Changed Bug title to 'kernel-handbook: encourage disabling DEBUG_INFO and 
setting TMPDIR' from 'dpkg-deb: should give a hint when it fails due to filling 
/tmp'
> submitter -1 !
Bug #681550 [dpkg] kernel-handbook: encourage disabling DEBUG_INFO and setting 
TMPDIR
Changed Bug submitter to 'Jonathan Nieder ' from 'Yann 
Dirson '
> reassign -1 debian-kernel-handbook 1.0.13
Bug #681550 [dpkg] kernel-handbook: encourage disabling DEBUG_INFO and setting 
TMPDIR
Bug reassigned from package 'dpkg' to 'debian-kernel-handbook'.
No longer marked as found in versions dpkg/1.16.4.3 and dpkg/1.15.8.10.
Ignoring request to alter fixed versions of bug #681550 to the same values 
previously set
Bug #681550 [debian-kernel-handbook] kernel-handbook: encourage disabling 
DEBUG_INFO and setting TMPDIR
Marked as found in versions kernel-handbook/1.0.13.
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
617299: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617299
681550: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681550
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
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/handler.s.c.134224257432391.transcr...@bugs.debian.org

Bug#678443: Hard lockups due to "lockup-detector" (NMIs) on multi-Pentium-3 SMP systems on all kernel builds since 2.6.38