Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 12 19:51
    zheli commented #700
  • Dec 12 19:19
    ethindp commented #696
  • Dec 12 11:57
    phil-opp commented #696
  • Dec 12 11:40
    phil-opp commented #700
  • Dec 12 10:12
    phil-opp edited #692
  • Dec 12 10:04
    phil-opp commented #692
  • Dec 12 09:51

    phil-opp on master

    Code examples are _additionally… (compare)

  • Dec 12 09:51

    phil-opp on master

    Improve rendering of "```" (compare)

  • Dec 12 09:48

    phil-opp on license

    (compare)

  • Dec 12 09:48

    phil-opp on master

    Update copyright year in MIT li… License blog content under CC B… Clarify licensing in root README and 3 more (compare)

  • Dec 12 09:48
    phil-opp closed #705
  • Dec 12 09:10
    phil-opp synchronize #705
  • Dec 12 09:10

    phil-opp on license

    Clarify licensing of contributi… (compare)

  • Dec 12 09:08

    phil-opp on master

    Remove azure pipelines CI script (compare)

  • Dec 12 09:06
    phil-opp synchronize #705
  • Dec 12 09:06

    phil-opp on license

    Ignore README.md in zola proces… (compare)

  • Dec 12 09:00
    phil-opp opened #705
  • Dec 12 08:55

    phil-opp on license

    Update copyright year in MIT li… License blog content under CC B… Clarify licensing in root README (compare)

  • Dec 12 08:33

    phil-opp on post-08

    Use Github Actions CI badge Merge branch 'post-01' into pos… Update Github Actions badge for… and 12 more (compare)

  • Dec 12 08:33

    phil-opp on post-04

    Use Github Actions CI badge Merge branch 'post-01' into pos… Update Github Actions badge for… and 4 more (compare)

Lachlan Sneff
@lachlansneff
Awesome.
Lachlan Sneff
@lachlansneff
@phil-opp Here's the next pr: rust-osdev/os_bootinfo#5
Lachlan Sneff
@lachlansneff
The bootloader is failing to build for me:
Compiling bootloader v0.2.0-alpha-004 (file:///Users/lachlansneff/.cargo/git/checkouts/bootloader-fb1ae7c8d7214858/05a5d93)
error[E0636]: the feature `nll` has already been declared
  --> src/main.rs:10:12
   |
10 | #![feature(nll)]
   |            ^^^

warning: the feature `iterator_step_by` has been stable since 1.28.0 and no longer requires an attribute to enable
 --> src/main.rs:3:12
  |
3 | #![feature(iterator_step_by)]
  |            ^^^^^^^^^^^^^^^^
  |
  = note: #[warn(stable_features)] on by default

warning: the feature `pointer_methods` has been stable since 1.26.0 and no longer requires an attribute to enable
 --> src/main.rs:8:12
  |
8 | #![feature(pointer_methods)]
  |            ^^^^^^^^^^^^^^^

error: aborting due to previous error
Philipp Oppermann
@phil-opp
Why are you still using the alpha version?
I'm currently not near a computer, so I'm not sure what's the problem
Lachlan Sneff
@lachlansneff
I'm using a fork of it that supports packaging. The current upstream has the same problem I believe.
Lachlan Sneff
@lachlansneff
Oh, btw @phil-opp, can you update the published version of os_bootinfo when you get the chance?
Philipp Oppermann
@phil-opp

can you update the published version of os_bootinfo when you get the chance?

Done (as version 0.3.0)

Lachlan Sneff
@lachlansneff
Thanks :)
Lachlan Sneff
@lachlansneff
Also, looks like the x86_64 crate needs to be updated to use the new os_bootinfo version.
Philipp Oppermann
@phil-opp
Hmm, this dependency does not really make sense in my opinion. It was just a hack because the old bootloader loading mechanism couldn't ensure that the same bootinfo versions were used in the bootloader and kernel, so the workaround was to just eliminate almost all dependencies from os_bootinfo so that its types stay the same. With the new mechanism kernels should not depend on os_bootinfo directly.
I'm going to yank os_bootinfo version 0.3.0, because it is a backwards compatibitily hazard for kernels that still dependend on it directly.
I think the best way forward is to deprecate os_bootinfo completely and create a new crate with a different name that is used internally by the bootloader but never reported to the outside (only re-exported). This allows us to remove the VERSION constant and use dependencies more freely.
Lachlan Sneff
@lachlansneff
You could just have os_bootinfo be a module of the bootloader.
The main issue here is how ranges from the bootloader should be converted into ranges for the x86_64 crate.
Lachlan Sneff
@lachlansneff
Sorry, other way around
Philipp Oppermann
@phil-opp
Yeah, just making it a submodule is a good idea. We can always factor it out in a separate crate if needed
Lachlan Sneff
@lachlansneff
Btw, nebulet is waiting on this to work, do you mind if work on it so it can get done sooner?
Philipp Oppermann
@phil-opp
@lachlansneff Could you try rust-osdev/bootloader#23
Lachlan Sneff
@lachlansneff
Damn, I did exactly the same thing
https://github.com/lachlansneff/bootloader/tree/bootinfo
Philipp Oppermann
@phil-opp
Oh sorry
Lachlan Sneff
@lachlansneff
No worries
Philipp Oppermann
@phil-opp
I wanted to see whether it works out before I say anything
Lachlan Sneff
@lachlansneff
Let's take a closer work at the differences between them, but yeah
Philipp Oppermann
@phil-opp
Seems like you just used the PhysFrameRange types directly. I think this is the correct way forward, but I think it's better to do it in a seperate patch because it requires fairly large changes
So how about merging rust-osdev/bootloader#23 first and then doing the additional steps (removing repr(C), directly using PhysFrameRange, adding packaging support, etc) separately?
Lachlan Sneff
@lachlansneff
That's probably the right way to do it, but I need packaging support for nebulet, so I'm going to use my fork for now.
Philipp Oppermann
@phil-opp
Sure
It was one of the goals of the new bootloader dependency mechanism that it's easily possible to use a different bootloader
Lachlan Sneff
@lachlansneff
That's true.
It's probably safe to say that the new interface is stable.
Philipp Oppermann
@phil-opp
And it's good that the infrastructure no longer depends solely on me^^
Lachlan Sneff
@lachlansneff
Indeed
Scott McWhirter
@konobi
howdy all
I've been trying to get blog_os up and running on OSX, I've gotten it all to build without error, but the kernel just hangs and never outputs anything
is this specific to binutils on OSX? if so, is there some documentation on what/how to change the linker used somewhere?
@phil-opp great blog series btw... definitely one of the best approaches I've seen to explaining os dev in a consumable way in a long time
Scott McWhirter
@konobi
oh... was able to coax qemu on osx to show it up (using -curses as a qemu option)... looks like qemu on OSX has some pain points that make things tough to debug
Scott McWhirter
@konobi
@phil-opp I noted there's some interest in supporting ARM perhaps... has there been any movement along those lines at all?
Lachlan Sneff
@lachlansneff
Has anyone put thought into making an uefi version of the bootloader?
It doesn't look like it'd be much work.
Scott McWhirter
@konobi
it's been a few years, but the uefi tooling at the time was really quite poor... hopefully that's improved since
I have prior experience working with the u-boot source and the freebsd loader on ARM (armv7) and am currently interested in experiments with low cost, high performance ARM64 SBCs, so am hoping to avoid redundant work if an ARM bootloader is on the cards
Lachlan Sneff
@lachlansneff
No one is currently working on one unfortunately. You could though!
Scott McWhirter
@konobi
Cool... I'll likely be working with something like this... https://www.pine64.org/?page_id=61454
(either this, or another high spec "open" board)
which should hopefully make it more accessible to hobbyists
Lachlan Sneff
@lachlansneff
Awesome
Scott McWhirter
@konobi
yeah... $80 isn't too far out of reach