As Mat wrote, this is probably unreasonably limited. Nevertheless, I will try to pay as much attention to the sum of the questions as I would like for one reasonably resolved question, in the hope that this will help you start the study.
1 What is the difference between preemption and context switch?
Prevention is the act of interrupting a process without its participation. In this context, this probably means that a timer interrupt will fire. The word comes from the legal concept of preemption : action or right to demand or buy before or in preference to others. For your purposes, this means that when a timer interrupt is triggered, the interrupt service routine (ISR) has preference over the previously run code. This does not have to include the kernel at all; you can run the code in any ISR that will work proactively.
The context switch is what happens when the OS code (works proactively) changes the state of the processor (registers, mode, and stack) between one process or context thread and another. The processor status can be in a specific line of code in one thread. It will have temporary data in registers, a stack pointer in a specific memory region, and other status information. A proactive OS can save this state (either to static memory or to the process stack) and load the state of the previous process. This is called a context switch.
2 What are the main differences between a preemptive and non-responsive core? What is required for the programmer to make the kernel proactive?
In a proactive kernel, an interrupt can fire between any two assembly instructions (called "sequence points"). In an unmanaged kernel, a running process must call the yield() function, which allows other threads to run. Look-ahead kernels are more complex, but provide a better illusion of concurrency. Continuous kernels can be made very simple with setjmp.h , but each thread must regularly call yield() or the other threads will not execute.
When a function of type yield() is called, the state of the processor is saved automatically. If you want your OS to be proactive, you must save this information manually.
3 How to create and work with user mode?
ARM docs say that in user mode, any command switching to privileged mode will be considered an undefined instruction.
Right. However, they also say that any interrupt will be launched in privileged mode automatically. On an ARM system, you can use the svc instruction to generate a software interrupt. Then the SVC code (part of your OS) will run in privileged mode.
4 If so, is syscalls the only way to use the user program for user code?
Right. At least this is the only safe or correct way.
5 How does the kernel react or interact with user space, then?
In ARM, the SVC command can get an 8-bit value. This can be used to generate 256 system calls, such as exiting, turning on interrupts, turning off interrupts, or whatever you need. You can also choose to create a sharing or messaging engine if you need one.
6 Does this mean that the only kernel thread after boot (on a simple system) will be an idle thread?
It completely depends on how you design your system. This is probably simpler if you decide to start your kernel only after all your threads have been created - so you don't have to worry about dynamically allocating threads. Or you can start with an idle thread and add other threads later (through a remote shell? I think you want at least one user thread to work sequentially ...)
7 If the page where the kernel code and data is located does not appear when switching to the user process, and then in the standby or interrupt mode, how does the kernel code execute without displaying in the virtual address space?
Just like kernel mode code works in privileged mode, even if the code was previously executed in user mode, so kernel mode code is run from the main stack pointer (MSP), even if the process code uses a different address space.
8 Does the “preventive kernel” only have the kernel designed in such a way that it would be safe to have a context switch during kernel code execution? or is more work required, if any?
I think this means that the kernel can unload user code, and not that the kernel itself can be unloaded. It would be difficult and unusual for anything to interrupt the core. It will take more work, and I'm struggling to figure out why you need it.