HAL

[dc0d32]

Hey,

I searched the forum for HAL. Couldn't find any relevant thread, so starting a new one.

What things are usu included in a HAL?
i have brainstormed a few points as follows.

Code: Select all

/*the values in [ ] mean the code maturity level 0-9, relative to the rest of the entries*/

[ ] HAL
 +[ ] Spinlocks or semaphores or monitors..... decide. or support all. All kinds of synchronization routines.
 +[ ] IRQL management
 +[ ] Display [BootVid]
  ++[ ] Display ownership
  ++[ ] get and set display parameters
  ++[ ] display strings, something like printf
 +[ ] Internal Heap Memory management : malloc, calloc, free, realloc etc.
 +[ ] Paging
  ++[ ] allocate Virtual address space, the kernel maps this VASpace to a process. So the kernel does the mapping between VASID and PID, or PID may be set same as VASID
  ++[ ] Allocate a page in a virtual address space, mapping at given virtual address.
  ++[ ] Freeing the page ie. unmapping from given VAS
  ++[ ] Access permissions : setting and getting
 +[0] Port IO routines
 +[ ] Standard library
  +[ ] String operations
  +[ ] Searching and Sorting
 +[ ] FPU operations
  +[ ] If absent, emulate. but, I don't think there are new machines without one.
 +[ ] Resource Management
  ++[ ] Request/Report resource usage
  ++[ ] free allocated resources
 +[ ] Performance Counters : calibration, read, reset. These include TSC, interrupts /sec, IO reads/writes per second etc
 +[ ] abstraction for interrupts : mapping hardware specific interrupts to generic interrupt classes
  ++[ ] Software virtual interrupts : invoking, start, end, queuing, enabling, disabling, getvect, setvect etc
 +[ ] basic devices : these are the devices which are taken for granted
  ++[ ] DMA
   +++[ ] Read DMA counter
   +++[ ] start /schedule DMA transfer
  ++[ ] timer management
   +++[ ] Set resolution, get resolution
   +++[ ] Beep
   +++[ ] Delay, uDelay
  ++[ ] RTC
   +++[ ] get and set time, date
 +[ ] Processor management
  ++[ ] Starting
  ++[ ] stalling
  ++[ ] Caches
  ++[ ] querying state, errors etc
 +[ ] Context switching
  ++[ ] Processor Context base class
  ++[ ] Switching routines
  ++[ ] switching with and without virtual address space switching ie. threads in same and different processes
 +[ ] Environment variables
 +[ ] Profiling [OPTIONAL]
 +[ ] Debugging support [OPTIONAL]
  ++[ ] Debug Interrupt management
  ++[ ] Reading, demangling and managing symbols. now the symtab sections should not be stripped off
  ++[ ] Debugging over serial port????

anything more or less?


{Something bit off-topic:
I have been following the forum for almost a year now. What i've noticed that what most of us have been doing or have done till now are just HALs, things that can run as primitive kernels and not even traces of processes, synchros, networking, nice n big applications. IMHO, what many of us have ben building till now are not kernels, but HALs. No offence. Thats not my intension.
}

[Pyr0Mathic]

{Something bit off-topic:
I have been following the forum for almost a year now. What i've noticed that what most of us have been doing or have done till now are just HALs, things that can run as primitive kernels and not even traces of processes, synchros, networking, nice n big applications. IMHO, what many of us have ben building till now are not kernels, but HALs. No offence. Thats not my intension.
}

If i understand you correctly, then HAL is nothing more than a program which does act as an OS, but more like a mini-kernell to run a couple of task's and nothing more and basicly doesnt support most of the things "real" os's support.

I think that the main problem for that is that if you are building an OS you gotta start somewhere, so you first try to get something up and running and go on whit the next part. and things like building network drivers and device drivers take's a lot of time, atleast in my expirience. Also its pointless to support very smart ways of task-switching and other stuf in your os if you normally dont have more then 3 threads running...

In my case i am writing an OS to do a simple task (ftp-server) so am not going to spend my time building things into the os i wont use anyway, but i am not really at a university so most stuf i build into my os i come up whit by my self... so things like spinlock's, dont know what it is....

Might be a bit hard in the above tekst, but plz dont be offended.

Regards
PyroMathic

[JoeKayzA]

Maybe our definition of HAL differs, but IMO

+[ ] Internal Heap Memory management : malloc, calloc, free, realloc etc.
....
+[ ] Standard library
+[ ] String operations
+[ ] Searching and Sorting

shouldn't go into a HAL, these should be basic (and portable) library routines (ok, string and maybe sort routines could be implemented in an architecture-specific way for performance reasons). As long as you assume a flat memory model (*if* you do), the heap management functions should be perfectly portable as well.

+[ ] Resource Management
++[ ] Request/Report resource usage
++[ ] free allocated resources

How is the term 'resource' defined in this context? If it's too high-level already, I don't think this should go into the HAL either. Especially if it implies policy decisions, because the HAL should be kept absolutely policy-free IMO (only pure mechanism).

{Something bit off-topic:
I have been following the forum for almost a year now. What i've noticed that what most of us have been doing or have done till now are just HALs, things that can run as primitive kernels and not even traces of processes, synchros, networking, nice n big applications. IMHO, what many of us have ben building till now are not kernels, but HALs. No offence. Thats not my intension.
}

No offense taken, but mind that the terms 'HAL' and 'kernel' are still pretty poorly defined overall. As Pyr0Mathic already stated, you need something where you start, ideally from the bottom up, and in most designs, the bottom is a simple abstraction layer for hardware. I, for example, try to do a good job at keeping as much of the lower layers as possible completely policy-free, and let the 'mid' layers configure things at runtime. So most of my 'kernel' is in fact the HAL, not much more....

cheers Joe

[dc0d32]

@1 : the library
it wont be the one used by apps. Just used by the HAL functions themselves and the rest of the kernel above. The ones used by apps and other server processes will reside in normal general standard library. So, we have two separate implementations, the one used ni kernel is very minimal and performant, and the other is just general purpose with all bells and whistles.

@2 : Resources
well correct me if i am wrong. I consider IO ranges, non-RAM memory areas and shared IRQ as resources. They are mapped to a so called process - or in my case the virtual address space (VASID). I still need help on this.

@3 : first of all - i did not intend to start off that discussion. It was the result of 'thinking aloud'.



again : what should be added or removed?

[Combuster]

Although security should not be an abstraction layers immediate concern, it does help having an mechanism to either allow or deny processes access to it. If its missing you either have to hack user processes not to have access to it (which the hal in turn might not like), or run a win9x-like environment where everything can access anything. My boot module (deliberately avoiding using the term hal or kernel) checks a flag to see if it can access hardware functions.

the item "Basic devices" might be moved OUT of the HAL: this version for instance assumes a ia32/64 architecture (which not all os's run on). more generally, the pc speaker code can well be implemented outside the hal since it only needs access to a few ports and a timer. same goes for DMA and i wont even start on the video operations.
Timers gets a bit more difficult, but you can access the PIT and the like from outside the HAL and have all other drivers that need the timers route their calls through a timer sublayer.

Regarding the IA, some performance counters do not need to be within the HAL since they are well accessible from outside (the RDTSC/RDPMC instructions). Not sure what other hosts do regarding this matter, but at least for the IA i would leave them out of the HAL.

On the extreme though, only those things that a process can't bootstrap itself should be in the HAL - say if all processes were to run in ring 0 you wouldn't need much of a HAL, although having one simplifies things a lot.

[Colonel Kernel]

To me, the purpose of a HAL is to allow the same kernel binary to run on different machine types of the same architecture. In other words, the HAL contains all the device drivers needed by the kernel itself. For example, if your kernel can use either the PIC or the APIC depending on the chipset of the machine it's running on, then I'd put all interrupt controller-related stuff in the HAL.

My $0.02.

[JoeKayzA]

@1 : the library
it wont be the one used by apps. Just used by the HAL functions themselves and the rest of the kernel above. The ones used by apps and other server processes will reside in normal general standard library. So, we have two separate implementations, the one used ni kernel is very minimal and performant, and the other is just general purpose with all bells and whistles.

I know, this wasn't meant to be the library for applications. But it's still some kind of runtime library, this time for in-kernel code. Heap management, string operations and stuff IMO don't abstract hardware, therefore I would place them somewhere else than in the HAL.

Furthermore, I think Combuster and Colonel Kernel have a good point - if it's your intent to make your system portable between platforms, there should be a differentiation between "architecture specific" parts and "basic devices". Architecture specifics would be, ie., the layout of the gdt or idt, how to signal and handle interrupts, how to deal with page tables and stuff. Basic devices, however, would be interrupt controllers, RTC, DMA controllers - things that are not really defined by the architecture, but that are common to be used along with it.

Just my opinion - but I guess that what you've asked for.

cheers Joe