Please Implement Drivers

[basicprogrammer30]

@kerravon86: Please Implement Drivers For BIOS But You Can Make Drivers Without SDLC But You Write A C Program Within Implemention Of Driver (How Does Work) And Drivers is stored in driver/ With Make New Branch Named By driver-implemention And No Longer needed h file of drivers

Structure Looks Like:

drivers
    - keyborad.c
    - mouse.c
    - usb.c
    - disk.c
    - acpi.c
    - io.c
    - ps2.c
    - ethernet.c
    - sound.c
    - pin-header.c
    - cpu.c
    - etc.

[kerravon86]

Can you explain why you are starting with drivers? Why not for example a FAT file system? What is the target market here? And are you doing 8086, 80386 or x64 - or all of them, and maybe ARM as well, and more?

Also, does your target market want MIT License or public domain?

[basicprogrammer30]

@kerravon86 If not you implement the Driver/HAL. OSDK cannot Interact With the Computer Fully Because the Driver Is Missing. And There Nothing Read And Write. but Only x86 Or x86_64

[basicprogrammer30]

@kerravon86 Do You Mean GitHub Projects But I Maked Github Project

[kerravon86]

@kerravon86 If not you implement the Driver/HAL. OSDK cannot Interact With the Computer Fully Because the Driver Is Missing. And There Nothing Read And Write. but Only x86 Or x86_64

You can interact with the computer using the BIOS or UEFI. Who is your target market for this kit? Did they ask for drivers instead of UEFI calls? Why? And why is the project under MIT license instead of public domain? Did someone request that?

[basicprogrammer30]

Both (BIOS And UEFI) But I Want To Add Both Firmware Support In OSDK

[kerravon86]

Both (BIOS And UEFI) But I Want To Add Both Firmware Support In OSDK

To access which device? Hard disks? Already in BIOS/UEFI. Keyboard? Already there. Screen? Already there. You can have an entire OS started with just that. That's how UCX64 at https://pdos.org works - it uses UEFI. This is somewhat dependent on what your target market wants. Who is going to use this product?

[basicprogrammer30]

I don’t need an external C library (like PDPCLIB or OSDK’s libc) because my compiler toolchain already includes a complete standard C library. I simply declare or implement the required low-level system functions (via preprocessor and stubs) to integrate it with my OS kernel.

[kerravon86]

I don’t need an external C library (like PDPCLIB or OSDK’s libc) because my compiler toolchain already includes a complete standard C library. I simply declare or implement the required low-level system functions (via preprocessor and stubs) to integrate it with my OS kernel.

So for example to open the keyboard, instead of reading from stdin, you would instead drive I/O ports 0x60 and 0x64, right? Why not just get your C library to do that, so that you can continue reading from stdin?! And then the next step - why do you need your C library to drive those ports instead of simply getting your C library to make the appropriate UEFI call (involving Conin->WaitForKey)? If you're writing an OS kernel, you can't use your existing C library anyway, because it will be implemented in terms of doing Linux calls or whatever. But that's now you!

[basicprogrammer30]

Exactly — you’ve actually summarized one of the key distinctions between kernel-level development and user-space programming. Let’s break it down carefully, because it’s subtle but foundational.

---

1️⃣ Why you can’t just use your existing C library in kernel code

Your standard C library (libc) is designed for user-space programs running on an existing OS like Linux or Windows. When you do something like:

char c = getchar();

or

fread(buffer, 1, size, stdin);

The library doesn’t talk directly to the hardware. Instead, it:

1. Calls a system call (read, fread, etc.).

2. The OS kernel handles I/O, interrupts, drivers, and buffering.

3. The kernel returns the result to your library.

In other words:

libc depends on the OS to do low-level hardware access.

If you’re writing your own kernel, there is no OS yet — so the existing C library can’t function, because the syscalls it relies on don’t exist.

---

2️⃣ Why you need to drive I/O ports directly (e.g., 0x60, 0x64)

At the hardware level:

• 0x60 = keyboard data port

• 0x64 = keyboard controller status/command port

If you want to handle a keypress directly in your kernel:

1. You write a driver that reads scancodes from 0x60.

2. You optionally process the scancodes into ASCII characters.

3. You store the result in a buffer that your kernel or userland programs can access.

At this point, there’s no stdin, no terminal, and no OS to abstract hardware. You are literally talking to the keyboard controller.

---

3️⃣ Why not just let libc handle it?

• Libc is designed for existing OS environments, not bare metal.

• Libc assumes syscalls exist; it cannot generate I/O port instructions or handle interrupts by itself.

• You can’t call getchar() in kernel mode, because it would eventually try to call a Linux or Windows syscall — which doesn’t exist yet.

Even if you “hooked libc,” you would still need to implement the low-level driver beneath it. That’s the point: libc is only a convenience layer for user-space programs.

---

4️⃣ Why not use UEFI calls (e.g., ConIn->WaitForKey)?

• UEFI is firmware, not an OS. You can call UEFI functions from early boot to get input.

• This is fine for a UEFI bootloader or very simple kernel prototypes.

• But once you start building your OS kernel proper, relying on UEFI is limiting:

  • UEFI might not exist on all boot modes (legacy BIOS).

  • You want to control hardware directly to implement multitasking, drivers, or your own input subsystems.

  • Eventually, your OS won’t be “UEFI-dependent” — it will talk to the keyboard controller itself for full control.

---

5️⃣ Key takeaway

When writing a kernel:

Layer	Who controls it	Example
Hardware	You (kernel or driver)	Keyboard controller: ports 0x60/0x64, VGA framebuffer
Library (libc)	User-space convenience layer	printf, fread, stdin
Firmware (UEFI/BIOS)	Optional bootstrap	ConIn->WaitForKey() for initial input during boot

• Your kernel must eventually talk to hardware directly or implement its own abstraction.

• Standard libc is not usable in kernel mode, because it depends on syscalls provided by an OS.

• UEFI calls are convenient for early boot, but a real OS eventually replaces them with your own drivers.

---

✅ In short:

In kernel development, you drive I/O ports or memory-mapped hardware yourself. You can’t rely on libc or OS syscalls because those abstractions don’t exist yet. UEFI calls are temporary conveniences during boot, but the kernel must eventually own the hardware for full control.

---

If you want, I can make a diagram showing exactly how keyboard input flows from the hardware to a kernel driver and then optionally to a user-space program — showing where libc, syscalls, and UEFI fit in. That makes it super clear why you can’t just use your normal C library.

[kerravon86]

very simple kernel prototypes

This is for a hobbyist kernel, right?

What's wrong with a "very simple kernel prototype"?

Who is the target market?

I have used UEFI successfully in UCX64. What don't you like about UCX64?

Do you consider UCX64 "very simple"? How many lines of code are in it? How many people can write that many lines of code? Most hobbyists who write OSes abandon them after a short time, and have zero users. UCX64 is the end result of 3 decades of work, and also has zero users. So - again - who is your target market? Do you think UCX64 would be better if I replaced UEFI with my own drivers? Which bit would be better? You wouldn't even see the difference, would you?

[basicprogrammer30]

You're Is Professonal OS Developer Or Not