gdt: make GlobalDescriptorTable Copy

[haraldh]

Make GlobalDescriptorTable Copy,
so the const new() can be used in array initialization.

static mut GDT: [GlobalDescriptorTable; MAX_CPUS] = [GlobalDescriptorTable::new(); MAX_CPUS];

[phil-opp]

I'm not sure if making the GDT struct Copy is a good idea. However, you should be able to use rust-lang/rust#49147 for your use case. Just enable #[feature(const_in_array_repeat_expressions)] in your crate, then your above code example should work.

[haraldh]

@phil-opp sorry, I need non-nightly...

What's your reasoning for not making GDT Copy but TaskStateSegment is already??

[haraldh]

Hmpf.. even this requires GlobalDescriptorTable to be Copy

static mut GDT: [MaybeUninit<GlobalDescriptorTable>; MAX_CPUS] =  [MaybeUninit::<GlobalDescriptorTable>::uninit(); MAX_CPUS];

[haraldh]

@phil-opp sorry, I need non-nightly...

What's your reasoning for not making GDT Copy but TaskStateSegment is already??

ah, I see, because of #[repr(C, packed)]

[phil-opp]

What's your reasoning for not making GDT Copy but TaskStateSegment is already??

I generally don't like to make large structs Copy because of the possible performance impact. Also, the copy trait can also be a footgun for some types because of accidental copies. Regarding the TSS struct, I no longer remember why we implemented Copy for it, but the #[repr(C, packed)] attribute might be the reason.

For the GDT, I see another potential problem with implementing Copy: It might contain a pointer to a TSS instance. Technically, this pointer is an immutable reference so it could be Copy. However, the TSS specifies memory addresses in its stack tables that are used like mutable pointers by IDT handlers. So you really don't want to accidentally copy a GDT that references a TSS because then multiple cores might use the same stacks in their interrupts handlers. If you're sure what you're doing, you still can call clone() to make the copying explicit.

I need non-nightly...

That's unfortunate. I understand that this is an annoying problem. Maybe there are some crates.io crates that provide a workaround until the feature is stabilized? You could for example you might be able to use lazy_static in combination with array_init. A quick search on crates.io also resulted in your array-const-fn-init crate, maybe this also works in this case?

[phil-opp]

Another crate I found: arr_macro, motived by this post: https://www.joshmcguigan.com/blog/array-initialization-rust/.

[haraldh]

A quick search on crates.io also resulted in your array-const-fn-init crate, maybe this also works in this case?

Hehe, yes. I will be using this in the mean time.