Limine

[gloomy gulch]

Do we include the limine documentation inside ours?

How should we organize the module layout?

• The current layout is pretty messy with all the requests in the same module.
• We should probably group requests by category, like video, mp, memory, etc
• We might need a miscalaneous module

Do we use cbindgen? And in what way?

• I don't want to add a dependency for users
• The output doesn't let us put UnsafeCell around any of the fields
• It struggles with some of the macro hacks

Can we keep requests consecutive without needing linker support?

• Maybe an hlist

Can we setup a test suite?

[left yarrow]

I don't think bindgen is a good fit for this project

I personally wrote all the structs by hand

I also think we should link to, not include, the Limine documentation

And no, I don't think it's possible to keep requests consecutive without linker support, and I don't think trying to do so is something we should even be expected to do

[tiny monolith]

agreed on all of those

[timber imp]

well, you could construct an API which makes it work

like for example by wrapping all requests in a single top level macro or some such

[left yarrow]

Pragmatic approach would be not to macro the shit out of this. In C you also have to specify a custom section if you want to do that so why would the Rust bindings be special in that?

[timber imp]

its a design choice, and all design choices are equally valid tbh

[tiny monolith]

I'd favor keeping it as it is for the most part

although idk if we need the request start and end markers

in my kernel I just used the linker script to insert them manually

[timber imp]

in C you cant really solve this cleanly with a single big macro though

[gloomy gulch]

Yeah same, but I do think the current Request/Response API is a bit messy

I think I might try architecting a basic API for a few things and send it tonight

@left yarrow did you have any concerns about the 0.5 API?

[left yarrow]

Well that's not how the Limine C headers work and my approach to this is to make the Rust side look much the same as the C side

[gloomy gulch]

I'd prefer the rust side being more idiomatic rust as much as reasonable

[left yarrow]

Main annoyances are structs with dissimilar names, the rest of the differences would just be because of the from scratch rewrite

[left yarrow]

So did I, and I do think that what I wrote is as idiomatic as you can reasonably get without overengineering it to death

Especially since the Limine protocol's having read-only sections changed by the bootloader isn't something Rust understands in the first place

[gloomy gulch]

Yeah I haven't actually tried reading through your API properly yet

[left yarrow]

It does share some similarities with yours, though some names might be different for example

[gloomy gulch]

Hmmm the generic request struct is interesting

It does pollute the API a little, but it also seems a lot nicer than the macro

[gloomy gulch]

I think maybe one macro, containing all the requests for your entire program, and that also does a few extra things (don't have time to detail them right now) might be good, but as an optional feature, or maybe an entirely separate crate

[left yarrow]

Yeah it's the best compromise I could think of because that part is truly shared structure and logic

I agree that it's a bummer it needs to pollute the namespace

To have all the response data structures

[gloomy gulch]

It'd basically be a more restricted but powerful system

[gloomy gulch]

I do have a few ideas, but nothing concrete right now

Anyways I gtg

[left yarrow]

see you!

[gloomy gulch]

I'll try to respond during my lunch break in about 3-4 hours

[left yarrow]

ok

I'll be available then

[timber imp]

do you have to pollute the namespace?

you could only allow accesses through a type like Response<Framebuffer> or w/e

[gloomy gulch]

Oh with a sealed trait would be cool

[timber imp]

or a Request<Framebuffer>+Framebuffer would be better

[left yarrow]

Well I do it with type aliases e.g. HhdmResponse = Response<HhdmRespData> and that means HhdmRespData needs to be publicly visible afaik

[timber imp]

yes but you dont need to do that

[left yarrow]

I mean you could but then you'd have getters for every single field

[timber imp]

is it really that bad though

[timber imp]

you could make it so that all of the request fields are set by a static function

and then the response is the only public thing

[left yarrow]

wdym

the response fields are set by the bootloader

[timber imp]

yeah

from the users pov you can make an api like ```rs
#[link_section = "whatever"]
static FB: Request<Frambuffer> = Framebuffer::request(/* whatever parameters you need for that */);

fn foo() {
let _: Option<&'static Framebuffer> = FB.get();
}

although i think you sort of need to use getters anyway

for soundness

you cant give the user a &'static FramebufferResponse if you dont know that all versions are present

[left yarrow]

You need getters to write it soundly, because you have to store it in an UnsafeCell and do a read_volatile of the pointer itself to get rustc to not optimize it out

[timber imp]

and the versions that are present are only known dynamically

[timber imp]

if you are using read_volatile, you are doing it wrong

like in general tbh

[left yarrow]

This is the only way I can get rustc to not optimize the response field out

[timber imp]

if its in a syncunsafecell?

asm also prevents optimizing it out

or marking it as an export symbol i think

(although that might not work with lto, not sure)

[left yarrow]

It has to be a static not static mut to allow the user to not need unsafe

So you must allow interior mutability

[timber imp]

yeah

[left yarrow]

FWIW both Jason and myself used the same solution: UnsafeCell<*const Response> and then &*response.get().read_volatile()

[timber imp]

you can use global_asm to prevents opts (but i think that also doesnt work with macros)

[timber imp]

this is unsound

[left yarrow]

why

[timber imp]

you either make Response big enough to contain fields for all versions

[left yarrow]

I solved that by having separate getters for the new revisions

[timber imp]

in which case its unsound because a bootloader could be on an older version and allocate the structure right before an allocation boundary or the stack or whatever else

or you make it big enough to contain only the first revision, in which case its unsound because its a stacked borrows violation

under SB, a reference r: &T can only be used to access size_of_val(r) bytes at address &raw const r as usize

[left yarrow]

Example: https://github.com/robotman2412/limine-boot-rust/blob/main/src/request.rs#L201

(IIRC this was the only struct with added fields I found and all other ones only have revision 0 for the response)

Actually modules request has a similar thing. Once again, the response struct itself didn't change but what it points to did.

So no, AFAIK, all of this is sound.

(As far as the Limine protocol can even be sound in Rust memory model but that's unfixable)

[timber imp]

ah yeah i guess that is sound, sure

[timber imp]

well its fixable with the macro thing i proposed (but i get why its not a very enticing solution)

[left yarrow]

I don't like overrelying on macros plus it'd be the fourth rewrite at this point so we must ask ourselves whether we even want to rewrite again?

My opinion at the moment is my code isn't perfect but it works and is the most up-to-date thing we have at the moment

[gloomy gulch]

I don't think the volatile is necessary here, but the unsafe cell is

And fwiw lyly was the one who wrote that

[left yarrow]

If you don't read_volatile then in release mode the response() gets optimized out directly to None

We could try using a SyncUnsafeCell instead thought I fear it may have the same problem

[gloomy gulch]

To justify it we can tell the story that whatever calls the users entry point modified all the structs beforehand

[timber imp]

that imples read_volatile is also unsound

but it papers over the unsoundness

[left yarrow]

Again, why

Remember that the Limine protocol is the inherently unsound part here

[timber imp]

read_volatile is specified to be like read + reading is a side effect

[timber imp]

i dont think thats the case, no

[timber imp]

not read + reading is program input

[left yarrow]

As far as I know, "pessimizing" like this is not unsound

[gloomy gulch]

;asm -Copt-level=3 ```rs
use std::cell::UnsafeCell;
struct Foo(UnsafeCell<i32>);
unsafe impl Sync for Foo {}

static FOO: Foo = Foo(UnsafeCell::new(42));

#[unsafe (no_mangle)]
pub fn get() -> i32 { unsafe {
FOO.0.get().read()
}}

[vapid reef]

Assembly Output

get:
  mov eax, 42
  ret

masterjason9637 | 148ms | rust | rustc 1.94.0 | godbolt.org

[timber imp]

well you need to export the value obviously

[gloomy gulch]

Oh interesting

I feel like this is a misoptimization

[timber imp]

no, why?

[left yarrow]

I think you should make a distinction here between "incorrect" and "unsound" because I think you mean the former, not the latter

[timber imp]

the memory cannot be soundly accssed by anything else

[gloomy gulch]

Hmmm

[timber imp]

well it behaves the way youd want it to, so it is correct in that sense

[gloomy gulch]

Actually I guess it's true that nothing could link against it

[timber imp]

but its UB

[left yarrow]

This right here, by the way, is why I think the protocol itself is unsound

[timber imp]

well no, you can mark it as an export symbol

and then make sure there is some global asm somewhere which could access it

[gloomy gulch]

Okay this needs some more thought

[timber imp]

im not sure if sections count towards this

i would not be surprised if identifier-named sections do count as external access

[left yarrow]

Nothing we've written is UB. The way Limine modifies that field is. You suggest marking it as an export symbol to fix it. Let me just try that (removing the read_volatile in the process)

[timber imp]

read_volatile is UB here

[left yarrow]

No it's not

The write Limine did is

[timber imp]

well yes okay more accurately

undefined behavior occurs at the first AM operation in the entrypoint

[gloomy gulch]

I'd say this is limine being unsound by not loading the elf like it should

[timber imp]

that doesnt make it any better regardless

[gloomy gulch]

Yeah

[timber imp]

actually, idea

[gloomy gulch]

We need some way to pass the symbol outside the am before any execution

[timber imp]

could you make it so that the crate has a feature for each request

[left yarrow]

Ok stupid idea but: remove read_volatile and add an unsafe function that lets you write the pointer. Will rustc then respect what I want?

[timber imp]

if its exported

and the address of the object itself has to be exported too

so basically no

[gloomy gulch]

Yeah that method isn't useful

We really just need global_asm!("", sym FOO);

[timber imp]

i think this would work

or a macro

[gloomy gulch]

But that means we need to control the static definition

[gloomy gulch]

Or make this a sundress requirement for the new function

And it make it unsafe

[left yarrow]

The answer is no

[timber imp]

yeah obviously

you would be lucky for that function to even get codegened

[left yarrow]

So you mean to tell me the only technically correct way of doing this basically requires the user instantiate a bunch of macros

[timber imp]

or use features

or define it in inline asm and do linkonce crap

[left yarrow]

Well either way it seems impossible to encode in the type alone in a way the compiler will respect

[left yarrow]

You mean we instead basically put all the requests inside the crate's data instead, where we can control their symbols better

[timber imp]

yeah and then globalasm

[left yarrow]

So you would instead enable e.g. the mp feature for example and get it by doing limine::request::MpRequest::get() or something

I can confirm using global_asm works (though I'm still not sure this is how the language would intend you to do this kind of thing)

[left yarrow]

Namely, I would expect an attribute or something to mark a symbol as "must be exported"

But this is not a thing

As far as I know, the actual correct way is to do #[unsafe(no_mangle)] (because that forces symbols to be exported)

[left yarrow]

I am in favor of doing #[unsafe(no_mangle)] from inside the crate-owns-the-requests solution. Then crate-owns-the-requests thing also lets us pack them neatly into a section (maybe .rodata.__limine_requests or something?)

But all these sweeping changes would be for a version 0.7.x of the crate

For now we still need to reconcile two separate trees of stuff (rebase?)

[gloomy gulch]

Yes, but then then creating a new request requires unsafe, to make the user promise to export the symbol

[left yarrow]

thus why we should do this combined with the requests being features of the crate like @timber imp suggested

[gloomy gulch]

So the symbol is defined inside the library?

Then how does the user choose the initial value?

[left yarrow]

oh right

This wouldn't work for stuff like the stack request

[gloomy gulch]

I think we have to do macros then

[dark beacon]

@floral plover what would be the sensible thing to do in case there's no EDID for picking a video mode? Just go with the highest res offered?

right now i assume native res is something like 1280 or whatever

but that fails on tiny screens that offer like 1 res

How does limine handle it

[timber imp]

dont go with the highest res

if a mode is already set, then you can keep using that mode obviously

if the user asked for a specific one, you can also just use that

[dark beacon]

nah that's not possible on bios

[timber imp]

oh on bios can you not enumerate what is supported?

[dark beacon]

it sets text mode by default

[timber imp]

oh right you start in text mode lol

me dumb

[dark beacon]

yes, thats exactly what im saying

[timber imp]

if you use the highest res mode its very easy to enter a mode which isnt supported by the display afaik

[dark beacon]

im not sure its safe to just pick the biggest offered mode

[timber imp]

the best strategy is to choose the mode which offers the best display performance metric calculated at max(height*256/width, width*256/height)/max(bit_depth, 1)

[dark beacon]

currently i just fallback to assuming a tiny res and set that

[timber imp]

probably the safest thing to do tbh

i think like 640x480 is safe

[dark beacon]

but sometimes even that tiny res is not enough

[timber imp]

also wdym not enough

[dark beacon]

its too big

[timber imp]

ah

[dark beacon]

i assume 2x of that i think

[timber imp]

surely you have 640x480 though

[timber imp]

well yeah thats a lot less safe

[dark beacon]

iirc the laptop im doing this workaround for offers exactly 1 mode

so maybe just pick the one then

[timber imp]

well if you only have one mode just pick the one available mode lol

can picking a mode fail?

[dark beacon]

i dont have it unfortunately to verify that

[dark beacon]

yeah

[timber imp]

you could try picking random modes to see if they work but that sounds really slow

[dark beacon]

yeah, or even wrose it succeeds in setting it

https://en.wikipedia.org/wiki/Asus_Eee_PC

this one

@eternal plaza do u happen to remeber if your laptop offers just one video mode or multiple?

[eternal plaza]

I think it was something cursed

No

[dark beacon]

it's 1024 by 600 or something

[eternal plaza]

I can ask my friend although I don't even know how to check it

yeah, 600 by 800???

Wait

[dark beacon]

i can give u a build of my bootloader that dumps available resolutions

[eternal plaza]

I also had a AMD A10 PC which broke some bootloader

with a 4K 30 monitor

Either limine or hyper

[dark beacon]

broke how?

[dark beacon]

oh yeah that

absolutely insane res

[eternal plaza]

I don't remember

Like "no video mode available" kind of thing or something

I don't remember

[dark beacon]

hm yeah idk

[eternal plaza]

Something non-standard

[dark beacon]

i should just buy that laptop

also sometimes the framebuffer can be very high in memory and i dont map it explicitly right now which may be what killed obos

and the proto doesnt really specify that its mapped so its obos L anyway but yeah

[eternal plaza]

pmos wouldn't be affected because it maps framebuffer in userspace, at which point the kernel doesn't care where it is in memory

[north hollow]

i have one of these too!

[eternal plaza]

btw, who else uses hyper, besides us?

[dark beacon]

i've kind of abandoned it for a bit but im coming back to fix some stuff now

including the protocol

[eternal plaza]

you could run pmos on it, now that I almost have a reliable build system

[modern flume]

add hyper to the zag build system and I will use it

[dark beacon]

how do u do that

[modern flume]

idk, idk how hyper works

[dark beacon]

can u run my stuff on it if i give u a video mode dumper?

[modern flume]

but it'd be a matter of just creating an image with hyper in it lol

[north hollow]

My usb stick is MIA rn

🥀

But when I find it il let you know

[dark beacon]

similar to limine

[north hollow]

The laptop is in my closet rn

[dark beacon]

sure

[floral plover]

i default to 1024x768 -> 800x600 -> 640x480 if there is no edid, in that order, until one succeed, else, fail

[dark beacon]

oh cool

that makes sense

[dark beacon]

the reason u made bootservicesdata loader reclaimable is because acpi is sometimes in there right?

[floral plover]

some tables point to memory in there, most notably the BGRT

[dark beacon]

right lol

I wonder how big bootservices stuff is usually

[dark beacon]

@floral plover btw i dont know if u still do the removable vs non-removable check on BIOS, but the EDD trick seems to have regressed on latest VMWare

it no longer does v2 params so there's no EDD

the only workaround i can think of is special casing block_size = 2048

VMCrapBIOS

Ah actually it appears this behavior changes as you change the guest os mode: Ubuntu 64-bit hides EDD, Other 64-bit enables it

this stuff

basically this is what I came up with

Also the bios is so shit that even if you insert multiple ATAPI drives only one is actually shown by the BIOS

Actually if that's the case i can just hardcode if drive_index == 0x9F

btw all of this is an even bigger workaround for this

[north hollow]

[dark beacon]

okay that looks better

I wonder if maybe it's worth just checking cpuid for hypervisor also in this case and completely disabling this logic of drive validation

interesting, grub seems to be using this

to detect which drive is a cdrom

[north hollow]

You could also check directly if it’s VMware from the string too and skip only there

[dark beacon]

the hypervisor id u mean?

[north hollow]

Yes

IIRC they give a string/id right?

[dark beacon]

yeah, although im not sure if it's possible to disable paravirt for guest or hide that id

may be possible

[north hollow]

If the user is hiding that they are probably hiding the hypervisor bit in general so atp there isn’t much can be done in terms of detecting this bug other than always allowing it / probing the drive it’s self?

[dark beacon]

Yeah maybe

[dark beacon]

But anyway this thing works for detecting boot CD drives, from there u can technically just infer that its a removable drive

[floral plover]

it also limits itself to drives below 0xf0 now since @fresh nimbus reported that it wouldn't work on a random machine of his and that fix was the only thing i could figure out to make it work

this is how the removability of a drive is determined

[dark beacon]

Yeah basically this logic won't work on VMware in some cases as I've realized

The below 0xf is news to me tho

@fresh nimbus do you remember why it has to be below 0xf?

[fresh nimbus]

Fuck if I know. I think we did trial and error lmao

[dark beacon]

Was it like hanging?

[left yarrow]

Hardware quirks 👍

[dark beacon]

@floral plover This is what grub does btw:

• Check 0x00, 0x01 for floppies
• Only look at 0x80 - 0x90 for hard disks
• For cdrom there is only one: you probe it via int13, 4B01h (grub only allows cd0 for this reason)

The above is how it implements iteration of all disks

If you want to open a specific disk it allows to specify e.g. hdXX so u can technically bypass the 0x90 limit and open a cd disk by doing e.g. hd96 on QEMU

maybe this is the sensible way to do it

[dark beacon]

@fresh nimbus pretty please do u remember how the bug was manifesting itself? Like hang or crash? Also, which laptop was it

[floral plover]

the GRUB way doesn't necessarily mean the sensible way

[floral plover]

how about this, the same as it is right now but assume any drive outside the 0x80-0x90 range cannot be a fixed disk and must be removable/optical

but wait, that one bug may make this harder because then you don't know which one is a "fake hard disk" and which one is a real optical drive

[dark beacon]

Yeah lol

Or we can keep the logic as is and add a special case for the drive returned by 4b01

Since we know for sure its a CD

[floral plover]

yeah that's reasonable

[dark beacon]

For some reason 4b01 takes in an input drive, which is unused from what I've seen from testing on VMware and looking at seabios source

Also I have not yet tested if VMware still reports 4b01 if booted from a hard drive

If it doesn't that would be sad

This shit is a mess lol

[floral plover]

yeah that's what i was thinking as well

because it says "bootable"

[dark beacon]

Yep

Seabios stops reporting it if booted from a hard drive

[floral plover]

ok so basically GRUB cannot boot off of a CD if it booted from a hard drive

[dark beacon]

Yep

Or it can if you specify the CD as a hard drive instead via hdXX

[floral plover]

but that's only if it's within the 80-90 range, no?

which most likely it won't be

[dark beacon]

The range is only for iteration, which is used in ls commands etc

HdXX allows u to just open arbitrary drives

[floral plover]

well that's fucking stupid lol

[dark beacon]

It is

But yeah ls doesn't report CD if booted via hd

[floral plover]

it's such an odd scenario that i don't think it matters that much if on e.g. vmware or other quirky BIOSes like that it won't work

so i think adding the 4b01 exception on top of what we already have is reasonable for CD boot, and that's that

[dark beacon]

Another thing we could do is just check the hypervisor bit in cpuid and disable this validation logic in that case

[floral plover]

but that's a weird heuristic imo

[dark beacon]

Maybe

[floral plover]

because hypervisor doesn't mean that it couldn't theoretically have the same BIOS bug as that one compaq i guess

[dark beacon]

Since VMware bios hardcodes CD at 9F and its always the single CD it ever reports we could also just special case that specific index

Since the bug only exists on VMware

[floral plover]

yes but at that point that's just a worse version of getting the drive via 4b01 and using that to determine which index to except

[dark beacon]

Well no because remember 4b01 doesn't report anything if u have a CD but didn't boot via it

So technically e.g. limine wouldn't allow booting off of CD if booted via hard disk

On VMware

[floral plover]

as i said, it's such a quirky scenario that i am okay with that not working on specific firmware

[dark beacon]

Maybe

But its a VMware specific workaround anyway, so why not cover all edge cases

[floral plover]

and by getting the drive to except from 4b01 you can also guarantee that it is in fact optical media

by excepting 0x9f hardcoded then you either have to guess that it's a CD, or you have to trust the broken detection that will tell you it's not on vmware

[dark beacon]

9F + no EDD + sector size 2048 is a pretty good guess imo

[floral plover]

yeah tbf

i forgot the sector size

[dark beacon]

Yeah maybe that's what we should do

[floral plover]

god i hate ts ngl

[dark beacon]

Lmao

[floral plover]

not the workaround, i mean the bugs

[dark beacon]

Yeah

Its crazy how sloppy they manage to make this firmware stuff

[elfin shard]

this is an unrelated thing but can there be some kind of way to have the config editor enabled even with secure boot enabled? it sounds annoying that I'd have to disable secure boot if I want to temporarily adjust the kernel cmdline/the kernel itself (though that also has the issue of needing the hash) if I break something

[floral plover]

temporarily do your changes before enabling secure boot at once?

i.e. only enable secure boot once you know things work, plus, if you must, going in the BIOS and disabling secure boot to get the machine to boot and make your changes isn't that big of a deal

[elfin shard]

well yeah ig but sometimes I want to do stuff like blacklist a gpu driver for one boot if I want to do a passthrough to qemu without needing to have a separate menu entry for it (though I do realize that this probably isn't a very common thing to want, I also don't really care about the security part of secure boot so I don't have config hash/kernel hashes rn)

[floral plover]

https://codeberg.org/Limine/Limine/commit/3b7c85ff7142a1317f2d12e339bd7664b0922bd1

[dark beacon]

Yeah adding the same one

[fresh nimbus]

I think it was hanging and idr which box it was on

[dark beacon]

[modern mortar]

Older versions of my trace screen printed these sizes, i have some on screenshots (the numbers are hexadecimal and in pages, the first is bs code, then bs data, then reserved):

opi5, edk2
714
3937
1b70

hp probook 4530s
846
7436
800

pinetab2, uboot
3155
10019
1fa4

pine book pro, uboot
38fa
14
7e9

What do you mean by "loader reclaimable"? bs code and data are free after EBS (as per the specification). If something in ACPI points to bs typed memory, it's a bug. Screw that bgrt then.

[dark beacon]

You cant just say screw it

Thats not how it works in the firmware world

[dark beacon]

0x3937 pages?? Isn't that a shit ton

[modern mortar]

It's a vendor logo thing. They must have not put it into boot services data. They violate their own spec.

[modern mortar]

Look at the pinetab number. 😏

[dark beacon]

What does it needs like 200 megs for

[modern mortar]

Have no idea.

And the difference between pt2 and pinebookpro. How?

[floral plover]

5.2.23.4 Image Address
The Image Address contains the location in memory where an in-memory copy of the boot image can be found. The
image should be stored in EfiBootServicesData, allowing the system to reclaim the memory when the image is no
longer needed.

cc @dark beacon

it's not a firmware quirk/spec violation - the spec itself says it is going to be there (ACPI spec)

[dark beacon]

yeah i already made the patch to count that stuff as reclaimable

as for how the fuck it makes sense if BGRT is something you use after you exit boot services that escapes me

[modern mortar]

That's funny, especially given there is EfiAcpiReclaim type for exactly that. What you quoted is against the UEFI spec, since it says, that all memory typed as boot services is free after EBS. Now, good luck for all the OS developers with early init that sincerely believed at this stage all bs typed memory is free.

[floral plover]

ok then the ACPI spec is against the UEFI spec, do i care? not really

literally 100% of machines i have encountered with a BGRT place it in EfiBootServicesData

[modern mortar]

It seems they got lost between 3 pine trees.

[brisk wind]

???

[floral plover]

lol what

[eternal shell]

what does that even mean

[modern mortar]

I mean ACPI contradicts UEFI. That is a Ukrainian saying for such a situation. I don't know how I will handle this bgrt nonsense. Currently, I don't use it. But why they couldn't use EfiAcpiReclaim type? Didn't they see the word "Acpi"? In conjunction with "Reclaim"? Didn't they read the UEFI spec?

[floral plover]

i see

[dark beacon]

i mean havent u seen aml

its hard to come up with a less competent bytecode

like literally even if u wanted to make it worse it would be really hard

[floral plover]

@dark beacon wanna see something idiotic?

https://github.com/Limine-Bootloader/Limine/commit/c871e24388e8919507d892dcd42a623d1ffa6e2c

[dark beacon]

Lol

How did you find out about it

[floral plover]

someone on CachyOS complained about how when booting with Limine the iGPU is no longer available on certain Macs

so i asked Claude if it had any idea, and to do some research, and it found out that this is apparently something that EFISTUB does

[dark beacon]

So without this it just shuts the GPU down after ebs?

[floral plover]

yeah

apparently

i didn't have the person test it yet because they reply once in a while

[dark beacon]

What the fuck

[floral plover]

yeah

[dark beacon]

Mandatory vendor specific interface is funny

[modern flume]

Bruh why is limine back on GitHub

[north hollow]

#1384888317597974600 message

Mint replied here about this

[tribal lagoon]

can't wait for it to move back to codeberg

[eternal shell]

tldr shit reliability and a ton of virtue signalers demonizing the project because of one claude commit

[modern flume]

Those guys are idiots

[floral plover]

tbf the shit reliability plays a BIG role

[eternal shell]

almost every time i wanted to access something it was dead

[north hollow]

Codeberg and gnu servers are having a race to the bottom

[eternal shell]

you also get less contributions

[worthy vapor]

Soon itll move to gitlab or some shit

[north hollow]

or my git server

it has good uptime

[floral plover]

that too, true

[eternal shell]

with all due respect, it also doesn't have any users

[north hollow]

I know I’m just joking

I think I have a mirror there

Because code berg was so ass

I needed somthing that actualy worked

[eternal shell]

i mean

i have my own as well

https://git.mrvn.sh

[north hollow]

Waow based

Forgejo really needs to get federation working good soon

That would fix a lot of the issues with smaller servers

[floral plover]

Evalyn's based for self hosting ngl

for your own projects that don't have or aim to have a big userbase, it's nice

for something like Limine it would be kinda hard, even if i wanted to, sadly

but if that federated sort of gitea thing becomes a reality it would make this much more feasible

oh yeah you already mentioned it, mb

[north hollow]

I self host as much crap as I can

It’s really nice

[north hollow]

Limine on Evalyn git when federation is up ?

I use two laptop hard drives I salvaged in a mirrored raid

So it’s pretty redundant

And the CPU has thermal paste inside the socket for extra cooling

[floral plover]

as a mirror, sure. but given that i just moved back to GitHub it'd be pretty insane to move again

[north hollow]

My server supports pull mirrors

Infact I’m pretty sure I already have one setup for Limine when codeberg was dying

[floral plover]

oh then you can already mirror it if you want :p

[north hollow]

Forgejo is pretty nice tho

Sad codeberg has to have these issues

[eternal plaza]

Why not host on gitlab in the first place?

[limber bear]

gitlab sucks

[ancient cedar]

LBML (Limine Biotloader Mailing List) when?

[brisk root]

Nah GNU is way lower

[modern flume]

I don't see the appeal of gitea for your own stuff

Use cgit

Way cooler

[eternal shell]

why?

cgit is useless

you get issue trackers, prs, project boards, actions, etc

and a nice webui

[north hollow]

I like forgejo better than gitea personally

Especially since gitea uses AI art

[modern flume]

Gitea has way too many features that you don't need if you're one person

[north hollow]

What if you want a friend or two to make a PR or some crap

Not like it’s crazy heavy anyways

[modern flume]

They send you a patch via mail

[brisk root]

It's literally so simple lmfao

git format-patch and then add them as attachments to the email

Or upload them via discord

[eternal shell]

ew

[eternal shell]

it's so simple that nobody ever fucking does that

i hate mailing list patches

[brisk root]

Because having another way to do it indicates preference for that way unless otherwise given

If my primary method of accepting patches is a mailing list, but you send me a GitHub/Codeberg/Gitea/Gitlab PR, I'm rightfully going to be a bit annoyed

[eternal shell]

ok

i think mailing lists are chaos for big projects

[brisk root]

Ok

I disagree

[ancient cedar]

this, I used to use this when my home server working (its fucked now)

[modern flume]

There's git send-mail even

[modern flume]

Literally the biggest open source project ever does it lol

[eternal shell]

yeah and it's aids

[brisk root]

yeah but you have to have a mail client properly configured on your machine and most people don't

[modern flume]

No I do it via gmail

[modern flume]

I'm curious to hear your arguments

[eternal shell]

idk i'm looking at it from an outside perspective and don't understand how people can properly track patches

[modern flume]

Like sure it's a bit more work than just pressing merge

But it works

[eternal shell]

i mean like collaborations on PRs for examples
on github you can easily see the final diff, inline comments, normal comments, etc

sure it works, but it's not very ergonomic

[modern flume]

You can easily just look at the patch

It works everywhere a mail client works

It's very simple and not centralized

[eternal shell]

that wasn't even my argument

all the features github and derivates have exist for a reason

otherwise everyone would be using mailing lists

linux only uses it because that's what they always have been using

[tribal lagoon]

[modern flume]

They exist and are popular because they're dumbed down

[eternal shell]

dumbed down = easy to understand

no need to complicate it

[north hollow]

easier / more user friendly != dumbed downed

[eternal shell]

just call me a newgen 💀

[modern flume]

well in this case yes

[north hollow]

it does the same thing in a more organized way. it dosnt reduce feature sets

[modern flume]

It literally does

There are cases where GitHub gives up and just gives you commands to run lol

Idk I'm not against GitHub or anything, I like to work with it better, but calling mailing lists "aids" is a literal skill issue

[lunar jackal]

when in the build process does this get filled with real data?

or does it just never get?

[left yarrow]

I don't think it does; Limine requires a partition table for bios-install, and this BPB would be in the first sector--but the actual FAT filesystem starts elsewhere.

[gloomy gulch]

@bold thorn @left yarrow
I've been thinking about how to structure the request API macro (which is required for soundness) and these are my two ideas:

Option 1

request!{
    static FOO: FooRequest = FooRequest::new(123);
}

// Expansion
{
    const TMP: FooConfig = { FooRequest::new(123) };
    static FOO: FooRequest = unsafe { TMP.build() };
    global_asm!("/* {0} */", sym FOO);
}

Option 2

static FOO: &FooRequest = foo_request!(123);

// Expansion
static FOO: &FooRequest = {
    const ARG1: i32 = { 123 };
    static TMP: FooRequest = unsafe { FooRequest::new(ARG1) };
    global_asm!("/* {0} */", sym TMP);
    &TMP
};

I was wondering what you guys thought

@tiny monolith sorry lyssie

[left yarrow]

Would vouch for option 1, with the additional suggestion that we make it an array kinda deal (i.e. requests! and you can put all of them in there)

[gloomy gulch]

Yeah, kinda like a thread local macro

[left yarrow]

I do see, however, that with how it is currently written, you will need to do proc macros to expand it correctly

[gloomy gulch]

Why?

[left yarrow]

Because of the const TMP: FooConfig bit

I don't know of a way to imply a type in this manner.

Maybe we could say

impl FooRequest {
     pub type Config = ...;
}

And use const TMP: FooRequest::Config = ... instead

Now you can just use the type name passed in the macro

[gloomy gulch]

Or make this the expansion

{
    static FOO: FooRequest = const { 
        let cfg = FooRequest::new(123);
        unsafe { $crate::build_request(cfg) }
    };
    global_asm!("/* {0} */", sym FOO);
}

Rely on type inferrence

[left yarrow]

What do you want to use the builder pattern for here, anyway? Why doesn't more direct initialization suffice?

To enforce use of the macro?

[gloomy gulch]

Yes

[left yarrow]

hmm

[gloomy gulch]

Without the global_asm!, inserting the magic numbers into the binary is unsound

[left yarrow]

we could argue about where but yes

[lunar jackal]

I like iption 1 more

[lunar jackal]

But where would the partition table be?

[left yarrow]

For GPT, that starts at sector 1

And a copy at the end of the disk

[left yarrow]

I'm concerned a beginner that doesn't check the README would try FooRequest::new and not get why it doesn't work

[north hollow]

Or just anyone checking out the crate and assuming the crate is self explanatory enough to just use whatever

This sounds like a mistake I’d make

[gloomy gulch]

I well if they check the docs for the new function, or Config type, it'll tell them exactly what to do

But maybe there's a better way

[left yarrow]

I argue the call to FooRequest::new should be impossible to do by accident, but I can't think of a way to strictly enforce this, because $crate::some_function is the only sound way to do what we need from the macro

[gloomy gulch]

There's option 2

[north hollow]

I personally think where possible somthing shouldn’t be confusing enough to need that. Especially where it’s that easy to fumble.
Just my two cents though

[gloomy gulch]

static FOO: &FooRequest = foo_request!(123);

// Expansion
static FOO: &FooRequest = {
    const ARG1: i32 = { 123 };
    static TMP: FooRequest = unsafe { FooRequest::new(ARG1) };
    global_asm!("/* {0} */", sym TMP);
    &TMP
};

[left yarrow]

While true, this will mean we need to make one macro per request, which all have largely similar content

Even if that's just calling a second helper macro that does all the actual work

[gloomy gulch]

What about a request macro that takes a config?

[left yarrow]

please elaborate

[gloomy gulch]

static FOO: &FooRequest = request!(FooConfig::new(123));

// Expansion
static FOO: &FooRequest = {
    static TMP: FooRequest = const {
        let cfg = { FooConfig::new(123) };
        unsafe { $crate::build_request(cfg) };
    };
    global_asm!("/* {0} */", sym TMP);
    &TMP
};

[left yarrow]

Now we're talking

[gloomy gulch]

Hmm we do need some way to pass linker section info into the macro though

[left yarrow]

Though we should again be weary of the inability to imply the type of TMP here

Unless we make it not quite an actual expression, the FooConfig is not something I know a way to extract from the macro parameters, and therefor we can't do a FooConfig::Request type

[gloomy gulch]

Maybe <FooConfig as $crate::Config>::Request would work as the type?

Oh you're right

Can we export a symbol from global_asm somehow? nvm that won't work for other reasons

[left yarrow]

Well that would be what we wanted to do, but I don't think there's a typeof in Rust, is there?

[gloomy gulch]

Technically there is, but it's only used in error messages

So no

[left yarrow]

Yeah because you would need a typeof operator but Rust doesn't have one

Let me try some stuff on godbolt

[gloomy gulch]

What about request!(Foo, 123)?

[left yarrow]

That's easy

[gloomy gulch]

Yeah but is that a good api?

[left yarrow]

No

It's definitely less readable

[gloomy gulch]

I think option 1 is probably the only way that would work

[left yarrow]

YEah

But we should introduce a trait bound on that build call

So that we don't allow someone to hide an unsafe operation through this

[gloomy gulch]

Yeah to get good error messages

[left yarrow]

that also

[gloomy gulch]

Exactly

[left yarrow]

I do thing we need to change how that's written just a tiny bit

Because it calls a different function than it seems with the operands given

Actually

I know what to do

[gloomy gulch]

Oh wait trait's aren't const

Uh I have an idea

[left yarrow]

request!{
    static FOO: FooRequest = FooRequest::new(123);
}

// Expansion
{
    static FOO: FooRequest = unsafe { <FooRequest as Request>::new(123) };
    global_asm!("/* {0} */", sym FOO);
}

[left yarrow]

crud

True

[left yarrow]

This would be perfect but it needs nightly Rust

Because nightly allows const in traits now

@gloomy gulch https://godbolt.org/z/3EYYa5Kxh

This is a bit hacky, but it enforces the trait bound

While still allowing the const function

[gloomy gulch]

How do you make a macro to parse that

[left yarrow]

https://godbolt.org/z/GG6ejeEr1

This is the best I can come up with so far

Since Request is an unsafe trait, we won't accidentally hide an unsafe in request!

The unused let allows the trait bound to be enforced

Least hacky solution so far, with proof of concept

Perhaps we should make a post for limine-rs specifically

So we don't drown the users here in impl details

[gloomy gulch]

Here's mine https://godbolt.org/z/Kzn1K566r

[left yarrow]

The main reason I don't like your way is because it seems as if FooRequest::new returns something else than it actually does

[gloomy gulch]

We could make it ```rs
limine::requests! {
static FOO: limine::FooRequest = FooConfig::new(123);
}

[left yarrow]

That's worse

[gloomy gulch]

wait nvm

[left yarrow]

ehh

hmm

My way can still hide unsafe code

If someone makes init {something_naughty; FooRequest::new(123)}

Though I suppose I could more rigidly enforce it by making that match as $Type2:ident :: new ( $($init:expr),* )

Then no problem

[gloomy gulch]

FooRequest::new({something_naughty; 123})

[left yarrow]

ts just keeps on going

[gloomy gulch]

The unsafe block must not contain any user expr

[left yarrow]

no untrusted ones, anyway

yeah no user expr

Makes me wish you could put a safe {} block in an unsafe {} one

Do any requests need multipl args? I think not, right?

Then again I'm not about to make every other request take exactly one...

[gloomy gulch]

Maybe we could make an unsafe fill_magic method, but that means you can use it incorrectly and not get a compile error

[left yarrow]

ehh

We should just do your way

I can't think of anything better

And internally, to avoid repetition, we should have another macro for defining a request type

(said macro needs to be at pub(crate) visibility)

[floral plover]

it's a workaround for quirky BIOSes

@left yarrow there is a new request and i made the IOMMU request x86-64-only because reasons

in terms of recent spec changes

the latter is just an API change mind you

and the new request is the TSC frequency request

[left yarrow]

Well it was already effectively x86-64-only anyway, doesn't really affect it much; it already documented the fact that that doesn't do anything for the other archs

I'll do some updatey business sometime this weekend i think

[north hollow]

What does this request report on systems with variant TSC I wonder? Or does it just not give a response at all

[floral plover]

it does, it's just going to be incorrect through power state transitions

maybe i should've made it such that it didn't on variant TSC systems

[north hollow]

Maybe add a flag that says it’s variant? Though you can just check CPUID

It’s good either way imo to have the benchmark since it may be more accurate

[floral plover]

yeah a flag would just be redundant

that was my initial reasoning for always providing it

that the kernel would be smart enough to check the invariant flag itself

[north hollow]

Nice feature though ty

[floral plover]

np

[lunar jackal]

Oh i thought that stage2 did that

[dark beacon]

What's the iommu request

[dark beacon]

Btw its not as simple, it may be constant but not invariant

There isn't a flag to check if its constant

And likely it is still constant even if the invariant flag is not set

[dark beacon]

It can still be useful in this case

[dark beacon]

Unless this is like an incredibly old cpu

Im not even sure its a thing in amd64

[limber bear]

limine disables iommus on x86-64 when booting limine kernels, unless you request for them to be left in whatever state the firmware configured them

[dark beacon]

there are x86 systems that have iommu on by default in non-passthrough?

[limber bear]

¯_(ツ)_/¯

[floral plover]

yes but it's not very common (yet)

[floral plover]

not just Limine kernels, it also disables them for multiboot kernels

it only leaves them as-is for Linux since that should know how to deal with them (though tbf that should be dependent on Linux kernel version, but that check is missing)

and well, for chainloading, but that's a given

[eternal plaza]

This reminds me of ACPI OS checks...

[left yarrow]

just nuke all computers at this point

none of them make any sense

[brisk wind]

computers were a mistake, return to monke

[eternal plaza]

I think if you're running ancient Linux versions on new hardware, it's your fault

Like what about the other operating systems that use Linux protocol?

[floral plover]

Limine new look, yay or nay?

consider i've done most of this to more gracefully handle portrait displays like phones

[timber imp]

idk if i like the font

does limine handle unicode properly now?

[uncut quartz]

font is ugly

[timber imp]

why not have a properly antialiased font? i know its more effort but its also much nicer visually

[dark beacon]

Yeah not a fan of the font

[floral plover]

alright i wasn't sure about the font either

what about the layout though?

[timber imp]

layout is fine

[uncut quartz]

i like cat

[floral plover]

same

[floral plover]

i actually prefer bitmap fonts but whatever

[timber imp]

a bitmap font is strictly inferior since you can always losslessly convert a bitmap font to a grayscale font, but the converse is not true

[floral plover]

i meant the looks, you know what i mean

also talk is cheap send patches

[frosty geyser]

when will we be able to change the font colours of the boot menu

[timber imp]

nah its not like a huge deal you see the screen for half a second

[frosty geyser]

I would like it yellow for my os to match the branding

[floral plover]

interface_help_colour: <whatever>

[dark beacon]

A freetype impl is probably more loc than limine itself

[floral plover]

and a security liability

[frosty geyser]

is that the ARROWS, ENTER? what about the blue title?

[floral plover]

interface_branding_colour you could just check CONFIG.md lol

[frosty geyser]

but that's two colours ...?

[floral plover]

?

[dark beacon]

Documentation is for the weak

[frosty geyser]

but your field is called interface branding colour, singular

there are two colours

[floral plover]

where?

[floral plover]

the branding text is always printed as a single colour

[frosty geyser]

cyan and green

[floral plover]

that's interface_help_colour, i already said it lol

[frosty geyser]

crazy request what if we wanted to change the wording

like if someone wanted to i18n it

[floral plover]

what do you want to change them to?

[frosty geyser]

I don't, personally

just if someone else did, might be a nice feature

like if their os was french for example

you wouldn't want your bootloader in English right? and you don't what to have to handle translations

[floral plover]

i guess

i mean i am not against localisation in principle

it's more of a talk is cheap send patches kind of situation

[frosty geyser]

what format are those strings? printf specifier with ansi?

[dark beacon]

What about the white text, like the rest of the ui

[floral plover]

there is no way to change that atm

[dark beacon]

Ah

[floral plover]

well

except changing the full palette that is

which you can do

[frosty geyser]

hmm that might be easier to implement

it's just flanterm right?

[floral plover]

yeah

[frosty geyser]

I'm still on limine 9, any big breaking changes on x86_64 between 9 and 12?

[floral plover]

hm

not when it comes to the protocol itself

new features sure, but the protocol is backwards compatible all the way to base revision 0 still

[frosty geyser]

nice, I might upgrade later

[dark beacon]

Didn't you strip support for most old revisions

[frosty geyser]

you did introduce breaking changes before e.g. different config format and didn't you remove limine terminal?

[floral plover]

for 1 version before people complained and i figured the amount of code needed to support them wasn't that much so i readded them

at least for everything except aarch64

which is still base rev 6 only

[floral plover]

the config format isn't part of the protocol, and yeah i removed the Limine terminal a while back, but that wasn't a base protocol breaking change, it was just dropping support for 1 feature granularily

[timber imp]

you can just take a grayscale version of the current font data

and then you dont have an issue

other than compositing etc etc

[lunar jackal]

Where does Limine have its MBR code? https://github.com/Limine-Bootloader/Limine/blob/v11.x/stage1/hdd/bootsect.asm

[elfin shard]

wdym?

the file you posted gets assembled to limine-bios-hdd.bin and that can be installed to a device using e.g. the limine host program (or passing the file to xorriso if you are making an iso image using xorriso, though in that case you'd use limine-bios-cd.bin)

[lunar jackal]

Uhhhh

Oh

So it isnt possible like creating an image and then installing limine to it and then dd'ing it to another drive?

[limber bear]

that’s exactly what you’re supposed to do

or, well, you can install limine directly to the drive

[lunar jackal]

but will things like the FAT BPB then be okay? Its cuz i dont' have the option of installing directly to the drive.

[frosty geyser]

if you can't install it to the drive where else would it go

take a look at how limine template works

that doesn't show how to do an installer though. I have a uefi based limine installer in my os but it doesn't play with others, no dual boot or custom partition options

it just rolls a uefi boot partition on top of what's there, based on the one limine-install makes

[lunar jackal]

okay just wanted to verify

be yea

make sense

[limber bear]

well as far as i can tell the bpb is part of the first sector of the disk, limine will overwrite that and provide it's own bpb though

you already linked the exact file that contains the boot sector

[steady turtle]

A beginner question: does the hhdm request map all of physical memory, or just the first 4GiB? I saw somewhere (prolly reddit, def wasn't the clanker) that it was only the first four gigabytes, but most information on the internet seems sorely outdated.

[north hollow]

its defined in the limine protocl spec, it maps a bunch of diffrent parts of the memory mapp and usable memory is included even beyond 4gv

[steady turtle]

Alright. I've read that spec a lot but I always find it bare 🤔 I have a #pf to diagnose and since it happens when allocating the highest available pages in the memmap I just wanted to be sure that it wasn't some dumb thing like that

[north hollow]

https://github.com/Limine-Bootloader/limine-protocol/blob/trunk/PROTOCOL.md#memory-layout-at-entry

for modern versions

[steady turtle]

I see

[north hollow]

and these regions are mapped like this

[steady turtle]

So what I think is probably the culprit is my "assume it'll work if it's contiguous" allocation scheme. Which breaks bc I probably have an error or smth means I'm not allocating enough pages

[north hollow]

you should only ever use ram part of a (usable) region, else its not ram lol

[steady turtle]

😂 yeah

[frosty geyser]

you said nothing really has changed breaking changes wise between 9 and 11?

well you renamed a whole load of the files, changed their naming, which means i have to change all my tooling 🙁

[eternal shell]

who said nothing has breaking changes

it's a new major version

[frosty geyser]

e.g. no more ./limine, its now limine-deploy etc, limine-bios-cd and limine-bios-hdd bins are changed...

[eternal shell]

also, what limine files are you depending on besides limine.h

[frosty geyser]

thats what mint said

theres nothing breaking changed

[eternal shell]

on the bootloader side#

[frosty geyser]

i have my own deploy scripts that build usb images. i dont use the template. my OS is way older than the template.

i also dont expect anyone to be git clone recursive'ing a subproject in

so generally, i just keep these around and update rarely.

brain@neuron:~/limine$ ls ../retrorocket/limine
BOOTX64.EFI  LICENSE  limine  limine-bios-cd.bin  limine-bios-hdd.h  limine-bios-pxe.bin  limine-bios.sys  limine.c  limine.h  limine-uefi-cd.bin  Makefile

once its tested, its ossified

[eternal shell]

are you not pinning a commit?

[frosty geyser]

no, i dont have it as a submodule

i update it when i have need to

[eternal shell]

what

you're confusing me

[frosty geyser]

its not a submodule of my os project

[eternal shell]

ok and

[frosty geyser]

its just a plain old directory

[eternal shell]

you can still pin a commit

[frosty geyser]

i have limine in a separate dir, outside my project, following master. when i have need i pull the latest master, test it and copy the limine binary and sys files over into the limine folder of my os project

[eternal shell]

do not follow trunk

this is a horrible idea

[frosty geyser]

trunk has always been fine for me

[eternal shell]

it may break at some point

[frosty geyser]

like i said, i test it

and?

end users arent doing this process

if its broken, i dont commit my changes

[eternal shell]

well either way i'm just saying that we don't support this

you are free to follow trunk, but don't expect things to not break between commits

[frosty geyser]

hmmmm wait a minute.... this is not my one i work from. absolutely not. no wonder im confused.

brain@neuron:~/limine$ git branch
* v4.x-branch-binary

[eternal shell]

v4 💀

[frosty geyser]

im nuking that folder and pulling v11 binary

because thats just confused the crap out of me

[eternal shell]

binary branches are also going away btw

[frosty geyser]

hmmm, why is the source build fussy about compiler

i tried to build it out of curiosity

configure: error: llvm-readelf invalid, set READELF_FOR_TARGET to a valid program

it continually does this for every binutils, expecting some llvm specific one

[eternal shell]

how do you configure

[frosty geyser]

just ./configure

[eternal shell]

how is that supposed to work

don't you have a cross compiler

[frosty geyser]

same way it works for every other autotools configure script, the defaults are supposed to be the sane ones

no?

[eternal shell]

and where do you pass your prefix

[frosty geyser]

i dont need one for my stuff

why would i need a prefix? im not cross compiling.

im on x86_64, building for x86_64, with no intention or need to compile anything else.

[eternal shell]

TOOLCHAIN_FOR_TARGET=

[frosty geyser]

my curosity has killed this cat. im just going to switch to the binary branch for v11 now. i forget, other OS adjacent projects are fussy

[eternal shell]

if you don't set it it defaults to llvm

[frosty geyser]

(i mean for my project its simple as: mkdir build && cd build && cmake .. && make -j)

no fetching dependencies prep step, no separate make image step

no need for cross

but not everything is as simple

[frosty geyser]

should the default not be empty?

[eternal shell]

if it's not set it's llvm

i guess it's because llvm can work irrespective of target

so you don't need a target prefix

[frosty geyser]

im guessing, its made this way because you can build a version of limine for like 4 different arches?

[eternal shell]

correct

[frosty geyser]

looks like i was on 10.1.1 before not 9

and updating to 11 fixed the bios boot issue on an old dell laptop i have

it still wont usb boot on my desktop, gigabyte motherboard

i think that may be a limine issue, i'll test it later with something else limine based

[eternal shell]

test with systemd boot and grub

[frosty geyser]

pretty sure those work, good idea

that particular desktop is fussy about usb devices

[eternal shell]

limine has no usb drivers

[elfin shard]

are there going to at least be binary releases then? because I like being able to just pull the files from somewhere if its some toy experiment os where I don't use a full meta build system

[eternal shell]

yes

[elfin shard]

nice

[frosty geyser]

hasnt stopped it working

limine boots fine off a usb stick and loads modules, was able to do it on usb from a bios boot?

[dark beacon]

Thank god

What is going to be used now?

[eternal shell]

wdym

nothing

[dark beacon]

So how do u get release artifacts

[eternal shell]

github

[dark beacon]

Github releases?

[eternal shell]

yes

[dark beacon]

Thank god x2

Binary branches has always been a terrible idea

[modern flume]

I agree

Binaries in the repo in general is a big no-no

[tribal lagoon]

I liked being able to put it as a submodule

[modern flume]

It doesn't make sense

[tribal lagoon]

what does not make sense?

[modern flume]

To have binaries in the repo

And to ship binaries as submodules

[tribal lagoon]

it obviously made enough sense to do it for years

[dark beacon]

I agree that it may be convenient but it's completely wrong to use git like that

and you suffer consequences like your repo taking a shit ton of time to clone or being slow in general etc

and just looking silly while doing it in general

[modern flume]

Yeah

[frosty geyser]

is someone going to sign these releases with e.g. GPG? would be nice

[eternal shell]

@floral plover

[frosty geyser]

thats the main reason releses > a branch imho, because you can put .asc artefacts next to it

[limber bear]

????

https://github.com/Limine-Bootloader/Limine/releases/latest

Read very carefully.

[young linden]

what is the reason for adding iommu disabling?

[frosty geyser]

so if you been signing since 9.1.1 there's really no need for a binary branch at all

[desert python]

i am stoopid

ok found the issue, i'm stupid

please excuse me for 4am stupidness

[floral plover]

for systems that autoenable IOMMU with kernels that don't support IOMMU

systems that autoenable IOMMU are going to get more common in the future

[brisk wind]

huh what's the context for IOMMU auto-enable?

how does that even work, is the firmware just using the IOMMU?

[tiny monolith]

the system just turns it on for fun /j

[floral plover]

yes

it's left on for the OS, so that there are no gaps where the IOMMU is off and DMA devices can alter kernel memory or the like

esp for systems with thunderbolt or USB4

[eternal plaza]

Is it normal that limine passes LIMINE_MEMMAP_RESERVED_MAPPED as RESERVED with multiboot2?

[floral plover]

why not?

[eternal plaza]

It's RAM (?)

[floral plover]

can you please get at what you think the issue is with actual data?

[eternal plaza]

Idk, it's not clear which cache bits I should be using when mapping that memory

Since it's reserved, but it's RAM

[tribal lagoon]

just don't map it

[eternal plaza]

But what if something like uacpi wants it

[tribal lagoon]

I doubt uacpi would access some memory without calling the kernel api map function

[eternal plaza]

I'm not talking about hhdm

(even though hhdm also maps it)

[tribal lagoon]

and in that you can use uncachable for everything

[eternal plaza]

Ok, that's what I wanted to know

[floral plover]

tbf uACPI should be the one telling you what caching mode it wants imo

[dark beacon]

how could it possibly know

the information it gets from firmware is: write 4 bytes to this address lol

[tiny monolith]

what's not normal is that you're using mboot2 when limine proto exists

[dark beacon]

he has support for both

[tiny monolith]

I've been reading too much machine-translated Russian lately, for a second I thought you meant limine when you said "he" (Russian has no word for "it")

[eternal plaza]

I mean the bootloader supports both protocols as well

[floral plover]

that sounds like ACPI being lackluster about that

[left yarrow]

For our Rust users: limine-rs just updated to 0.6.5 🎉

• Adds feature uuid for converting between limine::uuid::Uuid and uuid::Uuid
• Adds feature ipaddr for getting the TFTP IP address of limine::file::File as core::net::ip_addr::Ipv4Addr
• Implements the TSC frequency request
• Implements the flanterm FB parameter request
  The demo "kernel" will also be updated soon

CC: @gloomy gulch ^

[young linden]

https://www.reddit.com/r/osdev/s/vCvgRHNOar

limine barebones is ai generated

[frosty geyser]

and?

[jolly trout]

smartest r/osdev member

[floral plover]

it's not anyways

[wind junco]

the creator of aneoengine said that lmao

i was defending the guy

[young linden]

is iczelia now maintaining limine?

[tribal lagoon]

yes

@leaden rivet

[young linden]

oh okay

just wanted to know, since for the last 2 weeks they have been the only one pushing commits

[leaden rivet]

guten morgen

yes

[grave seal]

can somebody please test the release binaries for the 12.x versions? the BOOTX64/IA32.EFI are refusing to load with a Not Found error and i dont know if its something local on my system of if the binaries are just broken somehow

[left yarrow]

BOOTX64.EFI works fine in my Limine test "kernel"

btw @leaden rivet is there going to be a v12.x-binary branch again or is that not a thing anymore?

[leaden rivet]

not a thing. i don't think it was a good idea in the first place

[left yarrow]

ah

That means I have to check how the licensing situation works for redistributing rq since I do want up-to-date Limine

Ah 2BSD

It'll be fine then

[leaden rivet]

feel free to redistribute

sharing is caring

[dark beacon]

Yeah that really goes against the whole git philosophy

[frosty geyser]

you have to use releases now

those are the binary builds

https://github.com/Limine-Bootloader/Limine/releases/tag/v12.4.0

putting blobs in the repo was never a good idea, release bins is the way

wait. ignore me - I misread your request I think?

[leaden rivet]

in principle, if mercurial won the cvs wars, it wouldn't have been a problem.

all the worst features truly.

[left yarrow]

Does anyone happen to know if, through qemu, I can change the kernel command line passed through Limine?

I mean it's unlikely but it would be nice to do without changing the image yknow

[tired flower]

isn't there the Limine editor?

[left yarrow]

oh

ofc

Still would be bonus points if you could do it without manual typing

[tribal lagoon]

1. make a new config file
2. put limine:config: on the first line
3. -smbios type=11,path=limine.conf

[left yarrow]

oh cool thanks

[eternal shell]

how does this work

[tribal lagoon]

type 11 is oem string iirc

and limine reads that instead of the config file

[young linden]

when are we having a LMNE acpi table

[worthy vapor]

This will be limine exposes the requests in 2027

[leaden rivet]

mouse support on trunk

[young linden]

nice

can be useful in laptops with fucked up keyboards

[eternal shell]

nice

i have a touch laptop but it's arm

[tribal lagoon]

ext4 support when

[young linden]

we had it but we lost it

[worthy vapor]

Mint said it was too many things to maintain or whatever

[tribal lagoon]

it was bloat iirc

[leaden rivet]

this is necessary to operate the bootloader on handhelds

they usually have the shitty buttons to the side and a touchscreen, which UEFI exposes as a pointing device.

EXT4 on the other hand is not necessary for any purpose whatsoever

[eternal shell]

well

having the kernel on the root partition

[leaden rivet]

that is not necessary for any purpose whatsoever

[eternal shell]

symlink

[young linden]

the main argument for removing ext4 and other fses was that you could just have the kernel in the esp

along with the bootloader

[leaden rivet]

i still fail to see the use case

that would be so crucial that some users have to abandon limine for grub or systemd boot

[eternal shell]

people do that

sdboot has sd-util

limine has some weird java shit

i don't want to update my config all the time just to point it to a new kernel

[leaden rivet]

and they implement a proper ext4 driver that can recover a broken filesystem?

[eternal shell]

no

[leaden rivet]

we should probably upstream that and rewrite it in some more amenable language

[leaden rivet]

you should have tools to do this automatically anyway

[eternal shell]

no

arch just works

albeit not as stable, i'll give you that much

what about pseudo symlinks

[leaden rivet]

so what? debian just works and i've never touched my bootloader config

except setting a cool as shit E16 theme

[eternal shell]

?

don't see the relevance of that

[leaden rivet]

think about it

maybe you will

[leaden rivet]

then what happens in the scenario of a power loss?

they just boot off of the ext4 partition assuming that it's consistent?

the ESP will be consistent, as it's typically not written to, unless you've messed with some shit.

[eternal shell]

i feel like you're arguing against a point i wasn't even trying to make

sdboot uses the ESP too

but they have stupid scripts around it to automate kernel enrollment

[leaden rivet]

my point is that there is no use case where supporting ext4 is crucial and that while it is nice to have in some self-inflicted circumstances the downsides of it outweigh the overall usefulness

mouse support is clear as a crucial feature because otherwise the bootloader is completely useless on handhelds as you can't interact with the boot menu at all.

[eternal shell]

ext4 is not crucial

but it's still nice to have the option

[leaden rivet]

but i said that it's not NECESSARY, and you argued against it

[eternal shell]

no

[leaden rivet]

which clearly implies that you think that there is a scenario where this is necessary

[eternal shell]

absolutely not

i said that it's the reason why people are switching away

because they're being inconvenienced

[leaden rivet]

if these people put the kernel in the ext4 root partition they're in for more trouble anyway

i see no point in catering to them as they're clearly in the wrong

[eternal shell]

i don't get the power loss argument tho

[leaden rivet]

what's unclear about it?

[eternal shell]

it's not like you can do any meaningful work with a corrupt fs

like wow you can boot to an emergency shell and then do what exactly?

if the rootfs fails to mount, there's not much difference vs booting a rescue usb

i use limine on all my machines with Arch, but just on my main PC i have an openSUSE which has kernel version suffixes

i wonder if there's a way to address this without some config generation shit

[uncut quartz]

mouse support but no ext2 support

[leaden rivet]

so nominally ext's are journalling file systems, which means that after an unclean shutdown the kernel boots into a small program that replays the journal, even when mounted as ro. if we choose to not replay this journal, which is reasonable -- we don't want to support transparent encryption and compression either -- then the resulting view of the file system can be very inconsistent. for example, you can see only one half of a rename operation, an inode could reference a free block. in my opinion if the file system is in an inconsistent state no attempt at booting should happen and indeed this is the current behaviour of limine for all of its file systems: basic integrity is checked for and inconsistent systems within the scope of these basic checks are rejected.

[eternal shell]

fair point

[leaden rivet]

we could have automatic discovery of entries, maybe.

i'd have to think a lot about it

[eternal shell]

would be nice

what about something like fake symlinks?

[leaden rivet]

can you elaboate? i don't know what this means.

[eternal shell]

i.e. if limine reads a file that contains a resource path

[leaden rivet]

ah, one level of indirection

[eternal shell]

yeah

or i guess config snippets

i already had a draft for that

just needed some deliberation regarding hashing