Quotes of the week

[Posted February 12, 2014 by corbet]

This could be a cool drinking game. Every time you fix someone else's sparse error, they have to drink a pint.

... which game would result in a heightened mood amongst developers and even more Sparse errors, resulting in more fixes from PeterZ and more pints downed, creating a nice feedback loop. Sounds like fun for everyone, except Peter?

— Ingo Molnar

We don't really *have* a good way of deprecation, this is the problem. Usually it doesn't happen until we find out that a bug snuck its way in and "X hasn't worked for N releases now, and no one has noticed."

— H. Peter Anvin on subarchitecture deprecation policy

We plan to remove 31 bit kernel support of the s390 architecture in the Linux kernel sources.

The reason for this is quite simple: the current 31 bit kernel was broken for nearly a year before somebody noticed.

— Heiko Carstens using it in practice

Quotes of the week

Posted Feb 13, 2014 3:40 UTC (Thu) by jzbiciak (guest, #5246) [Link] (5 responses)

When I read "31 bit", I mentally made a similar expression to Bugs Bunny's, when he says "Hansel? HANSEL?! HanSEL?"

Quotes of the week

Posted Feb 13, 2014 15:17 UTC (Thu) by drag (guest, #31333) [Link] (4 responses)

IBM is a fun little world. I recommend everybody don a suit and tie once in their life and dive into it. It's like a alternate universe.

IBM's "31-bit" architecture

Posted Feb 14, 2014 17:41 UTC (Fri) by giraffedata (guest, #1954) [Link] (2 responses)

In this case, the special thing about the IBM world was a commitment to backward compatibility. You don't see that much in the modern world, but it was what made IBM - System/360 (aka s390): an architecture that let you run old software on a new computer.

So when IBM decided to expand addressability beyond 24 bits in its 32 bit architecture, it was important that existing users, no matter how old, be able to use the longer addresses while still running programs, libraries, and OSes designed for 24 bits. That meant reserving a bit in many words that contain addresses to indicate whether the user of that address expected the old 24 bit addressing mode or the new one.

The Linux kernel terminology may obscure the fact, but the architecture is 32 bits in every way except the width of a basic virtual memory address.

IBM's "31-bit" architecture

Posted Feb 14, 2014 18:15 UTC (Fri) by khim (subscriber, #9252) [Link]

Your explanation is essentially correct but leaves one to wonder just how this one bit helped and why it was even needed.

The reality is simple: IBM/360 and it's successors were always 32bit (later 64bit) but early models only used low 24bit for addressing memory and many programs took advantage of that and used few bits here and there as tagged pointers. IBM/370 expanded memory address beyond that, but simple idea to just start using the whole register to address memory was rejected since it broke old programs. Instead most significant bit was used as marker: if it was set then the rest was 31bit address, if it was unset then the rest 7 bits were ignored (and old programs or adaptations of old programs could have used it as tag). It's all described in wikipedia, actually.

IBM's "31-bit" architecture

Posted Feb 14, 2014 19:12 UTC (Fri) by drag (guest, #31333) [Link]

> an architecture that let you run old software on a new computer.

This and the fact that IBM had virtualization in their datacenters/mainframes decades before anybody else. x86_64 still hasn't caught up to were IBM was in the 90s.

Quotes of the week

Posted Feb 16, 2014 20:48 UTC (Sun) by robbe (guest, #16131) [Link]

The world as we know it seems to come to an end, though. Ending HW support after just 15 years? The tie seems to be history, too: We were visited by three IBM people whose job title matched .*sales.* -- none of them wore this once ubiquitous accessoir.

A year too short?

Posted Feb 13, 2014 9:50 UTC (Thu) by NAR (subscriber, #1313) [Link] (1 responses)

The systems I'm currently using have 2.6 kernels. I'm not quite sure how old they really are, but it still begs the question: can the kernel developers be sure that their changes get to the users within a year?

A year too short?

Posted Feb 13, 2014 14:59 UTC (Thu) by njwhite (guest, #51848) [Link]

That is a good point, but really you should have at least one person motivated enough to run new kernels for an architecture, or maintenance is not effectively happening anyway, and evidently nobody is motivated to do it.