std.os.uefi.tables: ziggify boot and runtime services

[dotcarmen]

this PR updates BootServices and RuntimeServices to an idiomatic interface similar to the pattern used in std.os.uefi.protocol. Part of my crusade towards making std.os.uefi more idiomatic

@linusg

another-one.png

It is appreciated! :^)

Not a thorough review, LGTM at a high level

i figured it's safer to obscure map_key values since as far as i can tell it's meant to be assigned by the system (only retrievable via getMemoryMap)

i couldn't find an easier way to manage dynamically constructing a tuple than this helper :/

this function is kinda gross :/ suggestions are welcome

A few minor nitpicks, but since we're overhauling boot services it's time we remove [*]MemoryDescriptor and []MemoryDescriptor from std.os.uefi, they are never valid because the size of the zig struct is almost never the size of the descriptor the firmware returns.

doesn't make sense to define wrappers for these functions imo

this function is now basically the handleProtocol function

afaict this was a bug 😬 exit_data.len for number of u16s but the spec says it's the number of bytes

i feel like this is ready for a final review :) i haven't tried it with my own project yet though, i'll tackle that later

really feels like [*:null]*anyopaque should work :(

haven't forgotten or abandoned this, I'm dealing with immigration stuffs :) I'll pick it up again soon

ok i may have gone a little overboard with 7372d65 so i partly reverted it in 04e3728 to keep the number of files in the diff small :) those align(8)s aren't an error or anything, they're just unnecessary now :)

otherwise the rest of the PR comments have been addressed!

I decided to not keep this as *const opaque{} since it might be nice to have the namespace eventually? idk

I actually feel like it'd be handy to do that for Event eventually 🙃

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

ah sorry i think i rebased and didn't mean to push the rebase 😅

here's the changes link for commits from last night: https://github.com/ziglang/zig/pull/23441/files/13858228112d8ee6798dd51032728f68c512bc5f..d37be4284b844684cd1f39b2fd543d8003dcb348

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

decided to include a pattern that i've been experimenting with in another PR i'm working on for std.elf, wdyt?

1. define IntFittingRange for the relevant value range

oh wait the start should be 0 😅 and the end should be _start - _end 😅

_end - _start *

2. function for constructing such values ie pub const my_invalid: MemoryType = .invalid(0x2);

Why are we constructing invalid memory types?

3. function for retrieving the value relative to the range's start

IMO, it is also a good idea to use _allocatePage in pool_allocator if alignment is 4096, as _allocatePool is slow.

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

I don't have an exact source to back this up, but testing on some hardware I have available I found that allocatePage is significantly slower than allocatePool.

rebased to latest master :)

Did another full review, I have only nitpicks left. Tested locally against a small UEFI app - not nearly exhaustive, but builds. Happy to merge after this!

^ tried to rebase on latest master but the diff got nasty, i'll merge. reverted the rebase-push

CI is failing

yup, just saw that lol, looking into it now

Thanks for your patience with this! Let's merge 🎉

LFG, glad to see this. I hope we can get #22226 next. I'll rebase it tonight after work, feel free to review.

[dotcarmen]

this PR updates BootServices and RuntimeServices to an idiomatic interface similar to the pattern used in std.os.uefi.protocol. Part of my crusade towards making std.os.uefi more idiomatic

@linusg

another-one.png

It is appreciated! :^)

Not a thorough review, LGTM at a high level

i figured it's safer to obscure map_key values since as far as i can tell it's meant to be assigned by the system (only retrievable via getMemoryMap)

i couldn't find an easier way to manage dynamically constructing a tuple than this helper :/

this function is kinda gross :/ suggestions are welcome

A few minor nitpicks, but since we're overhauling boot services it's time we remove [*]MemoryDescriptor and []MemoryDescriptor from std.os.uefi, they are never valid because the size of the zig struct is almost never the size of the descriptor the firmware returns.

doesn't make sense to define wrappers for these functions imo

this function is now basically the handleProtocol function

afaict this was a bug 😬 exit_data.len for number of u16s but the spec says it's the number of bytes

i feel like this is ready for a final review :) i haven't tried it with my own project yet though, i'll tackle that later

really feels like [*:null]*anyopaque should work :(

haven't forgotten or abandoned this, I'm dealing with immigration stuffs :) I'll pick it up again soon

ok i may have gone a little overboard with 7372d65 so i partly reverted it in 04e3728 to keep the number of files in the diff small :) those align(8)s aren't an error or anything, they're just unnecessary now :)

otherwise the rest of the PR comments have been addressed!

I decided to not keep this as *const opaque{} since it might be nice to have the namespace eventually? idk

I actually feel like it'd be handy to do that for Event eventually 🙃

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

ah sorry i think i rebased and didn't mean to push the rebase 😅

here's the changes link for commits from last night: https://github.com/ziglang/zig/pull/23441/files/13858228112d8ee6798dd51032728f68c512bc5f..d37be4284b844684cd1f39b2fd543d8003dcb348

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

decided to include a pattern that i've been experimenting with in another PR i'm working on for std.elf, wdyt?

1. define IntFittingRange for the relevant value range

oh wait the start should be 0 😅 and the end should be _start - _end 😅

_end - _start *

2. function for constructing such values ie pub const my_invalid: MemoryType = .invalid(0x2);

Why are we constructing invalid memory types?

3. function for retrieving the value relative to the range's start

IMO, it is also a good idea to use _allocatePage in pool_allocator if alignment is 4096, as _allocatePool is slow.

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

I don't have an exact source to back this up, but testing on some hardware I have available I found that allocatePage is significantly slower than allocatePool.

rebased to latest master :)

Did another full review, I have only nitpicks left. Tested locally against a small UEFI app - not nearly exhaustive, but builds. Happy to merge after this!

^ tried to rebase on latest master but the diff got nasty, i'll merge. reverted the rebase-push

CI is failing

yup, just saw that lol, looking into it now

Thanks for your patience with this! Let's merge 🎉

LFG, glad to see this. I hope we can get #22226 next. I'll rebase it tonight after work, feel free to review.

[dotcarmen]

this PR updates BootServices and RuntimeServices to an idiomatic interface similar to the pattern used in std.os.uefi.protocol. Part of my crusade towards making std.os.uefi more idiomatic

@linusg

another-one.png

It is appreciated! :^)

Not a thorough review, LGTM at a high level

i figured it's safer to obscure map_key values since as far as i can tell it's meant to be assigned by the system (only retrievable via getMemoryMap)

i couldn't find an easier way to manage dynamically constructing a tuple than this helper :/

this function is kinda gross :/ suggestions are welcome

A few minor nitpicks, but since we're overhauling boot services it's time we remove [*]MemoryDescriptor and []MemoryDescriptor from std.os.uefi, they are never valid because the size of the zig struct is almost never the size of the descriptor the firmware returns.

doesn't make sense to define wrappers for these functions imo

this function is now basically the handleProtocol function

afaict this was a bug 😬 exit_data.len for number of u16s but the spec says it's the number of bytes

i feel like this is ready for a final review :) i haven't tried it with my own project yet though, i'll tackle that later

really feels like [*:null]*anyopaque should work :(

haven't forgotten or abandoned this, I'm dealing with immigration stuffs :) I'll pick it up again soon

ok i may have gone a little overboard with 7372d65 so i partly reverted it in 04e3728 to keep the number of files in the diff small :) those align(8)s aren't an error or anything, they're just unnecessary now :)

otherwise the rest of the PR comments have been addressed!

I decided to not keep this as *const opaque{} since it might be nice to have the namespace eventually? idk

I actually feel like it'd be handy to do that for Event eventually 🙃

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

ah sorry i think i rebased and didn't mean to push the rebase 😅

here's the changes link for commits from last night: https://github.com/ziglang/zig/pull/23441/files/13858228112d8ee6798dd51032728f68c512bc5f..d37be4284b844684cd1f39b2fd543d8003dcb348

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

decided to include a pattern that i've been experimenting with in another PR i'm working on for std.elf, wdyt?

1. define IntFittingRange for the relevant value range

oh wait the start should be 0 😅 and the end should be _start - _end 😅

_end - _start *

2. function for constructing such values ie pub const my_invalid: MemoryType = .invalid(0x2);

Why are we constructing invalid memory types?

3. function for retrieving the value relative to the range's start

IMO, it is also a good idea to use _allocatePage in pool_allocator if alignment is 4096, as _allocatePool is slow.

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

I don't have an exact source to back this up, but testing on some hardware I have available I found that allocatePage is significantly slower than allocatePool.

rebased to latest master :)

Did another full review, I have only nitpicks left. Tested locally against a small UEFI app - not nearly exhaustive, but builds. Happy to merge after this!

^ tried to rebase on latest master but the diff got nasty, i'll merge. reverted the rebase-push

CI is failing

yup, just saw that lol, looking into it now

Thanks for your patience with this! Let's merge 🎉

LFG, glad to see this. I hope we can get #22226 next. I'll rebase it tonight after work, feel free to review.

[dotcarmen]

this PR updates BootServices and RuntimeServices to an idiomatic interface similar to the pattern used in std.os.uefi.protocol. Part of my crusade towards making std.os.uefi more idiomatic

@linusg

another-one.png

It is appreciated! :^)

Not a thorough review, LGTM at a high level

i figured it's safer to obscure map_key values since as far as i can tell it's meant to be assigned by the system (only retrievable via getMemoryMap)

i couldn't find an easier way to manage dynamically constructing a tuple than this helper :/

this function is kinda gross :/ suggestions are welcome

A few minor nitpicks, but since we're overhauling boot services it's time we remove [*]MemoryDescriptor and []MemoryDescriptor from std.os.uefi, they are never valid because the size of the zig struct is almost never the size of the descriptor the firmware returns.

doesn't make sense to define wrappers for these functions imo

this function is now basically the handleProtocol function

afaict this was a bug 😬 exit_data.len for number of u16s but the spec says it's the number of bytes

i feel like this is ready for a final review :) i haven't tried it with my own project yet though, i'll tackle that later

really feels like [*:null]*anyopaque should work :(

haven't forgotten or abandoned this, I'm dealing with immigration stuffs :) I'll pick it up again soon

ok i may have gone a little overboard with 7372d65 so i partly reverted it in 04e3728 to keep the number of files in the diff small :) those align(8)s aren't an error or anything, they're just unnecessary now :)

otherwise the rest of the PR comments have been addressed!

I decided to not keep this as *const opaque{} since it might be nice to have the namespace eventually? idk

I actually feel like it'd be handy to do that for Event eventually 🙃

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

ah sorry i think i rebased and didn't mean to push the rebase 😅

here's the changes link for commits from last night: https://github.com/ziglang/zig/pull/23441/files/13858228112d8ee6798dd51032728f68c512bc5f..d37be4284b844684cd1f39b2fd543d8003dcb348

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

decided to include a pattern that i've been experimenting with in another PR i'm working on for std.elf, wdyt?

1. define IntFittingRange for the relevant value range

oh wait the start should be 0 😅 and the end should be _start - _end 😅

_end - _start *

2. function for constructing such values ie pub const my_invalid: MemoryType = .invalid(0x2);

Why are we constructing invalid memory types?

3. function for retrieving the value relative to the range's start

IMO, it is also a good idea to use _allocatePage in pool_allocator if alignment is 4096, as _allocatePool is slow.

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

I don't have an exact source to back this up, but testing on some hardware I have available I found that allocatePage is significantly slower than allocatePool.

rebased to latest master :)

Did another full review, I have only nitpicks left. Tested locally against a small UEFI app - not nearly exhaustive, but builds. Happy to merge after this!

^ tried to rebase on latest master but the diff got nasty, i'll merge. reverted the rebase-push

CI is failing

yup, just saw that lol, looking into it now

Thanks for your patience with this! Let's merge 🎉

LFG, glad to see this. I hope we can get #22226 next. I'll rebase it tonight after work, feel free to review.

[dotcarmen]

this PR updates BootServices and RuntimeServices to an idiomatic interface similar to the pattern used in std.os.uefi.protocol. Part of my crusade towards making std.os.uefi more idiomatic

@linusg

another-one.png

It is appreciated! :^)

Not a thorough review, LGTM at a high level

i figured it's safer to obscure map_key values since as far as i can tell it's meant to be assigned by the system (only retrievable via getMemoryMap)

i couldn't find an easier way to manage dynamically constructing a tuple than this helper :/

this function is kinda gross :/ suggestions are welcome

A few minor nitpicks, but since we're overhauling boot services it's time we remove [*]MemoryDescriptor and []MemoryDescriptor from std.os.uefi, they are never valid because the size of the zig struct is almost never the size of the descriptor the firmware returns.

doesn't make sense to define wrappers for these functions imo

this function is now basically the handleProtocol function

afaict this was a bug 😬 exit_data.len for number of u16s but the spec says it's the number of bytes

i feel like this is ready for a final review :) i haven't tried it with my own project yet though, i'll tackle that later

really feels like [*:null]*anyopaque should work :(

haven't forgotten or abandoned this, I'm dealing with immigration stuffs :) I'll pick it up again soon

ok i may have gone a little overboard with 7372d65 so i partly reverted it in 04e3728 to keep the number of files in the diff small :) those align(8)s aren't an error or anything, they're just unnecessary now :)

otherwise the rest of the PR comments have been addressed!

I decided to not keep this as *const opaque{} since it might be nice to have the namespace eventually? idk

I actually feel like it'd be handy to do that for Event eventually 🙃

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

ah sorry i think i rebased and didn't mean to push the rebase 😅

here's the changes link for commits from last night: https://github.com/ziglang/zig/pull/23441/files/13858228112d8ee6798dd51032728f68c512bc5f..d37be4284b844684cd1f39b2fd543d8003dcb348

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

decided to include a pattern that i've been experimenting with in another PR i'm working on for std.elf, wdyt?

1. define IntFittingRange for the relevant value range

oh wait the start should be 0 😅 and the end should be _start - _end 😅

_end - _start *

2. function for constructing such values ie pub const my_invalid: MemoryType = .invalid(0x2);

Why are we constructing invalid memory types?

3. function for retrieving the value relative to the range's start

IMO, it is also a good idea to use _allocatePage in pool_allocator if alignment is 4096, as _allocatePool is slow.

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

I don't have an exact source to back this up, but testing on some hardware I have available I found that allocatePage is significantly slower than allocatePool.

rebased to latest master :)

Did another full review, I have only nitpicks left. Tested locally against a small UEFI app - not nearly exhaustive, but builds. Happy to merge after this!

^ tried to rebase on latest master but the diff got nasty, i'll merge. reverted the rebase-push

CI is failing

yup, just saw that lol, looking into it now

Thanks for your patience with this! Let's merge 🎉

LFG, glad to see this. I hope we can get #22226 next. I'll rebase it tonight after work, feel free to review.

[dotcarmen]

this PR updates BootServices and RuntimeServices to an idiomatic interface similar to the pattern used in std.os.uefi.protocol. Part of my crusade towards making std.os.uefi more idiomatic

@linusg

another-one.png

It is appreciated! :^)

Not a thorough review, LGTM at a high level

i figured it's safer to obscure map_key values since as far as i can tell it's meant to be assigned by the system (only retrievable via getMemoryMap)

i couldn't find an easier way to manage dynamically constructing a tuple than this helper :/

this function is kinda gross :/ suggestions are welcome

A few minor nitpicks, but since we're overhauling boot services it's time we remove [*]MemoryDescriptor and []MemoryDescriptor from std.os.uefi, they are never valid because the size of the zig struct is almost never the size of the descriptor the firmware returns.

doesn't make sense to define wrappers for these functions imo

this function is now basically the handleProtocol function

afaict this was a bug 😬 exit_data.len for number of u16s but the spec says it's the number of bytes

i feel like this is ready for a final review :) i haven't tried it with my own project yet though, i'll tackle that later

really feels like [*:null]*anyopaque should work :(

haven't forgotten or abandoned this, I'm dealing with immigration stuffs :) I'll pick it up again soon

ok i may have gone a little overboard with 7372d65 so i partly reverted it in 04e3728 to keep the number of files in the diff small :) those align(8)s aren't an error or anything, they're just unnecessary now :)

otherwise the rest of the PR comments have been addressed!

I decided to not keep this as *const opaque{} since it might be nice to have the namespace eventually? idk

I actually feel like it'd be handy to do that for Event eventually 🙃

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

ah sorry i think i rebased and didn't mean to push the rebase 😅

here's the changes link for commits from last night: https://github.com/ziglang/zig/pull/23441/files/13858228112d8ee6798dd51032728f68c512bc5f..d37be4284b844684cd1f39b2fd543d8003dcb348

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

decided to include a pattern that i've been experimenting with in another PR i'm working on for std.elf, wdyt?

1. define IntFittingRange for the relevant value range

oh wait the start should be 0 😅 and the end should be _start - _end 😅

_end - _start *

2. function for constructing such values ie pub const my_invalid: MemoryType = .invalid(0x2);

Why are we constructing invalid memory types?

3. function for retrieving the value relative to the range's start

IMO, it is also a good idea to use _allocatePage in pool_allocator if alignment is 4096, as _allocatePool is slow.

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

I don't have an exact source to back this up, but testing on some hardware I have available I found that allocatePage is significantly slower than allocatePool.

rebased to latest master :)

Did another full review, I have only nitpicks left. Tested locally against a small UEFI app - not nearly exhaustive, but builds. Happy to merge after this!

^ tried to rebase on latest master but the diff got nasty, i'll merge. reverted the rebase-push

CI is failing

yup, just saw that lol, looking into it now

Thanks for your patience with this! Let's merge 🎉

LFG, glad to see this. I hope we can get #22226 next. I'll rebase it tonight after work, feel free to review.

[dotcarmen]

this PR updates BootServices and RuntimeServices to an idiomatic interface similar to the pattern used in std.os.uefi.protocol. Part of my crusade towards making std.os.uefi more idiomatic

@linusg

another-one.png

It is appreciated! :^)

Not a thorough review, LGTM at a high level

i figured it's safer to obscure map_key values since as far as i can tell it's meant to be assigned by the system (only retrievable via getMemoryMap)

i couldn't find an easier way to manage dynamically constructing a tuple than this helper :/

this function is kinda gross :/ suggestions are welcome

A few minor nitpicks, but since we're overhauling boot services it's time we remove [*]MemoryDescriptor and []MemoryDescriptor from std.os.uefi, they are never valid because the size of the zig struct is almost never the size of the descriptor the firmware returns.

doesn't make sense to define wrappers for these functions imo

this function is now basically the handleProtocol function

afaict this was a bug 😬 exit_data.len for number of u16s but the spec says it's the number of bytes

i feel like this is ready for a final review :) i haven't tried it with my own project yet though, i'll tackle that later

really feels like [*:null]*anyopaque should work :(

haven't forgotten or abandoned this, I'm dealing with immigration stuffs :) I'll pick it up again soon

ok i may have gone a little overboard with 7372d65 so i partly reverted it in 04e3728 to keep the number of files in the diff small :) those align(8)s aren't an error or anything, they're just unnecessary now :)

otherwise the rest of the PR comments have been addressed!

I decided to not keep this as *const opaque{} since it might be nice to have the namespace eventually? idk

I actually feel like it'd be handy to do that for Event eventually 🙃

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

ah sorry i think i rebased and didn't mean to push the rebase 😅

here's the changes link for commits from last night: https://github.com/ziglang/zig/pull/23441/files/13858228112d8ee6798dd51032728f68c512bc5f..d37be4284b844684cd1f39b2fd543d8003dcb348

The standard describes an event registration as a VOID*, and the standard provides absolutely no methods to operate on the registration value other than passing around the VOID*, so I say it makes no sense to change this from a *opaque{}.

If for some reason someone finds a good reason to make this a namespace that would be a better time to make this change.

decided to include a pattern that i've been experimenting with in another PR i'm working on for std.elf, wdyt?

1. define IntFittingRange for the relevant value range

oh wait the start should be 0 😅 and the end should be _start - _end 😅

_end - _start *

2. function for constructing such values ie pub const my_invalid: MemoryType = .invalid(0x2);

Why are we constructing invalid memory types?

3. function for retrieving the value relative to the range's start

IMO, it is also a good idea to use _allocatePage in pool_allocator if alignment is 4096, as _allocatePool is slow.

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

Not that that's a bad idea for the special case of exactly 4K alignment, I definitely would need a source to back up that allocatePool is significantly slower than allocatePages on at least a few firmware UEFI implementations

I don't have an exact source to back this up, but testing on some hardware I have available I found that allocatePage is significantly slower than allocatePool.

rebased to latest master :)

Did another full review, I have only nitpicks left. Tested locally against a small UEFI app - not nearly exhaustive, but builds. Happy to merge after this!

^ tried to rebase on latest master but the diff got nasty, i'll merge. reverted the rebase-push

CI is failing

yup, just saw that lol, looking into it now

Thanks for your patience with this! Let's merge 🎉

LFG, glad to see this. I hope we can get #22226 next. I'll rebase it tonight after work, feel free to review.