Google's Fuchsia OS Developer Site Debuts (Forbes)

Posted Jul 1, 2019 17:46 UTC (Mon) by gregkh (subscriber, #8)
In reply to: Google's Fuchsia OS Developer Site Debuts (Forbes) by Cyberax
Parent article: Google's Fuchsia OS Developer Site Debuts (Forbes)

> First, it has a stable driver ABI.

I stand by my statement that anyone who claims they want a stable driver api doesn't know what they are doing from a technical point of view. The amount of cruft that internal apis like this build up over years and decades will kill an operating system, and we have the prior art to prove it.

Also, no one can claim a stable driver api before they actually have released anything _and_ tried to keep it stable for a number of years :)

I am eager to see how this actually plays out, and am glad to see some more competition in the kernel space, we desperately need it. There are lots of interesting ideas in Fushia, and of course, if any of them actually work out to be a good idea and improvement, there's no problem with having Linux adopt them as well. So we all benefit from this work

Google's Fuchsia OS Developer Site Debuts (Forbes)

Posted Jul 1, 2019 17:51 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Stable driver ABI doesn't have to be all-or-nothing. It's generally acceptable to break it once every several (~5) years. And it's not like we don't know by now what most drivers need.

Google's Fuchsia OS Developer Site Debuts (Forbes)

Posted Jul 1, 2019 18:28 UTC (Mon) by ncultra (✭ supporter ✭, #121511) [Link] (1 responses)

Fuchsia drivers run in user space and most of the API is message-based, which means specialization and evolution occur via message protocol changes. I think it is a false comparison to the linux driver API, so read up on the Zircon DDK.

Google's Fuchsia OS Developer Site Debuts (Forbes)

Posted Jul 1, 2019 21:46 UTC (Mon) by mageta (subscriber, #89696) [Link]

Breaking messaging protocols is just as simple as breaking a function-interface. Challenges to support backwards-compatibility remain much the same for both as well - just look at old protocols like SCSI-3 (which is also just message passing basically) and such. In order to support very old version of the protocol you run in danger of collecting a lot of cruft and bit-rot, just as you do in function-call/binary ABIs.

Binary ABIs probably add to the problem, because there is no 'passing-layer', but that is not the only problem in preserving a stable API. The information you pass, may it be function-arguments, or protocol messages have to stay the same for it to claim to be backwards-compatible/stable, and that is the challenge.

Google's Fuchsia OS Developer Site Debuts (Forbes)

Posted Jul 1, 2019 20:45 UTC (Mon) by roc (subscriber, #30627) [Link] (2 responses)

> if any of them actually work out to be a good idea and improvement, there's no problem with having Linux adopt them as well.

It's not that easy. Some of the ideas (e.g. "have less than 500 syscalls", "use capabilities instead of namespaces") would require breaking backward compatibility. Others would require far-reaching architectural changes in core subsystems, e.g. to support Fuschia's VM features. If you rewrite Linux's internals and replace its syscall interface is it still Linux? :-)

I'm still skeptical about Fuschia taking on Linux until we hear more about WHY Google is doing it and what the long-term plan is.

Google's Fuchsia OS Developer Site Debuts (Forbes)

Posted Jul 4, 2019 6:20 UTC (Thu) by smurf (subscriber, #17840) [Link] (1 responses)

It's still "Fuchsia", no matter how people manage to mangle that poor plant's name.

I assume that any sort of Linux ABI compatibility isn't in the charts for Fuchsia any time soon ..?

Google's Fuchsia OS Developer Site Debuts (Forbes)

Posted Jul 4, 2019 7:59 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

The syscall layer there is completely different. Fuchsia supports a subset of POSIX API, so recompiled code will work.

A translation layer like Linuxulator from BSD might do the trick, though.