OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Nov 23, 2017 9:52 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 17 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: New memory map structure
PostPosted: Sun Oct 25, 2015 8:27 am 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 870
Location: Finland
Owen wrote:
But why not the UEFI memory map structure? No translation on UEFI. On non-UEFI, map the "native" format into a UEFI memory map. And if you need a type which UEFI doesn't define? Well, as said, there are 2^31 type codes reserved for arbitrary use by the OS.

Additionally, whatever part of your system sets up paging needs to make a call back into UEFI with the address map anyway. If all you have is a translated map, you're in for a world of hurt there.


It has been more than a year I started this topic. The first post did make sense back then but now I am leaning toward using this UEFI structure also on non-UEFI computers. I totally ignored the fact that on UEFI computers I would need to give the map back if I wanted to use runtime services. Having a native format described in the first post for the OS itself (to which memory maps are converted, whether they came from the UEFI or not) does not offer any significant advantages in this case. The OS will handle memory in its own internal structures so the format would have been only a transfer format. Converting "BIOS formats" to the UEFI format (with good validity checks) makes sense at this point and the "post-boot" state is uniform between the legacy and modern systems.

Owen wrote:
So why invent something new and perfect?


I did and do like the gapless memory map.

_________________
Undefined behavior since 2012


Top
 Profile  
 
 Post subject: Re: New memory map structure
PostPosted: Sun Oct 25, 2015 9:47 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8151
Location: At his keyboard!
Hi,

Antti wrote:
Owen wrote:
But why not the UEFI memory map structure? No translation on UEFI. On non-UEFI, map the "native" format into a UEFI memory map. And if you need a type which UEFI doesn't define? Well, as said, there are 2^31 type codes reserved for arbitrary use by the OS.

Additionally, whatever part of your system sets up paging needs to make a call back into UEFI with the address map anyway. If all you have is a translated map, you're in for a world of hurt there.


It has been more than a year I started this topic. The first post did make sense back then but now I am leaning toward using this UEFI structure also on non-UEFI computers.


Somewhere in that year, I've stolen the "gapless" idea and started using it in my code. I've found it more convenient, mostly because you can insert entries without changing the previous entry's "length" field.

I've also switched from "types" to flags (e.g. one flag for RAM, one flag for volatile, one flag for faulty, one flag for hotplug, etc), and that has made things simpler and more flexible (especially when firmware reports the same area as 2 or more different types, as you can find a "safe combination" using AND/OR instead of ugly lookup tables).

Antti wrote:
I totally ignored the fact that on UEFI computers I would need to give the map back if I wanted to use runtime services.


In my opinion; you shouldn't need to use any of the UEFI run-time services after boot, and the kernel (and majority of the OS) shouldn't know or care if the firmware was BIOS or UEFI or something else. If you look at the run-time services, they're all either things that boot code can use before calling "ExitBootServices()" (e.g. getting/setting UEFI variables, getting current time), or things that would be done via. ACPI anyway (reset/shutdown), or things that no OS should be permitted to do at all (e.g. diddling with firmware updates and the massive security implications that entails, which should have only been allowed from a special UEFI application/utility). That only leaves the virtual memory services (which are pointless if you're not using run-time services).


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 17 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot] and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group