Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let’s write a Kernel with keyboard and screen support (2014)

arjunsreedharan.org

Post reply on HN
Print view View original

31–40 of 40 posts

Re: Let’s write a Kernel with keyboard and screen support (2014)

#31

Post by zaarn »

jjoonathan wrote: post #29
zaarn wrote: post #19

Earlier quoted context omitted.

If you're on UEFI, the 16bit environment is very likely running inside a UEFI "hypervisor" (ie, it puts the CPU into 16bit mode after setting up the appropriate interrupt handlers and hardware drivers). If you boot Windows or Linux via UEFI and not BIOS methods, then you never leave 64bit mode during boot. Real BIOS that boots from 16bit is quite a rarity these days.

Does UEFI start the same way as BIOS (firmware on LPC bus, PC starts at 0xFFFFFFF0)? Or is there a different top level mechanism? My understanding was that the CPU still starts in 16 bit real mode (with an evil hack to sign-extend IP) but that by the time UEFI hands off to code on a hard drive it is in long mode.

UEFI starts the same way but yeah, it hands off 64bit (or 32bit if you have a 32bit UEFI).

Re: Let’s write a Kernel with keyboard and screen support (2014)

#32

Post by alexis_read »

I've not watched the series, but the full stack (ie. Cpu and gpu design in verilog, hdmi, bootstrapped mutitasking os dev, not your average FullStack marketing-speak) for a platform is done by bitwise: https://m.youtube.com/#/user/pervognsen

Looks very accessible :)

Re: Let’s write a Kernel with keyboard and screen support (2014)

#33

Post by peatfreak »

meuk wrote: post #22
zaarn wrote: post #2

If anyone wants to breach into kernel development, I recommend osdev[0], which is a very good resources for beginners and others. 0: https://wiki.osdev.org/Main_Page

The forums are also excellent. They are a little bit like the Arch Linux forums: People can be a bit snarky, but pretty much everyone is extremely smart and pretty helpful. Noobs are tolerated if they are willing to put in some effort.

> Noobs are tolerated

Sounds enticing!

Re: Let’s write a Kernel with keyboard and screen support (2014)

#34

Post by jrockway »

zaarn wrote: post #15
jrockway wrote: post #12

Earlier quoted context omitted.

grub is pretty bloated but also reliable. Finding the kernel is not as easy as it used to be. You need to read the partition table on the disk. You need to be able to understand the filesystem that the kernel is stored on. This adds a fair bit of complexity.

On a modern UEFI system you actually get provided with an API that can do all that for you, though only FAT32 partitions are supported for the FS out of the box (you can load your own drivers for more). If your boot partition is FAT32, UEFI makes things much much simpler.

True. And I think that's more than adequate for your homebrew OS. (Which can just have a second stage if you really need to boot off of an encrypted RAID-5 partition connected to a custom storage controller.)

Re: Let’s write a Kernel with keyboard and screen support (2014)

#35

Post by ajross »

mcculley wrote: post #26

This is making me wonder: Thinking about Dan Luu's research on latency of modern systems ( https://danluu.com/input-lag/ ), what is the minimum latency one could get in a modern system (e.g, USB keyboard, modern display hardware)?

Display refresh had never gotten much faster than 100hz or so, so that will be your limit. USB, even terrible implementations thereof, is much faster.

Re: Let’s write a Kernel with keyboard and screen support (2014)

#36

Post by fao_ »

peatfreak wrote: post #21
hazz99 wrote: post #11

For further reading, I can't recommend enough this free book: http://pages.cs.wisc.edu/~remzi/OSTEP/ It's fantastically well-written, yet detailed without being overwhelming.

I just read one chapter, which I thought was OK. It felt more like a book on how the C programming language translates to operating system concepts, rather than a book about the operating system concepts themselves. For example, the chapter I read discusses malloc() and indicates that it allocates memory from the heap, but it doesn't mention sbrk().

These days sbrk is rarely used, in fact, on Apple systems I am under the impression that it is depracated (A quick search confirms this impression).

The correct approach is to use mmap with the MAP_ANON flag (Which interestingly isn't doesn't seem to be fully documented in the Linux documentation...)

Re: Let’s write a Kernel with keyboard and screen support (2014)

#37

Post by mooman219 »

ajross wrote: post #35
mcculley wrote: post #26

This is making me wonder: Thinking about Dan Luu's research on latency of modern systems ( https://danluu.com/input-lag/ ), what is the minimum latency one could get in a modern system (e.g, USB keyboard, modern display hardware)?

Display refresh had never gotten much faster than 100hz or so, so that will be your limit. USB, even terrible implementations thereof, is much faster.

144Hz refresh is rapidly growing more and more common as displays become easier to drive. I'm sure the market penetration isn't as high as 4K screens, but I'm confident in it being the 2nd most popular refresh rate after 60Hz. I really refuse to work on 60Hz at this point. I notice significantly more eyestrain on lower refresh rate displays. Switching form a 144Hz display to a 60Hz feels noticeably worse.

Re: Let’s write a Kernel with keyboard and screen support (2014)

#38

Post by nineteen999 »

desertrider12 wrote: post #10
zaarn wrote: post #8

Earlier quoted context omitted.

Process management is hard. And that's if you throw out all the important stuff like "I want to run my programs outside the kernel" and "It sure would be nice if programs didn't have to share address space". I recommend the OSDev wiki for a deeper dive but ultimately, implementing processes involves a lot of different moving pieces that need to work. The most basic process manager would be cooperative, otherwise you'…

If anyone wants to try this, on x86 getting a regular interrupt for preemptive multitasking is pretty easy, you can write an interrupt handler for the [real-time clock]( https://wiki.osdev.org/RTC ). This will work on any PC and takes about 15 lines of code to set up. Every 1ms, whatever's running will be paused and your scheduling code can run. Actually writing the scheduler is the hard part ;)

Then you want virtual memory and before you know it you are twiddling the CR0/CR3 registers and knee deep in multi-level page table management. At least that's how I remember it from my own 32-bit kernel experiment some years back, and as far as I got before I was in well over my head.

Re: Let’s write a Kernel with keyboard and screen support (2014)

#39

Post by zaarn »

tenebrisalietum wrote: post #30
zaarn wrote: post #19

Earlier quoted context omitted.

If you're on UEFI, the 16bit environment is very likely running inside a UEFI "hypervisor" (ie, it puts the CPU into 16bit mode after setting up the appropriate interrupt handlers and hardware drivers). If you boot Windows or Linux via UEFI and not BIOS methods, then you never leave 64bit mode during boot. Real BIOS that boots from 16bit is quite a rarity these days.

"Running inside a hypervisor" is not equivalent to the UEFI setting interrupt vectors to point to its own code. Not sure how UEFI's "Compatibility Service Module" works exactly but if it acts like the original BIOS did, it's just a chunk of code that can be called, either by a program or be set as the destination for interrupts. But there is no "VM exit" mechanism like there is in hypervisors. One thing a hypervisor…

To my knowledge, UEFI does sorta do hypervisor-y things when running a 16bit bootloader since the GPU needs to be operated from 64bit ( via it's UEFI driver) and keyboard and mouse need to be emulated via UEFI drivers, which are also 64bit. That is unless the device has a CSM module and can run natively 16bit code during CSM boot, which not all devices can do.

Re: Let’s write a Kernel with keyboard and screen support (2014)

#40

Post by hazz99 »

peatfreak wrote: post #21
hazz99 wrote: post #11

For further reading, I can't recommend enough this free book: http://pages.cs.wisc.edu/~remzi/OSTEP/ It's fantastically well-written, yet detailed without being overwhelming.

I just read one chapter, which I thought was OK. It felt more like a book on how the C programming language translates to operating system concepts, rather than a book about the operating system concepts themselves. For example, the chapter I read discusses malloc() and indicates that it allocates memory from the heap, but it doesn't mention sbrk().

It often splits practical vs. theoretical concepts. One chapter might go over the theoretical scheduling algorithms, and then another might address practical solutions to internal fragmentation.

Disclaimer: I'm definitely not an expert, I'm reading the book to learn.

Post reply on HN