release v0.15 #446

Freax13 · 2024-01-14T12:01:40Z

This PR prepares the v0.15 release.

We had two PRs #261 and #439 implementing a trait for interrupt handler functions. I resolved conflicts in favor of #439 to avoid unnecessary breakages.
Some of the changes from #317 conflicted with #422. I resolved these by using a larger integer type such that underflows are impossible and we never need to return an error for underflows.

TODO:

Merge next into master.
Bump version in Cargo.toml.
Update changelog/write migration guide.
Wait for GDT breaking changes (Make GlobalDescriptorTable const generic #443)?

This is a *breaking change*, also add note about safety.

Followup to rust-osdev#259. Code previously merged as part of rust-osdev#227. Signed-off-by: Joe Richey <[email protected]>

This moves the code_selector to the `EntryOptions` structure. While rebasing this, I also updated the `Debug` implementation to actually print out useful information instead of just hex codes. I left the type field as binary, as that's what the SDM does. Signed-off-by: Joe Richey <[email protected]>

This makes the value easier to use and slightly improves the `Debug` implementation. Also, change the `InterruptStackFrame` to `#[repr(transparent)]`. It doesn't really matter but makes it clear that `InterruptStackFrame` and `InterruptStackFrameValue` are ABI compatible. Note that this now makes `InterruptStackFrameValue`s imposible to construct, but that seems fine. Signed-off-by: Joe Richey <[email protected]>

Signed-off-by: Joe Richey <[email protected]>

add `InvalidStarSegmentSelectors`

add `PcidTooBig` error

activate `feature(abi_x86_interrupt)`

implement `Index<u8>` for IDT instead of `Index<usize>` and add implementations for indexing with ranges

`ltr` atomically writes to memory when it changes the referenced tss entry's type to Busy 64-bit TSS. This means that the inline assembly in `load_tss` should not have the `nomem` option and that the `table` field in `GlobalDescriptorTable` must use a type that is interiorly mutable.

…types change `cpu_flags`'s type to `RFlags`

Co-authored-by: Philipp Oppermann <[email protected]>

fix `load_tss` and `GlobalDescriptorTable` and add `SingleUseCell`

Freax13 · 2024-01-14T14:49:20Z

Changelog.md

+
+## Other improvements
+
+- [idt: Fixup Options structure and cleanup set_handler_fn](https://github.com/rust-osdev/x86_64/pull/226)


I'm not entirely sure why this PR was merged into the next branch. AFAICT it doesn't introduce any breaking changes and doesn't depend on any changes in the next branch.

Looks like the behavior of set_handler_function/set_handler_addr was changed in a subtle way. Before #226, only the present was added to the entry options. Since #226, the whole options field is reinitialized, which means that the additional options are reset (if they were set before).

We should probably add the doc comment introduced in #226 to both set_handler_function and set_handler_addr:
https://github.com/rust-osdev/x86_64/pull/261/files#diff-399920f192f3fe5242eba18a5bdecd151fe662e3432e4836a34d11a7b8076b54R630-R638

Also, this part of the set_handler_fn comment is no longer true:

/// This method is only usable with the abi_x86_interrupt feature enabled. Without it, the
/// unsafe [Entry::set_handler_addr] method has to be used instead.

The function is no longer gated on the abi_x86_interrupt feature, only the impls for HandlerFunc* are. So users can still use this function if they provide their own HandlerFuncType implementation.

if they provide their own HandlerFuncType implementation

Speaking of which, we should probably make the HandlerFuncType an unsafe trait, given that we trust the to_virt_addr output.

Ah, I forgot that we only use the trait with specific types defined in InterruptDescriptorTable. So there is no reason for users to implement this trait. Still, an unsafe trait would probably better represent our intentions?

Also, this part of the set_handler_fn comment is no longer true:

/// This method is only usable with the abi_x86_interrupt feature enabled. Without it, the
/// unsafe [Entry::set_handler_addr] method has to be used instead.

The function is no longer gated on the abi_x86_interrupt feature, only the impls for HandlerFunc* are. So users can still use this function if they provide their own HandlerFuncType implementation.

It's still only usable if abi_x86_interrupt is active because the HandlerFuncType is gated behind abi_x86_interrupt:

x86_64/src/structures/idt.rs

Lines 839 to 855 in 47a11c9

macro_rules! impl_handler_func_type {

($f:ty) => {

#[cfg(feature = "abi_x86_interrupt")]

impl HandlerFuncType for $f {

#[inline]

fn to_virt_addr(self) -> VirtAddr {

VirtAddr::new(self as u64)

}

}

};

}

impl_handler_func_type!(HandlerFunc);

impl_handler_func_type!(HandlerFuncWithErrCode);

impl_handler_func_type!(PageFaultHandlerFunc);

impl_handler_func_type!(DivergingHandlerFunc);

impl_handler_func_type!(DivergingHandlerFuncWithErrCode);

Freax13 · 2024-01-14T15:03:59Z

There are still a bunch of deprecated functions on master. We'll want to get rid of them before releasing 0.15. @phil-opp can we still use #447 to get next up to date with master, so that we can create a PR targeting next removing all those deprecated functions?

…ster Update `next` branch with latest changes from `master`

…recate remove deprecated from_bits_unchecked functions

make `HandlerFuncType` unsafe

Freax13 · 2024-01-14T17:40:45Z

I think this PR is ready now.

Freax13 · 2024-01-14T17:41:45Z

Should we do a beta release first?

phil-opp · 2024-01-14T17:54:59Z

I'm fine with doing a beta release, but let's give @josephlr some time to take a look before we do the stable.

I created one more PR to update the docs for set_handler_fn: #451

Update docs to clarify new `set_handler_fn` behavior

phil-opp · 2024-02-06T10:51:50Z

@josephlr Friendly ping! Are you fine with releasing v0.15?

josephlr · 2024-02-06T11:02:46Z

Sorry for not being very responsive over the past month. I will try to take a look today, but overall a I have no issue with releasing 0.15

josephlr

This looks good. Thanks @Freax13 and @phil-opp for all the work.

There are a few Clippy findings which should either be fixed or silenced, but I don't think that should block release. I noticed that this PR is actually out of sync with the next branch (doesn't include #451), should we reopen a fresh PR which uses rust-osdev:next as the source branch?

Freax13 · 2024-02-08T16:52:39Z

I noticed that this PR is actually out of sync with the next branch (doesn't include #451), should we reopen a fresh PR which uses rust-osdev:next as the source branch?

Sounds good to me.

Freax13 and others added 30 commits June 4, 2021 00:30

replace software_interrupt! macro with generic function (rust-osdev#259)

885977a

This is a *breaking change*, also add note about safety.

software_interrupt: Add additional testing (rust-osdev#260)

33e8c3b

Followup to rust-osdev#259. Code previously merged as part of rust-osdev#227. Signed-off-by: Joe Richey <[email protected]>

fix typo in docs (rust-osdev#265)

69a6b1e

Merge branch 'master' into next

fb8c5e5

Signed-off-by: Joe Richey <[email protected]>

Merge branch 'master' into next

3b8a597

add PcidTooBig error

8fe252f

add InvalidStarSegmentSelectors

9b1773c

fix grammar

ddf7a68

Merge pull request rust-osdev#317 from Freax13/proper-star-error

a96abb2

add `InvalidStarSegmentSelectors`

Merge pull request rust-osdev#316 from Freax13/proper-pcid-error

734c419

add `PcidTooBig` error

activate feature(abi_x86_interrupt)

8294882

Merge pull request rust-osdev#320 from Freax13/fix-asm-const-operands

37f8b0d

activate `feature(abi_x86_interrupt)`

change Index<usize> to Index<u8>

88fee50

use u8 instead of usize for slice

99a334c

implement ranged index for idt

5be7446

use usize::from instead of casting

6eee5a8

Merge pull request rust-osdev#319 from Freax13/index-idt-with-u8

9ce47b3

implement `Index<u8>` for IDT instead of `Index<usize>` and add implementations for indexing with ranges

revert to old GDT but take &mut in load instead

aefd432

add Singleton<T>

597ff85

fix test

96e0917

change cpu_flags's type to RFlags

c49a3b3

Merge pull request rust-osdev#324 from Freax13/interrupt-stack-frame-…

9f2114c

…types change `cpu_flags`'s type to `RFlags`

use swap and fix ordering

f677c78

Co-authored-by: Philipp Oppermann <[email protected]>

change Singleton's name to SingleUseCell

df498d8

add Send bound for SingleUseCell's Sync impl

23cf4c5

Merge pull request rust-osdev#323 from Freax13/mutable-gdt

230c303

fix `load_tss` and `GlobalDescriptorTable` and add `SingleUseCell`

add an immutable getter for the level 4 page table

0aa7b93

phil-opp mentioned this pull request Jan 14, 2024

[Question] Why at most 8 entries for the GDT? #395

Closed

phil-opp linked an issue Jan 14, 2024 that may be closed by this pull request

0.15 Tracking issue #262

Open

13 tasks

phil-opp mentioned this pull request Jan 14, 2024

Should we add an register abstraction? How should it work with and ? #448

Open

Freax13 added 2 commits January 14, 2024 14:25

fix date for 0.14.11 release

ee78cc0

update changelog for 0.15.0 release

5133c37

Freax13 commented Jan 14, 2024

View reviewed changes

bump version

c34c84a

Freax13 marked this pull request as ready for review January 14, 2024 14:52

Freax13 requested review from phil-opp and josephlr January 14, 2024 14:52

phil-opp and others added 2 commits January 14, 2024 16:55

Merge pull request rust-osdev#447 from rust-osdev/update-next-with-ma…

47a11c9

…ster Update `next` branch with latest changes from `master`

remove deprecated from_bits_unchecked functions

e24d811

Freax13 mentioned this pull request Jan 14, 2024

remove deprecated from_bits_unchecked functions #449

Merged

make HandlerFuncType unsafe

e7f53ac

Freax13 mentioned this pull request Jan 14, 2024

make HandlerFuncType unsafe #450

Merged

Freax13 added 2 commits January 14, 2024 18:30

Merge pull request rust-osdev#449 from Freax13/enhancement/remove-dep…

4fc44a6

…recate remove deprecated from_bits_unchecked functions

Merge pull request rust-osdev#450 from Freax13/enhancement/idt

fb5416c

make `HandlerFuncType` unsafe

phil-opp added 2 commits January 14, 2024 18:51

Update docs to clarify new defaults for set_handler_fn

5384bd1

List new IDT defaults as breaking change in changelog

0c368ad

Merge pull request rust-osdev#451 from rust-osdev/update-docs

32ed8fc

Update docs to clarify new `set_handler_fn` behavior

josephlr approved these changes Feb 7, 2024

View reviewed changes

mark as beta-release

8e13191

Freax13 closed this Feb 8, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

release v0.15 #446

release v0.15 #446

Freax13 commented Jan 14, 2024 •

edited

Loading

Freax13 Jan 14, 2024

phil-opp Jan 14, 2024

phil-opp Jan 14, 2024

phil-opp Jan 14, 2024

phil-opp Jan 14, 2024

Freax13 Jan 14, 2024

Freax13 commented Jan 14, 2024 •

edited

Loading

Freax13 commented Jan 14, 2024

Freax13 commented Jan 14, 2024

phil-opp commented Jan 14, 2024

phil-opp commented Feb 6, 2024

josephlr commented Feb 6, 2024

josephlr left a comment •

edited

Loading

Freax13 commented Feb 8, 2024


		## Other improvements

		- [idt: Fixup Options structure and cleanup set_handler_fn](https://github.com/rust-osdev/x86_64/pull/226)

	macro_rules! impl_handler_func_type {
	($f:ty) => {
	#[cfg(feature = "abi_x86_interrupt")]
	impl HandlerFuncType for $f {
	#[inline]
	fn to_virt_addr(self) -> VirtAddr {
	VirtAddr::new(self as u64)
	}
	}
	};
	}

	impl_handler_func_type!(HandlerFunc);
	impl_handler_func_type!(HandlerFuncWithErrCode);
	impl_handler_func_type!(PageFaultHandlerFunc);
	impl_handler_func_type!(DivergingHandlerFunc);
	impl_handler_func_type!(DivergingHandlerFuncWithErrCode);

release v0.15 #446

release v0.15 #446

Conversation

Freax13 commented Jan 14, 2024 • edited Loading

Freax13 Jan 14, 2024

Choose a reason for hiding this comment

phil-opp Jan 14, 2024

Choose a reason for hiding this comment

phil-opp Jan 14, 2024

Choose a reason for hiding this comment

phil-opp Jan 14, 2024

Choose a reason for hiding this comment

phil-opp Jan 14, 2024

Choose a reason for hiding this comment

Freax13 Jan 14, 2024

Choose a reason for hiding this comment

Freax13 commented Jan 14, 2024 • edited Loading

Freax13 commented Jan 14, 2024

Freax13 commented Jan 14, 2024

phil-opp commented Jan 14, 2024

phil-opp commented Feb 6, 2024

josephlr commented Feb 6, 2024

josephlr left a comment • edited Loading

Choose a reason for hiding this comment

Freax13 commented Feb 8, 2024

Freax13 commented Jan 14, 2024 •

edited

Loading

Freax13 commented Jan 14, 2024 •

edited

Loading

josephlr left a comment •

edited

Loading