Switch all bitfields to bilge, take notes

[hecatia-elegua]

This is good for converging on one thing instead of the 3-4 we currently use and for experimenting and finding usecases for bilge.
Really complicated ones could get their own issue for later.
There're also some places with manual bit-shifting to get at fields, which we can convert to real bitfields.

Let's crudely measure build time before and after as well?
I'll do time make build like trice, on linux, with nothing besides console open, with make clean inbetween.
Then again trice, to also look at hot builds.

I'll be working on this with @pickx, so here's a list with all crates.
Remove the crates which have nothing to change in them and tick all items which are done.
in kernel:

• acpi (seemed like a lot, might be good to do this in steps if there are too many changes)
• apic (good one)
• ata (good one)
• boot_info (bitflags)
• e1000 (medium amount)
• gdt (small amount)
  - [ ] gic (wip/later)
• intel_ethernet (medium amount)
• interrupts (uhhh, this is rtc again? for testing?)
• ioapic (a bit special)
• iommu (medium amount)
• ixgbe (looks like a lot)
• keyboard (wip)
• libtest (bit_field, but actually not? run cargo udeps on all crates or sth)
• memory (bitflags, but actually not? probably removed dependency)
  - [ ] memory_aarch64 (cortex_a crate, we won't do this)
• memory_structs (maybe this could be a usecase for #[level] or sth else)
• mlx_ethernet (with zerocopy byteorder usecase - we'd have to see how to test this and then look for how to best handle alignment 1 and so on, hopefully outside of the bitfields)
  - [ ] mod_mgmt (parse_nano_core_binary acts on some flags from the crate xmas_elf, can't change things here, but the usecase is interesting)
• mouse (wip)
• multicore_bringup (icr and GraphicInfo, even if unused, having real names there and printing the info helps with bugs, such as Fix real hardware graphics mode picking #952)
• page_attribute_table (another nice example)
• page_table_entry (works a lot with its inner value, note usecases here)
• pci (wip, classes are interesting)
• pic (enums/intralingual stuff, not sure if bitfields)
• pit_clock (small changes)
• pit_clock_basic (small changes)
• pmu_x86 (looks fun)
• ps2 (wip)
• pte_flags (bitflags .bits() generates different things depending on arch)
• rtc (not specifically bitfield, but intralingual design -> good_first_issue!)
• signal_handler (uncommented bitflags, but let's convert anyways)
• simple_ipc (AtomicU16 as underlying type)
• slabmalloc and _safe, _unsafe (pages.rs contains Bitfield, which is special)
• text_terminal (csi_dispatch has some special consts and ansi_colors is interesting)
  - [ ] tss (maybe in the x86_64 dep)
• tty (there are some special consts)
• vga_buffer (only ColorCode, which is tiny, so maybe not)

Also note that all the network cards (e.g. e1000) are getting reworked, I think?

[hecatia-elegua]

build time measurements before:

real 0m35.458s
user 6m19.956s
sys 0m33.889s

real 0m38.732s
user 6m57.044s
sys 0m38.434s

real 0m35.494s
user 6m20.150s
sys 0m34.353s

with another time command:
379.11user 33.55system 0:35.35elapsed 1167%CPU (0avgtext+0avgdata 855736maxresident)k
8inputs+6948336outputs (1820major+8701940minor)pagefaults 0swaps

[kevinaboos]

As i mentioned before on discord and in #967, in order to evaluate the strengths of bilge's design, we should first attempt to use it in pte_flags. That is the highest-priority and most rigidly-defined/well-understood use case in the entire system where bitflags already fails to adequately represent the semantics of PTE flags fields.

If you feel that pte_flags is too complex and would like to start with another crate, that's fine too. Feel free to recommend one or two initial crate candidates that you find appealing, and then I can help recommend a good first approach and/or clarify anything about that crate's expected bitflag-related behavior.