vdamewood has quit [Read error: Connection reset by peer]
gog has quit [Ping timeout: 250 seconds]
vdamewood has joined #osdev
k8yun has joined #osdev
gog has joined #osdev
Brnocrist has quit [Ping timeout: 260 seconds]
Brnocrist has joined #osdev
Terlisimo has quit [Quit: Connection reset by beer]
Likorn has quit [Quit: WeeChat 3.4]
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
Brnocrist has quit [Ping timeout: 260 seconds]
Terlisimo has joined #osdev
gog has quit [Ping timeout: 260 seconds]
Brnocrist has joined #osdev
freakazoid343 has joined #osdev
nyah has quit [Quit: leaving]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
Mutabah has quit [Ping timeout: 260 seconds]
Mutabah has joined #osdev
Mutabah has quit [Ping timeout: 260 seconds]
Mutabah has joined #osdev
sonny has joined #osdev
_xor has joined #osdev
_xor has quit [Quit: WeeChat 3.4.1]
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
mahmutov has quit [Ping timeout: 246 seconds]
srjek has quit [Ping timeout: 240 seconds]
Mutabah has quit [Ping timeout: 272 seconds]
Mutabah has joined #osdev
sonny has quit [Quit: Ping timeout (120 seconds)]
<heat>
compiling llvm with gcc is physical pain
<heat>
5GB of swap are being used!
<heat>
89ºC average temps 😎
<heat>
i'm owning global warming with my llvm builds and forgetting to use clang to build them
<moon-child>
little tidbit I read somewhere: clang runs faster when built by clang, and gcc runs faster when built by gcc
<moon-child>
or, put another way: clang is tuned to optimize clang, and gcc is tuned to optimize gcc
<heat>
clang builds clang a lot faster than gcc does
<heat>
gcc builds gcc a tiny bit faster than clang
<heat>
and ld.lld is way faster than any other linker
<moon-child>
I meant the speed of the generated compiler on arbitrary code
<heat>
(except mold but that one technically isn't ELF standard compliant)
<heat>
yeah i understood
* moon-child
nods
<moon-child>
I think mold is planning to support elf fully, just not there yet. But neither mold nor lld can do linker scripts, sooo
<heat>
lld can lol
<moon-child>
wait it can?
<moon-child>
since when?
<heat>
yup
<heat>
since a long time ago
<heat>
fuchsia helped it get there
<klange>
lld has had support for binutils ldscripts for a while now
<heat>
but it can succesfully link fuchsia, linux
<heat>
my kernel too
<moon-child>
'unknown section directive: 4K'
<moon-child>
and link time isn't a bottleneck for me anyway, yet. But good to know
<heat>
use 4096
<heat>
if non-lto link time is a bottleneck for a kernel, delet
<heat>
i set out to make my OS buildable by full llvm (clang + lld) and full gnu (gcc + binutils) and it damn sure does that
<heat>
only my gcc package fails to build because gcc goes brrrr
<heat>
gcc needs the multilib configuration to build the runtime and it can only get that from the cross gcc or the compiler that's building it
<heat>
if the xgcc is for another system and the compiler isn't gcc, well, it's screwed
bradd has quit [Read error: Connection reset by peer]
bradd has joined #osdev
sonny has joined #osdev
sonny has left #osdev [#osdev]
heat has quit [Ping timeout: 260 seconds]
kingoffrance has quit [Ping timeout: 240 seconds]
k8yun has quit [Quit: Leaving]
atrapa has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
kingoffrance has joined #osdev
freakazoid343 has quit [Ping timeout: 256 seconds]
gog has joined #osdev
C-Man has quit [Ping timeout: 246 seconds]
gmodena has joined #osdev
GeDaMo has joined #osdev
no-n has quit []
* vdamewood
gives gog a fishy.
* gog
eats fishy
vimal has quit [Quit: Leaving]
bauen1 has quit [Ping timeout: 246 seconds]
<Griwes>
Whew, just wrote a lot of code that just worked out of the box up until a point where I knew it wouldn't and how it wouldn't and that's exactly what happened. I should probably end coding for the evening on this unusually high note
<mjg>
magic code which happens to work from the get go tends to have nasty bugs man
<Griwes>
It's not even magic, just a bunch of it
<moon-child>
mjg: eh, let him have his moment :)
<Griwes>
I *am* about to make userspace do its first mapping of memory fully on its own, once I finish one more syscall, but I'll do that tomorrow
<Griwes>
Well, "finish" the syscall, most of this will require a *lot* more thought to get this into a reasonable shape with permissions and whatnot
<mjg>
back when i was a student i wrote a toy malloc
<mjg>
i figured i will give it a first run by employing it in gcc
<mjg>
aand it worked fine
<moon-child>
I can see where this is going
<mjg>
or so i thought, turns out it did not use it :D
<mjg>
i got my crashes after i fixed that problem
<moon-child>
oh lol whelp
<moon-child>
I was hoping for really subtle miscompilation
<mjg>
i don't know if you can realistically mess this up in the suggested manner
<mjg>
by accident i mean
<mjg>
it would definitely make for a good story though
<moon-child>
yeah
vimal has joined #osdev
Burgundy has joined #osdev
bauen1 has joined #osdev
C-Man has joined #osdev
Jari-- has quit [Ping timeout: 246 seconds]
the_lanetly_052 has quit [Ping timeout: 246 seconds]
<bslsk05>
www.theregister.com: Helios-NG: An open source cluster OS • The Register
<GeDaMo>
I have a vague memory it's because there was a 68K version of Tripos and they used that as the basis for Amiga's DOS
Optimus has joined #osdev
<geist>
yep thats exactly what it was
<GeDaMo>
And Atari used CP/M 68K as the basis of their TOS :P
<GeDaMo>
Also DR's GEM GUI
wootehfoot has quit [Ping timeout: 260 seconds]
<catern>
related to my post, does anyone have pointers to systems which can tolerate memory failures? i'm sure there are OSs which could tolerate this (I think Linux even could handle it, if the memory was hotplugged after boot)
<GeDaMo>
Wasn't there a fault tolerant system called Tandem?
<geist>
yah was just trying to remember the name
<geist>
iirc it ran two machines in parallel, cross checking each other
<j`ey>
Tandembaum :P
<geist>
dunno precisely how it handled failures
<GeDaMo>
"To contain the scope of failures and of corrupted data, these multi-computer systems have no shared central components, not even main memory." https://en.wikipedia.org/wiki/Tandem_Computers
<bslsk05>
en.wikipedia.org: Tandem Computers - Wikipedia
<catern>
hm, I'm hoping for something more conventional - like, you could imagine an OS being able to tolerate some physical memory disappearing out from under you, if it doesn't contain any kernel data
<catern>
just kill everything using that memory and carry on
<GeDaMo>
How do you detect that the memory isn't there?
<catern>
i guess you start getting faults when processes try to write to it?
<GeDaMo>
A segmentation fault has to do with page permissions, not hardware defects
<GeDaMo>
There's no guarantee that accessing non-existent memory wouldn't just return random values
<GeDaMo>
Unless you have error detection / correction in hardware
<gog>
yeah you'd have to have a hotplug mechanism on the memory
<GeDaMo>
I'm not sure if something like ECC notifies the OS of problems like that
<gog>
which does exist
<catern>
well i have no idea, what normally happens when you try to access a physical address which doesn't exist?
<gog>
undefined behavior
<gog>
and it might even depend on the range of addresses, what the memory controller is wired or programmed to do in that event
<gog>
if anything at all
<geist>
i thought i remember hearing that some of the big sun servers could handle live hot plugging of memory
<catern>
geist: well, Linux can
<geist>
but pobably more of an ECC failure rate, move stuff off that stick, let you swap it live
<gog>
geist: yeeah i've only heard of high-availability systems having that capability
<catern>
but I'm talking about if you, say, pull a stick out at random
<gog>
sun servers would be in that category
<geist>
same with hot plugging cpus
<kingoffrance>
^
<catern>
gog: okay, so you don't know what happen? that's fine, maybe someone else knows
<kingoffrance>
e4500 had little boards cpu +ram
<gog>
catern: i'm saying it's gonna depend on the system
<geist>
catern: i doubt it.
<catern>
gog: yes, that's why I said "normally"
<geist>
basically pulling out a stick on a running system, unless the hardware is doing effectively some sort of memory RAID is probably going to be bad no matter how you cut it
<gog>
and doing it randomly without telling the OS so it can tell the hardware will leave the data bus floating
<geist>
since any reasonably modern system will end up user and kernel data all over all of the ticks
<geist>
so chances are you'll take out something critical
<geist>
or a little piece of effectively everything
<kingoffrance>
there were basically 4 more of those "slots" on the back, and perhaps rules which could take cpu/ram board, or I/O, or some other type
<gog>
what is this a server for ants?
<geist>
yah surprisingly couldn't find a bigger picture, but this was a server from 25 years ago
<kingoffrance>
guessing those are scsi hard drives geist
<geist>
yah iirc at the time they were dual or quad core ppro 200s
<geist>
serious computing
<geist>
i think 9GB SCSI 10k was pretty much the best thing you could get
freakazoid343 has quit [Remote host closed the connection]
<geist>
would have been i guess around 1997
bauen1_ has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
dennis95 has joined #osdev
pretty_dumm_guy has joined #osdev
bauen1 has quit [Ping timeout: 256 seconds]
freakazoid343 has joined #osdev
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
scripted has joined #osdev
<scripted>
Hello people. I'm stuck with this page frame allocator I tried to write using a tutorial. So the issue is that the both variables (end_mmap_addr and curr_mmap_addr) are 0, so I think I've made a mistake while passing the multiboot structure. The line I'm talking about is 20 https://github.com/ScriptedDeveloper/CrazeOS/blob/unstable/src/pageframe/pageframe.c
<bslsk05>
github.com: CrazeOS/pageframe.c at unstable · ScriptedDeveloper/CrazeOS · GitHub
bauen1 has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
scripted has quit [Ping timeout: 256 seconds]
heat has joined #osdev
<heat>
scripted I know you're not here, but you never set your mbd global
<heat>
it's just NULL
<GeDaMo>
You could try sending them a message through memoserv
freakazoid343 has quit [Read error: Connection reset by peer]
dennis95 has quit [Quit: Leaving]
GeDaMo has quit [Remote host closed the connection]
freakazoid343 has joined #osdev
atrapa has quit [Quit: atrapa]
<gorgonical>
geist: I am reading that Zircon takes thousands of cycles for round-trip IPC, where something like L4 is just under a thousand. Is that architectural or just the result of Zircon maybe not being as optimized?
<gorgonical>
I know L4 and its kin have been studied, written, and re-written over like 3 decades now
epony has quit [Quit: QUIT]
freakazoid343 has quit [Ping timeout: 240 seconds]
Burgundy has quit [Ping timeout: 260 seconds]
chibill[m] has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<geist>
completely different design
<geist>
also really hard to compare synchronous and asynchronous microkernels, since they tend to have a different set of expectations as to what you can do per IPC
<geist>
the IPC (of which there are a few different types) on zircon can do much more than a synchronous L4 call
<gorgonical>
is Zircon synchronous?
<heat>
no
<geist>
no
<heat>
jinx
<gorgonical>
I see
<gorgonical>
Makes a lot more sense
<geist>
so usually that's the spin that sync ukernels have: "we are so much faster!" which at the atomic level sure
<geist>
but it's really hard to compare because a single sync call does less
<geist>
not that i'm not a fan of sync microkernels, i think they're great
<geist>
i implemented one a while back, following the QNX model. would like to do that again some time
<gorgonical>
I'm actually working on implementing an L4-alike
<geist>
if nothing else because its less kernel code. very elegant, though it moves the load somewhere else
<gorgonical>
Slowly*, but I am
<geist>
but many times real workhorses are not as elegant as you'd like, since getting stuff done is the general requirement
<Ermine>
So there's no consensus on synchronous vs asynchronous microkernels?
<geist>
that's also fun about hobby os stuff, you're usually not reqiuired to actually do anything for a production environment. so you can err o the side of simple or elegant and feel good about it
<geist>
haha consensus
<gorgonical>
Because recently microkernels are coming back due to hardware changes I would say even the consensus that monolithic > microkernels is lost
<gorgonical>
Not even to mention that Minix is probably the most widely-used kernel on earth
* geist
rolls eyes
<gorgonical>
lol
<Ermine>
Hehe
<geist>
i've heard that so many times. by that metric i bet vxworks or freertos is
<geist>
or that gigantic piece of the pie: <misc>
<gorgonical>
Sort of how Java claims several billion devices use it when you install the runtime
<geist>
or hell, even LK. probably a few billion of those
<gorgonical>
Unfalsifiable, but plausible
<Ermine>
LK = little kernel?
<klange>
java gets that claim from technicalities like javacard
<geist>
but yes ukernels have never really gone away, in embedded or constrained environments they have been a workhorse
<geist>
hell, even my car (Subaru) has QNX all over it
<geist>
was digging through the firmware update blob. it's all kinds of QNX
<geist>
Ermine: yeah
<klange>
My motorcycle runs Linux - and shockingly to me, was built with an Angstrom tool chain. In 2020.
<Ermine>
I did some key combination on samsung galaxy ace while powering it on, and it showed me 'little kernel' string. And nothing more
<gorgonical>
klange: that sentence sounds like something a crazed cyberdeck cowboy would say in a late 90's scifi novel
<gorgonical>
"my motorcycle runs linux"
* Ermine
is now interested which os powers our car
sonny has joined #osdev
<gog>
i'm gonna install haikuon the computer i replace my autonomic nervous system with
<gorgonical>
Gotta go with ReactOS. That's what it does, reactions
<gorgonical>
duh
<gog>
hah
<jimbzy>
You silly fools and your vehicles that "run". Mine sits on concrete blocks on the front lawn!
* Ermine
dreams of having his router running microkernel os
<klange>
You have a *lawn*?
<klange>
Lucky.
<gorgonical>
I would 100% trade having a lawson's for the lawn I have
<klange>
Speaking of which... brb
<jimbzy>
Two of them, klange. One in the front and one in the back.
<gog>
car? i have feet
<gog>
and a bus pass
<jimbzy>
I walk a lot here.
<Ermine>
You guys are moving?
<gorgonical>
Just up and down the two lawns
<jimbzy>
Nah, mostly on the sidewalk but sometimes I venture out into the street like a rebel.
<gog>
hell yeah
sonny has left #osdev [Closing Window]
the_lanetly_052_ has joined #osdev
mahmutov_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 260 seconds]
mahmutov has quit [Ping timeout: 272 seconds]
Payam38 has quit [Quit: Client closed]
dzwdz has quit [Ping timeout: 240 seconds]
dzwdz has joined #osdev
nyah has quit [Ping timeout: 260 seconds]
<Bitweasil>
I have the weed fields... lawn is an optimistic aspirational term.
<gorgonical>
I've heard goats are really great for lawn management
<Bitweasil>
Problem with goats is that they "manage" everything else around, too.
<gorgonical>
What, you don't want your entire front lawn to be surrounded by chicken wire just to control your lawngoats?
Likorn has quit [Quit: WeeChat 3.4]
<zid>
You just stake the goat down
<zid>
and it eats away a perfect circle of destruction
<Ermine>
Goats should not overmanage the lawn
heat has quit [Remote host closed the connection]
Vercas has quit [Ping timeout: 240 seconds]
<zid>
IAC SHOULD NOT grass IAC
Optimus has quit []
dude12312414 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 272 seconds]