<not_not>
am i the only one who thinks unix and linux SUCKS ?
<not_not>
something WAY smarter could be done
<blockhead>
CP/M :)
<not_not>
"everything is a file" fuck off
<klange>
not_not: Please refrain from explicit language.
<klange>
Saying Unix and Linux suck is low-effort. Unix has had detractors since before most people here were born.
<klange>
Even its own creators thought they could do something better.
<not_not>
ye it doesnt SUCk its very good but
<not_not>
operating the computers at the time where it was mostly files, printers and terminals as hardware everything is a file makes hella sense ye
<not_not>
but writing to /dev/videomem just wont do
<klange>
Unix's concept of "everything is a file" is widely misunderstood. What it meant in Unix was more along the lines of "everything can have a name in the filesystem".
<klange>
For actual semantics of 'everything is a file', see plan9 where that went to its [il]logical conclusion.
<bslsk05>
en.wikipedia.org: Worse is better - Wikipedia
<not_not>
ye it is smart i love it about unix in many ways
<klange>
Software, like many things in life, is about tradeoffs.
<not_not>
and the / root file system omg yes
<kingoffrance>
also funny enough that is east const versus west const :)
<klange>
Unix wanting to put everything behind a block or character device was about simplifying interfaces and making things reusable.
<not_not>
ye, unix is very reusable
<not_not>
dont get me wrong if i need a job done and can't afford a failiure i install debian
<not_not>
think my first server ran 4 years without a reboot, and that was a power outage
<kingoffrance>
i dunno, my opinion is either to c89 or not to c89. to posix or not to posix. i mean unix is just code for c, no?
<klange>
Unix is more than / distinct from C, while a lot of what made Unix different from its contemporaries is now baked into concepts in C.
<scaramanga>
i'd say one of the biggest problems with unix is the security model which hasn't really kept up with how modern huge applications work now
<dh`>
the security model is fine, the problem is web stuff was bolted on without thinking
<not_not>
ye
<scaramanga>
the idea that "if I run it, then it has permission to do anything I can do" seems just mad, now
<not_not>
yup
<not_not>
but i think hardware needs to be redesigned
<not_not>
security wise
<scaramanga>
it's quite cumbersome to bolt on sandboxing and stuff for large application environments and so on
<scaramanga>
or to express the idea that my word processor shouldn't be able to have access to my SSH keys
<dh`>
oh, that's not the issue I thought you were chasing after :-)
<not_not>
a completely seperate and fast ram chip just to push iptr on on call, not on same ram chip as data or code
<not_not>
would eliminate arbitrary code execution through stack buffer overflow
<scaramanga>
i'm thinking of ideas like object capability systems, sandboxing, and eg. android-style permission model... not that any of those are perfect but just the idea that things could work in a fundamentally different way than "child process inherits everything of parent process, and UID is the unit of security granularity"
<scaramanga>
i think it's sth that still can be interesting to OS developers who wanna avoid going down the "yet another POSIXish" thing path
<scaramanga>
not_not, isn't that how shadow-stack works on x86 now?
<not_not>
idk im not that updated
<not_not>
hope so
<scaramanga>
yeah, it's called CET in intel parlance
<bslsk05>
en.wikipedia.org: Shadow stack - Wikipedia
<not_not>
but i think we are overlooking something we should make a new type of processor
<scaramanga>
rust solves many of those problems mostly statically (and more safety problems besides), again not perfectly, but it's a pretty good and interesting direction
<not_not>
ye wanna try rust
<not_not>
also somehow thought idk what would happen if iptr starts high and decrements instead of increments
<scaramanga>
it's definitely worth a look, i've been noodling around with it for less than a year, but it's changed my perspective in some ways i wouldn't have predicted (after 20+ years of C, and being quite pro-C in general)
<not_not>
C is god
<scaramanga>
C will always be my first love :)
<not_not>
same
<not_not>
i was just 12 years old
<scaramanga>
a tender age :)
<not_not>
wrote my first gameboy advanced homebrew game in C
<scaramanga>
there are things in rust to dislike, but overall it get a lot right, and a does a lot of things i really want C to do
<not_not>
just made a pointer to the video buffer
<scaramanga>
eg. everything is const by default, const actually works properly, etc.
<scaramanga>
which also solves aliasing, which is frustrating to optimize around in C
<not_not>
had my first empire of hacked video game servers when i was 16
<scaramanga>
were you one of xbox underground by any chance? :)
<not_not>
nah, was lamerlord in jk3
<scaramanga>
yeah rust, some stuff to dislike is: hard to avoid aborts on allocation failures, which i understand why they did that, but it's annoying for most of my use cases, but its mostly stdlib issues rather than fundamental language issues
<not_not>
laming is killing someone with their light saber down and or chat bubble up so they cant defend themselves when you kill them
<not_not>
and this gives the admin an excuse to use /kick or /ban
<not_not>
and enforce some rule
<not_not>
in a game
<not_not>
so first time we got warned for laming we started calling us [lc]lamerlord [lc]lamerking etc etc
<not_not>
we got loads of kicks
<not_not>
but someone told us we could say a too long message in chat and the game crashed
<not_not>
so i looked into that bug
<not_not>
thats when i met my second love, assembly
<not_not>
i was like WAH the data that gets overwritten when you spam the chatbox in jk3 is the iptr?!?!??! and people just use it to crash the game
<not_not>
so i spendt a week skipping school untill i got the shellcode right and managed to dodge all the 0 bytes and it friggin worked
<not_not>
the cmd.exe was piping io to a netcat on my server and all their base were belong to lamerclan
<not_not>
ofc i never ever hacked in my life after that since im no longer a minor but
<not_not>
and dad who starts holding speaches and respect muh authority loud voice yell at me for any minor tendencies that i should think of doing something against the law
<not_not>
came down the stairs to yell at me cuz fbi had called him
<not_not>
and he raises his yelling finger
<not_not>
tries as hard as he can to yell
<not_not>
but smiles with tears in his eyes he so proud XD
<Mutabah>
If that sample ends up being longer than 5 lines... please use a paste service
<not_not>
ahh
<not_not>
ok
<Mutabah>
Or at least be done with it and paste into the channel
<Mutabah>
instead
<Mutabah>
of
<Mutabah>
putting
<Mutabah>
each
<Mutabah>
line
<Mutabah>
like
<Mutabah>
this
<not_not>
if you copy a string into a local array in a function
<not_not>
sorry
<kazinsal>
a bug in your understanding of a programming language is not a bug in a programming language
<not_not>
but only copying till you hit the 0 char
<not_not>
nah its not a bug in the programming language
<not_not>
c programmers are expected to know not to write out of bounds of buffers
<not_not>
c pointers being able to write to anywhere u want is a feature
<not_not>
ts why i love c
<not_not>
but if someone who dont know the secret rules of c, and just copy a string into a buffer untill they hit the 0x00 terminator and the string is longer than the buffer
<not_not>
and the string comes from user input from the net you can overwrite the return pointer to where the program should execute after the function is donem, and make that point to the start of your string and fill that string with an evil program that downloads and installs a virus on that computer
<not_not>
god i wanna go program some C now, cya
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<dh`>
"secret"
<not_not>
yes, only people who read the manual know this
<kazinsal>
the
<kazinsal>
*what*
<not_not>
...... the manual
<Mutabah>
This just in - people who don't know the language make errors.
<not_not>
XD
<Mutabah>
Now, the fact that people who _do_ know the language often make the same mistake is a problem with the language
<Mutabah>
but, that's because it was designed for a much simpler time
<not_not>
ye, should make another language written in c where strings aren't a mine field
<Mutabah>
IMO, that's rust :)
<not_not>
it is?
<not_not>
heard ALOT of good stuff about rust havent tried yet
<not_not>
should i install rust asap?
<Mutabah>
Well, I see rust as being c++ written with the benefit of hindsight (and many more years of language design theory)
<not_not>
nice
<not_not>
best and easiest language is brainfuck
<not_not>
++++++++++ [>++++++++++ <-] >+++++++ .
<not_not>
and thats how to output 'a'
<CompanionCube>
haha rust go RIIR.
<CompanionCube>
i thought of that joke and had to make it
<not_not>
what is RIIR?
<kazinsal>
can rustc spit out 8086 instructions? I have a horrible idea for an april fools joke
<CompanionCube>
'rewrite it in rust'
<CompanionCube>
kazinsal: iirc the rustc backend uses llvm, so...
<Mutabah>
kazinsal: Hmm... don't think so, but you could do evil things with compiling for i386
<kazinsal>
currently fighting with openwatcom for an april fools joke, which apparently does not support the tiny memory model
<kazinsal>
quite annoying, considering my target machine for this is a PC/XT
<kazinsal>
and I do not expect to have much memory on such a machine
<not_not>
ultimate language that is purely theoretical is: not, not not, not not is is, is is not not, is is is, not is not. not not not is not.
<not_not>
but srsly if u change 1 and 0 into not and not not instead u pack more info
<not_not>
than a boolean being true or false
<CompanionCube>
kazinsal: inb4 write it in free pascal for dos
<CompanionCube>
which has the tiny memory model
<kazinsal>
or turbo C!
<kazinsal>
apparently bcc has it but it also explicitly does not support any dialect of C other than K&R
<kingoffrance>
rur is the sound of the hippo. EIEIO actually, this has possibilities
Lumia has quit [Quit: ,-]
sdfgsdfg has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
<kingoffrance>
how else can you manage a bunch of machines or processes, without sounds to notify you when programs hit errors?
archenoth has quit [Remote host closed the connection]
<bradd>
hi. regarding uefi. When I get the memory map, all virt-page addresses are 0. Can I write to the phys address in boottime code? (i.e. is phys 1:1 to virt during boottime)?
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
mahmutov_ has joined #osdev
[_] has joined #osdev
[_] has quit [Read error: Connection reset by peer]
[itchyjunk] has quit [Ping timeout: 240 seconds]
vdamewood has joined #osdev
vdamewood has quit [Remote host closed the connection]
vdamewood has joined #osdev
terminalpusher has joined #osdev
terminalpusher has quit [Remote host closed the connection]
vinleod has joined #osdev
vdamewood has quit [Ping timeout: 250 seconds]
sdfgsdfg has quit [Quit: ZzzZ]
GeDaMo has joined #osdev
<geist>
bradd: yes
<geist>
uefi by definition runs with a 1:1 mapping of virtual to physical
<bradd>
sounds good. now I can move forward :)
<geist>
also wow, reading backlog for the last few hours
<Mutabah>
Things got a little crazy
<klange>
Notably, _how_ an implementation provides that 1:1 mapping is not specified... got bit once in a 32-bit EFI loader because the EFI was setting up PAE and I was not turning it off.
<bradd>
ok. I dont intend to support 32bits so thats fine then
Jari-- has quit [Ping timeout: 250 seconds]
heat has joined #osdev
<heat>
sup
<heat>
warmth here
<vinleod>
Slurp, slurp.
vinleod is now known as vdamewood
<zid>
I'll take a bit of warm
<heat>
question: How more efficient is queueing device operations and letting the interrupt handlers actually submit them instead of waiting (like a TX irq for NIC packet transmission for example)
<heat>
right now all my block and nic drivers work in a completely synchronous fashion and I'm thinking switching to doing stuff async like this might be faster
<heat>
but I'm not 100% sure
<zid>
.. negative? :P
<heat>
hm?
<zid>
negative more efficient
<kazinsal>
maybe more efficient in the "you can run some other code while you wait" sense
<kazinsal>
but interrupt latency might hurt you
<zid>
yea, depends what you're optimizing for
<zid>
but 'efficiency' there strikes me as.. the opposite of what you're suggesting
<kazinsal>
maybe if you want maximum efficiency you put a do_various_kernel_microtasks() in the busy loop
<kazinsal>
do things like check timers and age stuff out
<heat>
for block devices the advantages are obvious
<heat>
you can queue IO and do other stuff
<kazinsal>
yeah
<heat>
like queuing more IO
<heat>
for networking there are also a bunch of advantages
<heat>
mostly that the network stack doesn't sleep
<heat>
I followed linux in that sense
<kazinsal>
on a NIC you've got transmit latency at the two digit microsecond scale usually
<kazinsal>
not much time to do things, but enough to do a few boring maintenance tasks
<zid>
Is that ever going to be an issue though?
<zid>
if my program is just trying to stuff data down a NIC as fast as possible, I want you to spin on the transmit ready reg
<heat>
like, you'll need to wait for the IRQ anyway when doing tx so you might as well not wait using the current thread
<heat>
spinning on something is probably a bit too specific for a general purpose OS (or the general purpose networking stack)
<zid>
and if my program isn't trying to stuff data, it isn't shitting on the NIC fast enough for it to actually spin
<zid>
so imo it's a solution in search of a problem?
<heat>
so you'll need to wait on the TX irq anyway, and because of that you're better off having pushed more data through the socket and maybe into the NIC
<heat>
it's possibly not to wait for TX and try to push more data through the socket
<heat>
instead of while(!tx_ready()); you try to send more stuff through the socket
<heat>
literally a poor man's async IO (and I believe this is how Linux does it as well)
<kazinsal>
yeah as someone who doesn't do "general purpose OS", I do while(!tx_ready()) { check_timers_and_do_idle_bullshit(); }
<heat>
i can also imagine doing a spin like that ending up slowing down other threads if you're trying to share a socket or something
<zid>
if you really wanna slow it down: Do some complicated heuristic to figure out how long it's likely to block for
<zid>
based on the estimated link speed
mahmutov_ has quit [Ping timeout: 256 seconds]
Burgundy has joined #osdev
aejsmith has quit [Remote host closed the connection]
aejsmith has joined #osdev
<geist>
yah in the case of queining tx on the eth you almost certainly want it to be async
<geist>
queue the tx, move on. let the tx irq handler put the buffer back in the queue/pool/etc
<geist>
then rx is by definition async because it just comes in when it does
<geist>
also entirely possible the net stack will generate more than one packet for a user level action, like sending more data than the MTU so it chops it into separate packets that all get queued at the same time
<geist>
which is great ecause most eth nics let you queue a lot of packets on the tx path at once. worst case is something like rtl 8139 that has 4 TX descriptors. more modern/better stuff you can queue basically as much as you want to allocate a ring buffer for
<geist>
i was noticing, for example, the default TX/RX queue depth on an e1000 in windows is 512 TX, 256 RX
<geist>
(bt that's just a transfer descriptor, a packet may use as many of those as it has contiguous physical runs)
<heat>
geist, yeah, the question is more of a "when do you not want a certain IO path to be async"
<heat>
because TX looks pretty async-able, disk IO should be async
<geist>
in general for more than trivial drivers i generally prefer a queue + wakeup style api
<geist>
and then with that you can always make a sync wrapper on it: queue a transfer, in the callback signal a wakeup primitive
<geist>
and the driver can do what it needs to do to block if more than N things are queued, etc
<geist>
i should say queue + callback style api
bgs has joined #osdev
<geist>
and in lots of hardware thats kinda how it works anyway, the async completion part happens in IRQ land. or maybe some driver worker thread
<heat>
yeah I have a feeling that lots of things should be async in driver land
<heat>
a few days ago I checked out fuchsia's USB drivers and I noticed a lot of promise, async code
<geist>
yah usb tends to be highly async in general
<geist>
but even fairly synchronous block devices, like say, SD/MMC, you can still build an async/callback style api where the higher level SDMMC stack queues transfers against the SDHCI
<geist>
ATA too, though depending on what the IDE implementatino is it may or may not support more than one outstanding request at a time
<heat>
and you're still better off trying to queue further IO even if you don't have a queue in hardware
<geist>
yah the driver can implement its own SW queue past hardware if it wants
heat has quit [Remote host closed the connection]
heat has joined #osdev
vdamewood has quit [Ping timeout: 240 seconds]
vinleod has joined #osdev
aejsmith has quit [Remote host closed the connection]
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
mahmutov_ has quit [Ping timeout: 240 seconds]
mahmutov_ has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
[itchyjunk] has joined #osdev
epony has quit [Quit: QUIT]
immibis has quit [Ping timeout: 256 seconds]
dennis95 has quit [Quit: Leaving]
mmohammadi9812 has joined #osdev
epony has joined #osdev
srjek has joined #osdev
dennis95 has joined #osdev
dude12312414 has joined #osdev
matrice64 has joined #osdev
Brnocrist has quit [Ping timeout: 256 seconds]
matrice64 has quit [Client Quit]
fel has left #osdev [Leaving]
Mikaku has quit [Quit: server maintenance ...]
Brnocrist has joined #osdev
mmohammadi9812 has quit [Ping timeout: 240 seconds]
i2p-enjoyer has joined #osdev
i2p-enjoyer has quit [Quit: leaving]
Mikaku has joined #osdev
kpel has joined #osdev
kpel has quit [Quit: Leaving]
EtherNet has quit [Quit: WeeChat 3.5-dev]
EtherNet has joined #osdev
dude12312414 has quit [Ping timeout: 276 seconds]
sortie has quit [Quit: Leaving]
dude12312414 has joined #osdev
sortie has joined #osdev
ChanServ has quit [shutting down]
ChanServ has joined #osdev
immibis has joined #osdev
pwng has joined #osdev
mmohammadi9812 has joined #osdev
Oli has joined #osdev
mmohammadi9812 has quit [Ping timeout: 256 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
biblio has joined #osdev
biblio has quit [Quit: Leaving]
<geist>
neat
mahmutov_ has quit [Ping timeout: 240 seconds]
<geist>
j`ey: cool, if i only had an arm64 windows machine
<geist>
though actually begs the question: can you boot arm64 windows on qemu
<j`ey>
geist: I think so, with UEFI/EDK2
<geist>
yah
<geist>
dunno what kinda gfx console it wants
<geist>
oh looks like they did a bunch of work iplementing a proper gicv3 driver, neat
<geist>
i should get in touch with them and see about merging some stuff back
<geist>
been meaning to do a gicv3 for a while, just never came up
mahmutov_ has joined #osdev
mahmutov_ has quit [Ping timeout: 256 seconds]
Oli has quit [Ping timeout: 256 seconds]
<geist>
re: windows on arm really doesn't look like they have generic ARM platform support
<geist>
mostly rpi for windows iot (which seems to have not been updated since 2019) and some windows 11 preview but for a few snapdragons
GeDaMo has quit [Remote host closed the connection]
<j`ey>
oh, yeah, i dunno about a ful windows image actually, my coworker has run some cut down windows thing for testing
<pwng>
hey everyone
<pwng>
how do you prefer sharing code?
<pwng>
can i put some code in pastebin and share the link? or is there a more favorable way?
<zid>
I personally prefer gist.github.com but whatever is probably fine
<zid>
as long as it has line numbersw
<pwng>
Great
<pwng>
So I have a question that's probably more C-related that osdev-related, but I would really appreciate your help. So I have some global uninitialized variables defined out of BSS for some reason - https://gist.github.com/i3abghany/1aaf639027044bb6690bc4bdf7240af6 `KMEM_END and `MEM_TOP`. The first two symbols are defined in the linker script:
<pwng>
the problem that I'm facing is that I use the memset the memory starting at _kernel_mem_end, which overwrites KMEM_END and MEM_TOP. Is that something I should expect?
<pwng>
j`ey: I use the notation at the very end of the doc, which means I don't have to extract the address of them i think?
<zid>
there is no such thing as KMEM_END or MEM_TOP
<zid>
they are symbols
<zid>
There's 0 data associated with them, their value is their address
<j`ey>
KMEM_END is a C global, that should be in bss
<pwng>
You said above that "if you declared them in the linker script, they are symbols". and this doesn't apply to KMEM_END and MEM_TOP, may I please ask why there are no data associated with them?
<zid>
yea for those two
<zid>
the other two no
<j`ey>
but its odd that KMEM_END is after _bss_end
<pwng>
Yes I understood that the other `extern blah[]` things no data associated with them
<pwng>
8char
<j`ey>
pwng: try .bss*
dennis95 has quit [Quit: Leaving]
<pwng>
Same `readelf` output
<zid>
I've still not seen an actual problem though?
<j`ey>
you could try fix them all, then you would have seen this issue immediately since it would have errored about sbss
<zid>
or just looked at the readelf output from the .o file, or used a symbol map
<pwng>
yes that's great
<pwng>
i was `readelf`ing the final, linked obj file so sbss wasn't included at all
<pwng>
zid: j`ey: many thanks for the help, I appreciate your time <3
<zid>
that's what you get for not using a pastebin :P
<pwng>
next time I won't forget :D
<geist>
ah and yes. sbss is a riscv thing
<geist>
you will want to merge that with bss
<geist>
as yo probably just figured out
<zid>
also itanium!
<geist>
the compiler may choose to put variales in sbss or not (or sdata vs data) based on whatever it was feelig like at the time
<zid>
for itanium it's bss that's within 22 bits of gp
<geist>
yep. riscv it's only +/- 2K so i find it to be of dubious use
<geist>
and you end up burning a whole reg for it. for kernel stuff it's probably better to just take over the gp register and use it as say the per cpu pointer
<geist>
sicne it's the linker that does the gp relaxation, you can bascally just not emit a magic symbol in your liker script and it wont do it
<bslsk05>
github.com: lk/linker-onesegment.ld at master · littlekernel/lk · GitHub
<geist>
looks like there's a srodata too
<klange>
random question for me to ask at 7am, but, anybody got a recommended starting point for aarch64?
<geist>
hardware wise or docs wise
<geist>
?
<zid>
or just coding some rad assembly?
<zid>
that one? gcc and instruction reference
<geist>
for emulated hardware, `qemu -machine virt` is a great starting place. it has a nice simple machine with PCI and whatnot so you can add in decent hardware you probably already have drivers for (once you write a PCI bus manager)
<klange>
"I want to build a 'hello world' so I can have a base that blats some output as a starting point for a port"
<geist>
if you get say an 8GB rpi4 you can put ubuntu on it and then run qemu with kvm on a reasonably decent arm core
<klange>
I have an rpi400 for actual hardware, and an M1 Mac and direct access to a marcan.
<geist>
machine virt is pretty good for that. you can boot your kernel (elf file is fine) with `qemu -machine virt -kernel foo.elf`
<geist>
(and other siwtches, etc) and you'll have a hello world within like 5 instructions of asm
<geist>
set sp, branch to C, go to town. much more straightforward than x86
<zid>
I have a question about arm actually
<zid>
this devicetree stuff, does the soc maker / bios vendor / whoever provide the devicetree crap as an actual file they give you, or is it in memory somewhere like acpi?
<geist>
then once you piddle wth the arch, booting on the rpi is not too mucn more complicated
<zid>
I've seen the format and stuff but nobody mentioned that vital part
<j`ey>
zid: a file
<geist>
there's source versions (.dts) and flattened device tree (.dtb)
<geist>
usually the bootloader ends up with the .dtb sitting in a FS or some flash section that it calls up and hands off to the kernel
<bslsk05>
github.com: linux/t8103-j313.dts at master · torvalds/linux · GitHub
<geist>
in the case of qemu -machine virt it actually synthesizes it in memory
<j`ey>
and a few levels up theres a bunch of dts
<geist>
there's a compiler/decompiler for device tree (dtc) that can build the source into dtb
<klange>
Hm, I guess I'll just stub out my arch-dependent functions and use my existing build, then.
<klange>
Got a ref for devices on that virt target? Serial or a framebuffer?
<geist>
klange: yeah would recommend really really early just tossig together a hello.S project and get your feel for getting hte cpu in the right state
<geist>
klange: serial. lemme find it
<j`ey>
PL011 is the serial for virt
<j`ey>
qemus PL011 emu means you pretty much can write output witha few lines
<bslsk05>
github.com: qemu/virt.c at master · qemu/qemu · GitHub
<geist>
in the sense that all you need to get working is a) know where to link your code to run (0x4000.0000+ is ram) and b) where the uart is
<geist>
PL011 is a public doc you canget. it's a similar but not really 8250 style serial port
<geist>
so you can pretty easily start blatting out characters. no setup needed on qemu since it's not real
<klange>
I've got a UART adapter for the rpi as well, that was a pain to get working - the package I bought came with two, and one was DOA but only in one direction.
<geist>
the virt machine is basically the base ARM server spec: one serial port, a GIC interrupt controller, device tree to describe, etc
<geist>
and PCI and/or virtio-mmio to add more peripherals
<geist>
which rpi do you have?
<klange>
I don't know how much I care to do osdev stuff anymore, but I do want to do some arm, and I might as well do that in the context of porting Misaka.
<klange>
400
<klange>
The improved 4 in the kit keyboard case.
<geist>
if/when you want to start hacking on real hardware there, the difference between 3 and 4 is a lot. good
<geist>
rpi4/400 are more modern, though fiddly, but well understood
<geist>
but like i said i'd spend a weekend getting used to the arch on an emulator, outside of the context of the kernel
<geist>
and just s yo know, i've seen tis trap fallen into by lots of people
<geist>
ARM has a architecture spec, which is where you spend most of your time
<geist>
and hen docs for arm cores, which really just describe how the core matches to the spec
<geist>
so look up the ARMv8 arch manual and get a copy of that first
<geist>
if you just search fo arm docs lots of times yo get somthing like the cortex-a53 docs, which is not complete because it doesn't tell you how to do ARM ISA. it just says that this core implements these features, etc etc
<geist>
yah and some things like arch_get_kernel_directory you might need to rethink
<geist>
since that already leaks a bit much about the arch
<geist>
a little surprise there's not something like arch_context_switch in that list
<geist>
or is that code not yet arch abstracted?
pwng has quit [Ping timeout: 256 seconds]
<geist>
i see mmu_set_directory, that's probably used in a higher level context switch to set the new cr3?
<geist>
probably want to push that down a level, since the page tables dont work exactly the same way. i'd suggest making the page directory stuff abstracted behind an arch specific thread object or whatnot
<klange>
There should be an arch_save_context and arch_restore_context in there but my naïve `make | sed ... | sort | uniq` seems to have lost it.
<geist>
and then a single high level routine like arch_contet_switch
<geist>
ah
<geist>
anyway, looks like it's mostly abstracted, so that's good. honestly arm64 is about as close to x86-64 as you can get at a 10k foot level. same endian, basically same page tables, even pretty much identical struct packing and whatnot
<geist>
and that's really not a coincidence. even riscv64 doesn't stray far from the general overall arch pattern x86 has pretty much made standard
<zid>
I struggle to even consider anything else could exist at this point