LWN: Comments on "The trouble with SMC-R"

The trouble with SMC-R

smitty_one_each — Fri, 26 May 2017 10:58:33 +0000

With a curated tag ontology, you could. . .
fantasize aloud about solutions that would require an unlikely cultural shift to implement.

The trouble with SMC-R

rkeene — Fri, 26 May 2017 01:59:21 +0000

On average, a few hundred: https://abi-laboratory.pro/tracker/timeline/linux/

The trouble with SMC-R

smitty_one_each — Thu, 25 May 2017 17:31:16 +0000

I'm saying make the debut of a new API /in the kernel/ the "engagement".
How many APIs does the kernel debut per release?

The trouble with SMC-R

excors — Thu, 25 May 2017 17:28:53 +0000

But if everyone is sent ten thousand wedding invitations per marriage window, they'll filter them straight into the bin, and you're back to the original problem of how to make them aware of the few weddings that they really didn't want to miss.

The trouble with SMC-R

jem — Thu, 25 May 2017 16:02:36 +0000

Or everybody should get an invitation to the wedding, so that when the preacher says "speak now or forever hold your peace", you get a chance to object.

The trouble with SMC-R

smitty_one_each — Thu, 25 May 2017 14:16:15 +0000

Does every new API need a one-release "engagement" phase, so that it's in the kernel prior to "marriage"? A reverse deprecation, if you will?
There is always going to be someone who doesn't get the memo, and is surprised.
Putting some additional delay at the "ground truth" of a release would be one way to minimize that set of people.

The trouble with SMC-R

florianfainelli — Tue, 23 May 2017 00:18:21 +0000

>Perhaps an automated gizmo could generate weekly email reports of activity on kernel-related lists. A list manager could register kernel > source paths of interest. Any patch posted to any monitored list that touches those paths would be mentioned in a weekly posting to the > list that registered those paths (excluding those posted to the same list).

Problem was that AF_SMC was an entirely new path (net/smc) so the ownership and appropriate recipients would have been a bit hard to track down. You could say: with lack of a specialized recipients list, broadcast, but then we go back to square one: too much traffic.

The trouble with SMC-R

marcH — Sun, 21 May 2017 06:17:25 +0000

> This problem is definitely not unique to Linux.

These development scalability issues are indeed very common. On the other hand, trying to mitigate them with a pure email, "database-free" approach is less common.
https://lwn.net/Articles/702177/ "Why kernel development still uses email only"

The trouble with SMC-R

marduk — Fri, 19 May 2017 14:22:08 +0000

A large city... or pretty much any large corporation (and even some not-so-large ones). This problem is definitely not unique to Linux.

The trouble with SMC-R

liam — Fri, 19 May 2017 09:04:25 +0000

Isn't there a linux-api ml?

.......

Hmm, why yes there is!

And there's even this interesting bit of history:
"The difficulty of answering that question is a contributing factor to many problems in the Linux API—for example, insufficient design review before release (with the consequence that mistakes in API designs are recognized too late), insufficient prerelease testing, poor or late documentation, and delays before kernel APIs are made available via C libraries."

https://www.kernel.org/doc/man-pages/linux-api-ml.html

The trouble with SMC-R

pabs — Fri, 19 May 2017 05:14:44 +0000

Sounds like they need to switch to mailman, which supports splitting a mailing list up into sub-topics. Recently RH did that for their security mailing list:

https://access.redhat.com/blogs/product-security/posts/rh...

The trouble with SMC-R

shorne — Thu, 18 May 2017 23:58:47 +0000

I have Gmail setup listening to the linux-kernel list with a filter to tag any time 'openrisc' pops up in conversations. This allows me to track any activity.

If you don't mind using gmail, Something similar could be done to track and 'rdma' or other keywords you are interested in. I'm sure one could get procmail to do the same.

The trouble with SMC-R

ejr — Thu, 18 May 2017 20:24:02 +0000

Perhaps an automated gizmo could generate weekly email reports of activity on kernel-related lists. A list manager could register kernel source paths of interest. Any patch posted to any monitored list that touches those paths would be mentioned in a weekly posting to the list that registered those paths (excluding those posted to the same list).

Hooking it up to a patchwork-like web interface could be handy as well for the more web-inclined set.

On the technical topic, RDMA, distributed shared memory, and non-volatile memory are going to be cross-cutting concerns with plenty of activity for a while. HP's "the Machine" is one example system where these are deeply tied. There will be many APIs and interfaces. If history is relevant, most will go away. But the kernel still supports DECnet, so...