Andy-Python-Programmer / aero

Aero is a new modern, experimental, UNIX-like operating system following the monolithic kernel design. Supporting modern PC features such as long mode, 5-level paging, and SMP (multicore), to name a few.

Home Page:https://aero.andypy.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ABI emulation

YusufKhan-gamedev opened this issue · comments

nuff said, we need (easy to create) kernel level ABI emulation early on(maybe even add a linux ABI emulator).

3 questions, 1 remark:

  • Which ABI do you want to emulate, and why is it Linux?
  • Regardless if it is Linux, how much work do you estimate it would be?

Remark:

  • Be the change you want to see!
  • Which ABI do you want to emulate, and why is it Linux?
  • Regardless if it is Linux, how much work do you estimate it would be?

First 2 dont make sense(contradiction!), for the last one.....I wouldnt expect it to be that much work but nonetheless it would still be a major rework on how syscalls work, ill work on it

They do make sense, (the Linux thing is a joke, sorry if that didn't come across). So, which ABI do you want to emulate?

They do make sense, (the Linux thing is a joke, sorry if that didn't come across). So, which ABI do you want to emulate?

Every single one without exception. NT, SVR4, 4BSD, FreeBSD, NetBSD, OpenBSD, 1337BSD, AIXBSD, MACBSD, everything

And you wouldn't expect that to be much work? Please tell me you're trolling.

And you wouldn't expect that to be much work? Please tell me you're trolling.

[BSD, Linux, NT(later)]

I have much of the infrastructure for it right now, it should be trivialish for Open Group Loving kernels to be emulated.

Point still stands, ABI compat with the ones you mention all at the same time either require wine for all platforms or multiple libc's at once, and that is the least of my worries (NT not being anything like UNIX comes to mind). Even emulating one is a massive task that is near impossible (Linux being the easiest one due to the massive amount of documentation and source code being available). As for your point about much of the infrastructure, proof or you don't, as I highly doubt that you do.

I dont care about the libraries surrounding it, I only care about the kernel(personally) replacing the syscalls in areo is semi-trivial(what I have rn), problem rn is getting sys_exec to execute those calls(partiallyish done) and finding what ABI is being run.

Basically something similar to the compat subsystem of the BSD kernels is what I have partially(not close to finished) done.

The libc is for someone else to handle, all I care about rn is static binaries.

I dont care about the libraries surrounding it, I only care about the kernel(personally) replacing the syscalls in areo is semi-trivial(what I have rn), problem rn is getting sys_exec to execute those calls(partiallyish done) and finding what ABI is being run.

Basically something similar to the compat subsystem of the BSD kernels is what I have partially(not close to finished) done.

Not making much sense, as ABI emulation includes the libraries surrounding it, otherwise it's useless. And a static binary includes the libc, so you do care about it.

Not making much sense, as ABI emulation includes the libraries surrounding it, otherwise it's useless. And a static binary includes the libc, so you do care about it.

It includes the libc, ie. I dont have to fiddle with it. Useless or not someone can make it useful if they need to.

You still have to make sure that said libc actually works tho? So you do care about the libc. Also, libc is one of the surrounding libraries, so you care about those too.

shhhh thats not for me to worry about

Yes it is, ABI compat literally is tested by running binaries that aren’t recompiled or whatever. That means they are compiled against a libc for whatever ABI you’re doing. So you need to make sure that the libc works. It’s your job to care about that if you want ABI compat.

its my job to see that the compiled binary works on aero, not to see if the libc works(thought that is a part of it). Currently (theoretically) with the current state of the kernel musl compiled binaries will not work even if the ABI compat worked perfectly well and everything to do with the multiple libcs is done, this is for the future of the kernel, not the present.

If the compiled binary works, the libc works, so to make the binary work, you need to make the libc work, ergo the libc is your job. And with full ABI compat musl binaries would work fine. That is the thing, ABI compat isn’t achieved otherwise.

If the compiled binary works, the libc works, so to make the binary work, you need to make the libc work, ergo the libc is your job. And with full ABI compat musl binaries would work fine. That is the thing, ABI compat isn’t achieved otherwise.

sys_brk & sys_mprotect disagree

They don’t. In order to achieve full ABI compat, all syscalls must work like they do on the target platform, including sys_brk and sys_mprotect. It is up to the person making the ABI compat (you in this case) to ensure that, and implement any functionality or quirks wherever needed. Otherwise it isn’t ABI compat.