To be honest, I don’t know what he is suggesting because he doesn’t seem to be able to explain it in any way that makes it seem viable. You have this:
“the web”… to make this utopia work, everyone needs to buy in to this “new world order”. Until then, we still have html that needs to be rendered by some process - and that needs to be client side for security, given the current model of the web.
application UI… you will either need an external toolkit (ala BeApi or Qt or whatever) that is plugged in to the runtime and can translate the UI to the native** API, or you will need to be able to compile the entire UI in a way that can be run under this runtime. Either way, it still doesn’t really make anything better.
every issue we have on the forums seems to be able to be solved by webassembly… but no one can actually explain how, why (as in why you would do it that way and why it is better than just writing code) and would have us believe that it will all magically be cross platform. This is the same song Java, Adobe Flex, Qt, Gtk and React sing/sang… (and probably more) and if I hadn’t heard it before, maybe I wouldn’t be so sceptical.
Nothing being said yet is realistic. Nothing is quantifiable. I think, getting the runtime to compile and run would be a great first step. Then, getting the runtime to run a simple UI app using the BeAPI (even if it is wrapped up in some way) or possibly Qt would be good. Forget about all the Flutters and Darts, forget all the Go and Rust bindings… just get the runtime to compile some C/C++ to webassembly, and run the same binary output on a 32bit version of this runtime and a 64bit version of this runtime and you have a winner. Get it to build and run on RISCV, and you are golden. That is all we really need from this. All the rest of the pie in the sky claims can be done when the runtime is actually past POC and can run real apps under Haiku. That’s what I’d like to see anyway.
** by native we mean “native code” not native to Haiku API specifically. Any compiled C/C++ UI toolkit could be viable.
The point I was trying to make about the ANSI codes is that once most of the UI is moved to a locale-neutral bytecode, only inline markups are needed. ANSI already had codes for underlining and boldface so it could be a starting point. Most markups in HTML need to be moved to the GUI layout anyway.
It’s quite unfortunate that modern web development decided to go all in on using JavaScript for almost everything making the world wide web an incompatible mess of things.
that’s a sad reality, but it’s the world we are stuck with.
would be awesome if there were a way to design a real web api, that was coherent, performant, reliable, functional and implementation would be consistent.
In the process of trying to implement the Region crate used by Wasmer, I’ve discovered a potential conflict in the headers. Since Haiku was identified as a POSIX operating system by the C compatibility headers, the unix.rs header was automatically linked in causing a conflict between the protection bit setter and getter. I was using B_WRITE_PROT and friends to convert between native and the intermediate format used internally by the Region crate. However unix.rs was converting PROT_WRITE to convert the other way. This BeOS native vs. POSIX conflict may be nothing but in the interest of trying to be consistant with the rest of the headers, I’ve branched off my fork of region.rs to make a more POSIX compliant version.
In order to do this, I need to find the equivalent of ‘kinfo_getvmmap’ call on FreeBSD’s sys/user.h header or KERN_PROC_VMMAP on OpenBSD’s sys/sysctl.h header. So far the only equivalent I’ve found in the Haiku docs are the BeOS equivalent, AreaInfo. Is that all we have to work with? If so, is the B_WRITE_PROT equivalent to PROT_WRITE on Haiku?
The Region crate implements its own Protection type that abstracts the platform’s underlying memory protection flags.
In the unix.rs to_native() function, the flags are converted to Posix’ PROT_*.
I also understand that some of the functionality there is exposed through Unix functions like mprotect and friends.
I think what you need to figure out is whether you can implement the entire native abstraction using Haiku’s native functions. If so, then the easiest way out for you might be to just skip the Posix abstractions.
Thanks for the tip, nielx, I got the native version done but it is more failure-prone than the POSIX versions. I suspect the problem is that Areas under Haiku are grouped together and pages are addressed separately by the Region crate. It looks like I’ll have to divide up each Area so that the pages are all separated.
Thanks for asking! The most problematic code comes down to querying the page tables. It seems that every operating system has a different way to do it and even the POSIX operating systems do it differently under the hood. The portions of the Region crate that are easily accomplished using the POSIX layer are done by unix.rs which is normally included by the POSIX compatibility layer but then the query code needs to be able to handle the reading back of the values from the page tables. If you can read the rust code, my attempts are at https://github.com/SamuraiCrow/region-rs and the native branch is the one that doesn’t use the POSIX layer. The master and POSIX branches are currently in step with each other.
Edit
I forgot to mention that the OS specific code is in the src/os/ directory in the repo.
os/haiku.rs: line 19 in combination with line 22: if you choose B_FIXED_ADDRESS then you need to specify the start address (see the B_BOOK), so fixed addresses will not work.
os/haiku.rs: line 31 no need to get the area info, as the pointer addr will contain the address for the return value.
os/haiku.rs: lines 14 in combination with line 35: potential memory leak here, as addr_info will only be freed if the area calls are succesful.
os/haiku.rs: lines 27-29 and 32: invalid use of last_os_error(). The area functions give the area directly and do not set errno, therefore this call will return an invalid error (set by a previously failed POSIX call).
os/haiku.rs: QueryIter::new() … not quite sure how you imagine this to work. You do some teaminfo voodoo (why?), you find the area id using area_for(), which may work in some instances of the APIs use, but probably incorrect in others, as the call is to create an iterator that looks for areas in between the starting addr and the addr+size, not exactly the area that is at addr…
os/haiku.rs: line 137: this check is too restrictive. Probably not your fault because the BeBook says the only error code is B_BAD_VALUE, but my tests hang on a B_BAD_ADDRESS.
All this to say, that your code probably needs some more testing and more work before writing the approach off. My advice would be to try some more before you go the route of extending Haiku with non-posix linux/BSD APIs.
With the help of mmu_man during the code sprint, I got rid of what I thought were alignment errors. What they were, were null pointer checks on an unused pointer flagging my nulls as invalid. That only ended up solving one unit test that now passes because now the rest fail for a different reason.
It appears there is a problem with the wrapper of the area iterator. Mmu_man made sure the Haiku implementation was monotonic. I wouldn’t have thought of that.
Are there any other ideas of what may be wrong with my implementation of the region crate?
I guess I really don’t know what I’m doing. @nielx would you please look at my code again? I reworked the code significantly since your last review. Thanks for your help in the past.
For starters, my C++ isn’t that fluent so I was hoping to make this based on the BeBook or some other documentation. I like the way that rust catches the most obvious mistakes when using safe code. When making drivers like this, however, Rust is all unsafe and just an alternative syntax for C++. I was kind of hoping to have this part done by now so I could start on the fun part.
EDIT
I can read some C++ but it’s hard for me to write it. I’m not an experienced programmer so much as an analyst.
