[Galaxy S II Android Development] Hacre:
When you actually give constructive criticism instead of calling people rookies and dismissing their work out of hand, perhaps I'll have something to accept/respond to.

Constructive criticism here is a handy guide to help you out when you next feel a need to critique someone else's work.

As for our kernel (and by our I mean myself and netarchy) let's go through the commits:

Repo Init.

This was quite an important commit, as it made a git trackable source tree available.

Update to 2.6.35.8.

The boys in the mainline kernel do have an annoying habit of fixing bugs and providing updates to the tree. It felt like a good idea to try and track that where possible.

Update to 2.6.35.9.

The boys in the mainline kernel do have an annoying habit of fixing bugs and providing updates to the tree. It felt like a good idea to try and track that where possible.

Update to 2.6.35.10.

The boys in the mainline kernel do have an annoying habit of fixing bugs and providing updates to the tree. It felt like a good idea to try and track that where possible.

Update to 2.6.35.11.

The boys in the mainline kernel do have an annoying habit of fixing bugs and providing updates to the tree. It felt like a good idea to try and track that where possible. Getting bored yet? You did ask for "exactly". I think bug fixes to the kernel are a good enhancement for users of an SGS2, yes?

Update to 2.6.35.12.

The boys in the mainline kernel do have an annoying habit of fixing bugs and providing updates to the tree. It felt like a good idea to try and track that where possible.

Update to 2.6.35.13.

The boys in the mainline kernel do have an annoying habit of fixing bugs and providing updates to the tree...

New defconfig that builds and runs.

Unfortunately the defconfig that Samsung supplied doesn't actually boot when moved to the SGS2 itself. I think the advantage to the SGS2 user of resolving this is rather obvious. Do feel free to drop me a PM if you haven't figured it out, I'll gladly point it out.

set up gitignores

"gitignores" is a collection of files in each directory called ".gitignore". This configures git to ignore whatever files we deem fit. I do apologise profusely for this not being terribly useful to a USER of the SGS2 mobile telecommunications device, however it is rather useful to developers of this tree and to people who may want to fork the tree, as unnecessary files created at compile time won't be flagged for commit or upload by git. It's called collaborative development.

Set default safe speeds on boot up, and ensure that scaling_available_frequencies is present in sysfs.

Because we intended to add overclocking code to the kernel, which many users have asked for and therefore by providing such, we enhance their SGS2 using experience, we saw fit to ensure that the default code was not able to overclock every phone at boot up, as this could create instability for some users. Removing this potential instability is therefore a good thing. Making scaling_available_frequencies visible in sysfs provides compatibility with various CPU control applications. I'm sure we can agree that this is also a Good Thing(tm) for the end user.

Sleep death patch.

Sleep death sounds like a Bad Thing. Removing it sounds like a Good Thing.

Add SLQB.

There are arguments that SLQB is more efficient at memory management. We wanted to test this to see if it would provide an improvement to the use of the phone, therefore an improvement to the end user experience.

Add 1.4GHz overclock step.

There are users that want to overclock their phones so we tested some code. We wanted to make the test conservative so took the next logical step up from 1.2GHz to test the code and test anything that code might affect. This would later lead to proper and stable (assuming hardware support) overclocking code. This provided an enhancement to the user experience of people that wanted to overclock their phones.

Change default scheduler to CFQ.

Because the SGS2 uses block device emulation to access the various flash memory storage devices in the phone it became prudent to test which IO scheduler provided the best performance. Was there queueing optimisation in the flash controller? We had no way of knowing. So we tested noop, deadline and CFQ and found that of the default schedulers, CFQ performed the best. So it was set as default. This was done to enhance the performance of the phone therefore improving the experience of the end user.

BFQ.

Because we found CFQ to be the best performing IO scheduler of the defaults provided by the kernel tree we decided to experiment with other schedulers along this train of thought. So we added BFQ to see if it provided better throughput with the idea of improving the end user experience.

Add 1600MHz overclock.

As mentioned previously, there are users that wish to overclock their devices, or want to have that ability there for the future as they get halfway through their 18-24 month contracts and find that the device may not be keeping up with current software demands. We provided this ability to give those users what they wanted, thus enhancing their end user experience.

Remove interactive governor.

We found that the interactive governor was causing stability issues, particularly when coming out of deep sleep. We considered this would be detrimental to the end user's experience so removed it from the list of available governors to ensure that the end user experience was not impeded.

After this point there are some reverts after we noticed an issue with the phone not sleeping correctly and with overall stability. We decided that trying to find which carefully documented change had caused the issue would be prudent to ensure that we provided the end user with a satisfactory experience. I should at this point, point out that nothing had been released to the public yet.

cpufreq patch to address issue with second core forgetting min/max clock frequency.

When this patch was discovered in mainline we thought that the second core forgetting the settings we had applied was a Bad Thing, so we applied the patch, giving full credit to the author, to ensure that the end user experience was not impeded by this bug surfacing. It's worth noting that this patch hasn't been applied to Samsung's source.

net: wireless: bcmdhd: Fix memleak in dev->p.

We thought that a memory leak in the wifi driver of the phone was a Bad Thing and could potentially harm the end user experience, so we applied a patch that fixed it.

net: wireless: bcmdhd: Fix memory leak in case of dhd_bus_init() failure.

We thought that a memory leak in the wifi driver of the phone was a Bad Thing and could potentially harm the end user experience, so we applied a patch that fixed it.

ARM: EXYNOS4: Address a section mismatch w/ suspend issue.

Problems with going into suspend don't strike me as a Good Thing for a mobile telecommunications device that runs on battery power most of the time. We therefore decided, to enhance the end user experience, this patch would be a good idea.

cpufreq: Prevent memory leak in cpufreq_stats on hotplug.

I could be mistaken, but if memory serves me correctly, cpufreq is code that is used rather a lot on mobile devices such as the SGS2. As the SGS2 makes use of a hotpluggable second core, a memory leak in code that deals with that would be a Bad Thing for the end user experience. To ensure the end user experience was enhanced, we applied this patch.

Updated BFQ to v2 and Switch from BFQ-v2 to BFQ-v2-r1.

Because experiments we ran found that BFQ-v2-r1 performed significantly better on the SGS2 in IO tests than BFQ v1, CFQ, noop or deadline, we thought it would be a Good Idea to include the code in the kernel to enhance the experience of the end user, by improving the performance of their handset.

We then had to revert the BFQ patches as we'd forgotten to test the Simple IO Schedule (SIO), so to do so it was easier to revert and patch in SIO than edit the SIO patch to deal with the already present changes from the BFQ patches. It turned out that SIO did not perform well, so we reapplied the BFQ patches. It turned out in the end that BFQ is the best performing IO scheduler for the SGS2, so I guess the time we put in to find that out went towards enhancing the experience of the end user.

Overclock corrections, and a fix to prevent incidents where the cpu speed could briefly be allowed higher than policy->max.

It was discovered that with our overclock code, the cpu management could clock the CPU a step higher than specified with applications such as SetCPU. We thought this was not a good thing, so to enhance the experience of the end user, we fixed the bug.

Fix a bug in the camera driver caused by upping CONFIG_HZ.

We tried to up CONFIG_HZ to increase the tick time of the kernel to provide a more fluid user experience, unfortunately this had to be reverted due to the front facing camera having timing hard coded to 200Hz. We haven't got around to fixing the driver itself yet, but felt it prudent to revert the change to 400Hz so that the front facing camera still worked properly.

voltage control sysfs interface.

People had asked for the ability to control the voltage that the CPU in the SGS2 ran with. This was to either facilitate undervolting to save power, or overvolting to be able to overclock to higher speeds. Because this addressed people wanting to save power, or other people wanting to overclock their device, it struck us as a Good Thing to provide as it would enhance the end user experience.

I'm bored with this bull**** now, Adam. There's many other patches past these. If you need them all explained, I'll do it, but only the moronically stupid would look at my git page and determine that there's nothing of worth there. The end result of ninphetamine over the stock kernel is simple, better battery life for all but the overclockers and better performance for everyone. Handwaving away my changes to the Makefile won't negate the fact that I spent hours testing a plethora of combinations of CFLAGs to find those that produced the fastest and most efficient code on the SGS2 kernel. This is the very definition of improving the end user experience, providing code that's better than what they had to begin with.

Perhaps you've become lost in the great quest for online self worth or the plaudits of your users and as such you find no merit in applying patches/code generated by someone other than yourself. Well if that were the case, your AOSP project wouldn't exist at all, as you, by your own argument, should currently be sat trying to code your own mobile OS. The beauty of open source development is that there's never any reason to reinvent the wheel. Code created by others, fixes created by others are freely available to merge into your own project, completely free, free of cost and free of critique.

I'll tell you one other thing, as well. A good developer is judged only by two things. The quality of their project and the opinion of their peers. A developer's peers are other developers, not the peons that you're so drastically trying to win over by putting down other developers such as myself and netarchy.

Because with the attitude you displayed today, I can tell you this: The quality of your project is practically nil, it offers nothing that Cyanogenmod doesn't already provide and relies heavily upon them to even function. You've also done nothing to enhance the opinion of your peers with your unnecessary attack on the work done by myself and netarchy which was done in our own free time to provide something that the community did not already have. We never, at any point, decried AOSP or the Cyanogenmod project, we merely set out to provide an improved kernel for the plethora of ROMs that ARE CURRENTLY STABLE on the SGS2 and they happen to be ROMs that are based on Samsung's official ROM. We set out to do it and did it. We're still working on it.

The next time you decide to speak condescendingly about a project here on XDA, can I request that you pick on one that actually deserves it? My thanks to you if you manage to dig down deep and find that small amount of civility in yourself. Because right now, you're only serving to make yourself look like an elitist fool. Being elitist is all well and good when you're sitting high on a faultless project. Your project still has a great many flaws. So wind your ****ing neck in.

I'll even go so far to say that I'm all for railing on morons or calling out developers on detrimental or ****ty code. However attacking projects and developers that are actually doing good work, is ****ing out of order.

Hacre out.