Big Thing Start Small

we can use boot_map_alloc_region (similar) function at 1:54:48 rather than running loop.

I would love to follow along. But some videos are missing in your playlist. Any chance of having them?

@1:30:00 You might know, static_asserts were introduced in C11... of course ive just started following so i might be behind've what the whole intended story/premise is and everything. this is just a hobby, somethin ur interested in?

best moment: finding the bug: kzbin.infoUgkxzoPv3SmtoGQATZ3X7BSNKhSi1qx0wged?si=oyxxGW8vCeh834aP

Good stuff

Lets goo

Just watching few of your videos, just wondering how did you setup your iTerm2 like that. It's nice and compact.

the one he said people are poof poof on

what to know the name of binary disassembler mentioned in 21:49

Bro I thought the leaf was for weed smh

Awesome Project!. BTW I really like the name of your OS!. GardenOS :)

Hello, bro! What is your opinion about Rust program language? Is it fully able to write your own module for Linux? I gonna to try it. It will be for security purpocess. A lot of people think it is very hardening for memory protection, but I laugh when trying to work with a network there - a lot of functions doesnt work without "unsafe" - macross))))

Is the course work you’re following publicly available?

isnt this guy, the voice from the chatgpt videos?

Neat trick indeed, I'm guessing the MAP_ANNONYMOUS is required, since that's probably how the fault handler knows that the mapping does not actually represent something concrete, therefore allowing it to map to the zero'ed page it allocates by default. Now the question is can you use this concretely? (i.e for "real" reads that are tied to actual data). Would it be neat to tell mmap/read to always re-use the same physical page for all mappings, for a scenario where we know that we will read any given page only once? Or would that be terrible?

0:36: 💻 Exploring virtual memory management through page table functions in OS development. 0:36: Continuing work on the walk function for page table management 1:55: Goal of function is to find or create a page table entry for a given virtual address 2:06: Customizing the function to handle page table entries based on user preference 10:38: 🧠 Implementation details of navigating page tables to find a specific page table entry. 10:38: Process of computing a pointer to a page table entry based on a base pointer and page table index. 11:37: Usage of computed pointer to return the address of the page table entry in the happy case scenario. 12:04: Repetition of steps to aid in understanding and recalling previous work for future development. 20:14: 🧠 Understanding the translation from physical to virtual memory addresses in kernel development. 20:14: Each struct page info corresponds to a memory page. 21:22: Converting physical addresses to kernel virtual addresses using page to 2 KVA function. 21:46: Intention to improve naming conventions in code for clarity. 30:13: 💻 Understanding the mapping of virtual memory to physical memory through page tables in kernel development. 30:13: Physical range in page table rooted at page dur size must be a multiple of page size. 30:41: Setting up static mappings using permission bits for virtual and physical pages alignment. 33:19: Mapping a region of virtual memory to resolve to a region of physical memory in kernel development. 42:05: 💻 Discussion on setting permissions in page tables for virtual memory in x86 architecture. 42:05: Permissions in page tables are set using bits like present, read write, and user/supervisor. 43:00: The CPU sets accessed and dirty bits in page tables. 52:54: 💻 Understanding virtual memory mapping in kernel development 52:54: Virtual memory is represented by a base virtual address with page indexes 54:46: Utilizing page tables to convert page indexes to memory offsets for virtual addresses 55:01: Converting page indexes back into memory offsets for virtual addresses 1:05:26: 💡 Understanding the process of converting a physical address to a pointer in kernel development. 1:05:26: Subtract current base offset to convert physical address 1:05:52: Obtain index of physical frame by shifting 12 bits to the right 1:06:00: Retrieve pointer by adding index to K pages and returning it 1:17:37: 🧠 Developing virtual memory management in C for a hobby kernel project. 1:17:37: Function returns null should not be assumed to have done anything 1:18:04: Producing a real physical address by zeroing out low bits of page table entry 1:19:18: Transitioning from physical page allocation to virtual memory management 1:30:38: 🧠 Understanding the concept of TLB, virtual memory, and page tables in operating systems programming. 1:30:38: Source Opera memory address processor flushes TLB entries to cache page table entries. 1:30:46: TLB acts as a cache for page table entries, mapping virtual addresses to physical frames. 1:31:42: The necessity of validating pages in the page table and the limitations of the speaker's knowledge in mathematics for operating systems programming. 1:43:39: 💻 Understanding the importance of a specific function in virtual memory management. 1:43:39: Discussion on the necessity of a function for overwriting pages in virtual memory. 1:44:06: Confusion regarding the absence of a useful function in the TA solution. 1:44:23: Attempting to utilize a function to check for the presence of a page. 1:54:49: ⚙ Developing a kernel function to handle page tables and virtual memory in C language. 1:54:49: Focusing on handling simple cases first before dealing with complications like edge cases. 1:55:20: Asserting the existence of a page table entry (PTE) before proceeding with further operations. 1:56:22: Confidently asserting the non-null status of the PTE due to prior validation steps in the code. 2:05:23: 🧠 Discussion on creating pointers and handling table entries in kernel development. 2:05:23: Understanding the process of creating pointers and checking for their existence in the code. 2:06:16: Exploring the functionality of returning table entries and handling potential non-existent elements. 2:07:15: Avoiding unnecessary code duplication and focusing on obtaining the necessary table entry pointers efficiently. 2:17:00: 🧠 Understanding the concept of reinserting a physical page in virtual memory and potential failure scenarios. 2:17:00: Reinserting a physical page in virtual memory with existing physical page 2:18:11: Possibility of failure in the reinsertion process and handling it 2:19:03: Case where nothing needs to happen when reinserting the same physical page Recapped using Tammy AI

This is really nice. I always wanted to understand the licensing but never got around to reading it. This was helpful. Thanks!

Keep em coming! dont stop

thanks for the video. Great Exploration.

Can you send the link to the resources you are using?

you mentioned C++ , lookup includeOS

I think you need deep understanding. I never had that.

so how do i go from writing react components to writing kernal and understanding all this sorcery ?

Hey awesome video! I recently started learning more about OS, would you say the "OS: Three Easy Pieces" book is a good resource to learn the theory behind it? I've also heard that OSDev wiki is a good one

Do you recommend xv6 over pintOS for learning operating systems?

is it on github?

That website could you send me a link

wha'ts your editor font?

How is the app reminding you to take a break called?

Mad work. Appreciate that you post this online.

good stuff man! Dont stop

0:01: 🧠 Exploration of physical memory allocation in kernel development, focusing on learning core concepts and improving code quality. 8:37: 💻 Summary of physical memory allocation process in kernel development 18:05: 💻 Discussion on implementing a physical memory allocator function in a hobby kernel project. 28:56: 💻 Discussion on transitioning from C to C++, implementing assertions, returning pages to the free list, and testing the code. 37:11: 🔍 Discussion on debugging kernel memory allocation issues and handling optimizations in C++. 50:39: 🤯 Development process of an operating system kernel, focusing on x86 architecture and memory allocation. 1:03:20: 🧠 Understanding the management of page tables, linear to physical mappings, and virtual addresses in kernel development. 1:13:36: 💻 Exploring learning strategies for systems programming in C and Java, emphasizing step-by-step progression and project-based learning. 1:23:33: 🧠 Exploration of hierarchical paging structures in kernel development, focusing on extracting page table information from a virtual address. 1:38:42: 🧠 Understanding the process of converting physical addresses to kernel virtual addresses in x86 architecture. 1:52:15: 🧠 Development process of implementing page table entry and memory allocation logic. 2:04:12: 💻 Developing a hobby kernel in C with a focus on physical memory allocation. Recapped using Tammy AI

highlight: figuring out page_init() bug kzbin.infoUgkxDqATnxI0NaRVpx1gkbDeVjG7zYyQ0H3f?si=WFSxMO9npasVXmiE

0:00 start 0:05: 🧠 Overview of implementing physical memory allocator in kernel development. 0:05: Week 16 of kernel development stream, focusing on memory management 0:16: Preparing to work on memory management despite being sick 1:10: Moving on to memory management after completing lab one tasks 2:57: Tasks include implementing physical memory allocator and maintaining page data structures 4:24: Modifying files like M layout and pmap to define page structures 7:25: Examining existing kernel code and functions like Panic and assert 10:49: Implementing functions like boot Alec page and init page Alpage free 12:55: Confusion regarding specific code additions and function names 13:37: Focus on creating initial page directory before further modifications 15:15: 🧠 Exploring the development of a basic memory allocator within a hobby kernel project 15:15: Introduction to memory allocation for the kernel's page directory 15:53: Initial setup of a simple memory allocator using static variables 16:25: Functionality of the allocator to allocate contiguous physical memory 20:00: Description of the bump allocator approach being utilized 22:23: Implementation of memory allocation logic for requested block sizes 26:13: Testing and debugging strategies using print statements 27:09: Verification of allocator functionality through basic test runs 27:20: Initiation of print debugging to track variable values during execution 28:04: Preparation for executing the code to observe results and further debug 28:38: 💻 Exploring development of a physical memory allocator in an operating system kernel using C language. 28:38: The speaker is unsure about checking the character code for a specific item in memory. 29:35: They attempt to verify the consistency of the memory allocation starting point. 29:47: The speaker struggles with understanding how to check the BSS section for memory allocation. 31:53: A manual test is conducted to verify the memory allocation process. 32:11: The speaker considers implementing unit tests but decides against it for the current time. 33:22: An assertion is added to validate the memory allocation process. 34:07: The speaker intentionally triggers an assertion failure to test the validation process. 35:37: They express interest in developing their own operating system in the future. 36:35: The memory allocator functionality is successfully implemented and validated. 37:44: 💻 Exploration of memory management in kernel development, including page directory setup and physical memory allocation. 37:44: Discussion on using BSS section for memory allocation and kernel references. 40:06: Need for a structured approach to memory management in kernel development. 41:23: Creation of a new page directory for virtual memory layout. 43:05: Importance of setting up mappings for kernel execution and critical data access. 44:32: Importance of understanding virtual page tables for memory management. 45:00: Exploration of page table entries and their alignment considerations. 46:42: Use of global variables like PD Type for memory management operations. 47:01: Allocation of an array to track physical pages and corresponding page info. 48:49: Querying physical memory details through low-level hardware interactions. 49:24: 🧠 Exploration of physical memory allocation process and variable renaming in hobby kernel development 49:24: Discussion on available physical memory and variable values 54:05: Renaming of global variables for clarity 57:01: Allocation of memory based on page size calculations 59:53: Debugging process using the debugger tool 1:01:15: Verification of memory allocation through dumping and calculations 1:03:04: Confirmation of successful memory zeroing operation 1:03:36: Calculation of total allocated memory size 1:04:07: Discussion on zeroing out only the requested memory amount 1:04:23: 🧠 Overview of physical memory allocation in kernel development 1:04:23: Kernel development involves setting up initial data structures for physical memory allocation. 1:09:00: Allocating memory involves mapping memory using boot map region or page insert functions. 1:10:07: Kernel data structures include a list of free physical pages and pageinfos for tracking memory frames. 1:11:57: Pageinfos contain a refcount to track the number of pointers mapping to a page. 1:12:37: Intrusive linked list is used for storing pageinfos with direct links in the struct. 1:13:44: 🧠 Understanding the allocation and marking of physical memory pages in a hobby kernel development project. 1:13:44: Memory allocator functions are used to mark physical pages as free, with an exception for page zero. 1:14:05: Page zero is marked as in use to preserve certain structures, while the rest of the memory is considered free. 1:14:49: The reference count for each page is set to zero, even if already zero, during the marking process. 1:15:14: A pointer called PP link is used to maintain a linked list structure for free memory pages. 1:16:07: The process involves updating pointers and maintaining the integrity of the linked list structure for free pages. 1:19:04: The construction of the linked list is done in a way that appears to assemble it backwards. 1:23:14: The concept of 'in use' for a page is associated with preserving specific data structures within the memory allocation process. 1:24:42: The physical memory pages allocated using the page allocator have their pointers managed and updated accordingly. 1:25:20: 🧠 Exploration of memory allocation in kernel development, focusing on page list checks and modifications. 1:25:20: Page list checks are essential to ensure proper allocation and utilization of memory. 1:26:20: Understanding the functions and checks involved in verifying page entries. 1:27:25: Examining the calculation of physical addresses from page structures. 1:31:03: Identifying and asserting conditions for valid entries in the page list. 1:33:24: Initial modification to mark physical page zero as in use. 1:34:47: Consideration of exceptions in code execution based on page conditions. 1:35:13: Utilizing constants or arrays for better code readability and maintenance. 1:35:49: Iterative process of refining page list entries for efficient memory management. 1:36:00: Continued exploration and testing of modifications for desired memory allocation outcomes. 1:36:16: 💻 Exploration of memory allocation process in C, focusing on exclusion of memory regions and pointer manipulation 1:36:16: Discussion on excluding memory regions from allocation list 1:36:35: Implementation of excluding mechanism and potential impact on final shape of memory 1:38:02: Introduction of IO hole and its handling in memory allocation process 1:40:07: Conversion of physical addresses to indexes for memory allocation 1:42:36: Consideration of boundary conditions for memory exclusion and pointer manipulation 1:43:32: Simulation of memory allocation process with focus on IO hole region 1:44:01: Analysis of pointer swapping and list manipulation in memory allocation 1:45:09: Verification of correct pointer behavior for memory allocation list 1:45:42: 🧠 Illustration of managing physical memory in kernel development, including tracking used pages and utilizing symbols for memory boundaries. 1:45:42: Discussion on physical memory management and tracking used pages 1:46:59: Identifying kernel memory boundaries using symbols 1:54:07: Utilizing symbols for dynamic kernel size determination 1:55:17: 🧠 Development process of a physical memory allocator in a hobby kernel project. 1:55:17: Discussion on constructing page tables in the kernel binary 1:55:27: Allocation of page tables with boot allocator at compile time 1:56:09: Handling 'end' alignment issue in the code 1:57:24: Defining kernel regions and frame indexes for memory allocation 1:59:33: Marking boot allocator zone as non-free for memory management 2:03:12: Dynamic querying of memory allocation from the boot allocator 2:04:24: Debugging process to check page freelist functionality 2:06:14: Sanity checking variables and debugging incorrect calculations 2:08:44: Troubleshooting and adding print statements for further analysis Recapped using Tammy AI

keep it up sir

0:00 start 0:45: 🌱 Weekly update on kernel development progress and customization with MIT class homework. 0:45: Build is working with basic customization in progress. 1:14: Exploring VGA color customization and committing changes. 2:09: Continuing MIT class homework on console functionality. 9:27: 🧠 Exploring x86 Assembly development on Apple silicon computer with MIT class minimal OS. 9:27: Investigating stack pointer assignment and stack space utilization 10:16: Learning about earlyColonel entry code and x86 architecture in Kernel development 10:59: Using Apple silicon computer for development with no issues reported 18:39: 🧠 Understanding memory allocation in x86 Assembly through symbol table analysis. 18:39: Memory allocation involves initializing stack at the top of a memory region. 19:44: Symbol table reveals addresses like boot stack top at hex A, indicating memory layout. 26:28: 🧠 Understanding the manipulation of stack frames in x86 Assembly language during function execution. 26:28: Operating on the bootloaders stack frame and resetting the frame pointer to point to the stack pointer load. 27:23: Declaring extern Char and discussing the storage implications of such declarations in the function. 28:07: Questioning the use of CH star declaration and considering the possibility of using a pointer instead. 34:27: 💻 Analysis of x86 Assembly code structure and stack alignment during function calls. 34:27: The code structure involves pushing immediate values onto the stack, affecting alignment. 35:00: The stack alignment is disrupted by the sequence of push operations, leading to unaligned stack. 36:28: The dependency on EVP and ESP is highlighted in the function prologue for preparation before function call. 44:04: ⚙ Exploring x86 Assembly function calls and stack operations. 44:04: The function recursively checks if an integer is greater than zero before backtracking if not. 45:24: Each function call in x86 Assembly typically pushes 8 words onto the stack, including EBP and saved registers like EBX. 46:06: The individual delves into understanding the assembly code and calling conventions for function calls. 53:34: ⚙ Illustrating function calls and program counter manipulation in x86 Assembly. 53:34: Function calls passing arguments as pointers and integers. 54:58: Explanation of program counter push and branch logic execution. 55:07: Detailed breakdown of instruction flow after function calls. 1:02:56: 🔍 Understanding the stack frame setup and variable access in x86 Assembly language 1:02:56: EBP is pushed to save the frame pointer, followed by accessing variables by moving up the stack 1:04:00: Confusion arises due to switching between Intel and AT&T syntax, affecting the understanding of variable storage 1:05:07: Accessing function arguments involves moving up eight bytes from the base pointer location 1:14:31: 🧩 Exploration of x86 Assembly code and stack dump analysis to understand function calls. 1:14:31: Discussion on the significance of a specific value in the stack dump 1:15:08: Attempt to understand the function calls by analyzing the stack dump 1:16:25: Observation of the page directory in relation to the stack 1:25:15: 🔍 Understanding the preservation of registers in x86 assembly language and its relevance to calling conventions. 1:25:15: The importance of preserving certain registers like EBX across function calls in x86 assembly language. 1:27:41: Caller saved registers must be preserved by the calling function according to x86 calling conventions. 1:28:08: The provided resource on preserved registers in x86 assembly language helped clarify the concept for further assignment work. 1:35:56: 💻 Exploring x86 Assembly code and printing stack pointer values in hexadecimal format. 1:35:56: Introduction to printing stack pointer values using x86 Assembly code 1:37:07: Calling readEVP function to retrieve EVP value and printing it in hexadecimal 1:38:50: Determining the constant value of the stack pointer in the code execution 1:50:39: 🔍 Discussion on pointer declarations and debugging in x86 Assembly 1:50:39: Simplify the approach for now and clean up later 1:50:46: EBP points to a UN32t, while PC does not point to UN32t 1:51:15: Consider debugging to confirm pointer declarations 2:00:54: 🔍 Exploring how to navigate and analyze saved EVP values in the kernel development process. 2:00:54: Analyzing and printing information from the current DVP to understand saved EVP and PC values. 2:01:23: Continuously resetting and detecting new EVP values until eventually saving a null EVP, leading to further analysis in GDB. 2:01:40: Conducting backtrace checks in GDB to verify expected results and ensure no crashes or infinite loops occur during the process. Recapped using Tammy AI

stream highlight: working backtrace function: kzbin.infoUgkxYYJPZ9tXmhSZiSavHqN8_LpdPwWIQI_r?si=kOjZ04IMR35me5So

Interesting but how do the two methods guarantee correctness at the end of replaying all the commits in the rebase?

Actual Start of video: 2:00

0:26: 🌱 Troubleshooting build errors, preparing for OS class labs, and setting up Intel manual. 0:26: Struggling with build errors and debugging process 1:52: Attempting to fix build issues live and seeking help 4:46: Resorting to online search for solutions 6:06: Successfully resolving build error and making a commit 8:03: Continuing with MIT OS class labs exploration 9:20: Getting ready with Intel manual for future reference 9:28: Mentioning a bug in the room and warming up for the session 9:42: Planning to start working on segmentation exercise 12:41: 🧠 Exploration of transitioning to protected mode in x86 assembly via GDT manipulation. 12:41: Interest in deep understanding of segmentation in memory management mechanisms. 15:27: Initial boot code runs in 16-bit real mode before transitioning to protected mode. 16:02: Understanding the GDT and its role in setting up virtual addresses in protected mode. 17:24: Exploring Intel manual for detailed guidance on transitioning to protected mode. 19:07: Transition to protected mode involves setting PE flag in CR0 register and loading GDT. 19:15: Execution of 'move CR0' instruction crucial for entering protected mode. 19:26: Different requirements for switching to protected mode in N64 and i32 architectures. 19:39: Intel manual recommends steps to switch to protected mode, including disabling interrupts. 20:30: Use of AT&T syntax assembly for manipulating registers during mode switch. 20:37: 📚 Exploration of Intel manuals for protected mode initialization in kernel development 20:37: Learning about data structures like Global Descriptor Table (GDT) and Local Descriptor Table 22:20: Importance of software initialization for protected mode operation in processor 22:40: Loading minimum protected mode data structures and code modules for reliable operation 23:34: Necessity of initializing system registers before switching to protected mode 24:51: Instructions for loading GDT with Base address and executing far jumper call 27:22: Segmentation details and tasks in x86 architecture 29:01: Segment register handling after entering protected mode 30:38: Discussion on the use of TSS and tasks in kernel development 30:52: 💻 Exploring C code for printing octal numbers in a kernel environment 30:52: Understanding relationship between kernel and shared code for printing 31:46: Analyzing code structure in kernel printf.C for octal number printing 33:56: Exploring usage of callback functions for output in C printf 37:05: Modifying code fragment in print format.C for octal number conversion 38:03: Interpreting format string and implementing logic for octal conversion 39:24: Reviewing switch cases for different types of format specifiers 40:12: 🌿 Exploration of kernel functions and interfaces in C programming, focusing on CGA display driver 40:12: Discussion on accessing arguments in a printf call using VA list 41:24: Exploring the use of 'L flag' in handling various sizes in C programming 45:31: Implementation of octal character code in C programming 46:08: Explanation of the interface between printf.c and console.c in kernel development 49:02: Identification of different console types like serial console and CGA display in C programming 50:04: Analysis of the purpose of CRT size in CGA display handling 50:57: 🌱 Exploring initialization processes in kernel development, focusing on CGA display driver and memory layout customization. 50:57: Kernel initialization involves clearing BSS and setting up virtual memory. 55:59: Linker scripts help customize memory layout and export constants for C code. 57:14: Discussion on the unusual responsibility of kernel to clear BSS during initialization. 58:02: Considering alternative locations for BSS clearing such as bootloader or entry.S. 59:07: 🌿 Exploring the initialization of CGA display driver in kernel development and device access in memory. 59:07: Only one program header in the chronal binary, unlike typical binaries with multiple segments. 59:16: Speculation on the reason for single program header and potential influence of Linkerscript. 1:00:34: Discussion on debugging information and disabling stabs for successful build. 1:02:11: Limited functionalities of the kernel after initialization, focusing on console interaction. 1:03:00: Exploration of CGA initialization process and memory access for device interaction. 1:04:06: Attempt to understand memory mapping and physical address access in kernel development. 1:06:07: Analysis of device address in physical memory and its relevance in virtual memory environment. 1:07:08: Speculation on the fixed address of the device in physical memory and the need for virtual memory mapping. 1:08:05: Realization of the significance of low address access for device interaction in the kernel. 1:09:30: 🧐 Exploring memory mapping and device access in kernel development 1:09:30: Kernel has a padding zone to avoid bugs near memory border 1:10:05: Devices residing in memory require specific access, influencing memory mapping 1:12:17: Experimenting with removing unnecessary memory mapping for debugging purposes 1:13:33: Attempt to access memory without proper mapping leads to crashes 1:15:08: Using debugging tools like KGDB and GDB to analyze memory access 1:18:07: Encountering issues with memory access and seeking further information on CGA display driver 1:19:02: Attempting to learn more about CGA display driver through reference material 1:20:16: Documenting findings and preparing for further exploration in kernel development 1:26:05: 💻 Understanding the CGA display driver in kernel development through video RAM manipulation. 1:26:05: CGA text mode involves setting or clearing bits in video RAM for pixel rendering. 1:27:04: Each screen position in text mode occupies two bytes in video RAM. 1:28:05: Character attributes are defined in video RAM for text mode rendering. 1:29:36: Control registers 14 and 15 are crucial for setting cursor position in CGA display. 1:30:51: Accessing control registers involves using index and data registers through specific CPU instructions. 1:31:44: The process of writing data to screen buffer and reading it involves specific byte manipulation. 1:32:04: Interpreting data values in memory addresses requires understanding color mappings and byte representations. 1:33:09: The video explores the intricacies of CGA display driver implementation in kernel development. 1:33:47: 🌿 Exploring development of CGA display driver in x86 OS through debugging and code analysis. 1:33:47: Investigating port addresses and data manipulation for CGA initialization 1:34:13: Exploring error handling and memory management in driver development 1:35:09: Analyzing integration of keyboard and CRT in the code 1:36:57: Understanding cursor manipulation and data register operations 1:38:28: Attempting to print to serial console for debugging purposes 1:40:02: Utilizing debugger tools for code analysis and optimization 1:41:11: Learning about display driver construction and position calculation 1:42:03: Exploring 16-bit number construction and bit shifting operations 1:43:08: Engaging in OS development learning process with interest in virtual memory and hardware 1:45:01: 🧑‍💻 Discussion on debugging process, cursor position, and writing characters to display in C programming. 1:45:01: Weekly kernel development progress update 1:45:18: Storing current cursor position in local variable 1:46:04: Setting global variables to cursor position 1:46:47: Printing out cursor position using printf 1:47:36: Debugging process using GDB and print debugging 1:51:01: Discussion on writing characters to display in C 1:53:52: Issue with changing colors in display output 1:54:19: Advancing cursor position after writing data to video memory 1:55:15: Challenges with commenting out code affecting functionality 1:56:14: 🌱 Exploration of CGA display driver functionality and implementation details in C during weekly kernel development session. 1:56:14: Understanding the process of initializing CGA display driver and resolving recursive initialization issue. 1:56:23: Successful resolution of initialization issue leading to restored functionality. 1:56:40: Testing the impact of changing text color to red for a Halloween theme. 1:57:17: Learning about different text color codes and their representation. 1:58:23: Exploring the purpose of condition checking for CRT position exceeding screen size. 2:00:25: Understanding the functionality of memmove in copying text data for screen scrolling. 2:01:43: Implementing screen scrolling by moving text data up one line and clearing the last line for new text. 2:05:07: Utilizing carriage return and line feed characters to control cursor movement for new line implementation. 2:06:06: Ending the stream after two hours of productive learning and encouraging viewers to join future sessions. 2:06:36: ✌ Upcoming meeting confirmed for next time with a friendly farewell. 2:06:36: Friendly farewell 2:06:36: Meeting confirmed for next time Recapped using Tammy AI

kzbin.info/www/bejne/a4LQd3yMoMeVgs0 coming back to this: it crashed because the low memory mapping is mapped non-writable, and the code tries to write there. If I map it writable, everything works.

@44:54 I always struggle to figure out what Yak Shaving adventure is worth it vs the ROI on learning that thing just isn't worth.

stream highlight: blue text kzbin.infoUgkxH9KmtTEmhp7K4XnIeCh0oqSnDhpSVAMe?si=YYYGNyzMLDCm5Oqb

0:28: 🌿 Exploring a more mature OS development environment with JOS, highlighting its organized structure and out-of-tree build system. 0:28: Switching from xv6 to JOS for OS development due to JOS's maturity and organized structure. 3:26: JOS is considered more mature than xv6, with a cleaner repository structure and organized directories. 5:09: Not interested in fully fleshed out user space, preferring to build it up gradually in JOS. 5:18: Impressed by JOS's out-of-tree build directory for object files, a feature lacking in xv6. 6:22: Excited to explore JOS further and potentially incorporate it into future OS development projects. 6:28: Engaging with viewers in a casual and interactive manner during the stream. 7:20: Considering removing unnecessary parts of JOS for a more streamlined development experience. 7:51: Successfully cloning the JOS repository and starting with basic instructions for setup. 8:36: Utilizing existing i386 ELF tool chain from xv6 for building JOS, avoiding tool chain setup issues. 09:23: 🌿 Exploring the JOS kernel development process, x86 booting, and virtual memory setup. 09:23: Improved build system handles dependencies automatically 09:53: Utilizes recursive make for individual directories 12:04: Kernel build process simplified compared to xv6 16:06: Bootloader loads 512 bytes for boot process 16:23: Assembly code for early boot loader setup 16:39: Simple bootloader's main function boots Elf colel image 16:53: 🌿 Overview of x86 booting process, kernel loading, and virtual memory setup 16:53: Boot loader stores in first sector, followed by kernel in ELF format 17:31: Boot loader triggers C part to implement ELF loader for kernel 17:56: Basic IDE driver used for disk I/O operations 19:25: Communication with device using special IO instructions and port numbers 20:53: Kernel loads by reading sectors from disk based on ELF program headers 23:07: Kernel entry point, console driver, and virtual memory setup discussed 26:55: Kernel mapped to highest virtual memory address for higher half kernel 27:39: Compile-time constructed page directory and page tables for virtual memory translation 28:11: Restrictions on linking and static initializers in page directory setup 29:11: 🧠 Understanding the initial setup of virtual memory for a kernel in x86 architecture. 29:11: Relocation process involves adjusting the base offset to determine physical address. 29:59: Kernel's physical address is loaded at zero, while code is linked at a higher address. 30:53: Kernel is initially loaded to a high memory location as a scratch space before final placement. 33:03: Basic virtual memory is enabled by activating paging with necessary bit flips. 34:32: Struggle with AT&T syntax and adapting to 32-bit architecture for memory calculations. 36:29: Initial page directory includes identity mapping for virtual to physical addresses. 37:02: Experimenting with program headers and physical addresses to understand mappings. 37:02: Reserved virtual address space for Kernel's code can be adjusted to optimize memory usage. 38:09: Program headers provide information on loading the Kernel and its physical address. 45:42: 🧠 Understanding memory mapping and virtual addresses in OS development. 45:42: Physical memory is mapped at a specific address in the 32-bit address space. 46:11: The chosen address corresponds to 3840 megabytes in memory. 49:07: The address is significantly high in memory, beyond the one gigabyte mark. 49:47: Understanding the scale of memory addresses and their significance. 50:22: Improvement in comprehension of high hex numbers and memory address reasoning. 51:25: The address is in the vicinity of the two gigabyte mark in memory. 51:44: Realization of the address's positioning relative to gigabyte marks. 51:53: The address is in the gigabyte range, indicating its high position in memory. 52:18: The address is one megabyte below the top of the address space. 52:43: 🧠 Understanding virtual memory mapping and hex numbering in OS development. 52:43: Exploration of memory mapping in OS development 52:54: Calculating memory sizes in gigabytes and megabytes 53:16: Realization of error in calculations 54:16: Visualizing memory layout with diagrams 55:33: Learning about hexadecimal representation of memory sizes 1:01:56: Understanding the significance of memory addresses 1:02:27: Curiosity about physical memory mapping 1:03:11: Investigating mystery of data retrieval from disk 1:03:48: 🧠 Understanding the physical memory setup for JOS kernel loading and virtual memory mapping. 1:03:48: Kernel loaded at 1 Megabyte in physical memory by the boot loader. 1:04:48: Kernel's code linked to run at Kern base plus 1 Megabyte. 1:09:08: Kernel code located in the top 256 megabytes of physical memory. 1:10:05: Trivial page directory set up to translate virtual addresses to physical addresses. 1:12:04: Kernel expects to be located one megabyte above the current base. 1:13:06: Boot loader follows program headers to load kernel from disk. 1:14:05: Kernel ends up at a specific physical memory location based on the setup. 1:14:56: 🧠 Understanding the setup of virtual memory for OS development on x86 architecture. 1:14:56: Virtual memory is created to recreate an offset from a base region for the kernel. 1:15:15: Padding is added below the kernel to prevent bugs from reaching the memory edge. 1:19:05: Page directories and page table entries are essential data structures for paging on x86. 1:20:05: Page directories point to physical memory addresses, while page table entries map virtual memory regions. 1:25:01: Page table entries are used to map 4K regions within a larger 4 megabyte virtual memory space. 1:26:16: 🧠 Understanding the setup of virtual memory in JOS kernel and the critical instructions involved. 1:26:16: Virtual memory setup involves one page table with a thousand entries mapping 4 megabytes. 1:33:25: Kernel runs high in memory after enabling paging with critical instructions in entry.s. 1:35:55: Symbol 'relocated' in the kernel links to high memory addresses for safe memory access. 1:36:31: 🕵 Exploration of x86 kernel debugging and virtual memory setup in OS development 1:36:31: Understanding the critical role of a seemingly useless page directory entry in virtual memory setup 1:36:52: Introduction to the concept of virtual memory and its impact on system operation 1:38:08: Discussion on potential faults like Segmentation Fault or General Protection Fault in absence of proper memory mapping 1:44:23: Attempt to debug kernel using GDB and KVM for better understanding of system behavior 1:46:07: Realization of unintentionally completing a lab exercise in OS development during debugging process 1:46:22: 🧠 Overview of transitioning from low to high memory in x86 architecture during OS kernel booting 1:46:22: Understanding the transition process from low to high memory during OS kernel booting 1:46:33: Explanation of memory layout and debugging in the initial phase 1:47:06: Attempting to set breakpoints and analyze entry points during bootloading 1:50:20: Observing memory addresses and limitations below the one megabyte line 1:52:03: Realization of the need for faster debugging methods rather than single-stepping through instructions 1:53:33: Achieving a deep understanding of the booting process and kernel relocation in virtual memory 1:54:06: Explanation of seamless transition between virtual memory locations using relative jumps 1:56:06: Clarification on the concept of virtual copies of data in physical memory mapping 1:56:56: 🧠 Exploration of boot loader stack, virtual memory setup, and debugging in OS development. 1:56:56: Initial confusion regarding stack location in boot loader execution 1:57:18: Realization that kernel runs on boot loader stack without modification 1:58:31: Discussion on resetting frame pointer for proper kernel initialization 1:59:13: Debugging process using GDB to set stack pointer to physical address 2:01:37: Encountering memory access errors due to unmapped virtual memory pages 2:03:34: Speculation on processor reset triggering and restarting from boot loader 2:04:32: Attempt to print interrupts using GDB flag 'DDint' 2:07:26: Unsuccessful debugging attempt and decision to end the stream 2:07:50: 👋 Invitation to join Discord, like, subscribe, and tune in next Sunday for more content. 2:07:50: Promise of upcoming content next Sunday 2:07:50: Encouragement to like and subscribe 2:07:50: Invitation to join Discord for updates Recapped using Tammy AI

0:01: 🌿 Efficient C header cleanup process continues with potential codebase switch and user/kernel space considerations. 0:01: Realization of using outdated codebase from GitHub, considering switch to OS 161 from Harvard. 2:02: Questioning the efficacy of current cleanup efforts due to potential codebase switch. 3:11: Exploring potential shared files between kernel and user space, identifying duplication for future cleanup. 5:55: Deliberation on unifying kernel and user space implementations for potential future ease. 6:03: Initiating C header cleanup process by duplicating and organizing string files. 6:49: 🌿 Efficient C header file organization and system call understanding in OS development. 6:49: Discussion on organizing C header files and system calls in OS development 8:05: Reviewing code movement and file organization 12:12: Exploring system calls and user space interaction 14:37: Understanding the implementation of system calls and arguments handling 16:09: Analyzing the relationship between header files and function symbols 18:31: Identifying the main receiver of system calls in the OS development process 19:48: Encountering syntax errors and missing includes during code cleanup 26:42: 🧠 Exploration of implementing spin locks in an operating system, including atomic operations and inline assembly. 26:42: Spin locks are basic and low-overhead mechanisms in OS development. 27:02: Spin locks involve atomic operations to set and acquire the lock. 28:05: Disabling interrupts may be necessary when locking a spin lock. 28:49: Implementation may require creating custom atomic swap operations using inline assembly. 29:31: Understanding syntax and usage of inline assembly is crucial for implementing spin locks. 30:12: The process involves taking addresses and values, returning results, and using barriers. 30:23: 🧹 Efficiently cleaning up C headers in an OS development project. 30:23: Legacy memory barrier usage discussed 31:21: Review of critical sections and lock acquisition 32:46: Questioning the necessity of strong memory barriers 34:49: Moving type definitions to appropriate header files 36:43: Identifying and making functions static for optimization 38:55: Refactoring forward declarations and structure placements 44:03: Addressing redundant function names and includes 45:51: 🌿 Efficiently restructuring C header files for an operating system development project. 45:51: Identified dependencies and included necessary headers like proc.h and fs.h. 46:12: Explored functions like procdump, setprocsleep, and sleep lock in the code. 47:48: Discussed the implementation of sweight and wake up functions. 49:17: Encountered a dependency issue with fs.h in the file system section. 52:40: Addressed the problem by creating a separate header file for FS types. 59:21: Moved code to the new FS types header file and cleaned up the FS file. 1:00:38: Finalized the restructuring process by removing unnecessary code. 1:01:24: 🧹 Efficiently cleaning up C header files in an OS development project. 1:01:24: Focused on restructuring dependencies on FStypes for faster compilation. 1:05:16: Identified the need for struct iode over FStypes for clarity. 1:12:02: Removed unnecessary includes from multiple files using command line find and sed. 1:19:15: Discovered and fixed issues with make kernel build process. 1:21:00: Successfully relocated util.h include and resolved related compilation errors. 1:24:43: 🌿 Efficient cleanup of C header files completed in video segment. 1:24:43: Migration effort to remove header files completed 1:25:04: Mechanical task of moving towards working on C code 1:25:11: Future plans to engage in more substantial work 1:25:18: Reflecting on the completion of the task Recapped using Tammy AI

your discord expired i believe, interesting project

Is this a fork of some other OS project?

Which mic are you using, it sounds nice!

0:28: 🌿 Efficiently cleaning up C header files for better build performance and dependency management. 0:28: Working on C code instead of build system for variety 1:35: Exploring virtual memory and understanding system better 3:41: Porting Panic code to assert macro and cleaning up headers 4:31: Checking build and run status before proceeding 6:02: Addressing unhygienic and non-idiomatic shared header file issue 7:00: Highlighting drawbacks of shared header files for build performance 7:40: Starting cleanup process with bio.c file 7:59: 🧹 Efficiently cleaning up C header files by creating new headers and moving prototypes. 7:59: Created new header file bio.H and moved prototypes there. 8:07: Included bio.C in bio.H and updated dependencies in other files. 12:15: Checked if def.H was needed and confirmed its necessity for block layer dependencies. 15:18: Researched IDE and confirmed its relevance for block layer dependencies. 16:38: Moved prototypes to types.H and made necessary pragma changes. 17:13: Created branch for commit and successfully completed commit for bio.H. 17:50: Duplicated exec file and moved prototypes to new header exec.H. 18:24: Reviewed forward declarations and planned to clean them up later. 18:34: Identified the need to update dependencies for files using exec. 18:49: 🧹 Efficiently cleaning up C header files in an OS development project 18:49: Analyzing kernel code implementation for exec syscall 19:18: Questioning the usage of certain functions in user space 20:41: Identifying and discussing the purpose of 'exact' in the code 23:10: Examining the file.h header file and its contents 25:04: Considering the separation of internal and external APIs in code organization 26:54: Discussing the possibility of moving private elements to the C file 28:03: Cleaning up header files by creating separate header files for different translation units 29:01: Questioning the presence of an unnecessary external struct definition 29:35: Transitioning from build system work to coding tasks 29:58: 🧹 Efficiently cleaning up C header files for OS development. 29:58: Identified public struct types in header files. 30:41: Moved function definitions into a public file for accessibility. 32:45: Added forward declaration for 'struct stat' to resolve compilation error. 33:23: Checked client files for inclusion of necessary headers. 34:09: Addressed unique functions like 'file init' in specific headers. 37:54: Implemented 'pragma once' directive in all header files for consistency. 38:03: Reviewed and updated existing header files for completeness. 38:31: 🌿 Efficiently cleaning up C headers and making necessary amendments in OS development. 38:31: Identified the need to amend header files in C files for proper organization. 40:35: Explored an alternative IDE implementation called memIDE. 41:00: Made corrections to header files placement for better code structure. 44:19: Ensured consistency by including necessary header files in the code. 45:10: Tested the functionality of M IDE usage in the code. 45:21: Reviewed IDE usage in different parts of the codebase. 46:23: Examined the role of IDE in storage device interface. 47:17: Checked the build status of the kernel to ensure overall functionality. 47:25: Acknowledged the importance of continuous integration for code validation. 47:34: 🧹 Efficiently organizing C header files during OS development. 47:34: Organizing header files by moving functions and prototypes 48:29: Updating clients to depend on new header file 55:24: Identifying private data and making appropriate changes 56:49: Discussing the convention of private types and data 57:10: Analyzing the contents of 'kbdc' and 'kbd' headers 57:54: 🧹 Efficiently organizing C header files in OS development with a speedrun approach. 57:54: Working on xv6 OS from MIT as a side project 58:37: Forking an inactive OS project for learning purposes 59:50: Cleaning up header files by declaring unused functions as static 1:02:24: Moving private constants from header to C file for better organization 1:05:05: Refactoring code movement as a separate cleanup commit 1:06:01: Day job involves C++ development for musical instruments, not OS development 1:06:11: Engaging in software engineering tasks like managing dependencies and cleaning up code 1:06:49: 🧹 Efficiently cleaning up C header files and moving private data for better organization 1:06:49: Moving private constants into kbddoz for cleanup commit 1:10:00: Identifying existing structures as private and moving them into C file 1:13:26: Cleaning up by removing unnecessary global variable 'is MP' 1:14:05: Questioning the need for 'is MP' as a mutable global variable 1:14:53: 🧹 Efficiently cleaning up unnecessary code in C headers and files for better organization and optimization. 1:14:53: Discussing the benefits of using ifdef for single vs. multi-processor systems. 1:15:32: Considering the trade-offs between having separate builds for optimization vs. a single dynamic build for flexibility. 1:16:26: Identifying unnecessary external references and planning for cleanup. 1:18:06: Addressing dead code by removing unused functions like pick enable. 1:19:58: Moving functions like pick init to appropriate header files for better organization. 1:23:38: Exploring the process of creating a new header file for switch.s implementation. 1:25:23: 🧹 Efficiently cleaning up C header files and removing dead code in OS development. 1:25:23: Identified dead code in timer related files and removed unused prototypes. 1:29:45: Copied and cleaned up header files related to UART implementation. 1:33:00: Removed unused struct buff and updated log related files. 1:34:18: Investigated logging system related to filesystem operations. 1:35:03: Ensured consistency in updating begin and end operation functions. 1:35:36: 🧹 Efficiently cleaning up C header files in an OS development project. 1:35:36: Identified and addressed usage of CIS file and system CIS calls. 1:35:58: Successfully compiled and ran the code after adding forward declarations. 1:37:11: Implemented trap and pipe headers, ensuring private struct usage. 1:43:44: Reviewed and optimized sleep lock implementation across files. 1:46:06: Adjusted sleep block references in various client files for consistency. 1:47:58: 🧹 Efficiently cleaning up unused code in C headers during OS development. 1:47:58: Discovered unused code in the header files and removed it for optimization. 1:51:29: Identified and removed dead code related to 'zos time' function. 1:55:45: Deleted the unused 'RTC date' variable and its references. 1:57:06: Prepared to address the 'call spinlock' issue in the next session. 1:57:58: 🌱 Effortless code refactoring experience leads to streamlined development process. 1:57:58: Mechanical refactor made coding easy 1:57:58: Streamlined code refactoring process 1:58:04: Gratitude for viewers Recapped using Tammy AI