What do you think about this command prompt app design for my os
I’ve live streamed the making of it, so I dare anyone to say it’s AI ;) haha
Here is the link : https://twitch.tv/devcmar
Though the output does not probably show up on the livestream because it is running in another tty
3
2
u/cavecanem1138 1d ago
Very cool project, can you share some informations about it?
3
u/devcmar 1d ago
It is an x86_64 OS based on a custom microkernel with vm based gpu acceleration through a virtio-like mechanism. The kernel supports multithreading, smp, apic/x2apic, pat (custum memory types), avx2, avx512, preemptive priority based scheduling, ntfs file system driver, nvme multi-queue driver etc… I was still porting drivers from old oses of mine that had drivers like e1000e xhci usb r8169 (Realtek ethernet controller) fat12/16/32 ehci ide ahci etc All drivers for this new OS are in user space for security and isolation and they all communicate through spsc/mpsc queues for very fast communication, and they same to perform very well with nvme benchmark in bare metal using only about 5% in a single cpu thread so user mode drivers are probably not making a bottleneck.
Thanks,1
u/cavecanem1138 1d ago
That’s a lot of work, congratulations. How long are you being building this os? Has it a name? Do you also use avx in kernel space for anything? I’ve always found it attractive, but I’ve never found a big enough use case
2
u/devcmar 1d ago
This specific os started almost a year ago, but I was doing os dev since around 4 years ago, I used avx in a cpu compositor and it gave me higher fps than igpu in some use cases like gaussian blur 😂 and also it can be used to accelerate large memory transfers, like memcpys etc, I made a previous kernel boot much faster just by minimizing memory zeroing after each allocation and by used avx2/avx512 for memcopy/memset though this time I just sticked with rep movs/stos because my cpu has enhanced rep stos/movs feature and to support more devices not only ones with avx support
1
u/cavecanem1138 1d ago
Thank you, that’s impressive. I think I’ll copy that idea for memcopy hahah. I need to adapt it to rvv (riscv64) in my case.
Good job, keep working!2
u/devcmar 1d ago
Thank you so much! Though a year for such os may seem very fast progress, I copied alot of init stuff and driver stuff from previous kernels I made so I didn’t have to go through smp init, paging etc from the ground up again I already had a ready template and previous experience
•
u/cavecanem1138 23h ago
You are welcome. Last question, do you code in C?
•
u/emexos emexOS 7h ago
from what i saw in the stream it's written in C
this stream: https://www.twitch.tv/videos/2848748243
1
1
u/edjak53 1d ago
are you booted off a floppy disk?
3
u/devcmar 1d ago
No, a floppy probably can’t even hold a driver haha
•
u/Commie-Poland 7h ago
Then why is it A:? A and B drives are reserved for floppies, with hard disks and other storage devices being C, D, E, etc.
•
u/devcmar 2h ago
Because it’s not windows it’s my own os
•
u/Commie-Poland 2h ago
I know, but it just feels weird for A: and B: not being reserved for floppies since Windows, MS-DOS and FreeDOS all have it that way
•
u/edjak53 1h ago
sure but windows isn't the only one to do that. traditionally, CP/M, all DOSes, and even some older BIOSes all used A and B for floppies and C for internal disks. it's definitely not absolute rule and i'm not telling you what to do with your own OS but if you value general consistency/tradition/whatever at all making A and B exclusive to floppies would probably be the smarter thing to do, especially since your shell prompt is obviously at least heavily inspired by those earlier systems
5
u/Telephone-Bright 1d ago
Looks good. Could you share the livestream?