HAL design

[hawkw]

I think it would be great to write an interface layer that abstracts over platform-specific code, and then implement it for each architecture we want to target. We should probably design the interface first, based on the kernel's requirements, rather than writing a bunch of platform code & then trying to abstract over it — it seems easy to accidentally design an interface that basically reproduces a specific platform and requires others to jump through hoops to implement it.

Things we should include in such an interface:

• abstract over "boot params" from a bootloader (e.g. multiboot)
  • memory map, boot flags, # CPUs? etc
  • (unless we want to write our own bootloader which seems like an additional yakshave that should probably be avoided)
• cpu junk
  • enumerate CPUs/cores
  • assign tasks/threads/whatever to CPUs
• paging junk (i think we can assume paging?)
  • translate physical <-> virtual addrs
  • map pages
  • allocate page frames
• interrupts
  • some kinda interface for cross-platform interrupt handlers (presumably not the actual ISRs which are probably pretty platform specific, but the kernel logic they call into)
  • enable/disable interrupts
• "arch init"
  • e.g. whatever setup the platform requires (populate descriptor tables, flip bits in control regs, whatever
  • might be split into "stages" or something based on how much of a kernel we have (e.g. "here's the stuff you do as soon as the kernel starts, like populating the cross-platform boot params", "here's the extra init you do once we can alloc kernel heap objects", whatever)
  • might be per-component (e.g. "init the memory management component")
• etc?

[hawkw]

it would be cool to have a HAL library that drivers could also be written against, but see #3

[iximeow]

(unless we want to write our own bootloader which seems like an additional yakshave that should probably be avoided) hello, the bootloader-writer has logged on

i broadly agree though and really just think it would be fun to write a bootloader.

i'm also super not sure how much A or H the HAL should do, entirely because i've never thought about trying to interact with "storage" or "peripherals" before. my spiciest(?) take on this is that trying to fit hardware into a file model is not great and makes for extremely uninformative errors when something goes wrong. i want to know what parameter was invalid, or why it was invalid, not simply EINVAL.

i think this means the HAL would have to know about hardware-specific error modes, but i'm not sure if or how it applies to different interconnects (device X over usb vs pcie vs ...) at all

[hawkw]

i [...] really just think it would be fun to write a bootloader.

strong agree but i don't think we would get very far on a kernel if we decided to also do a bootloader. if we abstract over "boot info" we could always replace multiboot with ixiboot later.

i'm also super not sure how much A or H the HAL should do

so, you just want it to be a "Layer"? :P

trying to fit hardware into a file model is not great and makes for extremely uninformative errors when something goes wrong. i want to know what parameter was invalid, or why it was invalid, not simply EINVAL.

i think this means the HAL would have to know about hardware-specific error modes, but i'm not sure if or how it applies to different interconnects (device X over usb vs pcie vs ...) at all

mostly agree, but i don't think the HAL itself would have to be necessarily aware of hardware-specific error modes so much as provide an interface for returning richer errors defined by the hardware device; e.g.:

trait Hardware {
    type DeviceError: crate::Error;
}

(of course this code is wildly reductive, but imagine something like that but useful 😄)

[hawkw]

cc #8

[hawkw]

i started playing around with a pretty bad hal ages ago, most of this is probably garbage and shouldn't reused https://github.com/sos-os/hal9000/tree/master/hal9000/src

[hawkw]

basic HAL structure rough thoughts:

• "architecture" trait defines things like "what is a physical addr"
• traits for "controllers" for various subsystems
  • InterruptControl for adding/removing ISRs, enabling/disabling IRQs
  • TaskControl for enumerating, starting, stopping tasks
  • MemControl for translating addrs, allocating page frames (is this multiple traits?)
• initialization == constructing a control struct?
• trait for boot parameters