<zid>
rip, the server I use as a socks proxy to get around ip blocks and stuff has dead
<zid>
didn't come back online after a reboot apparently, and it's colo'd to "some guy's business" rather than a real datacenter with KVM video and stuff
Vercas6 has quit [Remote host closed the connection]
<heat>
it's not code
<heat>
just a feature
<heat>
well, feature description
<mrvn>
a bugreport?
<mrvn>
.oO(It's not a bug, it's a feature)
<sbalmos>
heat: good, give in to the futile inevitability. windows rules all.
<geist>
i can tell you the smoke they emit is nasty, so go ahead and swap them now. i figured i'd just wait until they pop and then do it
<geist>
hadn't accounted for the terrible smoke
<sbalmos>
geist: it's... unique, isn't it? ;)
<geist>
yeah
<sbalmos>
geist: So leave it to Phil Opperman (sp?) to drop my jaw again. Buried down in his bootloader repo, he manages to do an MBR stage1 in 16-bit Rust with barely any assembly.
<heat>
that sounds dubious and fiddly
<sbalmos>
definitely gave me a "wait, wut?" moment
<bslsk05>
github.com: bootloader/i386-code16-boot-sector.json at main · rust-osdev/bootloader · GitHub
<mrvn>
can it jump to 64vbit?
<mrvn>
-v
<sbalmos>
it eventually does, yes
<heat>
anyway that seems super risky and odd
<mrvn>
single step
<sbalmos>
no
kof123 has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
Vercas6 has joined #osdev
gog has joined #osdev
<geist>
hah cute
<geist>
though to be fair i dont see it actually switch into protected mode
<geist>
it seems to use some asm to get into an okay context, then branch into rust which seems to read some partition tables and branch to a second stage
<mrvn>
the second stage would do that
<geist>
it's a ncie piece of code, but not really that surprising to be honest. could easily do that in C too
<mrvn>
you can do it in c++ as constexpr
<mrvn>
build all the bootstrap page tables and descriptors and such
<geist>
well, i'm not sayign it's better or worse to do it in C/C++, etc. i just mean there's not a partiular technical challenge there to be honest. where you have tos tart getting really tight is when you do a double bounce into protected mode
<geist>
but it is neat to see that rust can do 16bit
<mrvn>
only challenge is to get the first stage to fit in 500 or whatever byte.
<geist>
but i also declare it not dubious and fiddly. seems straightforward split of assembly and rust. much like exactly how you'd do it in C. so it seems clean to me
<mrvn>
how much unsafe_* does it use?
rwxr-xr-x has joined #osdev
<mrvn>
moin 755
<rwxr-xr-x>
yoo
<rwxr-xr-x>
how's it goin?
<mrvn>
it's rusting
<heat>
geist, I expect that 16-bit rust can blow up super easily
<heat>
both at runtime and in size ;)
<mrvn>
why? it's not using noticeable more ram than C
<heat>
how much testing does llvm get on 16-bit code, really? probably just some entry code for some kernels
<heat>
I know for a fact that they explicitly don't support old CPUs
<heat>
(they = LLVM)
<CompanionCube>
for 16-bit x86, there is also that iirc rust doesn't do segmented memory well?
<mrvn>
if it can jump to 32bit with under 64k code/heap then that isn't a problem
<heat>
<mrvn> why? it's not using noticeable more ram than C <-- I would consider all usage of C languages and above fiddly
<CompanionCube>
mrvn: true
<mrvn>
The fiddly bit is getting a list of blocks for the second stage to load.
<mrvn>
and then loading kernel+initrd in 32bit mode.
<mrvn>
Do you jump back into the bios? Do you write your own disk driver? Your own FS driver or use blocklists again?
<mrvn>
but that's language unspecific
<heat>
the more you do in an tight environment with a language and toolchain that aren't really specifically targetted for that, the more fiddly it gets and the more chances you have of blowing things up
<heat>
like, how can you be so sure your code doesn't suddenly blow past 512 bytes in size?
<mrvn>
you cross that bridge when you fall off it
<rwxr-xr-x>
amazing
<rwxr-xr-x>
love that
<sbalmos>
ls -l my_rusty_loader -> is it bigger than 512? Nope? We live to fight anotehr day!
<mrvn>
sbalmos: stat or wc -c
<\Test_User>
'is it really so hard to write a 510 byte bootloader that you need a higher level language'
<mrvn>
aparently
<sbalmos>
\Test_User: not at all. slipping more into the "because you can" realm
<\Test_User>
sbalmos: fair
<mrvn>
Same reason why you would write a game for the C64 in C++.
rwxr-xr-x has quit [Remote host closed the connection]
elastic_dog has quit [Killed (platinum.libera.chat (Nickname regained by services))]
elastic_dog has joined #osdev
<mrvn>
23:59, this (monday) too shall pass
<\Test_User>
22:01 still
<\Test_User>
*23:01
<heat>
exactly
<heat>
21/11 rulez
carbonfiber has quit [Quit: Connection closed for inactivity]