Solved Resources/Books to learn about FreeBSDs Application Binary Interface and Memory Management Syscalls

SDK Chan

SDK Chan

Like the thread says, I need to get familiar with both topics.
On Amazon I discovered this interesting book.
It sounds as it goes into the right direction.

Are there other resources and books you could recommend ?
 
danger@

Thread 'FreeBSD Development: Books, Papers, Slides'

Hey...

Here, I would like to maintain a list of books, slides, tutorials, videos and other multimedia resources which are related to FreeBSD development. If you know some other resources which should be mentioned here, please send me a PM here or an email to danger@FreeBSD.org. Thanks!

Books
  • Thanks
 
SDK Chan said:
On Amazon I discovered this interesting book.
Click to expand...
That is the best book about FreeBSD internals.

But why? At the user application level, all you need is documented in man pages (which to a large extent follow Posix). So I have the same question cracauer already asked. I think we (as usual?) have an XY problem here: what are you really trying to accomplish?
 
cracauer@ said:
Why the ABI? Do you want to skip using libc for system calls?
Click to expand...
I do not know if I want to skip it, but the chances could be there I guess.

ralphbsz said:
I think we (as usual?) have an XY problem here: what are you really trying to accomplish?
Click to expand...
Well...
I am trying to port over a game console emulator from Linux to FreeBSD.
It was initially written for Windows, then ported to Linux.
FreeBSD to some extend supports Linux syscalls, through linuxulator, I think.

My problem here is, I want to create equivalent FreeBSD syscalls to the already existing Linux ones.
Since GTK3 is external in that project, I want to compile it headless with devel/sdl20 first.
 
cracauer@ said:
What kind of Linux system calls does the emulator need that are not already in the Linuxulator? A lot of them are already in.
Click to expand...
I did not test it with linuxulator.
Actually I wanted to create a native FreeBSD port, like it was done with emulators/yuzu.
Not sure if there would be performance benefits in doing so compared to the linuxulator approach ?

Again there are two steps to get linuxulator working, right ?
One being to mount specific filesystems, another one would be to get a debian/cent-os ? based live system on FreeBSD ?

I am not sure, but I think the first step, mounting just specific filesystems would not impose any performance loss, but I am not sure about the second step at all...
 
Ok, interesting.
I guess it might be worth to try out.
If linuxulator really has almost every system call, then the software should work without porting.
 
SDK Chan said:
Ok, interesting.
I guess it might be worth to try out.
If linuxulator really has almost every system call, then the software should work without porting.
Click to expand...

Well, there is more to it than just having a system call.

Many system calls have many features and not features might be present in the Linuxulator. For example, the Linux ptrace(2) system call has a bazillion of tricks that are hard to reproduce and they might be used in an emulator.

Many system functions are all funneled through the ioctl(2) system call. Many.

Things in /proc and /sys might or might not be present.

But either way, starting with the Linuxulator is clearly the way to go here instead of adding system calls to the FreeBSD API. Plus, it would improve FreeBSD a lot, whereas pure Linuxisms in the FreeBSD API would probably be rejected in review.
 
To be honest, I am really rethinking some things right now as I am talking to some switch emulator project leaders.
The emulator in question is a game emulator called Ryujinx.
It is written in C#, not so good if you want performance, besides I do not really know to which extend dotnet is supported on FreeBSD.
The Avalonia UI does not really work, but the ugly GTK 3 does, and it is an external so, some work would be needed to get it updated as not to break the project for existing Windows, Linux, MAX OSX users.

The emulator is in a okay state, since no updates are provided any more as of October 10th 2024.
Even if I get it to work, sane people will prioritize C++ emulator projects more than C# as it is seen with new Nintendo Switch emulators or forks of emulators/yuzu.

Altogether I think I should focus here on a C++ based Nintendo Switch emulator project.
After a discussion with the project leaders, we came to a conclusion that it does not matter what you do.
Nintendo is targeting emulators like crazy, and if there does not exist a reason to take your project down, they will find one, create one, or bribe the lawyer.
The Ryujinx team in this case got bribed.
It is not an aspect of legality anymore, it is just corruption at this point.

So, naturally people who dare to develop Nintendo emulators are forced to hide themselves, developing emulators now in secret once they go mainstream.
Not every person has the patience, time, courage, and mindset to do so.
Only 2 of 5 leaders are self-hosting, one of them even in the dark web only to preserve games.
If Nintendo really goes on rampage, they will do everything to shut down public projects.

One of the 5 leaders is the developer of nxEmu.
He hosts on github, and hopes to avoid Nintendos DMCA.
The project is completely legal, but Ryujinx was, too.
So, hosting on github will only result in nothing in the long term.

I really respect the 2 leaders hosting securely.
So, yes, there is already a development team.
Now, I somehow want to unite them, and develop with them together...

Actually Yuzu is outdated.
I will see how to port its fork Torzu over, as I want to get it further developed since it is in the safest position right now, hosted very securely, and it has updates for playing new games which yuzu lacks.
 
You must log in or register to reply here.
Back
Top