LWN: Comments on "3.4 Merge window part 1"

3.4 Merge window part 1

BenHutchings — Wed, 28 Mar 2012 01:14:11 +0000

Solarflare SFC9000-family hwmon controllers, Solarflare SFC9000-family SR-IOV controllers

The SFC9000 family chips are network controllers. The hwmon and SR-IOV support are new and optional features of the existing driver (sfc).

3.4 Merge window part 1

djm1021 — Sun, 25 Mar 2012 16:38:28 +0000

OK, I see what you mean. Actually, ramster *was* reverted just after it was merged into staging-next in early February (because it was dependent on xvmalloc which, coincidentally, had just been removed from staging-next) and then ramster was added back to staging-next soon after, and THEN disabled with CONFIG_BROKEN because it was dependent on a git pull ordering (cleancache fix) in linux-next. That sordid staging-next history was entirely merged into linux-next and into Linus's tree. So 3.4-rc0 never reverted ramster, although the git log might imply otherwise.

So we were both not wrong. ;-)

Now that all those dependencies are resolved in Linus's tree, a simple patch to remove the CONFIG_BROKEN in ramster's KConfig has been submitted and is awaiting merging for -rc1 via GregKH. Anyone wishing to try ramster in 3.4-rc0 can manually remove the CONFIG_BROKEN.

3.4 Merge window part 1

cesarb — Sat, 24 Mar 2012 22:36:33 +0000

AFAIK, Corbet was not wrong. IIRC, ramster *was* removed, and added back again a few patches later.

3.4 Merge window part 1

djm1021 — Thu, 22 Mar 2012 01:50:31 +0000

Thanks for the mention of RAMster and the other article references! A couple of quick corrections: (1) RAMster is still in 3.4 as can be seen in Linus' git tree under drivers/staging/ramster. It is marked with CONFIG_BROKEN only because it is waiting for another patch (submitted by Konrad Wilk) changing the name of some functions in cleancache that it depends on... as soon as that patch is merged, the CONFIG_BROKEN can be removed from ramster's Kconfig. (2) In the merged ramster code, the ocfs2 dependency has been removed. At the request of Sunil Mushran, the small amount of ocfs2 cluster management and messaging code has now simply been duplicated for ramster as it will likely evolve quite differently and there just isn't enough code to make it worth pulling it out for global use beyond ocfs2. (This decision can be revisited later before ramster would be promoted out of staging.)