Index
> MenuetOS > ProgressGoto page 1, 2 Next |
| Author |
|
|
daniel.lewis 01 May 2008, 06:45
Spent my code time this month working on my scripting engine, so no progress. Been thinking to study up Virtual Iron, see if there are exposed interfaces to make life easier - like being able to start in pmode or lmode.
Well practiced and studied laziness outdoes blind hard work most days. _________________ dd 0x90909090 ; problem solved. |
|||
01 May 2008, 06:45 |
|
|
Madis731 03 May 2008, 18:56
Well, sad to see your posts unanswered, but I see no solution from my end. Try to mail Ville directly and ask him in e-mail or post this thread. In his busyness he might not stumble here very often. Now that he also has Menuet's own board.
I feel that you are talking about 32-bit version, because 64 isn't open-source. So the points you gave actually mean, you've been improving or modifying 32-bit MenuetOS? |
|||
|
03 May 2008, 18:56 |
|
|
daniel.lewis 07 May 2008, 00:16
The website provides the algorithm in a format designed to be executed by the x86 platform, rather than read by a human. Fortunately, tools have existed for the past 20 years to translate from one to the other.
It's unfortunate that we need to do extra work because some people are uncomfortable with that. Anyways, I had offered to provide some patches behind closed doors and received no response so I'll assume they're also unwanted. Judging by the low activity around here, these forums are essentially dead. My recommendation is to check out http://www.kolibrios.org, which is an open source fork, but if you're stuck on Menuet for some reason... http://menuet.2.forumer.com/ _________________ dd 0x90909090 ; problem solved. |
|||
|
07 May 2008, 00:16 |
|
|
Ville 08 May 2008, 12:09
Couple of notes..
> 1) Removing obsolete API calls (done) System calls are build upon programming needs. It's likely that all of the system calls are used by some application. > 5) Causing all applications to run in ring 0 (weird bug atm) If new features are added, ring-3 protection needs to be preserved. > The website provides the algorithm in a format designed to be executed > by the x86 platform, rather than read by a human. Fortunately, tools > have existed for the past 20 years to translate from one to the other. > It's unfortunate that we need to do extra work because some people > are uncomfortable with that. Programming language is a personal choice. Both Fasm and Menuet32/64 are for assembly programming. Regards, Ville |
|||
|
08 May 2008, 12:09 |
|
|
daniel.lewis 09 May 2008, 06:57
1, 5) Graphics and HID driving should theoretically be a separate programming effort. Putpixel, etc, was separated out into a different bundle of code and I'm thinking to assign them different interrupts. Something like:
0x40 for OS 0x41? for graphics? 0x42? for keyboard and mouse? Would seem sensible, but I can't remember what interrupt addresses are taken. ~~ The security model I'm thinking of is to use Pacifica/VT/Virtual Machine to multiplex securely; and to use my algorithm (the modified Menuet) to act as the application with seemingly raw hardware access to an arbitrarily consistent hardware platform. ~~ Quote: The website provides the algorithm in a format designed to be executed by the x86 platform, rather than read by a human. Fortunately, tools have existed for the past 20 years to translate from one to the other. Quote: Programming language is a personal choice. Both Fasm and Menuet32/64 are for assembly programming. Yup. I've no problems with the assembler language. Translated plain, what I said was that the menuet website provides the program in binary form, not assembly. Fortunately there are disassemblers to translate from the one to the other. I am still working off 0.78 however, since that debacle earlier. I do wish I could use 0.84, but I'm restricted from translating it to assembler, and I refuse to read the machine code directly, even just to understand the USB improvements. The arbitrarily consistent hardware I want these appliances to have available is x86-64, DMA, USB 3.0, AC 97, USB 3.0 disk space and Eth 10/100/1000. I realize USB 3.0 isn't even fully spec'd yet, but I'd imagine it's not terribly far from USB 2.0 so that's probably a good place to plan from. Regards, Daniel _________________ dd 0x90909090 ; problem solved. |
|||
|
09 May 2008, 06:57 |
|
|
Ville 09 May 2008, 19:31
Currently only interrupt 0x40 is available from ring-3 application. Calling other interrupts will generate a general protection fault and will terminate the application. Menuet32 uses single interrupt for system calls since it's easy to implement and doesn't duplicate programming efforts. A single interrupt is also somewhat easier to supervise. Menuet64 has both 0x40 and 0x60 interrupts available, also from 32bit application.
After the USB mass storage code is running flawlessly, we should add more support for different device classes, like networking. |
|||
|
09 May 2008, 19:31 |
|
|
daniel.lewis 12 May 2008, 06:34
The other interrupts generate a GPF because the IDT is set up to do so (at least, it looks this way). Most OS IDTs use a default GPF error for unused slots, so all that needs happen is a function pointer to a new ISR in the IDT in slot 0x41 iff the 0x41st slot points to that default.
Looking forward to USB. That'll be cool. _________________ dd 0x90909090 ; problem solved. |
|||
|
12 May 2008, 06:34 |
|
|
Madis731 12 May 2008, 16:39
Actually I don't understand the benefits of your proposal, daniel.lewis. From programming side it doesn't matter if you change interrupts or registers. It doesn't change functionality - whether its done in one way or the other in an OS.
|
|||
|
12 May 2008, 16:39 |
|
|
daniel.lewis 13 May 2008, 00:18
 You're right, Madis. Separating the interrupts is merely a symbolic indication to programmers that there is some difference between one or the other. I'm simply indicating a device-wise isolation to compartmentalize work.
I would recommend: cpu/thread/eip related memory/paging/alloc/gc related disk/storage related display/gpu/physics related audio in/out related network/tcp/ip related keyboard/mouse/hid related timestamp/clock/apic/little things related By compartmentalizing device like that, you can upgrade each device in parallel to the others, out of sync, and beginning to remember the right interrupt for a given category is easy (6-8 is a good number for the brain). You can approach the cpu driver as a whole and without clutter and envision gaps and overlap in it's functionality. That is what I was moving towards. _________________ dd 0x90909090 ; problem solved. |
|||
|
13 May 2008, 00:18 |
|
|
edfed 13 May 2008, 00:29
Quote: a device-wise isolation to compartmentalize work. and to comparmentalise coding. a global interface, x86 oriented, shall be found and deeply studied to have a strong and powerfull system. each layers shall work in parallel, and be as concice as possible. this is not only menuet os related, but all os related. and one precision, before to devellop something impossible to rely to other OS, we can seek a method together. exactlly as the OSI and W3C make, but FASM oriented, about os construction, and with direct application. one second very important thing is to permitt to all FASM based os to execute the same executables binaries, providing a comon minimal interface with the kernel based on normalised hardware. i have a preference for the .com binary, as it can be executed from boot to v86, and in Protected mode too. org 100h philosophy. we can use 256 bytes from kernel to provide a semaphore array used by the kernel to communicate with the executable. this 256 bytes zone can be used as a device interface too. for example , the keyboard, it can store all the status of all keys. and for network, it can store the content of a NE2K page. for audio, it can store the generic controls of the card. and so on. |
|||
|
13 May 2008, 00:29 |
|
|
daniel.lewis 13 May 2008, 01:52
This is my example of taking Menuet and completely compartmentalizing it in this fashion. Go ahead and do it differently or not at all, I don't care. I find it's fairly revealing and useful though.
int 0x41 : cpu driver call rax : function 5 - Delay 9 - Get process info 10 - Wait for event 11 - Check for event 22 - Wait for event with timeout 40 - Set bitfield for wanted events 51 - Threads 105 - Delay (ms) 123 - Wait for event with timeout (ms) 126 - Switch to 32 or 64 bit 256 - Start process 512 - Terminate process int 0x42 : memory driver call (obviously needs more work) rax : function 64 - Application memory resize int 0x43 : display driver call rax : function 0 - Draw window 1 - Draw pixel 4 - Draw text 7 - Draw image 8 - Draw button 12 - Window draw state 13 - Draw rectangle 15 - Draw background 35 - Get pixel 38 - Draw line 47 - Draw number 50 - Draw freeform/transparent window 61 - Framebuffer access 67 - Resize/move window 113 - Scrollbars 119 - Draw circle 120 - Window skinning 122 - 3D API 124 - Hide/Show/Activate window 125 - Window transparency int 0x44 : hid driver call rax : function 2 - Get key 17 - Get button info 37 - Get mouse data 66 - Keyboard data mode * - note: some stuff in menuet is intermingled with CPU driver int 0x45 : misc calls (refactor!) rax : function 3 - Get date/time 9 - Get process information 26 - Get general system information 58 - Filesystem 60 - IPC 63 - System debug information 110 - Get information about me 111 - Who am I? 112 - Get configuration information 121 - Drag and Drop 500 - System int 0x46 : port driver call (refactor!) rax : function 42 - Read data from IRQ 44 - Define ports to read at IRQ 45 - Reserve/Free IRQ for data read 46 - Reserve/Free port for direct read 52 - Network interface 53 - Network interface 114 - CD Audio 115 - PCI 116 - Driver state access 117 - Audio 118 - MIDI _________________ dd 0x90909090 ; problem solved. |
|||
|
13 May 2008, 01:52 |
|
|
System86 14 May 2008, 00:25
Makes sense, but why are the subfunctions not consecutive. Why not have them go up 0, 1, 2, 3, 4, etc. for each interrupt, if that is done? Is the reason backwards compatibility (to make it easier to port existing code)?
Also, why do other systems (like Linux) use only one interrupt (int 80h) (just a question, not sure why)? There are 256 ints available, and even with 32 reserved and 15 for IRQs, there are lots of ints left. I think each driver could have its own vector, kind of like in BIOS/DOS, were video=10h, disk=13h, kdb=16h, DOS=21h, mouse=33h, etc. There are plenty of interrupts available, why not use them? |
|||
|
14 May 2008, 00:25 |
|
|
Madis731 14 May 2008, 05:47
I'll have to agree more with daniel.lewis's proposal here because going the DOS ways has a few more negative sides.
One is programming. You will have to program every vector. MenuetOS resolves this by having only one, but asking user the function (=EAX/RAX). Other is well debatable, but this 32-to-64-bit transition showed us how sparing ints may help. Just change one value from 40h to 60h and you're calling 64-bit functions. When you take most of the ints in 32-bit world, you'll have to scrap everything or write over them etc. daniel.lewis was proposing organizing. You're thinking on the road of separating everything. |
|||
|
14 May 2008, 05:47 |
|
|
daniel.lewis 15 May 2008, 00:17
 Okay.
He was right about making the interrupts more consecutive, I was just showing the mapping from the current numbers into appropriate groups. Separating interrupts into specific devices gets problematic because it's quite feasible these days to have a single terminal server with 300 users. Or the OS being used with a similar number of DoF for a robotic assembly line. Point being, you want broad semantic categories on an ISR, at most. That way at most you'll have 16 interrupt lines, and can do what Madis suggested. The reason you *do* want more than one interrupt line is so you can keep your API coherently listed even when you need to add 1 function to the memory driving component.  _________________ dd 0x90909090 ; problem solved. |
|||
|
15 May 2008, 00:17 |
|
|
Tolle 16 May 2008, 01:25
The following is all in my honest opinion:
Quote: The design goal has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs. Consider the following examples: Code: ;Let's draw a black pixel at 10,10 mov rax, 1 mov rbx, 10 mov rcx, 10 mov rdx, 0 int 0x60 ;Now, since i don't like remembering numbers i use a neat little trick putpixel equ 1 button equ 8 waitforevent equ 23 mov rax, putpixel mov rbx, 10 mov rcx, 10 mov rdx, 0 int 0x60 ;Since the above works out quite nice, i decided to add another equ sysint equ int 0x60 mov rax, putpixel mov rbx, 10 mov rcx, 10 mov rdx, 0 sysint ;I don't have to worry about sysint, ;it will always do what i want and always logically conclude my system call. ;It will work for every function out there, ;i can easily spot a mistake and i have to make zero modifications ;to the kernel to code like this today. ;If we modify MenuetOS to add more interrupts i could still use equ's ;but i will at least double my changes to goof up because now i have ;to remember not one but two numbers/identifiers per sytem call. mov rax, putpixel ... sysintdraw mov rax, getprocessinfo ... sysintcpu mov rax, getprocessdata ... sysintcpu ;Since you knew it was coming, you will have noticed that i conclude ;both getprocessinfo and getprocessdata with sysintcpu while ;in the example daniel.lewis gave above, i would have ;to type something like sysintmisc, my mistake. ;I hope i don't spend the rest of the day looking for this bug. ;+ you are opening a whole can of worms on deciding what function ;belongs in which subfamily. a problem we don't have now. ;32 vs 64 is pretty strict, i can live with that one. ;If you want to have some sort of structure in your own programs, ;you can also use equ's display_putpixel equ 1 hid_getkey equ 2 ... Keeping structure might seem great and it usually is. But fighting numbers with even more numbers will (again imho) always fail. The less i have to remember and think about things, the better. |
|||
|
16 May 2008, 01:25 |
|
|
daniel.lewis 16 May 2008, 05:27
Well Tolle, there is no additional abstraction or layers or new code or new bugs.
Right now, flow goes into an interrupt, goes to an isr function which is a switch and each case is a "function". My proposal, flow goes into an interrupt, goes to an isr function which is a switch and each case is a "function". 
Personally, I think it makes sense separating "draw a button" from "get process info" on the API. More importantly, I think it makes sense to group things different ways to recognize the gaps and overlap in functionality provided by one. Like I said, use it as you see fit. _________________ dd 0x90909090 ; problem solved. |
|||
|
16 May 2008, 05:27 |
|
|
Madis731 16 May 2008, 05:28
I'm for it with my both hands. You are better off hiding the numbers with macros as Tolle showed us here. Then the user doesn't care anyway about what's behind it.
|
|||
|
16 May 2008, 05:28 |
|
|
Ville 16 May 2008, 17:06
Currently we only need to remember a single system call for function. Adding new interrupts will just add another layer to be remembered. Not to mention the need to rewrite most applications and M64 system calls.
|
|||
|
16 May 2008, 17:06 |
|
|
daniel.lewis 21 May 2008, 05:17
Meh. For my fork I don't care about apps yet, just the OS. I look at it as a need to move to support drivers; and that using a single address space for all drivers will result in more pollution long term than using address spaces for each driver class.
It might also be possible to dynamically map interrupts to a program but ultimately if you want device drivers it makes sense to offer them some kind of ISR interface. I would also like to say that I haven't yet done what I've said above and by the time I do a good number of the relevant function calls will be different. |
|||
|
21 May 2008, 05:17 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|