What are services

[devc1]

I do not feel respected by someone running to the mods once called out on their behavior

I was actually warned twice on some very simple things because they ran to mods and told them about small things I've said.

And I especially do not feel respected when someone demands an answer by only a single member.

Where did I do that ?

Let's just stop talking about (the bumping the thread thing) and Sorry if I disturbed anyone.

[AndrewAPrice]

What makes the kernel run a specific driver, my kernel just lists pci devices and runs the driver for the device. But what about an acpi driver ? Should it run all the drivers at once, and if (for e.g.) acpi is not found the driver will just shutdown ?

So there's a chicken-and-egg problem in microkernels in that can be summed up as:
1) I need to load my disk driver so I can read from disk
2) I need to read from disk to load my disk driver.

Depending on where along the micro/monolithic spectrum you're on, you might have the code for loading programs in a service (rather than the kernel) - so how can you load that?

Monolithic kernels are probably easier to get started, because all of this is compiled into the kernel and are not seperate programs.

For microkernels, you have a few options. Some use an initrd which is a small disk image loaded into memory, so the kernel can read the initial services/drivers. I use GRUB as my bootloader, and GRUB lets you load what are called "multiboot modules", which just copies the file off disk into memory for you, so your microkernel can load these services/drivers before knowing how to read off a disk.

Getting back to your question:

Should it run all the drivers at once, and if (for e.g.) acpi is not found the driver will just shutdown ?

There are two things you can either do:
1) Run the driver. If it doesn't detect the device it's made for, it quits.
2) Enumerate through detected devices and when you recognize one, load the driver.

Most interfaces such as PCI and USB let you loop through connected devices and tell you info about the device (PCI has: device id, vendor id, class code, subclass, revision id), and if you have a database of drivers built for your OS, see if a driver exists for that device and try to load it.

It would kind be inefficient for a large OS such as Windows to try to load every known driver on startup, but back to solving the chicken-and-egg problem, on your first boot (e.g. booting the install disk) you probably do have to load every known disk driver and let all but one fail, but then during installation, you could find the driver that actually worked, and write it into your initrd/boot configuration. In this way, you precomputed during installation what the essential devices are, so you don't have to on each boot.

Before Plug-and-Play it was difficult to detect hardware, and the user had to be familiar with their computer, which often meant video games asking you what type of sound card you had when you installed them:

[Octocontrabass]

Most interfaces such as PCI and USB let you loop through connected devices and tell you info about the device (PCI has: device id, vendor id, class code, subclass, revision id), and if you have a database of drivers built for your OS, see if a driver exists for that device and try to load it.

ACPI has this as well, so on modern PCs you only need to start your ACPI driver and let it start any additional drivers.

[rdos]

Most interfaces such as PCI and USB let you loop through connected devices and tell you info about the device (PCI has: device id, vendor id, class code, subclass, revision id), and if you have a database of drivers built for your OS, see if a driver exists for that device and try to load it.

ACPI has this as well, so on modern PCs you only need to start your ACPI driver and let it start any additional drivers.

ACPI doesn't know anything about PCI devices or USB devices (at least shouldn't). It only knows about legacy stuff. And it knows how IRQs are routed for PCI devices, but you could potentially probe them to avoid loading a bloated ACPI driver that likely is several hundred kBs big.

Most modern drivers either use PCI identification or USB identification, and ACPI doesn't know (at least shouldn't know) anything about that.

Additionally, most modern PCI devices either has MSI or MSI-X support, which means you don't need to care about IRQ mappings or sharing them.

The natural hierarchy is that at the bottom you have a PCI driver that can enumerate PCI devices. PCI based device are at the next level. They will ask the PCI driver for a specific PCI device (vendor, product), or a PCI class. USB drivers are PCI drivers.

If you want to support legacy drivers, you just compile them into the kernel, or load the driver at boot time. They are better off probing for the device rather than using ACPI. For instance, IDE drivers will check a number of IO ports for a disc. A serial port driver would do the same (but using different IO ports). On old hardware, ACPI is not guaranteed to exist, or work properly, so I simply won't load the ACPI driver when the system only has a PIC controller. The PCI mappings typically are correct for the PIC controller, so ACPI is not needed to discover them. IRQ detection also works well with the PIC controller as it has known number of IRQs (15).

[devc1]

but how about non pci/usb device drivers (for e.g. ACPI, HPET, PCI, TPM...)

Should I implement the pci driver (itself) which probes for devices, in a service ? Because the kernel has no knowledge to detect if pci exists in this world : )

Should the acpi driver also be implemented in a service ?

[Octocontrabass]

ACPI doesn't know anything about PCI devices or USB devices (at least shouldn't).

ACPI knows about PCI host bridges, which means your ACPI driver can start PCI host bridge drivers which can enumerate the PCI bus(es).

USB is (typically) behind PCI.

It only knows about legacy stuff.

Maybe that's how it was when ACPI was first introduced in 1996, but in the past 25 years new hardware has been introduced that can only be enumerated through ACPI.

On old hardware, ACPI is not guaranteed to exist, or work properly,

Neither of these are concerns for a 64-bit OS.

But if you are indeed writing an OS for old hardware, then when you encounter a PC that doesn't support ACPI correctly you'll know all of the "standard" legacy devices are present or can be detected through "standard" means.

[rdos]

ACPI doesn't know anything about PCI devices or USB devices (at least shouldn't).

ACPI knows about PCI host bridges, which means your ACPI driver can start PCI host bridge drivers which can enumerate the PCI bus(es).

But the IO ports used for PCI are fixed, and so you don't need ACPI to get those. I've not seen a computer yet (old or new) that use different IO ports for PCI.

USB is (typically) behind PCI.

Exactly, so USB drivers query PCI for certain device categories, and ACPI has no role there.

On old hardware, ACPI is not guaranteed to exist, or work properly,

Neither of these are concerns for a 64-bit OS.

Perhaps not, but I see no reason why I would want to write a 64-bit OS. 32-bit protected mode is hugely superior to long mode, and works on everything back to the first 386.

[devc1]

Code: Select all

But the IO ports used for PCI are fixed

ACPI enumerates PCI Express buses not normal PCI, PCIe is accessed through MMIO which is much faster than the IO Ports.

Code: Select all

Perhaps not, but I see no reason why I would want to write a 64-bit OS. 32-bit protected mode is hugely superior to long mode, and works on everything back to the first 386.

How is it superior than 64 bit, before explaining I tried Unity (game engine) on both 64 bit and 32 bit windows, and it was much slower on the 32 bit one.
Why ? Because 64 bit mode offers alot of new features for optimization and security, 64 bit allows more than 4 gb of address space (the bare minimum recommended ram these days is 16GB), You can play with virtual memory as you want and you don't have to check for SSE2, PAT/MTRR (To enable special memory cachings such as Write Combining), ACPI, APIC... + MMIO is much faster than the IO ports. + Writing a 64 bit OS maybe frustrating at the start but as soon as you learn it becomes interesting and funny

[nexos]

But the IO ports used for PCI are fixed, and so you don't need ACPI to get those. I've not seen a computer yet (old or new) that use different IO ports for PCI.

But pretty much every computer made in the past 10 years uses PCIe

Because 64 bit mode offers alot of new features for optimization and security, 64 bit allows more than 4 gb of address space (the bare minimum recommended ram these days is 16GB)

I agree that 64 bit systems are better, but the only reason why they are faster is because they have twice as many registers. And many computers these days (such as mine) have 8GB of RAM still.

Also, on 32 bit systems PAE allows you to use up to 64GB of RAM.

[rdos]

Code: Select all

But the IO ports used for PCI are fixed

ACPI enumerates PCI Express buses not normal PCI, PCIe is accessed through MMIO which is much faster than the IO Ports.

Not true. PCI and PCIe use the same software interface. Enumeration of PCI devices is done with IO ports, and this is so for both PCI and PCI express. ACPI has no role there. It's the BARs that typically are memory mapped. However, memory mapped BARs are slow too compared to physical memory, so the operational data of PCI devices typically use schedules in physical RAM and bus mastering.

Why ? Because 64 bit mode offers alot of new features for optimization and security, 64 bit allows more than 4 gb of address space (the bare minimum recommended ram these days is 16GB), You can play with virtual memory as you want and you don't have to check for SSE2, PAT/MTRR (To enable special memory cachings such as Write Combining), ACPI, APIC... + MMIO is much faster than the IO ports. + Writing a 64 bit OS maybe frustrating at the start but as soon as you learn it becomes interesting and funny

In short: Long mode lacks proper protection. ACPI is an interface with little relevance, large complexity, and thus require a huge code base to support. It's perfectly possible to use ALL physical RAM in protected mode (PAE paging). MMIO of course is available in protected mode too, and so is SSE and PAT/MTRR.

[rdos]

But the IO ports used for PCI are fixed, and so you don't need ACPI to get those. I've not seen a computer yet (old or new) that use different IO ports for PCI.

But pretty much every computer made in the past 10 years uses PCIe

The difference is only in the hardware. The software interface is the same.

I agree that 64 bit systems are better, but the only reason why they are faster is because they have twice as many registers. And many computers these days (such as mine) have 8GB of RAM still.

Yes, a larger number of registers could be advantegous, but it also requires more time to switch tasks. As for the registers being 64-bit instead of 32-bits, this is seldom an issue. Most code work fine with 32-bit ints, and it is quite rare to use the "long long" type to force 64-bit variables. And it is also a fact that 64-bit pointers and 64-bit variables require more space than 32-bit pointers and 32-bit variables, and so use more space in caches, and thus have higher cache-miss rates, and ultimately become slower.

Also, on 32 bit systems PAE allows you to use up to 64GB of RAM.

Not so. PAE paging allows you to use the full address space. I have a setup with 128MB of RAM, and all of it is accessible in my 32-bit protected mode OS. The trick is that you can memory map any physical address, and as long as you don't need true random access, there is no speed penalty.

Also note that PAE paging uses one paging level less than long mode paging, and thus requires fewer memory access on cache misses. Protected mode paging have two levels less than long mode paging, and also consume only half as much of memory to keep track of paging structures. The latter means it's advantageous to use protected mode paging when the computer has no physical memory above 4GB. Both because it is faster and because it consumes less memory.

[nexos]

The difference is only in the hardware. The software interface is the same.

Not so. MMIO is used in PCIe, plus there is an extra level of indirection above the bus.

Both because it is faster and because it consumes less memory.

i386 most certainly is not faster. It has half as many GPRs, making memory access more common. That more than accounts for any extra TLB miss overhead.

ACPI is an interface with little relevance, large complexity, and thus require a huge code base to support.

It's the foundation of modern PC architecture. That's rather important IMO.

[rdos]

The difference is only in the hardware. The software interface is the same.

Not so. MMIO is used in PCIe,

I'm enumerating both PCI and PCIe with IO ports. This is only for detection so is not a speed issue. The PCI driver will cache all devices found during the initial enumeration. The code basically queries all PCI addresses for devices. That's a method that works regardless of ACPI.

plus there is an extra level of indirection above the bus.

That's quite irrelevant since normal computers are not using this.

i386 most certainly is not faster. It has half as many GPRs, making memory access more common. That more than accounts for any extra TLB miss overhead.

No need for an i386. Protected mode paging can be used on any processor (as long as all physical memory is below 4G).

ACPI is an interface with little relevance, large complexity, and thus require a huge code base to support.

It's the foundation of modern PC architecture. That's rather important IMO.

Correction: It was supposed to be the foundation of modern PCs, but it has become more or less obsolete if you don't enjoy porting it to your OS. Why is it obsolete? Because the processor objects are not provided, so processor core regulation needs a "processor driver" (or looking for the information in the Intel & AMD manuals). Because most PCI devices no longer need IRQs, and support MSI and MSI-X. Because you can discover PCI devices with the "brute force method". Because the presence of legacy devices is quite rare, and the few that still exist like the real-time clock use fixed IO ports.

[rdos]

but how about non pci/usb device drivers (for e.g. ACPI, HPET, PCI, TPM...)

Should I implement the pci driver (itself) which probes for devices, in a service ? Because the kernel has no knowledge to detect if pci exists in this world : )
I
Should the acpi driver also be implemented in a service ?

I think HPET always is at a fixed adress and so is the APIC, so they are easy to detect. ACPI itself is not a device, and so doesn't need any driver. PCI uses a fixed IO port that can be used for enumeration.

I'm a bit unsure if processor cores and their APIC addresses can be discovered without ACPI, but they probably can.

[AndrewAPrice]

This is a bit of a silly argument because one could also argue to build a real mode OS and if you need anything better something is wrong with you...

I haven't owned an x86 processor that didn't support long move since the mid 2000s - some 17 years ago. I don't expect the audience of my OS (which honestly is just me) will want to run it on a pre 64-bit x86 processor.