i didnt want to add this because i wasnt sure how to do it with kernel-2.eclass
patch name: linux-2.6.9-sh.patch.bz2
i've uploaded the files to dev.gentoo.org /space/distfiles-local ... the file applies cleanly to the ebuild-unpacked 2.6.9 source code
We're moving towards gentoo-dev-sources being a central support kernel.. Could we investigate patching it there instead?
(Haven't looked at the patch yet..)
personally i do not use g-d-s on any of my machines and would prefer to keep it purely vanilla ...
by definition, applying this patch makes it not vanilla ;p
g-d-s is mostly just arch, bugfix, and security patches. The only major feature additions are fbsplash, speakup, inotify, and bbr, and those can all be disabled if you don't want them. I'd consider adding your arch patches to g-d-s to consolidate kernel development in one place and cut down on the bloated number of kernel packages in the tree...
it is a patch which will result in a vanilla sh tree
i could have easily just made my own kernel ala mips-sources since sh is developed in a cvs tree outside of the bitkeeper mainline
it really doesnt matter to me whether it's also added to g-d-s as long as it makes it into development sources also
We've been over this debate too many times to count... d-s is a vanilla tree (ala kernel.org). g-d-s is now a minimal patchset which contains just arch patches, bug fixes, security fixes, and a minimal set of neccessary features, so there is really no need to have things like mips-dev-sources, sparc-dev-sources, etc.
Many people have complained about feature bloat in the g-d-s sources, but that hasn't been the case for a while now, and if you are affraid of the new features appearing in the g-d-s sources, perhaps a viable solution would be the addition of a USE flag to control whether the 4xxx and 5xxx patches get applied.
correction... we'd want the USE flag to exclude 3xxx, 4xxx, and 5xxx... forgot about the 3xxx ones, but there aren't any performance patches in the patchset yet anyways...
also, of the patches in g-d-s that are in 1xxx and 2xxx, almost all of them are in bk for 2.6.10, so really, I don't see the aversion to using this kernel as it basically 2.6.9 with very select portions from 2.6.10...
maybe i'll just do a 'sh-sources' and save the hassle of g-d-s and not being added to vanilla d-s
there's a good reason hppa and mips have their own kernel sources ... unlike ia64/x86_64/x86/arm/s390/etc..., these arches are heavily maintained outside of the mainline tree and make their own interim releases apart from mainline
as it is, i had to tweak the sources by hand so that they wouldnt change the behavior of dev-sources other than when ARCH=sh
vapier: Please don't add sh-sources. There is really no need. We can include these patches in the gentoo patchset. I don't see what you mean by "the hassle of g-d-s"
Wow, this patchset is _way_ too big. It touches a lot of places. Any reason this
stuff hasn't been pushed upstream? Is it not ready for mainstream?
So, at first glance, care to break it up into different pieces at the least?
you're right that including the patch in dev-sources would violate our 'this is the kernel like you get it from kernel.org' (plus security patches)
i can try g-d-s and see how it goes, and if there's issues with that, then i'll just fork sh-sources (2.4 isnt support with sh so no need for sh-dev-sources)
as for the patchset being 'too big', i dont see how that matters at all ... more than half the files the patch applies to are in sh subdirs while most of the remaining files create sh-specific drivers
as for why this stuff hasnt been pushed back into mainline, the main sh kern dev does it on his own time and it's not my place to dictate to him how he manages the kernel
It's "too big" in that it touches files outside of the sh arch tree. That's
why I would hesitate to add it to our tree.
You could just apply the patch (if you don't want to break it up) if you are
building for the sh arch. That would be fine for me for now, but eventually
I would like to see these changes pushed upstream (and if it's the responsibility
of the sh maintainer, poke them to be a good developer and do so. come on, even
mips is playing nice with mainline now...)
all but like 4 or 5 of the files touched outside of the /sh/ subdirs are not sh-specific
drivers/cdrom - dreamcast changes
drivers/char - new rtc support for a sh board
drivers/i2c - new support for a sh board
drivers/input - support/fixes for dreamcast/hp600/etc... (all sh machines)
drivers/maple - a bus that only exists in the dreamcast afaik
all the files are either new (and only used by SH) or wrapped in SH-specific defines ... some of the changes are a bit dodgy/ugly (like the stuff in mm/) which is why i imagine they havent been pushed into mainline, but they are all SH-wrapped so only SH users get these bitss
Created attachment 45762 [details, diff]
What about something like this? The ultra1/sparc stuff was my fixup for sparc
which hasn't been committed yet, so just ignore that hunk...
I don't know if UNIPATCH_LIST accepts the use? ( ) logic, but that's simple
enough to fix.
Adding mips as they may be interested in this conversation (see the attachment)
> g-d-s is now a minimal patchset which contains just arch patches, bug fixes,
> security fixes, and a minimal set of neccessary features, so there is really no
> need to have things like mips-dev-sources, sparc-dev-sources, etc.
Sadly not true...
i cant vouch for sparc since i dont track them at all but i'm pretty sure i can safely say that there's no chance of integrating mips-sources at this time with g-d-s
mips/hppa does their own version tracking outside of mainline ... trying to force the two together is just not reasonable at this point in time
Ciaranm: Look at the recent patchsets. It IS true. Every single patch aside from the 4xxx ones is either in 2.6.10 or is a workaround for a specific issue (like the NIS lockup on sparc (which won't get in mainline) or the ultra1 workaround).
Using my suggestion above, the 4xxx patches wouldn't be included with USE=minimal. The only additions would be the security and bug fixes (thus this would be IDENTICAL) to mips-sources-2.6.9-r<current> as that's what I based the values off of.
mips-sources and hppa-sources applies a patch to the mainline, so it's definitely viable using the ARCH_URI in kernel-2 (which is done already in the <arch>-sources) Why not just do that with g-d-s... if they want to bump to a new version of their cvs tree, they just bump the g-d-s version, strip out the other archs, and bump the variables for their arch (MIPS_CVSVERSION or whatever it was)
I'm not keen on having use- or arch- based patch application in gentoo-dev-sources. Yes we've had it a few times in the past but I would prefer not to see it repeated.
Main reason for this is, it makes my job (seemingly as primary maintainer at this point in time) harder as I then need to go and test multiple use/arch combinations, and bug reports become harder to work through.
Plus another thing that appears to work well is the fact that we don't pack our kernel with cruft which won't get in mainstream, and because of this, we get a lot more respect from the proper kernel developers.
I understand that if a specific arch requires a really intrusive patch which probably needs a lot of refinement before it gets accepted by Linus, then this presents a problem with the current gentoo-dev-sources attitude. In which case, I think its ok to temporarily have arch-specific-sources (at the choice of the arch maintainers).
However once the patches become more manageable then its time to move into our multi-arch development gentoo-dev-sources. This exact scenario has happened with amd64, ia64, ppc, ppc64. And Jeremy is doing a grand job of breaking down the sparc64 problems and joining in on the fun.
So, for now, I think that if the sh patch cannot be broken down and improved, then sh-sources should be created by the sh maintainers. But I think at the same time we should immediately start breaking it down and fixing it up for mainline inclusion.
And yes, although it didn't used to be, gentoo-dev-sources *is* pretty minimal right now. Check out the slimness of the 2.6.10 tree which I have been preparing:
All it is missing right now is fbsplash (waiting on spock to fix that up), apart from that its ready to roll when 2.6.10 goes final.
All of the feature patches there are non-intrusive to other sections of the kernel, with the debatable exception of inotify, which is almost ready to be included mainline now. Plus Greg is in discussion with the squashfs author to get squashfs included in mainline.
Also, I would be interested to know the origins of the sh patchball so that we can keep track of it.
can we discuss non-sh somewhere else ? perhaps gentoo-dev ?
after all, that is the point of this bug :P
in terms of pushing the sh patch into mainline, we're really not in the position to do that, end of story
i rolled the patch myself from the sh cvs tree against a vanilla 2.6.9 tree
I still think mips is better off retaining its own mips-sources package set, the primary reason still being the CVS tree off linux-mips.org. I know Ralf recently fired another mips mega-patch at Linus and Andrew, which will cut back on the overall diff size between mainline and LMO CVS for awhile, but he may not make another sync for several more versions (before this, I believe the last one was ~2.6.6).
Not to mention, current 2.6.9 mips-sources includes a set of patches for Cobalt mips support tied to a local USE, and a patch for Octane (SGI IP30) support, also tied to a local USE. I also have markers in the ebuild for eventual support for Origin (SGI IP27) via local USE once iluxa or some other mips hacker manages to track down and kill off the strange bug making >2.6.6 unbootable on such machines.
Also, me and iluxa will probably come into possession of a Broadcom development system soon, that's based on a completely different line of mips processors (different in regards to the RXXXX line SGI uses, but they're similar at the arch level), and there's no telling if that will require additional patches to support that system. If so, it too will be tied to a local USE.
The use of all these local USE flags is to keep things segregated until they get merged into LMO CVS mainline, so incase there's a flaw in the IP30 patch that could possibly crossover to IP32 and IP22, it won't get the chance to do so. Because of this, I don't want to bloat g-d-s with all these USE flags, or deal with constant rev bumps incase I decide to do a newer CVS pull of LMO code, or integrate a newer patchset for one (or more) of the various supported machines.
It basically boils down to not wanting to step on people's toes. We also have been mixing 2.4 and 2.6 ebuilds in mips-sources for awhile, and with the advent of 2.6.9, are finally able to mark one of the 2.6's as unstable for eventual deprecation of 2.4. This leaves mips with only two entries in sys-kernel: mips-sources and mips-headers (which also intermixes 2.4 and 2.6 ebuilds, since the 2.6 is strictly for experimentation and testing).
In the end, perhaps a policy needs to be drafted up in regards to archs that can get the core support they need out of mainline versus the archs that need to utilize a tree other than mainline for their core support. Why Ralf prefers to maintain mips in a separate CVS versus DaveM maintaining sparc inside linux bitkeeper is an unknown for me, so for archs like sparc, they can easily use g-d-s, because any needed patches would be minimal in a majority of cases. Mips OTOH, requires a number of various patches, depending on what particular machine you're looking to run, primarily due in part to mips being a more varied architecture than sparc.
All that said, this is probably why it's good for CVS-based kernel sources for archs like hppa, mips, and sh, should be fine running their own *-sources (and if needed, *-headers). What I do think can be done to avoid the hassle of multiple patches, especially security based, being duplicated across various arch sources, is setup a specialized kernel patch directory on the mirrors that can have things like security patches and generalized kernel feature patches (speakup, bootsplash) added to it for all the *-sources to pull from if needed, enabled by local USE (or global). It's basically a tatic of centralizing the common patches, since it's more difficult to seamlessly centralize the archs.
Okay, I'm done now.
Adding mips back incase anyone else has comment (we like following these little debates...)
The debates moved to email. Don't worry, it's being taken care of :)
Where are these email debates? I don't see it on any of gentoo-core, gentoo-dev, gentoo-kernel, or the kernel/x86-kernel aliases.
getting back to the issue at hand ...
do i have to roll a new one for 2.6.10 to get this integrated into portage ?
ive just uploaded linux-2.6.10-sh.patch.bz2 to /space/distfiles-local/
I think we need to create a new package for this, at least for now. If you post a 2.6.11 patch I'll roll you an initial ebuild for it.
forget it, i'll take care of it myself, less bs that way