CryptoDavid has quit [Quit: Connection closed for inactivity]
dasabhi has joined #osdev
navi has quit [Quit: WeeChat 4.2.1]
<dasabhi>
hellooo
<dasabhi>
i may have asked this a long time ago, but i forgot so have to ask again
<dasabhi>
on xv6 i noticed when i build and run with multicores, i noticed that all the qemu threads are executing the kernel code
<dasabhi>
i initially thought there would be some locking mechaism in the code to prevent the other cores from executing into kernel code
<dasabhi>
but all of them run the _entry code and then the kernel C code, which is odd, is this how it should be?
<heat_>
it depends
<heat_>
what xv6? x86?
<dasabhi>
riscv xv6
<geist>
hmm, not sure i understand the question
<geist>
all the cores are executing the kernel code?
<dasabhi>
i will try to rewrite
<dasabhi>
yes
<heat_>
if(cpuid() == 0){
<geist>
or do you mean they all start simultaneously? that's a riscv emulation thing if you dont use SBI
<heat_>
there's the deal
<heat_>
geist, i have to note xv6 is exquisitely weird and boots in M mode :/
<geist>
if you're running supervisor code on riscv, you're *supposed* to be using SBI, which will among other thing traps SBI
<geist>
wat.
<heat_>
yeah it boots in M mode, does some stuff and drops to S mode
<geist>
okay, well then yes that's exactly how qemu works w/riscv. it will simultaneously start all cores, and it's up to whatever is running at machine mode (usually SBI) to trap everything but one of them
<geist>
LK can boot that way too, and I have code to explicitly trap them, basically as heat says
<bslsk05>
github.com: lk/arch/riscv/start.S at master · littlekernel/lk · GitHub
<geist>
if booted in M mode, it traps all but one cpu, and if booting in S mode, the first cpu is whatever SBI decided to release first. works both ways
<dasabhi>
yeah they chose to let all cores in riscv run to _entry and even start.c then only one gets to continue in kernel main.c
<geist>
yep
<dasabhi>
they could have locked out the cores earlier in the _entry
<geist>
indeed
<dasabhi>
a simple conditional statement checking mhartid
<geist>
i hope they assign each of them a separate stack up to that point
<heat_>
yeah they do
<dasabhi>
yeah they do
<heat_>
sike
<heat_>
i do have to mention they ARE BOOTING INF UCKING M MODE
<heat_>
WHY
<dasabhi>
why not?
<dasabhi>
is this a security thing?
<geist>
well, checking mhartid is not good, actually. because a) not all riscv machines start at hartid 0, and b) if in SBI cpu 0 is not guaranteed to be the first
<dasabhi>
and define "booting"
<heat_>
well for one M mode is not guaranteed to be available to the kernel
<geist>
which is why i have the 'boot lottery' thing there, which just lets one through and calls it cpu 0
<heat_>
usually you run on top of SBI, or UEFI
<heat_>
heck, i think riscv UEFI runs in S mode on top of SBI too
<geist>
right. if they *require* it boot in M mode that needs to be changed in the long term
<geist>
if they support both, then that's basically what I do in LK
<geist>
but that's so you can use it in a more embedded situation
<geist>
but most likely it's never been run on actual real hardware, so it's just an experiment for now
<heat_>
xv6-riscv is bizarre stuff
<geist>
which is fine, but it's an issue they'll need to fix if they want to boot on something real
<heat_>
you know they implement split address spaces?
<heat_>
like, just as a meltdown mitigation
<geist>
ah, well, it's not like it's a product or anything. let them play
<heat_>
yeah, so skip the mitigations
<geist>
right. probably just someone wanted to do it
netbsduser has quit [Ping timeout: 256 seconds]
<geist>
but yeah that's gonna be terribad on riscv
<heat_>
i like os161
<geist>
could also be re: SBI the intention is to run it on raw FPGAs where someone would have to port SBI first
<dasabhi>
isnt os161 more of a gimmic?
<heat_>
no? it's less of a gimmick
<geist>
and no one really wants to, so this way you can just load it directly on FPGA simulation, etc
<heat_>
it's very BSD-ish
<dasabhi>
i am a little lost on the SBI part here
<dasabhi>
openSBI is a spec right for the interactions between riscv firmware and the bootloader/os right?
<heat_>
yes
<dasabhi>
so does all riscv hardware implement sbi?
<dasabhi>
and since its qemu, there is no sbi there
<geist>
*if* it has supervisor mode, which is i think implicit here
<geist>
there's absolutely SBI there in qemu, you just have to tell it to load it
<dasabhi>
ahhh
<heat_>
actually it's the reverse, you basically need to tell qemu *not* to load it
<dasabhi>
so with sbi loaded, the initial firmware before kernel _entry is more complex then the four instructions i am currently seeing i guess?
<geist>
right, was just looking through my code
<geist>
-bios none causes it to raw load you at machine mode
<bslsk05>
github.com: lk/scripts/do-qemuriscv at master · littlekernel/lk · GitHub
<geist>
i should ask though, is this riscv64 right?
<dasabhi>
yes i believe so
<geist>
i say because the SBI thing is not really true in riscv32
<geist>
since no one really cares about running supervisor mode stuff on rv32, there's no SBI port for it (at least prebuilt in qemu)
<geist>
so if they're doing an xv6 for rv32, then actually what they're doign is the only option
<heat_>
actually linux supports riscv32
<heat_>
and so does musl, there was quite a push for it
<heat_>
i guess for embedded but not too much
<dasabhi>
so riscv foundation doesnt want kernel running in M mode yeah? they want bootloader and the rest to be in S mode?
<geist>
it didn't last i checked, does it support it in full supervisor though?
<dasabhi>
only sbi should be in M mode is that right?
<dasabhi>
unless there is a hypervisor ofc?
<geist>
dasabhi: yes, that's the idea. whatever is 'above' the supervisor mode kernel is supposed to act like SBI
<geist>
whether or not it's opensbi in M mode, or you're under a hypervisor
<heat_>
yeah looks like S mode, with MMU and all
<geist>
heat_: huh. okay. then question is does it expect SBI?
<geist>
of course it could be opensbi can be built for it. lemme see, actually
<geist>
oh well, disregard
<heat_>
reading through the kconfig it seems so
<geist>
at least with qemu 9 there is a full opensbi for rv32 now
<geist>
just like rv64. boot with -bios default (or no bios) and it just runs
<geist>
okay, so everyting applies then for both rv32 and rv64 now
<dasabhi>
so is SBI code before _entry or bootloader, supposed to lock out the other cores?
<heat_>
yep
<dasabhi>
ah unlike what is going on in xv6
<dasabhi>
but its also a board specific thing too right? to activate all the cores on bootup, vs just firing one
<geist>
and then there's SBI calls to individually start each core
<geist>
well the idea is the SBI itself is board specific, so it hides those details
gildasio has quit [Remote host closed the connection]
<geist>
it starts the kernel and gives you a device tree, so you can have a semi generic kernel that probes where things are
<dasabhi>
okay interesting
gildasio has joined #osdev
<geist>
what is sort of interesting is that QEMU itself is actually running a port of opensbi to qemu-virt machine. it doesn't *have* to. it could have just directly implemented SBI inside itself
<geist>
that's basically what it does for PSCI on ARM
<geist>
but i guess to let them debug opensbi they just actually emulate the full stack of software
<geist>
but presumably when the first qemu + KVM solution for riscv is implemented (bound to be pretty soon) they'll have to move the SBI emulation into QEMU because int aht situation it wont be able to emulate M mode
<geist>
ie, something will need to trap SBI calls an implement it outside of the guest
<dasabhi>
what exactly is an SBI call?
<geist>
this is where you should probably just look in the docs
<bslsk05>
riscv-non-isa/riscv-sbi-doc - Documentation for the RISC-V Supervisor Binary Interface (84 forks/319 stargazers/CC-BY-4.0)
<geist>
it's just a syscall into the machine mode layer, basically
<dasabhi>
that is whats weird, after SBI spcification firmware hands off to bootloader/kernel
<dasabhi>
how do you syscall into the sbi firmware?
<heat_>
ecall
<dasabhi>
SBI firmware isnt running anymore after it hands off to the kernel
<geist>
you just syscall from supervisor mode, and it's trapped by machine mode
<geist>
it absolutely is running, that's the point
<geist>
it stays resident
<geist>
but in the case of plain opensbi it's not really actively doing anyhting. it just passively sits there and waits for you to boot a cpu, set a timer, etc
<geist>
the direct analogy to this is PSCI on ARM. Usually a thing called Trusted Firmware
<geist>
lives in EL3, etc
<dasabhi>
ah so if i am doing hardware specific things, then i have to interact with SBI again is that it?
<geist>
depends on precisely what hardware
<dasabhi>
ahh okay i was under the impression after hand off to the kernel, nothing is more foundational then the kernel
<geist>
opensbi doesn't 'own' much hardware, so mostly no. but it owns, for example, the timers, and the interrupt controller that can fire inter-processor-interrupts
<dasabhi>
interesting
<geist>
nope, that's not really the case. mostly is the case on x86, but this isn't x86
<dasabhi>
oh ofc, because all those things are board specific
<geist>
(and even then on x86 it's still got firmware running, SMM, etc but it's made to be transparent)
<dasabhi>
i didnt know this at all
<geist>
this is a case where it's a new architecture so they went ahead and just defined that there's no fiction and defined a software interface to talk to the underlying firmware
<dasabhi>
this is very new to be
<dasabhi>
new to me*
<geist>
note this SBI thing is a bit sloppy and i think they coul dhave done a better job
<geist>
but it's there and getting extended, so it doesn't seem to be going anywhere
<dasabhi>
i guess the idea is to keep the kernel very much hardware independent yeah?
<heat_>
i mean it's getting extended and cut open
<geist>
well, at least with regards to things like booting cpus, power management of cpus, etc
<heat_>
don't you have direct timer extensions now? and direct IRQ stuff
<geist>
heat_: yeah
<geist>
SSTc, etc
<geist>
but it's more like 'by default these pieces of hardware are owned by SBI, unless an extension says you can directly access it, like sstc'
<heat_>
are the new IRQ controllers also owned by SBI?
<geist>
i dont know yet to be honest
<geist>
haven't looked that close at it
<heat_>
unrelated but i'd really like a github PR feature where you'd be able to merge it after CI goes through
<heat_>
it's annoying to babysit for some minutes while it builds
<dasabhi>
so some observations about SBI, 1. it looks like this completely eliminates the need for board support packages for riscv boards, since SBI passes off a device tree to the kernel
<dasabhi>
2. kernel only runs in S mode now, and SBI firmware has higher priv than the kernel, i dunno about this one
<dasabhi>
this give me intel me engine vibes
<heat_>
1) no, you still need the drivers, the device tree doesn't run itself
<heat_>
2) this is more like SMM, which was widely known
<dasabhi>
well opensbi doesnt stop me from writting a kernel that runs in M mode right?
<heat_>
if it loaded first you can't run in M mode
<dasabhi>
yeah i dont know about this... why the fuck is there some one with more priv than my kernel
<heat_>
because it's doing the dirty work for you
<dasabhi>
yeah thats great, but i still need my kernel in M mode, i dont want some vendor code to have access to my registers and shit
<heat_>
you can't
<heat_>
also, get used to it
<dasabhi>
jfc
<dasabhi>
is this really the case with all real riscv hardware?
<dasabhi>
on real riscv hardware i cant run my kernel in M mode at all?
<heat_>
all hardware in general
<heat_>
i guess if you pick and choose you might be okay, but all the interesting choices go out the window
<heat_>
there's a blob somewhere, there are many blobs in many places, many co-processors doing stuff, lots of undocumented hardware (bcuz), lots of weird layering in the name of security or compatibility or both
<dasabhi>
even in fucking riscv man
<dasabhi>
wtf
<heat_>
riscv is an open ISA not an open architecture
<dasabhi>
riscv foundation even gave them a way to do it with sbi spec
<geist>
but hang on a sec. opensbi doesn't hide all of hardware
<geist>
it only marks a few registers off limits. the ones it's using
<geist>
access to hardware is on an architecture like riscv basically determined solely by what MMIO registers are available
<geist>
the vast majority of it will be directly accessible to you (on real hardware). on virtual hardware it's all emulated anyway
<dasabhi>
thats fine, but i am complaining about the priv modes
<Ermine>
the open thing about riscv is a set of pdfs you can download from their sites
<heat_>
no, riscv is actually royalty free
<geist>
dasabhi: you realize it's more or less the exact same thing everywhere else right? they just dont hvae a fiction of hiding it
<geist>
which i actually enjoy
<dasabhi>
wait, if i cant run in M mode, how the fuck do i build an hypervisor?
<geist>
ARM has 4 priviledge levels, kernels run in the 3rd level down
<geist>
dasabhi: you a) read the manual and b) you'd realize that hypervisor mode is supervisor
<dasabhi>
yeah i know about the other ones, but i didn't think this would be a thing in riscv as well
<geist>
hypervisors dont work as a higher priviledge in riscv. looks much closer to x86
<geist>
a supervisor mode kernel enters VS mode when it wants to run a guest
<geist>
if VS mode is not present, no hypervisor for you
<geist>
basically type 2 from the get go
<geist>
(and what ARM now does with uh, LPE? LSE? i forget mode)
<heat_>
isn't LSE the cmpxchg stuff?
<geist>
yeah uh watever it's called
<geist>
but not to get distracted
<geist>
point is riscv you have what you need there in supervisor mode. if the V extension is present and available (ie, not being nested under another hypervisor) you set up some shadow registers, set up the shadow page table, and basically eret into VS mode, where the guest is running
<geist>
it's pretty clean
<geist>
then the guest can bounce around inside it's S and U mode, but when it's in S it's really running under an alternatie shadowed regime
<geist>
(and yes i'm fucking up its and it's a lot)
<heat_>
riscv is LITERALLY 1984
<dasabhi>
jezz so the only real hardware i am running in M mode is the one i implement myself on an fpga
<heat_>
it's joever
<geist>
dasabhi: eh?
<heat_>
he's still thinking about M mode
<geist>
or any ebedded risc. or you buy a real one and root it and write your own M mode firmware, if you want
<geist>
pretty much all of the low end embedded riscv just implement M and U mode (or M mode only) which is perfectly valid
<Ermine>
mips mips mips
<heat_>
yeah the early rv socs are so boring and primitive they don't have the CLASSIFIED stuff yet
<geist>
the only required implementation of riscv is M mode. but if you have S mode you must have U, etc
<geist>
heh
* geist
goes to grab foods with fam
* geist
poofs
<heat_>
poof
<dasabhi>
thanks for all the info geist
<dasabhi>
very insightful convo today
<dasabhi>
heat_: you got a link to your kernel?
<dasabhi>
github link to your kernel work?
<heat_>
github.com/heatd/Onyx
<bslsk05>
heatd/Onyx - UNIX-like operating system written in C and C++ (10 forks/76 stargazers/NOASSERTION)
<dasabhi>
did you build this from scratch
<dasabhi>
your doc is confusing me, is it not a standalone kernel ?
<heat_>
yes
<heat_>
no it's a kernel plus userspace plus libc
<heat_>
but i mostly work on the kernel
goliath has quit [Quit: SIGSEGV]
Gooberpatrol_66 has joined #osdev
Gooberpatrol66 has quit [Ping timeout: 268 seconds]
<kof673>
> riscv is an open ISA not an open architecture so...are there any open architectures? (i am not concerned about raised issues, just asking in general)
dasabhi has quit [Ping timeout: 256 seconds]
<immibis>
an open instruction set architecture, not an open architecture?
<Mutabah>
I assume "open architecture" means that there's actual chip designs that are free for use
<Mutabah>
while RISCV
<Mutabah>
while RISCV just has minimal limits on the instruction set (i.e. the programmer interface)
<heat_>
yes that's what i meant
<Ermine>
The only difference is that you don't need to get license to produce risc-v chips
<Ermine>
like in arm case
<Ermine>
nothing demands vendors go blob-free
carbonfiber has quit [Quit: Connection closed for inactivity]
<kof673>
there are enough things like doom on a pregnancy test...if someone really wants something, it will happen (to a point)...maybe not the same level...ditto web browsers to a point
<kof673>
i don't really live in the real world so maybe my view is skewed lol
* kof673
.oO( avremu in latex ) if people have time to do that (not mocking it) then they can make "lite" versions of things
gog has quit [Quit: byee]
sbalmos has quit [Quit: WeeChat 4.2.2]
kfv has joined #osdev
kfv has quit [Client Quit]
<kof673>
i am just demanding equality i guess > xyz chose to be poor ok, then someone chose to need 64G for a web browser. that's all :D
sbalmos has joined #osdev
srjek has quit [Ping timeout: 264 seconds]
heat_ has quit [Ping timeout: 256 seconds]
agent314 has quit [Ping timeout: 246 seconds]
agent314 has joined #osdev
agent314 has quit [Ping timeout: 260 seconds]
agent314 has joined #osdev
wlemuel has joined #osdev
wlemuel has quit [Remote host closed the connection]
<kof673>
i linked something related that to before, so "parts" Aug 22, 2019 · IBM has open-sourced parts of its Power computer architecture
<kof673>
down at the bottom it mentions "SUIF" compiler, elsewhere: SUIF 1 is a parallelizing compiler and SUIF 2 performs interprocedural analysis > Cetus is a source-to-source parallelizing compiler for ISO/ANSI C
<kof673>
so that, could actually be useful
<geist>
dasabhi not really
<geist>
oh they logged off
zxrom has joined #osdev
kfv has joined #osdev
kfv has quit [Ping timeout: 272 seconds]
<ddevault>
random aside, has anyone had weird experiences with PCID not being available on AMD CPUs that are new enough where you feel like they damn well ought to have PCID
<ddevault>
do they advertise it somewhere other than the normal CPUID leaf?
<ddevault>
oh apparently AMD was just really late to the PCID game
<geist>
yeah the latter
<geist>
only showed up in like zen 2 i think
<geist>
zen 3 maybe
kfv has joined #osdev
kfv has quit [Remote host closed the connection]
dasabhi has joined #osdev
<dasabhi>
geist: hey i am here
<dasabhi>
even if i log off i monitor the irc logs from whitequark
<dasabhi>
do you guys use some kind of persistent irc client?
<kazinsal>
yeah a couple of us use irccloud
<geist>
i use irccloud, but before that i used to leave a screen session logged in somewhere
<kazinsal>
maintaining a znc instance was too much of a hassle so I just pay them five bucks a month or whatever
<dasabhi>
so yeah how complex is little kernel in reference to xv6
<dasabhi>
at a quick glance it definetly *seems* more complex
<geist>
well i dont really know xv6 at all, but LK is a different beast. it's more of a embedded, or core of a system
<dasabhi>
interesting, but it is still a generic kernel yes?
<geist>
yah
<dasabhi>
with some userspace stuff ontop?
<geist>
no
<dasabhi>
oh
<geist>
that's the big difference between it an xv6. littlekernel is just the kernel
<dasabhi>
so what is the point of the kernel then?
<geist>
you can run code in supervisor mode if you want
<geist>
can build entire embedded systems without a user space
<geist>
which is what it's mostly used for
<dasabhi>
but i have to integrate my own shell ontop is that right?
<geist>
but you can also layer a user space on top of it, which some forks do
<geist>
well, if you want a shell and you want it in user space, yes
<dasabhi>
okay interesting
<dasabhi>
zircon started off little kernel right?
<geist>
yes
<dasabhi>
why did they use LK as the base?
<geist>
because LK is a nice starting point to build more stuff on top of
<geist>
which is what a lot of folks use it for
<geist>
take LK, build your new bits on top of it, now you have a new thing
<dasabhi>
wait so without userspace, how do you test your changes?
<dasabhi>
something has to invoke the systemcalls right
<geist>
no. you dont need system calls to make a functional system
<geist>
you can start LK, run a shell, start more threads, etc. all in kernel space
<dasabhi>
wow that is new to me
<zid>
or do everything via shared memory and polling :D
<dasabhi>
so what do you have in your current repo for this, when you boot up the system
<dasabhi>
what do you get?
<geist>
the build system is very modular, so it's also possible to lay a user space on top of it. that's what my lkuser project i occasionall fiddle with does
<geist>
think of LK as a big pile of modules that let you assemble a curated kernel, drivers, and libraries to add your code to
<geist>
including a user space syscall layer that has some personality you want, and then build a user space on top
<dasabhi>
yes i understand that but currently how would you test to see a syscall is working for example
<dasabhi>
would you use lkuser?
<geist>
you are missing the point. you're assuming you need a syscall to do anything
<dasabhi>
basically how do you invoke that syscall for testing
<geist>
you have to have a syscall in the first place to test it
<geist>
there are no syscalls in the LK tree
wlemuel has quit [Quit: wlemuel]
<dasabhi>
ah
<dasabhi>
interesting
<geist>
like i said having a supervisor mode kernel with syscalls that user space writes code for is just a convention of larger systems
* kof673
gives dasabhi mmu-less system
<geist>
for most embedded stuff you just link it all together
<geist>
but then LK is flexible enough that it runs with and without mmu, with and without SMP, and nothing keeps you from building a syscall layer on top of the raw LK kernel apis
<geist>
and then implementing a user space. that's basically what zircon did
<geist>
and a few other systems that are based on like. Like, say Trusty
<geist>
or NLK
<dasabhi>
that is what i am trying to wrap my head around here
<dasabhi>
what is the point of a "kernel" on an embedded system without memory isolation
<dasabhi>
why not just write your main application as firmware
<dasabhi>
why do you really need a kernel?
<geist>
that is firmware
<geist>
it's all the same thing
<dasabhi>
is it so that the kernel can act like a library?
<geist>
right
<geist>
things like freertos are basically exactly that
<dasabhi>
ahh
<dasabhi>
ic
<geist>
link it with your code, link it in one blob of code, load it on your device, you have firmware
<dasabhi>
so it sounds like yocto linux with more steps
<dasabhi>
where i get to chose what i want through the build system to build w.e project i kind of want
<dasabhi>
well okay not exactly
<geist>
yea not exactly
<dasabhi>
but i see the point
<geist>
but what you get in the LK repo is one of many projects, and a project is basically a combination of modules. a lot of them are the -test module
kfv has joined #osdev
<geist>
which gets you a shell with a bunch of commands to fiddle with and test the system
<dasabhi>
that is interesting though, that it can be used to build an entire microkernel like zircon or can be used as a library os
<bslsk05>
travisg/toolchains - Shell script to build gcc for various architectures (33 forks/71 stargazers/MIT)
<geist>
anyway, cheers! have fun! yoiu'll have to download or build toolchains for the other arches if you want to play with them
<geist>
like riscv64, or x86_64 or so
<dasabhi>
yeah i figured
<geist>
there's some limited success using the host's toolchain for the same arch, and/or clang, but having these stock -elf ones is useful to even the playing field
<dasabhi>
so it gened the bin
<dasabhi>
i am guessing i have to feed that to qemu myself now?
<dasabhi>
first time seeing a shell inside the kernel
<ddevault>
?
<ddevault>
ah I'm missing context
<dasabhi>
not sure if you are following the previous messages
<ddevault>
yeah, apologies
<dasabhi>
was settingup littlekernel
kfv has quit [Ping timeout: 268 seconds]
<geist>
noice
<dasabhi>
oh you are here
<dasabhi>
thought you would have knocked out by now
<dasabhi>
would there happen to be a hypervisor module in little kernel
<geist>
no
<dasabhi>
would that be a useful PR?
<geist>
thought it'd be fun to do
<geist>
for what architecture?
<dasabhi>
all of them
<xenos1984>
geist: I had a look at your toolchains (nice work, btw) and I see they support C and C++, but apparently there are no freestanding C++ headers (like cstdint etc.) which are usually in include/c++ in a freestanding GCC toolchain, since these are part of libstdc++v3. So I wonder, is this an issue for compiling C++ code, which expects a freestanding C++ environment including these headers? Or am I missing something?
<dasabhi>
no thats way too much work
<dasabhi>
x86_64 riscv and arm64
aktaboot has joined #osdev
<geist>
xenos1984: yeah that's right. it is completely freestanding in that it depends on no libc support being present
<geist>
hence why it explicitly doesn't build that, that comes from the libc/OS combination that you're building with it
<geist>
the freestanding toolchains you're probably talkig about have some amount of something baked into them for that to be the case
dasabhi has quit [Quit: Lost terminal]
<xenos1984>
Hm... my understanding is that a freestanding implementation does not require a libc/OS. From http://en.cppreference.com/w/cpp/freestanding : "In a freestanding implementation, execution may happen without an operating system."
<bslsk05>
en.cppreference.com: Freestanding and hosted implementations - cppreference.com
Gooberpatrol_66 has quit [Ping timeout: 268 seconds]
<Ermine>
so eurovision winner weared win95 shirt?
kfv has joined #osdev
<xenos1984>
(Actually I am currently building my toolchain with newlib/libnosys to compile a hosted libstdc++, to get all headers, since building only the freestanding ones with --disable-hosted-libstdc++ failed as it was not supported without a libc. But that page also mentions "Some compiler vendors may not fully support freestanding implementation. For example, GCC libstdc++ has had implementation and build issues before ver
<xenos1984>
ry it again now with GCC 14.1.)
<geist>
yeah may be interesting to try again
<geist>
alas gotta go to bed right now :)
<geist>
but what you're seeing about not being able to do libstdc++ without libc is what i was talking about
<geist>
so usually the toolchains i've seen for embedded 'freestanding' usually have been built on top of newlib
<geist>
and basically just dont have much in the way of assumptions about the OS
<geist>
since LK provides it's own stripped out libc it would interact with newlib
<xenos1984>
Yes, indeed, it's even mentioned in the libstdc++ source, that it tries to build more than the C++ standard freestanding stuff even with --disable-hosted-libstdc++.
<xenos1984>
I'll give it a try and report back :)
kfv has quit [Ping timeout: 272 seconds]
zxrom has quit [Remote host closed the connection]
kfv has joined #osdev
zxrom has joined #osdev
kfv_ has joined #osdev
kfv has quit [Ping timeout: 272 seconds]
kfv_ has quit [Ping timeout: 260 seconds]
kfv has joined #osdev
heat has joined #osdev
kfv has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
theyneversleep has joined #osdev
gsekulski has joined #osdev
netbsduser has joined #osdev
gsekulski has quit [Ping timeout: 268 seconds]
heat has quit [Remote host closed the connection]
heat has joined #osdev
theyneversleep has quit [Remote host closed the connection]
xenos1984 has quit [Read error: Connection reset by peer]
<ddevault>
should I _really_ implement a blinking cursor on the framebuffer console by implementing kthreads and starting one up that does blit() sleep() unblit() in a loop
xenos1984 has joined #osdev
<kazinsal>
could just do it with your timer interrupt
<kazinsal>
hacky? a bit. easier? incredibly
<ddevault>
true
<kazinsal>
still a good idea to do kthreads but it's probably overkill to use a kthread for the framebuffer console cursor blink
foudfou_ has joined #osdev
foudfou has quit [Ping timeout: 260 seconds]
<ddevault>
kazinsal: thanks for the idea, I went with this
gsekulski has quit [Ping timeout: 268 seconds]
gsekulski has joined #osdev
<ddevault>
I'm going to need my signals to work a lot better before this isn't going to be broken
<mjg>
stuff no longer blinks on its own?
<mjg>
the only good thing about x86 was hw blinking man
<ddevault>
framebuffer vt
ppmathis has quit [Quit: Ping timeout (120 seconds)]
ppmathis has joined #osdev
<dostoyevsky2>
I prefer the nonblinking block cursor
<kof673>
eh, like mouse cursors, my #1 would be inverted lol
<dostoyevsky2>
doesn't grub also use the framebuffer? I got to check how they make the cursor blink
gsekulski has quit [Quit: Leaving.]
<Maja>
dostoyevsky2: ...do they actually bother making it blink?
<zid>
There's a background code to make it blink, but there's also a hardware cursor you can control in the ega/cga/vga spec
<zid>
invert to do block cursor, blink to do flashy
<zid>
space character with invert underline and blink gogo
<dostoyevsky2>
Maja: I haven't found yet any blinking cursor code in the framebuffer code... But grub has a terminal like vt100/vt52 builtin so they could do it via ansi escape sequences... man, wouldn't have thought that they put terminals into grub
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<dostoyevsky2>
Drawing text on the terminal via ansi escape sequences feels so inefficient and error prone, I wonder if there are better ways. I like how they did it in arcan, also it's really snappy, but you also lose a lot of features, like easily using a TUI over ssh
<bslsk05>
'[Cat9] Can your shell do this?' by crazyloglad (00:01:20)
k0valski18891621 has quit [Quit: Peace out !]
spare has joined #osdev
Matt|home has joined #osdev
m3a has joined #osdev
kfv has joined #osdev
kfv has quit [Ping timeout: 268 seconds]
kfv has joined #osdev
Arthuria has joined #osdev
divine has quit [Ping timeout: 255 seconds]
Arthuria has quit [Ping timeout: 256 seconds]
kfv has quit [Ping timeout: 246 seconds]
kfv has joined #osdev
Gooberpatrol_66 has joined #osdev
MrCryo has joined #osdev
xenos1984 has quit [Ping timeout: 240 seconds]
xenos1984 has joined #osdev
xenos1984 has quit [Ping timeout: 240 seconds]
kfv has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
xenos1984 has joined #osdev
teardown has joined #osdev
<heat>
i find blink useful in knowing that the system is definitely still alive and kicking
<heat>
vs not blinking and knowing it's hosed enough that i can't see anything at all
<kof673>
^^^
<GeDaMo>
Unless the hardware is blinking on its own without your puny software :|
xFCFFDFFFFEFFFAF has joined #osdev
brynet has quit [Quit: leaving]
Starfoxxes has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 255 seconds]
CryptoDavid has joined #osdev
brynet has joined #osdev
gog has quit [Read error: Connection reset by peer]
gog has joined #osdev
<geist>
re the blinking i think you just switch from a space with white to black background
<geist>
only real downside i have with blinking cursor is it takes a second or so for you to find it with your eye if you happen to glance while it's off
<heat>
i have a custom cursor, a slightly thicker underscore that's slightly lower down
<geist>
kinda like left/right turn signals
<geist>
usually what i do is set my terminals up to use a block cursor but with a color that stands out. like bright red or something
<geist>
and no blink
<heat>
yeah my "actual" terminals don't have blink, but i don't mind too much if its on
<heat>
i do really like it for onyx as a sanity check "yes the scheduler is running"
<geist>
word.
MrCryo has quit [Remote host closed the connection]
<heat>
so ermine has been trying out onyx on his old PC
<heat>
it turns out the firmware reserves 0x0 which i've been conveniently using as the SMP trampoline
Gooberpatrol_66 has quit [Remote host closed the connection]
<heat>
now, i don't care and i override that anyway, but it is *really* annoying and risky, even though i suspect they're reserving it for compat reasons
<geist>
ah yeah. i think i bumped into that years ago, i generally leave everything < 64K alone. but really the first page
<geist>
i hard code that sort of stuff to be 0x10000
xFCFFDFFFFEFFFAF has quit [Ping timeout: 256 seconds]
<geist>
but i've seen some e820 memory reports that also mark the first 1024 bytes or so as used
<geist>
presumably it's some vector table stuff for real mode
xFCFFDFFFFEFFFAF has joined #osdev
xFCFFEFFFFFFFFFF has joined #osdev
xFCFFDFFFFEFFFAF has quit [Ping timeout: 256 seconds]
xFCFFDFFFFEFFFA_ has joined #osdev
xFCFFEFFFFFFFFFF has quit [Ping timeout: 268 seconds]
<heat>
yeah
<heat>
i've always used 0 cuz qemu never reserved it and since it's BIOS IVT stuff i might as well just stomp all over it
<heat>
but this is risky, soooo... might as well try my hand at allocating it *before i hand regions off to the page allocator*
<heat>
i don't want to adapt my page allocator to be able to hand out memory under 1MB because that's extremely silly
<kof673>
wikipedia says 286 allowed changing it...so 286+ the BIOS/whatever could set it somewhere else, is how i interpret that. pre-286 it was stuck there
<kof673>
so, you just need to test for 286+ or not j/k
skipwich_ has joined #osdev
skipwich has quit [Ping timeout: 252 seconds]
spare has quit [Read error: Connection reset by peer]
spareproject has joined #osdev
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
xFCFFDFFFFEFFFA_ has quit [Read error: Connection reset by peer]
srjek has quit [Ping timeout: 264 seconds]
spareproject has quit [Remote host closed the connection]
aktaboot has joined #osdev
aktaboot has quit [Remote host closed the connection]
kfv has joined #osdev
kfv has quit [Client Quit]
[Kalisto] has quit [Quit: No' vemo']
[Kalisto] has joined #osdev
[Kalisto] has quit [Client Quit]
[Kalisto] has joined #osdev
troseman has joined #osdev
srjek has joined #osdev
troseman has quit [Client Quit]
<geist>
eep dumbass me updated the firmware on the switch that my VM server and NAS are connected to
<geist>
totally messed up all the VMs
<geist>
i hope they didn't corrupt their disk too hard
<heat>
what filesystem do you use?
<geist>
on what layer here?
<heat>
the vm server and NASes
<geist>
oh NFS
<geist>
it's running the disks over NFSv4.1 on the NAS box
<heat>
yeah but what do the disks use
<heat>
kinda what i meant xD
<geist>
on the nas? btrfs
<heat>
although nfs will screw up some bits of the data probably, and that's the big issue here
<geist>
on the VMs? depends on what OS they're running
<geist>
it's the sudden drop of the NFS link out from underneath it
<heat>
yeah
<heat>
does btrfs work well for you?
<geist>
yeah totally. it's a synology nas, uses btrfs natively and really has nice features
<geist>
worst case i can just restore the VMs from a btrfs snapshot
<heat>
i had little though wrt btrfs but like 2 weeks ago i saw a guy that had his system super-hosed and it turns out it was just his btrfs partition running out of disk space
<heat>
like ???
<geist>
but will lose a few days of state
<heat>
thought*
<geist>
otherwise yeahi've been using more or less exclusively btrfs on my machines for 3 or 4 years now
<geist>
never in a raid situation though, or at least if i do that i use dm-raid
<geist>
it is perfectly cromulent
navi has quit [Quit: WeeChat 4.2.1]
<heat>
god i hate that word
<geist>
teehee
<childlikempress>
it's a perfectly cromulent word
<geist>
you like your words to be embiggened
<heat>
i use ext4 and it's perfectly cromulent too
<geist>
the one i do like to use even though it's a totally UK word is 'chuffed'
<heat>
actually is there a difference between zfs/btrfs and data-journalled ext4/xfs?
<heat>
besides the block checksums which may or may not be a big thing depending on your angle
<heat>
cuz, you know, no way zfs cannot lose data unless it keeps churning IO on every syscall?
<geist>
it's copy on write, has sub-volumes, lets you snapshot, lets you do shallow copies
<geist>
shallow copies are fantastic
<geist>
modern gnu cp actually automatically does it unless you override with --reflink=never
<geist>
you copy some 20GB file and it returns instantly
<geist>
you should be suspicious!
<heat>
sussy copy
<geist>
but you can also dedupe stuff, there's an ioctl that lets you say 'this range of file is the same as range Y of that file and range Z of that file'
<nortti>
doesn't XFS do reflinks too?
<heat>
i believe so
<geist>
it checks before commiting it, but there are some tools that exhaustively scan files for candidates