Fixing broken userspace is NOT the kernel's job

Posted Apr 30, 2012 18:19 UTC (Mon) by drag (guest, #31333)
In reply to: Fixing broken userspace is NOT the kernel's job by pr1268
Parent article: Fixing the unfixable autofs ABI

That's like telling somebody that just fell down the stairs and broke their arm that they were stupid for slipping and they just need to walk back to the top the of the stairs and do it right this time. It's all fine and dandy, but it doesn't do anything to fix the current problem.

Plus I don't understand why it's so terrible that systemd checks to make sure that the data it's getting from the kernel is the correct size.

Magic numbers

Posted Apr 30, 2012 21:16 UTC (Mon) by man_ls (guest, #15091) [Link] (3 responses)

But why check only for exactly 300 bytes? It would be understandable if systemd would check that the size of the data is >=300. That way there would be room to add padding or even new fields at the end, if needed.

Magic numbers

Posted Apr 30, 2012 21:19 UTC (Mon) by felixfix (subscriber, #242) [Link]

Might be just general paranoia, to catch changes it doesn't know about. It won't catch all since there's no check for the layout of the data, but if someone adds or removes a member, or changes the size of some, it has a chance of noticing.

Magic numbers

Posted May 1, 2012 8:03 UTC (Tue) by mjt (guest, #1515) [Link] (1 responses)

It is not a magic number, it is sizeof(kernel packet), which turned out to be different on 32bit and 64bit. It is the unit of data kernel exchanges data with usespace, it is the protocol definition. The protocol itself wasn't designed properly, that's the whole issue.

Now, reading just 300 bytes (size of that packet on 32bit userspace) instead of 304 bytes which a 64bit kernel sent to userspace does the trick, but the pipe buffer now holds 4 bytes, which will be read by userspace as a NEW packet. Even if new packet actually arrives, for the userspace the result will be complete garbage, since the packet boundary got lost.

At any rate, no userspace trick will fix already released versions of userspace applications, which is the whole point. Yes it could be made differently, but what's done is done and we don't want to break it.

Magic numbers

Posted May 1, 2012 18:34 UTC (Tue) by dlang (guest, #313) [Link]

with the new packetized interface if you read 300 bytes, the other 4 bytes are forever lost, so the next read will get the correct packet boundary.

Fixing broken userspace is NOT the kernel's job

Posted May 4, 2012 17:44 UTC (Fri) by giraffedata (guest, #1954) [Link]

That's the wrong analogy for this debate. I'm sure you can think of a 100 cases where users got burned by a design decision in a user space program 5 years ago, and a kernel change today could compensate for it, but the consensus is the users should suffer.

Here's a closer analogy: John has 12 steps in his house. He likes to walk down them with his eyes closed and count the steps. Mary invites John over to her house and he resists, saying "I know where everything is in my house and I'm afraid I would get lost in your house." Mary assures him that her house is just like his in every relevant detail, and on that basis John accepts. But Mary has 13 steps and John, walking down with his eyes closed and counting to 12, falls and breaks his arm. Should Mary pay for his medical bills?

Did Mary break her promise? Is having one more step in the staircase is a relevant detail? Is a person entitled to walk down stairs with his eyes closed?

We typically say you can move a program from a 32 bit computer to a 64 bit one without change because the environment is the same in every relevant detail. We also say you can move a program from kernel release N to N+1 for the same reason. Automount and Systemd users are relying on some interpretation of those promises.