flat assembler
Message board for the users of flat assembler.
Index
> OS Construction > Modularity? |
Author |
|
edfed 08 Jun 2010, 00:11
two functoins needed for that
1/ load file in ram and return a far pointer + size 2/ launch that code from kernel main loop |
|||
08 Jun 2010, 00:11 |
|
cod3b453 08 Jun 2010, 18:33
I'm not sure if this is what you mean but I have all ISRs pointing to one master handler, which by default captures all exceptions but delegates other vectors to a lookup table of handlers if they have a non-null entry; these pointers are set up by externally loaded modules. I plan to do the same with syscalls.
|
|||
08 Jun 2010, 18:33 |
|
Tyler 08 Jun 2010, 22:47
edfed wrote:
I mean the types of things that are at the very core of a kernel, like hardware access and memory management. Things that are called by that main loop. For things that have residual data between runnings of the code, for example, the memory allocator always has data on the allocated memory, there would be a protocol for the old function to "tell" the new function what memory was allocated. cod3b453 wrote:
This is different, but you've caught my interest. How do you know what int # triggered your master isr? My idea is different because the loaded piece can replace a function used by the kernel itself. The pieces would be in a special object format(using an ld script) that would list the function names to be replaced, and the names of functions that would be invalid after patching(to prevent loading of mem allocator and not of mem freeer, etc.). |
|||
08 Jun 2010, 22:47 |
|
cod3b453 09 Jun 2010, 08:18
I create stub entries that align the stack by pushing dummy error values and then the isr number before jumping to the master handler:
Code: rept 256 i { idt_#i#: cli if (i-1) = 8 | (i-1) = 10 | (i-1) = 11 | (i-1) = 12 | (i-1) = 13 | (i-1) = 14 | (i-1) = 17 ; No dummy error code else push 0 ; Dummy error code end if push (i-1) ; Push the ISR number jmp core_isr_handler align_int3 16 } |
|||
09 Jun 2010, 08:18 |
|
baldr 09 Jun 2010, 12:49
cod3b453,
With call core_isr_handler (instead of jmp) and simple math you don't need push (i-1). The whole point of single handler still eludes me. Particular exception/interrupt handler already knows about error code presence, and unhandled exceptions/interrupts can be uniformly dismissed by #NP handler. |
|||
09 Jun 2010, 12:49 |
|
revolution 09 Jun 2010, 13:06
Tyler wrote: I've been thinking about some methods of modularity that would allow for pieces of kernel to be loaded(I literally mean kernel, not driver, for example, an isr module could be loaded) and used seamlessly by the kernel. Has this been done? If so, how? Of course with the ARM all external interrupts come in through one point so we have to distribute from there, whereas in the x86 the interrupts can come into separate locations and be handled directly. The approach taken by cod3b453 can be useful if you want to isolate drivers from the kernel (perhaps by using ring 1/ring 3 drivers?) and this gives the kernel a chance to do any special set-up/exit that might be required around the driver code. It all depends upon how you want to structure your OS. |
|||
09 Jun 2010, 13:06 |
|
cod3b453 09 Jun 2010, 19:17
revolution: I think Tyler means physically overwriting kernel subroutine code with an alternative, using a common data representation to glue it all together; this keeps the function pointers static but the code is dynamic.
Tyler: This (above^) should work as long as nothing is executing that function; it's not very different from 'hotfix' code patching which is fairly common. ---- baldr: That's not a bad trick, I might just 'borrow' it I chose the single handler for easier code maintenance, there's no other real benefit. |
|||
09 Jun 2010, 19:17 |
|
Tyler 09 Jun 2010, 22:16
revo1ution wrote:
It's similar in how a function is dynamically registered to handle a specific task, but it's the limitation that your kernel is still there as an extra layer of abstraction. In my model, the registered function would not be registered in the sense that the kernel gets the interrupt, then calls all functions registered, the function registered would simply become the handler. But not only in the way of handling interrupts, but in commonly used functions even within the kernel. For example, I'll use the physical page allocator(does arm have paging?), instead of: Code: call alloc_page ;... more code alloc_page: ;... code that will return free page mine would use: Code: call [alloc_page] ;... more code ; BEGIN writable mem dd alloc_page ; pointer to code that will return free page The difference is that the kernel memory management model could be adapted for the needs of the currently running system. If you're willing to sacrifice small data structures for fast alloc/free because speed is more important, use the fast allocator, if size is more important, use a size conscious allocator. The same concepts would be used on every function, the file open/close/read/write, console io, everything. It would allow for dynamic adaptation of the kernel to it's environment. There would be a protocol for each type of function, like for file handling patches, the current would produce a universally understood map of all open files upon being given a kill signal, the new one would then have an init function that would parse that map, format it as it likes for it's own use, and reproduce a map upon being killed. cod3b453 says it pretty well. It's still all theory, but if done right, this could make for a really cool kernel. |
|||
09 Jun 2010, 22:16 |
|
revolution 10 Jun 2010, 00:31
Tyler wrote: (does arm have paging?) Tyler wrote:
|
|||
10 Jun 2010, 00:31 |
|
Tyler 10 Jun 2010, 02:58
revolution wrote:
Thanks, that answers my question. Does Linux use kernel hooks? ISRs were an earlier example of what could be loaded, that wasn't intended to look like/be an ISR. I wrote:
|
|||
10 Jun 2010, 02:58 |
|
revolution 14 Jun 2010, 03:46
Tyler wrote: Does Linux use kernel hooks? |
|||
14 Jun 2010, 03:46 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.