On any reasonable modern processor you can rely on the existence of some sort of interrupt mechanism.zesterer wrote: Can I rely on the existence of:
- IRQs?
You cannot rely on any particular implementation of this mechanism being present. Each processor does things its own way.
On any modern processor intended for mobile, desktop, or server use you can rely on the existence of some sort of paging mechanism. You will also find paging on many, but not all, embedded processors. Unless you're developing an OS for embedded use, you should probably refuse to support processors that don't have paging, as it has significant benefits for reliability, security, and debugability, and non-embedded processors that don't have paging are going to be in very old, low-spec hardware.- Paging?
That said, most (all?) processors will *not* have paging active at boot, so your early boot code will have to deal with a non-paged environment (unless you outsource that to an external bootloader), but early-boot code will tend to be architecture-specific anyway.
You cannot rely on any particular implementation of paging being present. Address space size, number of paging levels, and page size may all vary.
The only processor that you're likely to encounter with segmentation is an Intel processor. Every modern operating system for Intel processors just uses it in real mode at boot time, then, when switching to protected/long mode, sets up the minimum in terms of segmentation that is needed to run as if the segmentation system didn't exist, and then promptly forgets about segmentation. In long mode and compatibility mode, segementation only exists for historical reasons and you can't do anything with it other than setting up a flat address space and forgetting about segmentation. The only reason you would ever use segmentation on an Intel processor is if you're running in real mode or 16-bit protected mode for some reason.- Segmentation?
That depends what you mean by "a serial I/O device". If you mean "an RS-232 device", no.- A serial I/O device?
No, multiboot is entirely a software thing. It's also mostly an x86 thing. It could conceivably be adapted to non-x86 systems, but you're not even guaranteed to see it on x86 systems. In fact, any x86 system that ships with a proprietary OS (which is to say, Windows), will almost certainly *not* have a multiboot compliant bootloader unless the user puts it there. That said, if the user has installed Linux, there almost certainly will be a multiboot compliant bootloader (though, depending on how the user has things set up, it may not be the first bootloader to run), and if someone is trying out alternative OSes, they're likely to try out Linux before they try out your OS, so even though the general rule is "no, you cannot count on a multi-boot compliant bootloader", you probably can count on the people that are likely to try your OS having one (on x86).- Multiboot-compliance bootloaders?
