Descriptor::tss_segment too restrictive?

[SamZhang3]

I'm trying to implement multitasking in user mode with the following setup:

• Each task has a user-mode and kernel-mode stack
• The kernel-mode stack pointer is placed in the privilege stack table of the TSS (so it is switched to on interrupts, exceptions, and system calls)
• On a context switch, the privilege stack table is updated to point to the kernel-mode stack for the new task

But with this crate, there is a problem. To add the TSS, the Descriptor::tss_segment function should be called with the TaskStateSegment structure, to create a Descriptor that can be added to the GDT. But the function expects a &'static reference to the TaskStateSegment, which means that, once called, no further modifications are possible to the TSS (the &'static reference cannot coexist with any mutable references), so it is not possible to update the TSS on context switching.

Would it be a good idea to loosen the requirements for calling this function?

[Freax13]

I'm trying to implement multitasking in user mode with the following setup:

• Each task has a user-mode and kernel-mode stack
• The kernel-mode stack pointer is placed in the privilege stack table of the TSS (so it is switched to on interrupts, exceptions, and system calls)
• On a context switch, the privilege stack table is updated to point to the kernel-mode stack for the new task

But with this crate, there is a problem. To add the TSS, the Descriptor::tss_segment function should be called with the TaskStateSegment structure, to create a Descriptor that can be added to the GDT. But the function expects a &'static reference to the TaskStateSegment, which means that, once called, no further modifications are possible to the TSS (the &'static reference cannot coexist with any mutable references), so it is not possible to update the TSS on context switching.

Would it be a good idea to loosen the requirements for calling this function?

The way I see it, there are two ways to solve this:

1. Add an unsafe function that makes the caller responsible for ensuring that the TSS is valid while the entry is in use.
2. Make it possible to modify the TSS fields atomically.

Option 2 will likely require breaking changes, so I tend towards option 1 for now (though we were planning on releasing a new breaking version anyways, so option 2 should also be good).

[phil-opp]

I think it makes sense to implement both option 1 and option 2. There will always be cases where our safe abstractions are not a good fit, so we should allow users to plug in their own abstractions if desired. So starting with option 1 sounds good to me!

@SamZhang3 If you have time, it would be great if you could create a PR to add an unsafe Descriptor::tss_segment_unchecked function that takes a *const TaskStateSegment as argument.