Linux 3.2-rc1
Linus Torvalds
I have to say, this wasn't my favorite merge window ever. I really
wanted to take only things that had been in -next, but verifying it
was fairly painful, since a lot of the trees had been rebased, and the
ones that hadn't been rebased often had some extra patches that still
showed up when I did my "git log linux-next..FETCH_HEAD" thing.
On the whole, most of it was all good, and I didn't really end up
complaining to people. I'm pretty sure that there were trees I
shouldn't have let through, but the majority really had been in -next.
The other point of irritation was that there really was a lot of stuff
that came in yesterday and basically treated the merge window as some
kind of high-tech limbo dance. If it hadn't been for a few trees I
wanted to pull, I had actually planned to do the -rc1 release Sunday
afternoon instead, just to cut those annoying last-minute pull
requests off.
And some trees didn't get pulled. You know who you are, and you can
try to appeal to my softer side if you think it was unfair. Of course,
if you *do* find my softer side, please tell my wife and kids too,
they'll be thrilled.
But the main reason some trees didn't get pulled was that they
generated long flame-wars, and I just felt like I really didn't need
the aggravation this time around, especially as I knew I had plenty
other trees to pull.
What *did* get pulled? A lot. The diffstat is huge, and is full of
renames. The network drivers got re-organized, which is a big chunk of
the renames, but there are architecture cleanups and re-organizations
there too (UML and some arm sub-architectures, for example) adding
their own set of renames. Along with some staging drivers that got
upgraded to non-staging etc etc.
Which brings me to a question I already asked on G+ - do people really
need the old-fashioned patches? The -rc1 patch is about 22MB gzip-9'd,
and part of the reason is that all those renames cause big
delete/create diffs. We *could* use git rename patches, but then you'd
have to apply them with "git apply" rather than the legacy "patch"
executables. But as it is, the patch is almost a third of the size of
the tar-ball, which makes me wonder if there's even any point to such
a big patch?
Apart from the re-organization, there is really just a lot of changes
all over. It's about 75% drivers (and that's without the renames
counted as big delete/create events - in the traditional diff, more
than 90% is drivers), 15% arch, and 10% "rest" (mainly fs and net -
with header file changes showing up in the statistics too).
What doesn't even show up in the stats is the VM changes, although
those may well be the most noticeable core stuff. It may be fairly
small, but it's rather more core, and has the potential to affect
everybody. People have been working on writeback tuning, and the whole
IO-less dirty balancing. So now foreground writeback should be a thing
of the past. Let's see how that all works out.
Have fun, give it a good testing. There shouldn't be anything hugely
scary in there, but there *is* a lot of stuff. The fact that 3.1
dragged out did mean that this ended up being one of the bigger merge
windows, but I'm not feeling *too* nervous about it.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Al Viro
> Which brings me to a question I already asked on G+ - do people really
> need the old-fashioned patches? The -rc1 patch is about 22MB gzip-9'd,
> and part of the reason is that all those renames cause big
> delete/create diffs. We *could* use git rename patches, but then you'd
> have to apply them with "git apply" rather than the legacy "patch"
> executables. But as it is, the patch is almost a third of the size of
> the tar-ball, which makes me wonder if there's even any point to such
> a big patch?
FWIW, agruen seems to be doing patch(1) development these days; the last
snapshot has this in NEWS:
* Support for most features of the "diff --git" format: renames and copies,
permission changes, symlink diffs. Caveats:
+ Binary diffs are not supported yet; patch will complain and skip them.
+ In the "diff --git" format, all the patches are relative to the original
state of the files to patch, allowing things like criss-cross renames.
GNU patch will currently fail for such patches.
* Support for double-quoted filenames in the "diff --git" format: when a
filename in a context diff starts with a double quote, it is interpreted
as a C string literal. The escape sequences \\, \", \a, \b, \f, \n, \r,
\t, \v, and \ooo (a three-digit octal number between 0 and 255) are
recognized.
Hell knows how long until they release it and distros pick the result, of
course. Their git tree on git://git.savannah.gnu.org/patch.git is fairly
quiet; there had been a bunch of local fixes since the last snapshot (this
April) but not much else...
Linus Torvalds
>
> FWIW, agruen seems to be doing patch(1) development these days; the last
> snapshot has this in NEWS:
>
> * Support for most features of the "diff --git" format: renames and copies,
> �permission changes, symlink diffs.
Oh, good.
>�Caveats:
> �+ Binary diffs are not supported yet; patch will complain and skip them.
> �+ In the "diff --git" format, all the patches are relative to the original
> � �state of the files to patch, allowing things like criss-cross renames.
> � �GNU patch will currently fail for such patches.
This is all fine. The criss-cross renames are possible, but I don't
generate them: you need to specify the "-B" flag to git to "break"
existing names, and none of my normal kernel patches ever do that. It
can be useful to find cases where people have renamed things on top of
existing files (which does happen occasionally), but on the whole it's
not a big feature.
And the binary patches we've always generated the magical git binary
version of, since there is no traditional format for that at all - and
it has never been a problem in practice. I think the only binary file
we have is the logo, and that one doesn't change.
So it sounds like 'patch' will handle all the cases that are really relevant.
> Hell knows how long until they release it and distros pick the result, of
> course. �Their git tree on git://git.savannah.gnu.org/patch.git is fairly
> quiet; there had been a bunch of local fixes since the last snapshot (this
> April) but not much else...
It sounds like I should continue to do the traditional patches for a
while longer, but it does sound like it's an issue that will fix
itself in the not too distant future. Goodie.
Linus
Nicholas A. Bellinger
> So it's been two weeks since 3.1, and you know how it works by now.
>
> I have to say, this wasn't my favorite merge window ever. I really
> wanted to take only things that had been in -next, but verifying it
> was fairly painful, since a lot of the trees had been rebased, and the
> ones that hadn't been rebased often had some extra patches that still
> showed up when I did my "git log linux-next..FETCH_HEAD" thing.
>
> On the whole, most of it was all good, and I didn't really end up
> complaining to people. I'm pretty sure that there were trees I
> shouldn't have let through, but the majority really had been in -next.
>
> The other point of irritation was that there really was a lot of stuff
> that came in yesterday and basically treated the merge window as some
> kind of high-tech limbo dance. If it hadn't been for a few trees I
> wanted to pull, I had actually planned to do the -rc1 release Sunday
> afternoon instead, just to cut those annoying last-minute pull
> requests off.
>
> And some trees didn't get pulled. You know who you are, and you can
> try to appeal to my softer side if you think it was unfair. Of course,
> if you *do* find my softer side, please tell my wife and kids too,
> they'll be thrilled.
>
> But the main reason some trees didn't get pulled was that they
> generated long flame-wars, and I just felt like I really didn't need
> the aggravation this time around, especially as I knew I had plenty
> other trees to pull.
>
Hi Linus,
(Just asking once more, so if you're really over it please ignore the
following..)
Is there any chance to get a merge window exception for the ib_srpt
driver..? We (Roland, Bart + myself) have agreed on the userspace
configfs API, and we collectively made forward progress without any
extra controversy or flames this time around. A first in the history of
mainline target mode code development!
That said, ib_srpt has been getting build testing in linux-next and is a
stand-alone driver that does not modify any existing external code, so
the merge risk is nill. The main reason I'm asking for the exception is
that we have a very time and resource intensive effort underway for v3.3
to get the qla2xxx FC target merged. So if your not completely joking
about appealing to the benevolent dictator here, please consider making
an one time exception for ib_srpt.
Thank you for the extra consideration,
--nab
Geert Uytterhoeven
<torv...@linux-foundation.org> wrote:
> And the binary patches we've always generated the magical git binary
> version of, since there is no traditional format for that at all - and
> it has never been a problem in practice. I think the only binary file
> we have is the logo, and that one doesn't change.
The logos are ASCII PNM files.
There are a few PDFs in Documentation/DocBook/media/{dvb,v4l}/ though
(strange, never noticed them before).
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
Udo Steinberg
LT> Have fun, give it a good testing. There shouldn't be anything hugely
LT> scary in there, but there *is* a lot of stuff. The fact that 3.1
LT> dragged out did mean that this ended up being one of the bigger merge
LT> windows, but I'm not feeling *too* nervous about it.
Hi,
The formatting of /proc/misc broke for cpu_dma_latency. This causes programs
reading from /proc/misc to complain. For example:
cryptsetup luksClose /dev/sdX
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
With Linux 3.2-rc1:
60 network_throughput
61 network_latency
62
236 device-mapper
237 loop-control
175 agpgart
144 nvram
231 snapshot
184 microcode
227 mcelog
63 vga_arbiter
With Linux 3.1:
60 network_throughput
61 network_latency
62 cpu_dma_latency
236 device-mapper
237 loop-control
175 agpgart
144 nvram
231 snapshot
184 microcode
227 mcelog
63 vga_arbiter
Cheers,
- Udo
Ming Lei
> On Mon, 7 Nov 2011 18:10:02 -0800 Linus Torvalds (LT) wrote:
>
> LT> Have fun, give it a good testing. There shouldn't be anything hugely
> LT> scary in there, but there *is* a lot of stuff. The fact that 3.1
> LT> dragged out did mean that this ended up being one of the bigger merge
> LT> windows, but I'm not feeling *too* nervous about it.
>
> Hi,
>
> The formatting of /proc/misc broke for cpu_dma_latency. This causes programs
The patch in blow link can fix the issue, maybe Rafael will push it out in -rc2.
http://marc.info/?l=linux-pm&m=132065404031749&w=2
thanks,
--
Ming Lei
Alessandro Suardi
Dell laptop support (and I'd suspect other drivers using LED support)
doesn't build with undefined LED-related functions, as in:
ERROR: "led_classdev_unregister" [drivers/platform/x86/dell-laptop.ko]
undefined!
ERROR: "led_classdev_register" [drivers/platform/x86/dell-laptop.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
It's enough to configure NEW_LEDS (unneeded in 3.1.0) to allow the build to go
through; maybe NEW_LEDS should be auto-selected in Kconfig by drivers that
make use of led_classdev_* functions ?
--alessandro
�"There's always a siren singing you to shipwreck"
�� (Radiohead, "There There")
Nick Bowler
> Have fun, give it a good testing. There shouldn't be anything hugely
> scary in there, but there *is* a lot of stuff. The fact that 3.1
> dragged out did mean that this ended up being one of the bigger merge
> windows, but I'm not feeling *too* nervous about it.
Mode switches are very noisy on an Intel G45 in 3.2-rc1:
HDMI hot plug event: Codec=3 Pin=3 Presence_Detect=1 ELD_Valid=1
HDMI status: Codec=3 Pin=3 Presence_Detect=1 ELD_Valid=1
HDMI: detected monitor W2253 at connection type HDMI
HDMI: available speakers: FL/FR
HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000, bits = 16 20 24
These lines get printed every single switch; previously only a single
line was printed once at boot (the "HDMI status" line).
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Thomas Bächler
> Which brings me to a question I already asked on G+ - do people really
> need the old-fashioned patches? The -rc1 patch is about 22MB gzip-9'd,
> and part of the reason is that all those renames cause big
> delete/create diffs. We *could* use git rename patches, but then you'd
> have to apply them with "git apply" rather than the legacy "patch"
> executables. But as it is, the patch is almost a third of the size of
> the tar-ball, which makes me wonder if there's even any point to such
> a big patch?
From a distro packager's point of view, I can say this:
For packaging, we always use the latest .0 release tarball and patch it
with the -stable patch files from kernel.org. It would be desirable if
those would keep working with GNU patch - not necessary though because
'git apply' doesn't require a git repository.
When packaging development versions of the kernel, it is much easier to
pull the lastest code directly from the git tree, so I never needed the
patch files for the -rc's.
Linus Torvalds
<alessand...@gmail.com> wrote:
>
> Dell laptop support (and I'd suspect other drivers using LED support)
> �doesn't build with undefined LED-related functions, as in:
>
> ERROR: "led_classdev_unregister" [drivers/platform/x86/dell-laptop.ko]
> undefined!
> ERROR: "led_classdev_register" [drivers/platform/x86/dell-laptop.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> It's enough to configure NEW_LEDS (unneeded in 3.1.0) to allow the build to go
> �through; maybe NEW_LEDS should be auto-selected in Kconfig by drivers that
> �make use of led_classdev_* functions ?
Yeah, that sounds like the right fix. There are a lot of "select
NEW_LEDS" around already, but apparently not the Dell driver.
Matthew?
Linus
Matthew Garrett
> On Tue, Nov 8, 2011 at 6:53 AM, Alessandro Suardi
> <alessand...@gmail.com> wrote:
> >
> > Dell laptop support (and I'd suspect other drivers using LED support)
> > �doesn't build with undefined LED-related functions, as in:
> >
> > ERROR: "led_classdev_unregister" [drivers/platform/x86/dell-laptop.ko]
> > undefined!
> > ERROR: "led_classdev_register" [drivers/platform/x86/dell-laptop.ko] undefined!
> > make[1]: *** [__modpost] Error 1
> > make: *** [modules] Error 2
> >
> > It's enough to configure NEW_LEDS (unneeded in 3.1.0) to allow the build to go
> > �through; maybe NEW_LEDS should be auto-selected in Kconfig by drivers that
> > �make use of led_classdev_* functions ?
>
> Yeah, that sounds like the right fix. There are a lot of "select
> NEW_LEDS" around already, but apparently not the Dell driver.
Sorry, missed that change. Yes, that sounds completely reasonable.
--
Matthew Garrett | mj...@srcf.ucam.org
Linus Torvalds
i915 people and the HDA people to the cc, and they can fight to the
death about this in the HDMI Thunderdome.
Guys: One.. Two.. Three.. FIGHT!
Linus
Linus Torvalds
<torv...@linux-foundation.org> wrote:
>
> Yeah, that sounds like the right fix. There are a lot of "select
> NEW_LEDS" around already, but apparently not the Dell driver.
Hmm. Interesting. Selecting NEW_LEDS (and LEDS_CLASS) leads to some
insane Kconfig warnings. Will have to take a look at what makes that
Dell driver different from the other laptop drivers that do the same..
Rafael J. Wysocki
> On Tue, Nov 8, 2011 at 9:43 PM, Udo Steinberg <u...@hypervisor.org> wrote:
> > On Mon, 7 Nov 2011 18:10:02 -0800 Linus Torvalds (LT) wrote:
> >
> > LT> Have fun, give it a good testing. There shouldn't be anything hugely
> > LT> scary in there, but there *is* a lot of stuff. The fact that 3.1
> > LT> dragged out did mean that this ended up being one of the bigger merge
> > LT> windows, but I'm not feeling *too* nervous about it.
> >
> > Hi,
> >
> > The formatting of /proc/misc broke for cpu_dma_latency. This causes programs
>
> The patch in blow link can fix the issue, maybe Rafael will push it out in -rc2.
>
> http://marc.info/?l=linux-pm&m=132065404031749&w=2
Yes, I've just sent a pull request with this one.
Thanks,
Rafael
Steven Rostedt
>
> I have to say, this wasn't my favorite merge window ever. I really
> wanted to take only things that had been in -next, but verifying it
> was fairly painful, since a lot of the trees had been rebased, and the
> ones that hadn't been rebased often had some extra patches that still
> showed up when I did my "git log linux-next..FETCH_HEAD" thing.
>
> On the whole, most of it was all good, and I didn't really end up
> complaining to people. I'm pretty sure that there were trees I
> shouldn't have let through, but the majority really had been in -next.
>
> The other point of irritation was that there really was a lot of stuff
> that came in yesterday and basically treated the merge window as some
> kind of high-tech limbo dance. If it hadn't been for a few trees I
> wanted to pull, I had actually planned to do the -rc1 release Sunday
> afternoon instead, just to cut those annoying last-minute pull
> requests off.
>
> And some trees didn't get pulled. You know who you are, and you can
> try to appeal to my softer side if you think it was unfair. Of course,
> if you *do* find my softer side, please tell my wife and kids too,
> they'll be thrilled.
/me searches for the softer side.
>
> But the main reason some trees didn't get pulled was that they
> generated long flame-wars, and I just felt like I really didn't need
> the aggravation this time around, especially as I knew I had plenty
> other trees to pull.
Is there a reason that the ktest tree didn't get pulled? Is it because
it is not in next (nor has it ever been). I could arrange to put it
there, but as it is a simple tool in the tools directory I didn't think
it required the next processing. But I could update that if so desired.
There hasn't been any flame wars on ktest either, so that could not be
it. Maybe I could start a flame war with myself to get it more
attention.
Anyway, the pull request is here, hopefully that softside exists.
https://lkml.org/lkml/2011/10/28/97
Thanks!
-- Steve
Linus Torvalds
>
> Is there a reason that the ktest tree didn't get pulled?
No, just was always below the radar for me, and ended up never happening.
You're good, I pulled. Your pull request came in early, there was no
real problem with it, just dropped.
Linus
Takashi Iwai
Linus Torvalds wrote:
>
> Hmm, I don't know what caused this to trigger, but I'm adding both the
> i915 people and the HDA people to the cc, and they can fight to the
> death about this in the HDMI Thunderdome.
It must be the new addition of ELD-passing code.
Fengguang, can the drm or i915 driver check whether ELD is changed or
not? Writing ELD at each time even when unchanged confuses the audio
side, as if the monitor is hotplugged.
>
> Guys: One.. Two.. Three.. FIGHT!
Round two!
Takashi
Borislav Petkov
> There hasn't been any flame wars on ktest either, so that could not be
> it. Maybe I could start a flame war with myself to get it more
> attention.
Sh*t, Linus beat me to it - I was just about to send a mail with the
subject "ktest is crap" ... Stupid timezones difference.
:-)
--
Regards/Gruss,
Boris
Wu Fengguang
> At Tue, 8 Nov 2011 12:23:30 -0800,
> Linus Torvalds wrote:
> >
> > Hmm, I don't know what caused this to trigger, but I'm adding both the
> > i915 people and the HDA people to the cc, and they can fight to the
> > death about this in the HDMI Thunderdome.
>
> It must be the new addition of ELD-passing code.
Yes, it's my fault.
> Fengguang, can the drm or i915 driver check whether ELD is changed or
> not? Writing ELD at each time even when unchanged confuses the audio
> side, as if the monitor is hotplugged.
It's sure possible to mask out the extra events.
I'll work out a patch tomorrow.
> > Guys: One.. Two.. Three.. FIGHT!
>
> Round two!
Three to fight!
Thanks,
Fengguang
Valdis.K...@vt.edu
> There hasn't been any flame wars on ktest either, so that could not be
> it. Maybe I could start a flame war with myself to get it more
> attention.
No, only the two Paul McKenney's are allowed to do that. ;)
Paul Rolland
On Mon, 7 Nov 2011 18:10:02 -0800
Linus Torvalds <torv...@linux-foundation.org> wrote:
> Which brings me to a question I already asked on G+ - do people really
> need the old-fashioned patches? The -rc1 patch is about 22MB gzip-9'd,
> and part of the reason is that all those renames cause big
> delete/create diffs. We *could* use git rename patches, but then you'd
> have to apply them with "git apply" rather than the legacy "patch"
> executables. But as it is, the patch is almost a third of the size of
> the tar-ball, which makes me wonder if there's even any point to such
> a big patch?
Is that what made the various tarballs for 3.2-rc1 land
in /pub/linux/kernel/v3.x and not in testing/ ? ;)
I spent quite a lot of time wondering where they could be in testing/ until
I accidently found them...
Anyway, to answer the initial question: no, I don't use the patch-blah
files, only full tarballs.
Best,
Paul
Randy Dunlap
> Which brings me to a question I already asked on G+ - do people really
> need the old-fashioned patches? The -rc1 patch is about 22MB gzip-9'd,
> and part of the reason is that all those renames cause big
> delete/create diffs. We *could* use git rename patches, but then you'd
> have to apply them with "git apply" rather than the legacy "patch"
> executables. But as it is, the patch is almost a third of the size of
> the tar-ball, which makes me wonder if there's even any point to such
> a big patch?
[email was too long/noisy, sorry for the delayed reply.]
[should I admit that I don't follow you on g+ ?]
Do you mean files like patch-3.2-rc1.gz or .bz2 or .xz?
Yes, I use them, but if I am the only user of them, I'll get over it.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Josh Boyer
> On 11/07/2011 06:10 PM, Linus Torvalds wrote:
>
>> Which brings me to a question I already asked on G+ - do people really
>> need the old-fashioned patches? The -rc1 patch is about 22MB gzip-9'd,
>> and part of the reason is that all those renames cause big
>> delete/create diffs. We *could* use git rename patches, but then you'd
>> have to apply them with "git apply" rather than the legacy "patch"
>> executables. But as it is, the patch is almost a third of the size of
>> the tar-ball, which makes me wonder if there's even any point to such
>> a big patch?
>
> [email was too long/noisy, sorry for the delayed reply.]
> [should I admit that I don't follow you on g+ ?]
>
>
> Do you mean files like patch-3.2-rc1.gz or .bz2 or .xz?
> Yes, I use them, but if I am the only user of them, I'll get over it.
Fedora uses those. We also used the -gitX snapshot patches when they
were generated, but now we do that by hand (which we also did for the
-rcX patches while kernel.org was down.)
josh
Linus Torvalds
>
> Is that what made the various tarballs for 3.2-rc1 land
> in /pub/linux/kernel/v3.x and not in testing/ ? ;)
No, that was just my release-script not putting them in the right place.
With the kernel.org security changes, the way I upload the files
changed radically, and my release script was broken. Blush.
Wu Fengguang
On Wed, Nov 09, 2011 at 03:40:19PM +0800, Takashi Iwai wrote:
> At Tue, 8 Nov 2011 12:23:30 -0800,
> Linus Torvalds wrote:
> >
> > Hmm, I don't know what caused this to trigger, but I'm adding both the
> > i915 people and the HDA people to the cc, and they can fight to the
> > death about this in the HDMI Thunderdome.
>
> It must be the new addition of ELD-passing code.
>
> Fengguang, can the drm or i915 driver check whether ELD is changed or
> not? Writing ELD at each time even when unchanged confuses the audio
> side, as if the monitor is hotplugged.
The attached patch is tested OK to prevent extra hot plug events.
However it has one side effect: when HDMI monitor is hot removed,
the ELD keeps remain valid. I need to find a way to test for the
presence of the monitor and handle that case as well. When all done,
I'll submit the patches together for review.
Thanks,
Fengguang
Boaz Harrosh
>
> Fedora uses those. We also used the -gitX snapshot patches when they
> were generated, but now we do that by hand (which we also did for the
> -rcX patches while kernel.org was down.)
>
> josh
My god that totally-brain-dead Fedora Kernel rpm generation.
RANT a head should be skipped!!
I wish there was a strait forward way to point to a Kernel
git tree HEAD and say "make rpm", which is simply the tar
of the "make modules_install" and the "make install" output
+ a simple script to manipulate grub.conf
Not today's Fedora-Kernel git tree which is not a Linux
git tree at all but those patches above + stable.
Any simple tree moments needs to involve black patch magic
and fear of hell. (Don't try this at home)
Actually the "grub-selector" should have been it's own
rpm. And each Kernel can/should be it's own independent
(none conflicting, right) package. I know, I know, it tries
to be that, but it is not. For example I want a low-latency
rt Kernel as a side choice for any Kernel, and so on...
Throw away that monstrous Fedora-Kernel-tree. There is
only one Kernel tree it is called Linux. You can do your
own back/forward port branches based on stable to your
heart's content with out inventing a new totally different
patches tree.
Someone stop me. There is no end to the RANT I can
generate about Fedora Kernel release
Boaz
Josh Boyer
> On 11/09/2011 09:28 AM, Josh Boyer wrote:
>>
>> Fedora uses those. �We also used the -gitX snapshot patches when they
>> were generated, but now we do that by hand (which we also did for the
>> -rcX patches while kernel.org was down.)
>>
>> josh
>
> My god that totally-brain-dead Fedora Kernel rpm generation.
>
> RANT a head should be skipped!!
>
> I wish there was a strait forward way to point to a Kernel
> git tree HEAD and say "make rpm", which is simply the tar
> of the "make modules_install" and the "make install" output
> + a simple script to manipulate grub.conf
I'm actually thinking about creating an exploded source Fedora git
tree. I just haven't gotten around to it yet because it's not exactly
straight-forward.
> Not today's Fedora-Kernel git tree which is not a Linux
> git tree at all but those patches above + stable.
> Any simple tree moments needs to involve black patch magic
> and fear of hell. (Don't try this at home)
There's a wiki page on building your own Fedora kernel. It's really
not that complicated.
> Actually the "grub-selector" should have been it's own
> rpm. And each Kernel can/should be it's own independent
> (none conflicting, right) package. I know, I know, it tries
> to be that, but it is not. For example I want a low-latency
> rt Kernel as a side choice for any Kernel, and so on...
Fedora has no interest in the kernels it isn't building, so we're not
really going to split things out separately like that because it
serves us no purpose.
> Throw away that monstrous �Fedora-Kernel-tree. There is
> only one Kernel tree it is called Linux. You can do your
> own back/forward port branches based on stable to your
> heart's content with out inventing a new totally different
> patches tree.
The git tree you're looking at is for the buildsystem to create RPMs.
That requires a spec file, tarballs, and patches. It can't build from
exploded source (at least not easily), so you're comparing apples to
oranges somewhat.
Anyway, if/when I get an exploded source git tree created for Fedora,
I'll post about it to the Fedora kernel list.
josh
Alan Cox
It's designed to produce kernel packages for distribution. It is indeed
useless for much else.
> I wish there was a strait forward way to point to a Kernel
> git tree HEAD and say "make rpm", which is simply the tar
> of the "make modules_install" and the "make install" output
> + a simple script to manipulate grub.conf
That's what the upstream make rpm tries to achieve. If it's not working
right on Fedora then we should fix it to work around any Fedora brokenness
> Not today's Fedora-Kernel git tree which is not a Linux
> git tree at all but those patches above + stable.
> Any simple tree moments needs to involve black patch magic
> and fear of hell. (Don't try this at home)
Fedora is now getting so weird and dependant on magic initrds it's become
pretty unusable for kernel development work nowdays IMHO because it's
undebuggable.
However "make rpm" from the Linus tree is meant to be as far as possible
generic.
Alan
Boaz Harrosh
>> My god that totally-brain-dead Fedora Kernel rpm generation.
>
> generic.
>
Me bang on the head, and red of shame. I only looked at the Fedora
tree and procedure and never thought of looking in the Linux Makefile.
I think you just saved me two days of work. I'll go try that out right
now.
> Alan
Thanks a million
Boaz