6:44 p.m.
Hi Bruno, Alan,
The rpmbuild interface does not provide the user a way
to go through the entire config options before proceeding
to build the kernel. If it does, I would really like to know
how it's done.
The current rpmbuild of the kernel builds bazillions of
drivers, most of which are very likely not needed by
the user's platform. This leads to an extremely time
consuming default build, and in my case, I have only
one machine which is a unicore.
Other problems are features that a user might neither
want nor need.
Is there a way to propagate this issue to development leads?
Thanx.
4:42 a.m.
On 28/11/12 18:52, Rick Stevens wrote:
I reiterate:
1. Install the kernel source RPM.
2. Navigate to your ~/rpmbuild/SPECS directory.
3. Do "rpmbuild -bp --target=x86_64 kernel.spec" or
"rpmbuild -bp --target=i686 kernel.spec" depending on your
processor.
4. Once that's complete, navigate to your
~rpmbuild/BUILD/kernel-3.6.fc17/linux-3.6.7-4.fc17.x86_64
directory. Read the "README" file. I say again, read the
README file!
5. Run "make nconfig" or "make xconfig" or whatever
"make *config" floats your boat and bugger the configuration
as you see fit.
6. Run "make" to build the kernel as you've specified. Follow
the directions in the README file's "COMPILING the kernel"
section.
That README file is chock full of what you need to do. This is the way
customized kernels are built. Always has been, probably always will be.
This is fine if you want a hand-built kernel and don't mind having to
manually save the config used for a given build and keep track of them
over time.
For development work that's normally convenient but if you're doing this
regularly to simply use the builds and want to keep track of your
changes and ensure they don't get mixed up or lost (what config options
did I enable in build x.y.z-foo??) using the SRPM and rpmbuild is easier
(you could also use a VCS but since the original question related to RPM
builds that doesn't seem to be the case).
Running an rpmbuild -ba will generate a new SRPM so as long as you keep
track of release numbers and preserve the SRPMs you can always go back
to see how a given binary RPM was configured (you also get the used
config-* included in it).
Regards,
Bryn.
4:35 p.m.
On Wed, 2012-11-28 at 13:10 -0800, Joe Zeff wrote:
What would be nice would be something like the traditional
./configure
that didn't just examine the build environment, but probed the hardware
and included the drivers you needed and only those. There would also be
(I hope) a way to specify extra drivers, such as for a camera that's not
always hooked up
In "those days", hot-plugged devices were rare. Now they are common. It
is a rare user indeed that doesn't have SOME device that isn't always
plugged in but does get used regularly. I don't think that very many
people these days would be able to use a "only compile for the currently
active devices" as a reasonable default. Maybe if you have a REALLY old
(pre-USB) system, but there are very few of those left in the hands of
non-geeks, I'll wager.
The truth is, it's really no big deal to have modules around that never
get loaded, and then if I do obtain a device later that uses them, they
get loaded and just work, and it won't be necessary for me to know which
module I need for my new hardware and/or recompile the kernel every time
I want to plug in a new device.
All that said, I can imagine some corner cases (e.g. developers who are
compiling the kernel every other day on relatively slow hardware) where
it might make sense to take the time to remove unused modules from the
compilation. But otherwise, it seems like it takes more time to
configure the unused modules out than it does to just wait for them to
compile. But whatever floats your boat...
--Greg
3:10 p.m.
On 11/28/2012 12:43 PM, JD wrote:
I do know about these rpmbuild options, which, when turned off
(--without xx)
does shorten the build time. But it is not enough. Building bazillions
of useless
(with regards to the user's HW platform) driver, enabling features by
default
which the user might not want, is what I would like to have a way for
the user
to have the fine grained configuration ability.
Back in the Second Millennium, when I first started using Linux, the
only way to update the kernel was to build your own. As most people
were still on dial-up, this was something you only did if you needed a
new feature, or if your current kernel was rather outdated.
When I first started doing this, the text-mode configure script was
fairly simple, and it was easy to know which features to include, which
to make into modules and which to ignore. By the time I moved from the
old-style RedHat to FC 6, there were so many options that I'd never
heard of that I was completely lost. I can just imagine what it would
be like today.
What would be nice would be something like the traditional ./configure
that didn't just examine the build environment, but probed the hardware
and included the drivers you needed and only those. There would also be
(I hope) a way to specify extra drivers, such as for a camera that's not
always hooked up, plus a few questions about whatever other options are
appropriate. That way, you'd get a customized kernel with exactly what
you need without having to be a hardware guru with a specialization in
CPU chips.
2:43 p.m.
On Wed, Nov 28, 2012 at 9:16 AM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
On Tue, Nov 27, 2012 at 6:44 PM, JD <jd1008(a)gmail.com> wrote:
> The rpmbuild interface does not provide the user a way
> to go through the entire config options before proceeding
> to build the kernel. If it does, I would really like to know
> how it's done.
>
I agree it's not intuitive but check and see if this is enough granularity
of control (from the spec file):
# The following build options are enabled by default.
# Use either --without <opt> in your rpmbuild command or force values
# to 0 in here to disable them.
#
# standard kernel
%define with_up %{?_without_up: 0} %{?!_without_up: 1}
# kernel-smp (only valid for ppc 32-bit)
%define with_smp %{?_without_smp: 0} %{?!_without_smp: 1}
# kernel-PAE (only valid for i686)
%define with_pae %{?_without_pae: 0} %{?!_without_pae: 1}
# kernel-debug
%define with_debug %{?_without_debug: 0} %{?!_without_debug: 1}
# kernel-doc
%define with_doc %{?_without_doc: 0} %{?!_without_doc: 1}
# kernel-headers
%define with_headers %{?_without_headers: 0} %{?!_without_headers: 1}
# perf
%define with_perf %{?_without_perf: 0} %{?!_without_perf: 1}
# tools
%define with_tools %{?_without_tools: 0} %{?!_without_tools: 1}
# kernel-debuginfo
%define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo:
1}
---end---
So you can do a rpmbuild -bb --without <option sans "with_">
HTH,
Richard
Thank you Richard.
I do know about these rpmbuild options, which, when turned off
(--without
xx)
does shorten the build time. But it is not enough. Building bazillions of
useless
(with regards to the user's HW platform) driver, enabling features by
default
which the user might not want, is what I would like to have a way for the
user
to have the fine grained configuration ability.
11:46 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/28/2012 05:07 PM, JD wrote:
The main point is that the build takes too darned long. On my
unicore cpu, it takes almost 2 days. Building bazillions of useless
modules is a great waste of time and machine.
If you want to change the set of modules enabled you'll have to do a
bit more as the kernel .config options aren't exposed in the spec file
in a way that you can control via rpmbuild options.
That said, you should check out Richard's suggestion as you may find
that it's the many variant (up/smp/pae/debug/debuginfo etc.)
sub-packages that are chewing up the time for you. If turning those
off gives you an acceptable build time it's less invasive than munging
the KConfig options to drop unneeded modules.
If you decide you do need to do that though you'll need to install the
SRPM (either with bare RPM build directory or via mock) so that you
can get access to the individual sources and patches that make it up.
If you're using the normal RPM directory layout then the files you're
interested in will end up in $rpmbuild/SOURCES (where $rpmbuild is
whatever RPM's %_topdir macro is set to).
For the kernel the interesting files are config-*-generic,
config-*-smp etc., Makefile.config and a perl script named merge.pl:
$ cd rpmbuild/SOURCES
$ ls config-* merge.pl Makefile.config
config-arm-generic config-powerpc32-generic
config-arm-highbank config-powerpc32-smp
config-arm-imx config-powerpc64
config-arm-kirkwood config-powerpc-generic
config-arm-omap-generic config-rhel-generic
config-arm-tegra config-s390x
config-debug config-sparc64-generic
config-generic config-x86-32-generic
config-i686-PAE config-x86_64-generic
config-local config-x86-generic
config-nodebug merge.pl
Makefile.config
The structure of the config files is fairly self-explanatory;
config-generic is the global catch-all and architectures and variants
(e.g. PAE, smp) can override specific values as needed.
If you just want to make a few local changes you can drop them into
config-local - this should have the highest precedence and is is
automatically merged by kernel.spec during %prep.
Regards,
Bryn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlC2TesACgkQ6YSQoMYUY979UACaA9xfSrM+sWT8c7FZsg+ecBwQ
8Z8AniFen3ow85YQrSO0B3YAb5a6LIXo
=PM95
-----END PGP SIGNATURE-----
11:16 a.m.
On Tue, Nov 27, 2012 at 6:44 PM, JD <jd1008(a)gmail.com> wrote:
The rpmbuild interface does not provide the user a way
to go through the entire config options before proceeding
to build the kernel. If it does, I would really like to know
how it's done.
I agree it's not intuitive but check and see if this is enough granularity
of control (from the spec file):
# The following build options are enabled by default.
# Use either --without <opt> in your rpmbuild command or force values
# to 0 in here to disable them.
#
# standard kernel
%define with_up %{?_without_up: 0} %{?!_without_up: 1}
# kernel-smp (only valid for ppc 32-bit)
%define with_smp %{?_without_smp: 0} %{?!_without_smp: 1}
# kernel-PAE (only valid for i686)
%define with_pae %{?_without_pae: 0} %{?!_without_pae: 1}
# kernel-debug
%define with_debug %{?_without_debug: 0} %{?!_without_debug: 1}
# kernel-doc
%define with_doc %{?_without_doc: 0} %{?!_without_doc: 1}
# kernel-headers
%define with_headers %{?_without_headers: 0} %{?!_without_headers: 1}
# perf
%define with_perf %{?_without_perf: 0} %{?!_without_perf: 1}
# tools
%define with_tools %{?_without_tools: 0} %{?!_without_tools: 1}
# kernel-debuginfo
%define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo: 1}
---end---
So you can do a rpmbuild -bb --without <option sans "with_">
HTH,
Richard
11:07 a.m.
On Tue, Nov 27, 2012 at 6:19 PM, William Brown <william(a)firstyear.id.au>wrote:
On Tue, 2012-11-27 at 21:06 -0500, Brian West wrote:
> On 11/27/2012 07:44 PM, JD wrote:
> > Hi Bruno, Alan,
> >
> > The rpmbuild interface does not provide the user a way
> > to go through the entire config options before proceeding
> > to build the kernel. If it does, I would really like to know
> > how it's done.
> >
http://fedoraproject.org/wiki/Building_a_custom_kernel
> > Thanx.
> i second that this would be nice so that we can tailor our kernels to
> our config and not have unrequired drivers.
The current kernel is module based, so you don't have "unneeded drivers"
loaded.
The main point is that the build takes too darned long.
On my unicore cpu, it takes almost 2 days.
Building bazillions of useless modules is a great waste of time and machine.
8:47 p.m.
On 11/27/2012 06:06 PM, Brian West issued this missive:
On 11/27/2012 07:44 PM, JD wrote:
> Hi Bruno, Alan,
>
> The rpmbuild interface does not provide the user a way
> to go through the entire config options before proceeding
> to build the kernel. If it does, I would really like to know
> how it's done.
>
> The current rpmbuild of the kernel builds bazillions of
> drivers, most of which are very likely not needed by
> the user's platform. This leads to an extremely time
> consuming default build, and in my case, I have only
> one machine which is a unicore.
>
> Other problems are features that a user might neither
> want nor need.
>
> Is there a way to propagate this issue to development leads?
>
> Thanx.
i second that this would be nice so that we can tailor our kernels to
our config and not have unrequired drivers.
rpmbuild's "-ba" option is there to create full binary and source
kernel RPMs. By definition, most modules will be built because that's
how the kernel is distributed. If you want to limit what gets built,
you have to change the build's config file. There's nothing mysterious
about it and the process hasn't changed in at least four years.
Start using the "-bp" option to rpmbuild. After that, go into your
~/rpmbuild/BUILD/kernel-xxx/linux-xxx directory, run "make nconfig",
bugger the config there, save it and do the normal kernel make/make
install operations. Check the README file in that directory for options
on how to configure and how to compile.
Really, it's been like this for a LONG time.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- If your broker is so damned smart...why is he still working? -
----------------------------------------------------------------------
8:28 p.m.
On 11/27/2012 09:19 PM, William Brown wrote:
On Tue, 2012-11-27 at 21:06 -0500, Brian West wrote:
> On 11/27/2012 07:44 PM, JD wrote:
>> Hi Bruno, Alan,
>>
>> The rpmbuild interface does not provide the user a way
>> to go through the entire config options before proceeding
>> to build the kernel. If it does, I would really like to know
>> how it's done.
>>
http://fedoraproject.org/wiki/Building_a_custom_kernel
>> Thanx.
> i second that this would be nice so that we can tailor our kernels to
> our config and not have unrequired drivers.
The current kernel is module based, so you don't have "unneeded drivers"
loaded.
So does this mean that when you install fedora or update your kernel
that it only configures the modules that your hardware requires thus
creating a custom kernel for your system?
-Brian
8:19 p.m.
On Tue, 2012-11-27 at 21:06 -0500, Brian West wrote:
On 11/27/2012 07:44 PM, JD wrote:
> Hi Bruno, Alan,
>
> The rpmbuild interface does not provide the user a way
> to go through the entire config options before proceeding
> to build the kernel. If it does, I would really like to know
> how it's done.
>
http://fedoraproject.org/wiki/Building_a_custom_kernel
> Thanx.
i second that this would be nice so that we can tailor our kernels to
our config and not have unrequired drivers.
The current kernel is module based, so you don't have "unneeded drivers"
loaded.
--
Sincerely,
William Brown
pgp.mit.edu
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x3C0AC6DAB2F928A2
8:06 p.m.
On 11/27/2012 07:44 PM, JD wrote:
Hi Bruno, Alan,
The rpmbuild interface does not provide the user a way
to go through the entire config options before proceeding
to build the kernel. If it does, I would really like to know
how it's done.
The current rpmbuild of the kernel builds bazillions of
drivers, most of which are very likely not needed by
the user's platform. This leads to an extremely time
consuming default build, and in my case, I have only
one machine which is a unicore.
Other problems are features that a user might neither
want nor need.
Is there a way to propagate this issue to development leads?
Thanx.
i second that this would be nice so that we can tailor our kernels to
our config and not have unrequired drivers.
-Brian
12:52 p.m.
On 11/28/2012 09:46 AM, Bryn M. Reeves issued this missive:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/28/2012 05:07 PM, JD wrote:
> The main point is that the build takes too darned long. On my
> unicore cpu, it takes almost 2 days. Building bazillions of useless
> modules is a great waste of time and machine.
If you want to change the set of modules enabled you'll have to do a
bit more as the kernel .config options aren't exposed in the spec file
in a way that you can control via rpmbuild options.
That said, you should check out Richard's suggestion as you may find
that it's the many variant (up/smp/pae/debug/debuginfo etc.)
sub-packages that are chewing up the time for you. If turning those
off gives you an acceptable build time it's less invasive than munging
the KConfig options to drop unneeded modules.
If you decide you do need to do that though you'll need to install the
SRPM (either with bare RPM build directory or via mock) so that you
can get access to the individual sources and patches that make it up.
If you're using the normal RPM directory layout then the files you're
interested in will end up in $rpmbuild/SOURCES (where $rpmbuild is
whatever RPM's %_topdir macro is set to).
For the kernel the interesting files are config-*-generic,
config-*-smp etc., Makefile.config and a perl script named merge.pl:
$ cd rpmbuild/SOURCES
$ ls config-* merge.pl Makefile.config
config-arm-generic config-powerpc32-generic
config-arm-highbank config-powerpc32-smp
config-arm-imx config-powerpc64
config-arm-kirkwood config-powerpc-generic
config-arm-omap-generic config-rhel-generic
config-arm-tegra config-s390x
config-debug config-sparc64-generic
config-generic config-x86-32-generic
config-i686-PAE config-x86_64-generic
config-local config-x86-generic
config-nodebug merge.pl
Makefile.config
The structure of the config files is fairly self-explanatory;
config-generic is the global catch-all and architectures and variants
(e.g. PAE, smp) can override specific values as needed.
If you just want to make a few local changes you can drop them into
config-local - this should have the highest precedence and is is
automatically merged by kernel.spec during %prep.
I reiterate:
1. Install the kernel source RPM.
2. Navigate to your ~/rpmbuild/SPECS directory.
3. Do "rpmbuild -bp --target=x86_64 kernel.spec" or
"rpmbuild -bp --target=i686 kernel.spec" depending on your
processor.
4. Once that's complete, navigate to your
~rpmbuild/BUILD/kernel-3.6.fc17/linux-3.6.7-4.fc17.x86_64
directory. Read the "README" file. I say again, read the
README file!
5. Run "make nconfig" or "make xconfig" or whatever
"make *config" floats your boat and bugger the configuration
as you see fit.
6. Run "make" to build the kernel as you've specified. Follow
the directions in the README file's "COMPILING the kernel"
section.
That README file is chock full of what you need to do. This is the way
customized kernels are built. Always has been, probably always will be.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- I was married by a judge. I should have asked for a jury. -
- -- Groucho Marx -
----------------------------------------------------------------------
4164
days inactive
4165
days old
12 comments
8 participants
participants (8)
-
Brian West -
Bryn M. Reeves -
Greg Woods -
JD -
Joe Zeff -
Richard Shaw -
Rick Stevens -
William