Page 3 of 5
Re: Enabling compiler optimizations ruins the kernel
Posted: Wed Sep 28, 2022 2:38 am
by rdos
devc1 wrote:What a DLL has to do with system calls ?
A DLL (Dynamic link library) is just like the static library you link to your programs using ld. But the dynamic library does not get linked on compile time, it gets linked by the OS in runtime.
How is that beneficial ? Well this solves a lot of problems, for example security updates or syscalls and other changes in the kernel will make other apps unusable. Instead of recompiling all the apps, I can just edit and recompile the DLL on My new OS version and every app will just work fine as previous.
Notice how the NT Kernel changes its tables, system calls and functions in almost each version. Without that, applications will become unusable on the new version.
I cannot see any advantage of Windows way of handing syscalls. They define the API based on a set of DLLs that export some given functions. For one, this means they must implement every function they ever had, otherwise applications will get unresolved imports. This is bloating the system given that many old functions might not be used. My syscalls will return with CY (error) if a syscall is not supported, and there is no need for any static code handling obsolete syscalls.
Re: Enabling compiler optimizations ruins the kernel
Posted: Wed Sep 28, 2022 3:26 am
by rdos
devc1 wrote:This is sooo inefficient according to my optimizing plans.
Why ? Because system calls are slow.
How I am fixing it ? These DLLs will contain heap management, IPC and other features implemented in user space and if a program decides to ruin them it will only damage the process and not the OS.
Heap management is generally a libc issue, not something you put in DLLs.
devc1 wrote:
for e.g. instead of a syscall at every malloc, the DLL will contain the tables (at an isolated area) and if it needs more pages then it will syscall.
Why would you want to implement malloc with syscalls? This should be linked to the application and part of the runtime library.
devc1 wrote:
Why a syscall at every IPC Send/Get request when we can just share some pages between processes and communicate without system calls.
Doesn't seem to be related to DLLs. You provide syscalls to create shared memory areas and then can create whatever IPC mechanisms you think are useful in shared memory.
Re: Enabling compiler optimizations ruins the kernel
Posted: Wed Sep 28, 2022 6:30 am
by nexos
devc1 wrote:Why a syscall at every IPC Send/Get request when we can just share some pages between processes and communicate without system calls.
That's not possible. You're gonna need to context switch at some point during an IPC request no matter what you do. You'll also need IPC to adjust mappings of pages so you can share them.
Re: Enabling compiler optimizations ruins the kernel
Posted: Wed Sep 28, 2022 1:31 pm
by devc1
rdos : you are just repeating what I said, the process will do a syscall only if it needs more pages of memory.
for IPC : My design is to have multiple 64 message entry lists for each connection (or process/thread). Where the sender can just allocate a message with the bsf instruction in a UnallocatedMessageBitmap, and the receiver can read also with "bsfq r64/m64" in a PendingMessageBitmap.
The connection will happen with a syscall, and the kernel will allocate the shared IPC resources.
Thus this design can be asynchronous at a level, and of course you can make synchronous communication at the same time.
Re: Enabling compiler optimizations ruins the kernel
Posted: Wed Sep 28, 2022 1:34 pm
by devc1
iansjack wrote:devc1 wrote:for e.g. instead of a syscall at every malloc, the DLL will contain the tables (at an isolated area) and if it needs more pages then it will syscall.
Does any OS use system calls for a (user process) malloc? Other than extending heap space, if it runs out, why would you need a system call for this?
This was just curiosity, however I figured it out myself. So what I said was right, I will only syscall if I need more pages.
Re: Enabling compiler optimizations ruins the kernel
Posted: Wed Sep 28, 2022 1:48 pm
by iansjack
Nice as it is to try and rewrite history to make yourself look better, you actually said:
instead of a syscall at every malloc
That just doesn’t happen.
Re: Enabling compiler optimizations ruins the kernel
Posted: Wed Sep 28, 2022 3:36 pm
by AndrewAPrice
iansjack wrote:Enabling all warnings is a good start. A quick Google will find other tools.
Turning on warnings is great for your own code. Warnings aren't so great when compiling third party libraries ported to my OS.
Re: Enabling compiler optimizations ruins the kernel
Posted: Wed Sep 28, 2022 6:20 pm
by kzinti
AndrewAPrice wrote:Turning on warnings is great for your own code. Warnings aren't so great when compiling third party libraries ported to my OS.
Then just turn them on for your own code?
Re: Enabling compiler optimizations ruins the kernel
Posted: Wed Sep 28, 2022 7:38 pm
by nexos
devc1 wrote:Code: Select all
STATUS Iansjack(){
listentoIansjack()
Understood()
IansjackSaysYouAreTryingToLookGood()
return ERROR_HE_IS_RIDICULOUS;
// I'm kidding.. :)
}
Really? iansjack is heads and tails above us
all in knowledge, you better listen to him. It's quite insulting for a rookie OSDev'er to talk to one of the most senior forum members that way. I know I would treat would he says with respect.
Re: Enabling compiler optimizations ruins the kernel
Posted: Wed Sep 28, 2022 7:47 pm
by nexos
devc1 wrote:My design is to have multiple 64 message entry lists
Whoa, arbitrary limits like this are just asking for trouble.
And, your design doesn't specify how process block to wait for incoming messages or block to wait for the receiver to be ready. That
has to be done with syscalls.
Re: Enabling compiler optimizations ruins the kernel
Posted: Wed Sep 28, 2022 8:40 pm
by nullplan
AndrewAPrice wrote:Turning on warnings is great for your own code. Warnings aren't so great when compiling third party libraries ported to my OS.
What, you don't have any standards for third-party code added to your OS?
Re: Enabling compiler optimizations ruins the kernel
Posted: Thu Sep 29, 2022 3:25 pm
by devc1
I just want to know why is this impossible ? I can't really understand your arguments.
It is just like a simple addition that after re-thinking about it, it seems not so usable.
The addition is the message queue that you can (if the send req is async) spam multiple messages on it then Block optionnaly (you mean by that Task Switch ?). This can be faster in some situations like the Window Manager when sending screen and cursor changes that happen at the same time.
This mechanism is used on most devices.
The thing will be simply like this:
Code: Select all
struct _IPC_MESSAGE_QUEUE
{
// Bitmaps for fast fetches
UINT64 UnallocatedMessages;
UINT64 PendingMessages;
// 64 asynchronous messages (can be expanded)
MSG Messages[64]
}
Re: Enabling compiler optimizations ruins the kernel
Posted: Thu Sep 29, 2022 6:01 pm
by nexos
But what happens if a server has a lot of incoming requests? Arbitrary limits would not be good here.
One thing to remember is that many OS design choice do seem preposterous, but, once you developed an OS or studied existing ones extensively. you'll see why there designed this way.
Re: Enabling compiler optimizations ruins the kernel
Posted: Thu Sep 29, 2022 11:31 pm
by iansjack
nexos wrote:But what happens if a server has a lot of incoming requests? Arbitrary limits would not be good here.
A linked list, rather than an array, is the better way to handle this sort of situation.
Re: Enabling compiler optimizations ruins the kernel
Posted: Fri Sep 30, 2022 6:06 am
by devc1
Thanks for your suggestions, I will try to implement a linked list. It seems better, one of the reasons that come to mind is that the app may get stuck if the message list is full and the server isn't responding, but in a case like this where the server chooses to not respond, the OS will keep allocating linked lists until it crashes.