Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 06 08:09
    ethindp opened #697
  • Dec 06 03:03
    luojia65 commented #692
  • Dec 06 02:58
    luojia65 commented #692
  • Dec 06 02:58
    luojia65 commented #692
  • Dec 06 02:55
    luojia65 commented #692
  • Dec 04 00:58
    luojia65 commented #692
  • Dec 03 21:18
    phil-opp commented #692
  • Dec 03 20:08
    luojia65 commented #692
  • Dec 03 20:06
    luojia65 commented #692
  • Dec 03 19:58
    luojia65 commented #692
  • Dec 03 19:58
    luojia65 commented #692
  • Dec 03 15:23
    ethindp commented #696
  • Dec 03 12:30
    wusyong commented #692
  • Dec 03 11:51
    phil-opp commented #692
  • Dec 03 11:50
    phil-opp commented #692
  • Dec 03 11:38
    phil-opp commented #696
  • Dec 02 23:55
    ethindp opened #696
  • Dec 02 19:44
    wusyong commented #692
  • Dec 02 14:16
    phil-opp edited #695
  • Dec 02 14:13

    phil-opp on status-update

    (compare)

Philipp Oppermann
@phil-opp
Adding it as dependency to blog_os also works fine
Lachlan Sneff
@lachlansneff
I'm not sure. Patching it to an old version makes it work.
Lachlan Sneff
@lachlansneff
I fixed the bootimage packaging pr.
Rob Gries
@robert-w-gries
Hey Phil, I just updated my kernel to build with latest rust compiler and latest dependencies. (I took a month off after getting engaged to my girlfriend! :smile:) I was working on my laptop last night and saw an error message while running bootimage that said something along the lines of You need to upgrade to 0.5.0, which I expected to see.
I upgraded to bootimage v 0.5.0 on my laptop and successfully built the kernel. I'm now working on my desktop, and I am able to build the kernel with bootimage 0.4.3. Is this expected? I thought there was a breaking change in the latest bootimage update.
rob@rob-VirtualBox:~/projects/rxinu$ bootimage --version bootimage 0.4.3 rob@rob-VirtualBox:~/projects/rxinu$ bootimage run Building kernel Finished dev [unoptimized + debuginfo] target(s) in 0.06s Updating registry `https://github.com/rust-lang/crates.io-index` Creating disk image at target/x86_64-rxinu/debug/bootimage-rxinu.bin
rob@rob-VirtualBox:~/projects/rxinu$ bootimage --version bootimage 0.4.3
Philipp Oppermann
@phil-opp
Congratulations!
Hmm, from which bootimage version did you see the error message?
Philipp Oppermann
@phil-opp
Bootimage 0.4.3 does not require any Cargo.toml entries and just downloads the latest bootloader version (unless specified otherwise). So it just ignores the bootloader/bootloader_precompiled dependency. This leads to possible breakage when new bootloader versions are published, so bootimage 0.4.4 defaults to bootloader_precompiled 0.2.0-alpha (the latest version at this time). In bootimage 0.5 the new dependency mechanism (bootloader is just an entry to the normal dependency table) was implemented. To ease transition from 0.4 it contains special error messages that link to the migration guide (I think that this is the message that you saw). This error is shown when either no bootloader/bootloader_precompiled dependency is present or an old configuration key in the package.metadata.bootimage.bootloader table is used.
It is a bit unfortunate that your project still builds with bootimage 0.4.3, but unfortunately there is no way to add new checks to this old version. I just hope that most people that use bootimage move to 0.5 quickly.
Philipp Oppermann
@phil-opp
Sorry for the churn, the automatic bootloader download of previous versions was a clear mistake in retrospective
Rob Gries
@robert-w-gries
Thanks Phil! Yes, the error message I saw is the one that links to the migration guide. The upgrade process wasn't a problem for me, I just didn't understand why my kernel was able to compile with an out-of-date bootimage. From a user perspective, I liked how the breaking change wasn't painful to fix and there were clear instructions on how to use the latest version. Compared to other projects that force breaking changes, this was much much better :+1:
Philipp Oppermann
@phil-opp
Glad to hear that!
Lachlan Sneff
@lachlansneff
Finally got back to the broken pr. Fixed now
Philipp Oppermann
@phil-opp
Thanks! I will take a look tomorrow
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
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