Future of This Crate
phip1611 opened this issue · comments
From official documentation/comments it appears that ucs2
is a base for String handling in the uefi
crate. However, there are exactly two usages in the output protocol implementation (output.rs).
The uefi
-crate provides Char16
CString16
and CStr16
to work with UCS-2/UEFI strings, however.
I have the the following variants in mind:
- A: We should move
Char16
CString16
andCStr16
from the uefi crate to this crate - B: drop this crate
I think A would be a good solution.
PS: Am I missing something? Is there a specific reason for the status quo?
I'm in favor of option A as well. I assume that a lot of stuff has just ended up in uefi-rs
just by inertia.
Nice. I can work on it in the next two weeks.
General question. The encoding looks way to complex, I think. From my perspective, the following encoding would be sufficient:
fn encode_char(char: char) -> UCS2Char {
let unicode_codepoint = char as u32;
if (unicode_codepoint <= 0xffff) {
UCS2Char(unicode_codepoint)
} else {
panic!()
}
}
Am I missing something?
PS: Oh, that is exactly how the Char16 type in the uefi crate does it :D
My ideas for version 0.4.0
- Let's wait until rust-osdev/uefi-rs#751 and possible follow-ups are merged
- Use rust edition 2021
- remove all existing functionality as it is covered by the abstractions added in next step
- move
Char16
,CStr16
andCString16
along will all tests to this crate - discuss whether we should stick to those names or something like
UCS2String
or justString
so that people work withucs2::String
,ucs2::str
and so on - release this
- use it in
uefi
@phip1611 Thanks for the initiative! Option A sounds like a good idea. It fits the general Rust pattern of favoring small, independent crates instead of monolithic ones.
Besides the changes you've mentioned in the comment above, I'd also like to add a few minor clean-ups to the to-do list:
- Rename the
master
branch tomain
- for consistency with theuefi-rs
repo. - Activate branch protection rules for
main
(we already have CI checks, they're just not enforced before merging PRs). We might not actually want this sinceucs-rs
is a much smaller crate with less risk for breakage, but I'm not certain. - Create a
CHANGELOG.md
document and start using tags for labeling releases of the crate (again, not sure if we actually need this from the start, considering the smaller API of this library).
Sounds good. Could you up our access to this repo's settings? Right now I don't have permissions to do the branch rename or update branch protection rules.
Sounds good. Could you up our access to this repo's settings? Right now I don't have permissions to do the branch rename or update branch protection rules.
Whoops, didn't realize there were permission issues. Should be fixed now.
Thanks. I've done the branch rename and added branch protection rules.