On to, 07 syys 2017, stan wrote:
On Thu, 7 Sep 2017 13:27:18 +0200
Jan Pazdziora <jpazdziora@xxxxxxxxxx> wrote:
Yes, it might become a mess if the tooling is not right or clear. But
it is also an opportunity to potentially get a choice between stay on
the old, stable, vs. get the latest greatest.
But it seems to be the wrong way to do this; trying to shoehorn
multiple version choice onto an operating system structure that is
designed around having only a single choice. I think it would be
better to re-design the OS to allow multiple versions of everything to
exist in parallel. Would that be a lot of work? Sure. But so is
modularization, and if the job is done properly by modifying the OS, the
end result is a lot more stable and extensible, as well as maintainable.
To take an example, let's think about libraries. Currently, the system
is designed to use a so number to mean that we are locked into some api
version, and restricting choices of applications based on that.
Imagine if, instead of so numbers, we use signatures of the api calls (a
la c++ overloading) to version libraries and calls within those
libraries. When the OS tries to load an application, it looks at the
signatures it needs for the libraries the application calls, checks the
call signatures of the functions it is using on those libraries, and
decides which version of the library to use. The package manager does
the same thing during install, to determine whether it can use existing
libraries, or has to install a new library with the correct signature
for the application it is installing.
The per-symbol API versioning in RPM was proposed five years ago by
ALT Linux people. It actually works well in their RPM fork.
An isolated version of that code is available at https://github.com/svpv/rpmss
You may want to read http://rpm5.org/community/rpm-devel/5356.html and
associated thread discussion to understand how it all works, but
overall it is much better suited to cover per-symbol export and import
between ELF objects. The ABI requirements become explicit and ability to
automatically detect which applications are using which symbols from a
library affected by a CVE is a good example where this could be used.
The whole tool chain will have to change for this. Compilers will have
to advertise signatures for all library calls in binaries. The OS will
have to match signatures between applications and libraries when loading
programs to run. Package managers will have to run garbage collection
on packages that no longer are used, especially libraries, and ensure
that a spanning set of library calls for all applications is
always present. Unfortunately, the library api function call signature
might be a false flag because the functionality could change without a
change in signature, but that should be rare.
However, after this is done, there is no need for modularity, or
rather, the entire system is modular. And that's the proper way to do
modularity. And it is pretty much invisible to the end user. They
just install a package, and the package manager installs whatever is
needed, if necessary. Of course, there has to be some mechanism to
determine which version of the application to run if there are multiple
versions of it installed.
And there are issues with the structure of the file system
(does /usr/bin or /usr/lib64 still make sense?), but I won't go into
that.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
--
/ Alexander Bokovoy
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
