Interrupt handlers from an OS standpoint

[blasthash]

I don't really see much difference between an OS that doesn't support things like USB and ACPI (that was designed for newer machines) and an OS that doesn't support things like USB and ACPI (that was designed for older machines).

It makes quite the difference when those are the primary systems the newer machine is designed to use. Luckily this motherboard I dug out was 2004-era so it still has quite a bit of legacy I/O aboard it (PS/2, serial, parallel, ATA) so even ignoring the USB, PCI, and ACPI/power management I could still demonstrate a proof-of-concept operating system with some workarounds. Using a modern-era motherboard and target system would change that significantly.

I prefer to do my odds and ends experimentation on older hardware because there is no contesting the fact that the older hardware was much more simple; one didn't have to make cache considerations, for example, because there was no cache. Newer hardware and devices throw a lot into the mix that depending on your perspective and your skill set can make things much easier or much more of a nightmare quickly.

PCI is probably easier to support than ISA (especially for things like figuring out which devices are present and which IO-ports, IRQs and memory areas they use); and if you want to avoid complexity I'd seriously consider not supporting ISA.

That depends again, on your perspective. From a configuration and detection perspective, you are undoubtedly correct, but in terms of the physical-level complexity, ISA was much simpler; simply using the 286 bus timings as a local bus. In fact, SCAT chipsets for 386-based machines simply generated ISA by making adjustments to the T-states of the bus signaling; it wasn't even true bus "translation". By virtue of this, there isn't much in the way of an ISA interface layer other than some pretty hairy logic for determining what device was in which slot and what its memory spans were. But the raw transactions were quite simple. I know that the hardware for PCI/PCIe ideally makes transfers equally transparent to the software level, but it's one evil for another.

For ACPI, it is an ugly mess (from an OS developer's perspective). However; you can ignore it completely and the system will be just like a older computer. For example, when the user presses the power button, your OS won't be given a chance make sure everything is in a sane state (and avoid things like file system corruption or lost data) - just like on old computers the power just unexpectedly disappears.

...

I'd (mostly) forget about ACPI's AML until after the OS works.

That will cause a chicken-and-egg problem. Unless ACPI systems also hold some sort of legacy 8259-compatible interrupt handling somewhere (or unless I've completely got the notions of ACPI wrong), I won't be able to configure interrupts until I can parse the necessary tables and get into the IOAPIC configurations. Granted that even includes keyboard servicing, it'll be hard to make my operating system anything more than a microcontroller program on 'roids.

Do you have any idea how to workaround that or design a minimal ACPI system that would serve for detection purposes?

[Brendan]

Hi,

For ACPI, it is an ugly mess (from an OS developer's perspective). However; you can ignore it completely and the system will be just like a older computer. For example, when the user presses the power button, your OS won't be given a chance make sure everything is in a sane state (and avoid things like file system corruption or lost data) - just like on old computers the power just unexpectedly disappears.

...

I'd (mostly) forget about ACPI's AML until after the OS works.

That will cause a chicken-and-egg problem. Unless ACPI systems also hold some sort of legacy 8259-compatible interrupt handling somewhere (or unless I've completely got the notions of ACPI wrong), I won't be able to configure interrupts until I can parse the necessary tables and get into the IOAPIC configurations. Granted that even includes keyboard servicing, it'll be hard to make my operating system anything more than a microcontroller program on 'roids.

Do you have any idea how to workaround that or design a minimal ACPI system that would serve for detection purposes?

Almost all modern/ACPI systems still have PIC chips; and you can still use them without IO APICs and without caring about ACPI at all (including both ACPI's tables, and ACPI's AML).

More importantly...

I don't think you're fully understanding what an OS really is: an OS is a set of extensible abstractions.

On one side, the hardware provides extensible abstractions. These are things like "80x86" (where the CPU provides a standard interface/instruction set, with extensions like FPU/MMX/SSE/AVX; and where software mostly doesn't need to care if it's an AMD or Intel or VIA or how it works internally); and things like "PIC" (where the chipset provides an interface in the form of a standard set of IO ports; and where software mostly doesn't need to care if it's an actual ancient 8259 chip or just something emulated by a south-bridge).

On the other side, the OS provides extensible abstractions. These are things like kernel APIs, device driver interfaces, networking protocols, etc; where applications can use these extensible abstractions without needing to care (e.g.) if there's 1 CPU or more, or if the file system is ext3 or NTFS, or if the networking is SLIP or gigabit ethernet.

In the middle, there's just more layers of extensible abstractions. For example, "ext3" file system code just uses some sort of "storage device interface" and doesn't need to care if the actual device is SATA or USB flash or RAM disk. For another example, a networking card device driver just receives IRQs (via. some sort of abstraction provided by a lower level) and doesn't need to care if it's actually using legacy PIC, or IO APIC, or MSI.

For developing an OS, the single most importing thing is designing those extensible abstractions. They must be suitably abstract - e.g. able to handle old hardware and modern hardware (and I'd strongly recommend designing them with foresight - e.g. hoping the abstractions will be suitable for future stuff that doesn't exist yet).

"Implementation" is just filling a gap between 2 abstractions. For example, maybe the hardware gives you a "PIT chip" abstraction and you need to provide a some sort of standardised "timer API" abstraction, so you fill that gap with some code. Maybe the hardware gives you a "PIC chip" abstraction and you need to provide some sort of standardised "IRQ API" abstraction, so you fill that gap with some code. Maybe you do ancient serial in January, modern HPET in February, ancient floppy controller in March, modern PCI in April, ancient PIT in May, modern SATA in June, ancient ISA ne2000 ethernet in July, modern USB keyboard in August.

What I'm saying is that the extensible abstractions are what matter; and the order you fill gaps is mostly arbitrary and doesn't really matter. You seem to be doing the opposite - focusing too much on which gaps you want to fill in what order.


Cheers,

Brendan

[blasthash]

Hi,

For ACPI, it is an ugly mess (from an OS developer's perspective). However; you can ignore it completely and the system will be just like a older computer. For example, when the user presses the power button, your OS won't be given a chance make sure everything is in a sane state (and avoid things like file system corruption or lost data) - just like on old computers the power just unexpectedly disappears.

...

I'd (mostly) forget about ACPI's AML until after the OS works.

That will cause a chicken-and-egg problem. Unless ACPI systems also hold some sort of legacy 8259-compatible interrupt handling somewhere (or unless I've completely got the notions of ACPI wrong), I won't be able to configure interrupts until I can parse the necessary tables and get into the IOAPIC configurations. Granted that even includes keyboard servicing, it'll be hard to make my operating system anything more than a microcontroller program on 'roids.

Do you have any idea how to workaround that or design a minimal ACPI system that would serve for detection purposes?

Almost all modern/ACPI systems still have PIC chips; and you can still use them without IO APICs and without caring about ACPI at all (including both ACPI's tables, and ACPI's AML).

More importantly...

I don't think you're fully understanding what an OS really is: an OS is a set of extensible abstractions.

On one side, the hardware provides extensible abstractions. These are things like "80x86" (where the CPU provides a standard interface/instruction set, with extensions like FPU/MMX/SSE/AVX; and where software mostly doesn't need to care if it's an AMD or Intel or VIA or how it works internally); and things like "PIC" (where the chipset provides an interface in the form of a standard set of IO ports; and where software mostly doesn't need to care if it's an actual ancient 8259 chip or just something emulated by a south-bridge).

On the other side, the OS provides extensible abstractions. These are things like kernel APIs, device driver interfaces, networking protocols, etc; where applications can use these extensible abstractions without needing to care (e.g.) if there's 1 CPU or more, or if the file system is ext3 or NTFS, or if the networking is SLIP or gigabit ethernet.

In the middle, there's just more layers of extensible abstractions. For example, "ext3" file system code just uses some sort of "storage device interface" and doesn't need to care if the actual device is SATA or USB flash or RAM disk. For another example, a networking card device driver just receives IRQs (via. some sort of abstraction provided by a lower level) and doesn't need to care if it's actually using legacy PIC, or IO APIC, or MSI.

For developing an OS, the single most importing thing is designing those extensible abstractions. They must be suitably abstract - e.g. able to handle old hardware and modern hardware (and I'd strongly recommend designing them with foresight - e.g. hoping the abstractions will be suitable for future stuff that doesn't exist yet).

"Implementation" is just filling a gap between 2 abstractions. For example, maybe the hardware gives you a "PIT chip" abstraction and you need to provide a some sort of standardised "timer API" abstraction, so you fill that gap with some code. Maybe the hardware gives you a "PIC chip" abstraction and you need to provide some sort of standardised "IRQ API" abstraction, so you fill that gap with some code. Maybe you do ancient serial in January, modern HPET in February, ancient floppy controller in March, modern PCI in April, ancient PIT in May, modern SATA in June, ancient ISA ne2000 ethernet in July, modern USB keyboard in August.

What I'm saying is that the extensible abstractions are what matter; and the order you fill gaps is mostly arbitrary and doesn't really matter. You seem to be doing the opposite - focusing too much on which gaps you want to fill in what order.


Cheers,

Brendan

I understand what an operating system is. I know that it is a combination of a program or process manager that allows for multitasking or some sort of efficiency with an API that attempts to be as hardware-agnostic as possible. The goal of that API and all the stacks of drivers and runtimes is to make different hardware perform in the same way and be accessible over a "common-mode" call system. That is not news to me.

But homogenizing across all combinations of hardware is not my goal, and most likely won't be for the foreseeable future. Making considerations for different sorts of interfaces and what-not isn't a core endpoint for me at this stage, because I want to be able to demonstrate that I have an operating system that works before I begin the process of porting it out and making such considerations. That doesn't mean every driver stage will be fully monolithic, nor does it mean all the layers will be epoxied together, but it means that writing possibilities for hardware that I won't be working with isn't a primary concern at this point.

I will agree with you that I seem to be focusing a lot on which concepts to work in first, but I won't agree on the concept of "too much". Interrupt processing is a key concern for me because that is what makes the operating system function in an event-oriented manner and not just be a linear execution of instructions that will do the same thing every time. Likewise, keyboard and mouse inputs are basic I/O and that will at least allow me to interact with the system, however one-sided it may be. When it comes down to the drivers, I will be free to decide which ones to work in what order, but if I don't do something to put some sort of backbone in this system, I'll have nothing to test those drivers on. I'm willing to trade off code-time efficiency at the beginning in lieu of getting a solid foundation laid down, rather than be in a hurry to hash out a large number of drivers that don't have a base to abstract over.

If I did that, knowing that I'll do nothing but accrue knowledge in the meantime, I'd just end up constantly rewriting what was always written because I realized better ways to do it. Not that that's necessarily a bad thing; release #1 will be many things, but efficient or stable won't be one of them.

Are these PIC compatibles accessed through the same legacy I/O port methods?

[eryjus]

Are these PIC compatibles accessed through the same legacy I/O port methods?

The wiki provides a good reference here: 8259 PIC