| |||||||||||||
Fixing broken userspace is NOT the kernel's jobFixing broken userspace is NOT the kernel's jobPosted Apr 30, 2012 17:46 UTC (Mon) by pr1268 (subscriber, #24648)Parent article: Fixing the unfixable autofs ABI
I think autofs and systemd should get their s**t together. While I think it's proper and appropriate for the kernel to avoid breaking userspace, I firmly believe it's also not the kernel's job to fix broken userspace! </rant>
(Log in to post comments)
Fixing broken userspace is NOT the kernel's job Posted Apr 30, 2012 18:19 UTC (Mon) by drag (subscriber, #31333) [Link]
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 (subscriber, #15091) [Link] 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]
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 (✭ supporter ✭, #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 (subscriber, #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.
Fixing broken userspace is NOT the kernel's job Posted Apr 30, 2012 18:26 UTC (Mon) by vrfy (subscriber, #13362) [Link]
Systemd just did not like to get any "shit" together in userspace:
http://lists.freedesktop.org/archives/systemd-devel/2011-...
Adding runtime matches for architectures in userland tools to find out what to expect from a running kernel interface is just not acceptable these days, and people should stop doing that. We need to fix what's broken, and not paper over it.
It's surely not the kernel's job to fix userland tools, but it's even less the job of userspace to work around obviously non-working kernel interfaces, when they should be fixed instead.
Fixing broken userspace is NOT the kernel's job Posted Apr 30, 2012 18:27 UTC (Mon) by arjan (subscriber, #36785) [Link]
but reality happens as well......
Fixing broken userspace is NOT the kernel's job Posted May 1, 2012 23:59 UTC (Tue) by mezcalero (subscriber, #45103) [Link]
Sorry, but systemd is not the place to put workarounds for broken APIs. Fix the stuff where it is broken, don't litter systemd code with it, thank you very much.
Fixing broken userspace is NOT the kernel's job Posted May 2, 2012 5:02 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
I have seen a very good companies product basically destroyed over many years of fixing things in the wrong place.
In opensource software there is almost never a reason to do this, and never without discussing the problem first.
That said, I have no problem with the sanity check that systemd is doing. They are not working around anything, they are just checking that what they are getting has a chance of being what they expect to get. They know the size of the object that they are getting, and so they only get that much data. fetching more would potentially cause other grief.
|
|||||||||||||