From: rh_ <richard_hubbe11@lavabit.com>
To: linux-kernel@vger.kernel.org
Subject: Re: apparent loss of continuity in kernel .config?
Date: Thu, 1 Jan 2015 11:24:24 -0800 [thread overview]
Message-ID: <20150101112424.2accee4e@127> (raw)
In-Reply-To: 201412310916.57808.gheskett@wdtv.com
On Wed, 31 Dec 2014 09:16:57 -0500
Gene Heskett <gheskett@wdtv.com> wrote:
> Greetings;
>
> Usually, when I build a new kernel, just placing a copy of an older
> versions .config in the unpacked src directory is sufficient that
> only what has been changed has to be answered during a make
> oldconfig, perhaps a couple dozen new features need to be answered
> yes or no, and I have a .config that will usually build me a bootable
> kernel. Not any more.
>
> Since my 3.16.0 has been suffering from stalls of up to 2 or 3
> minutes while both htop and gkrellm continue to report that there is
> nothing hogging the machine, in a general description that matches
> the Dave Jone saga, but w/o the log spew, probably because I don't
> have extreme debugging enabled.
>
> But its strange in how it manifests itself as it will do it from a
> fresh boot, and I get aggravated and reboot, and it doesn't do it
> till the next reboot which may be a month later. Almost an alternate
> boot phenomenon.
> Attempting to go from 3.16.0 to 3.16.7 last night, a make oldconfig
> started from scratch as if there were no .config's in the directory.
> I stood on the enter key to take the defaults, then ran a make
> xconfig to discover it was totally wrong for an AMD phenom, no
> networking, no disc drivers, video was an old ATI, when there is an
> nvidia card in it, yadda, yadda.
>
> I went thru this exercise 4 times, as I keep a gzipped copy on the
> config that built the kernel version in the boot directory with my
> build script. And every time it was the same story.
>
> Obviously I can't, at 80 yo, remember every item in a 28k .config
> file from build to build, so what am I doing wrong that is destroying
> this continuity?
>
> Thanks everybody.
Have you had any replies? I do similar but I may be less patient
than you. I keep dragging around my previous .config and when it
no longer works I just stay with the kernel that's working. And try
again later. It's been interesting to see what new things default
to "yes" along the way.
I would not call it "loss of continuity", I would call it loss of
backward compatibility. If the kernel breaks userspace it causes
a shitstorm but if the kernel breaks the kernel buildspace you're
supposed to suck it up and make a new .config from scratch.
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
Since voting machines,SCOTUS and juries have been compromised it
seems we're down to that last box.
next prev parent reply other threads:[~2015-01-01 19:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-31 14:16 apparent loss of continuity in kernel .config? Gene Heskett
2015-01-01 19:24 ` rh_ [this message]
2015-01-01 23:43 ` Gene Heskett
2015-01-02 16:59 ` rh_
2015-01-02 9:31 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150101112424.2accee4e@127 \
--to=richard_hubbe11@lavabit.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox