Going to reply in a new topic so that we don’t pollute the Python one.
The problem is not the binary compatibility itself. For a long time I was OK with the hybrid thing. The problem is that R1 should not have lasted so long. That’s why in the end I am going to drop this goal. We need to move a bit faster than in past to try to keep up with the world.
My estimation is that in pratice there’s very little people using BeOS era sw. Especially if we exclude nostalgic use.
I propose to take the good parts of the OpenBinder, especially where it is just an evolution of the BeOS design. Like for example, splitting BMessages into BMessage and BParcel. The latter would only contain the data, where BMessage would be specialized in the transfer itself.
The binder has a number of things that would carry Haiku into a new golden era. Once the process of selecting the parts has been done in a collaborative effort by the devs, we can begin to update the code on top of the evolved design and we’d get on R2 without the need to do a lot of work except keeping the current functionality and improving it. While doing this work I am pretty sure a lot of bugs would go away automagically and a lot of functionalities would become reality.
If you could put all that BeOS software in a closed garden instead of a full architecture, making x86 gcc7 arch the default (not the opposite), you would save a lot of time and things imo, for the 32 bits version. But it might be a big effort on changing the recipes, runtime, etc.
Importing ideas or code from OpenBinder means substantially improving the support kit. That’d be a support2_kit and as long as it is implemented the switch can be done with some calm. I think a full time dev can achieve it (the new support kit) in 2-3 months. Once you introduce the new support kit you can begin to move the code on top of it. There will be code that can be reworked trivially or even code that works out of the box.
You can see it as an upgrade path, but it’d be much more difficult if we go without any point of reference. Additionally, the Binder Kit is not that different from the current Android Binder, and we could evaluate taking parts of the Android C++ API.
You can take as example the introduction of Layouts. It took a while to rework the code on top of it, but how many general improvements resulted from it?
I don’t think that this makes a lot of sense, imo. There are some performance issues to resolve in our Support Kit that may require design changes, but overall I think we don’t need to radically rethink anything…
OpenBinder wouldn’t be a radical redesign though… and it’s actually tested and performant in the realworld already. As Barrett said more of an upgrade path… as long as the 2 kits could coexist whats the big deal?
That doesn’t seem right. Wouldn’t it be that you would have 2 message passing systems and the two could not talk between each other in the worse case.
Most likely they could be made to forward to one another in the worse case as long as one is a subset/superset of the other. Ideally whatever message passing is used for R2 is a superset of what R1 implements… and the APIs for R1 message passing continue to be supported on R2 in a deprecated manner.
You miss the point of the message passing system: the BLooper, the base message handler thread loop class which underlies BWindow, BApplication, etc. and BHandler, which builds on it, that underlies BView, etc. There can be only one BLooper and BHandler.
Why do the message passing APIs need to be changed at all? I am still confused as to the need for this. AFAIK all the major suggested innovations (outside of this thread) are incremental, not “break the world.”
Messages are not more than kernel port messages. As long as the BMessage(R1)/BParcel(R2) is kept internally coherent it is indeed possible to make them work flawless. I will add more, in fact we’d use KMessage for both.
The statement that they couldn’t cohesist is false.
Well that’d be much more easier than that. We can keep the messaging protocol (i.e. “be:whatever” stuff) consistent across both and have the internal representation of BMessage consistent then the two systems will cohesist without problems. In fact we’d just rebase the OpenBinder stuff on top of our current private API.
Radically changing what? The Binder is just an evolution of the support_kit, it adds some concept but it is not certainly a radical change. In fact, I will repeat the Binder was originally the planned BeOS R6 support kit.
EDIT: Well the binder includes also things which belongs to the app_kit, and the Binder Kit which is an abstraction layer, but in their context all this stuff is intended as “support”.
Uh … what? KMessage is a userland/kernel communication facet, it has nothing to do with the implementation of BMessage at all. What are you saying here?
What is the point of BParcel? It always seemed to me like a needless distinction between a “Message” and a “Parcel”. If you want to make an actual distinction, breaking messages into “variant” types makes some kind of sense; however that will get rid of the static typing, which I also think would be a mistake.
Again, why would we do that? What advantage does it bring?
Internal representation of BMessages has already changed multiple times; Haiku supports the R5 and Dan0 message formats in addition to using the “Haiku” message format internally for most things. So the byte representation of BMessage could be changed right now and we could retain backwards/forwards compatibility in most respects; this is a separate issue.
OK. So then what is the purpose of even using it?! IMO, our own code is more mature in some respects than it is. And it utilizes a number of features of our kernel (ports, mostly; the lack of those on other OSes is the major architectural difference in how OpenBinder works that I was referring to, as they’re completely integral to how BMessages get passed around on BeOS and Haiku) that other OSes don’t have.
Well, sorry I was enough clear. I did not mean of course we have to move it on top of KMessage. But there is an extensive use of it among the registrar and the app kit and we are not going to do all those “architectural changes” anyway.
We can discuss that. I am not saying that OpenBinder is 100% right. But there are lots of interesting ideas to evaluate. BParcel makes sense because it is a container. Especially if we look at it in the light of BValue…
The binder allows for a lot of new things. Allows for things which BeOS R5 didn’t really reach. It is entirely possible to make remote objects work like local ones.
Has this something to do with the discussion? I am just saying that we can reuse the same private stuff for both.
No. The binder has the exact same concept as basis. I think you didn’t go really over the API itself. The binder kernl module does indeed implement in kernel space the same concepts we use in our kernel.
What’d be the advantage? The binder does solve some architectural problems of the BeAPI. All those things that’d be needed to implement a modern operating system. We need to manipulate remote objects in the correct way. We need to add more use of templating. We need to add some higher level structures to reduce code usage and improve the OS security.
All this, and a lot more has been already addressed by the Be and then Palm engineers. We’d be blind to do not take the chance to learn from the evolution of the API that we reimplemented.
There’s moderate use among the registrar and app_kit, not “extensive”? And yes, it’s used here because they communicate with kernel components that also use it. It could be reworked to use something else … but why would you do that? It was created to fulfill the purpose it now serves.
How does it make sense as a container?
Is that really a good idea? RemoteMessageSender/Receiver are being developed as part of the support for remote debugging; I imagine implementing BHandler that operates over a network stream transparently to what the developer sees will not be very hard beyond this. So I don’t know why OpenBinder is at all valuable to us here.
Ah, I missed that part then; I didn’t look closely into how it was implemented.
Such as…?
Such as…?
I really don’t see what there is to be gained here, you are still being so vague.
Security-wise the two holes we need to clear up are port access permissions and area access permissions. We need a few more syscalls and some permissions checks (and to update key system components to handle them), but this is not so different from the shared memory permissions issue that sys/shm mostly solved a long time ago. So I don’t see what’s to be gained from OpenBinder.
Instead of being contrary… let him do his thing, and it only be accepted for inclusion in Haiku if it is provably better (benchmarks and regression tested) as well as equivalent and compatible API wise to what we have now without regression. From what I gather it has the potential to be better. Bringing features to Haiku that the Be developers intended to bring to R6 is a good thing as long as it doesn’t break R5 compatibility right?
And Barrett shouldn’t be surprised if his ideas get shot down if they don’t meet those criteria… but if it all works out great. I mean really that is how everything is supposed to work anyway.
OMG. Going to stop this discussion now. I had various times the pleasure to talk with you and answer your questions. I already know this is not going nowhere.
Well, the funny thing is that I have the right to do whatever with the code, once I see parts of OpenBinder that fits my needs I will indeed introduce them. But in general I am no surprised the discussion has got this way. You know I also learned to don’t talk too much with people in detail, why should I tell him the tons of security holes Haiku has? Let’s make him live in the eden.