<ohnx>
ah i have found `info irq` and it seems to show that interrupt 0 is getting fired, so it's definitely not the timer setup code... i'll have to take a closer look at my stuff. thanks, y'all!
<zid>
-d int :P
<klange>
- If you aren't enjoying what you're doing, stop now and find something else.
<zid>
osdev is just a sandbox playground to have fun in anyway
<kazinsal>
osdev was partially responsible for me landing my current job. not because of the code itself, just the sheer nerdery of the dedication required to spend a decade mucking around in the guts of kernel land
<kazinsal>
the code I actually write is completely irrelevant to my job. I get paid to work on datacenter infrastructure.
<graphitemaster>
POSIX compatibility is impossible and if you actually try to implement it you'll just have a Linux or BSD.
<klange>
- The things POSIX specifies and the things people seem to think POSIX specifies have very little overlap.
<junon>
yeah I've ditched POSIX entirely, I'll let someone else care about that if it ever comes to it lol
<junon>
but POSIX has little to do with the kernel anyway
<zid>
yea OS has two meanings here
<zid>
either 'just the kernel' or 'the entire platform'
<junon>
yeah
<zid>
I only *really* care about the former
<junon>
I care about both but still don't care about POSIX.
<junon>
:D
<graphitemaster>
- Having your OS compile itself isn't a valuable use of your time, then again neither is making your own OS.
<klange>
- Trying to make everything yourself just means you have a huge collection of garbage.
<blockhead>
i'd say having an OS compile itself is a rigorous sure-fire acid test?
<klange>
Not at all. A C compiler, even gcc, has very little interaction with the OS. Really simple file stuff and that's about it.
freakazoid343 has quit [Ping timeout: 252 seconds]
<blockhead>
oh, ok
<kazinsal>
I'd make the argument that having a self-hosting OS is a goal for a specific type of OS and is not a generic goal for all osdev
<blockhead>
we'll call that one of my baby questions then :p
<zid>
I really really don't care about hosting gcc
<kazinsal>
nobody is looking for a router that can compile itself ;)
<junon>
as long as it can open, read and write files, compilation isn't really special
<zid>
gcc is a beast of a project that needs a lot of infrastructure to build
<zid>
shells, make, etc all adds up even if gcc itself doesn't need many syscalls
<junon>
That's true, but that's also why I don't really like gcc.
<junon>
I use clang to build. Maybe it'll bite me, idk.,
* blockhead
ponders a router that can compile itself
<junon>
been working swell so far.
<zid>
I think its output is fabulous, shame that they started to rewrite half of it in C++ :P
<junon>
any openwrt installation can compile itself.
<klange>
clang is, frankly, worse in that regard
<zid>
I tried to compile llvm once and gave up on my 8th build system installation
<zid>
even just packaging llvm is too hard for me
<zid>
much less hosting that
<klange>
llvm's build infrastructure is gargantuan
<junon>
clang just needs cmake + a C++ compiler though. I use `ninja`, too. But I've never had issues building it.
<junon>
It just takes ages.
<kazinsal>
yeah, see, this is why I just download geist's toolchain script whenever I realize I need to update my archaic GCC toolchain]
<blockhead>
i keep misreading llvm as lvm and vice versa. name choices for software can be unfortunate
<zid>
My rule is that if you want a bizzare build system, you include it as source in your project and build it with make
<junon>
llvm has e.g. tablegen and stuff but it builds it all directly, anyway
<kazinsal>
easier to just hit `./doit` and go grab a coffee
<zid>
see: Kconfig for the linux kernel
<junon>
zid: my build system just needs `sh` and a C compiler on the PATH. :D
<klange>
my makefile builds a local tiny kuroko to run the interesting parts
<junon>
even better.
<zid>
junon: yea most of my code is perfectly happy with gcc -Iinclude *.c -o out
<junon>
it builds a custom Lua harness that runs a custom build system
<junon>
but everything is self-contained.
<zid>
kernel also needs -mno-redzone and stuff on top but is still just effectively gcc *.c
* kazinsal
should probably move from his current build setup of { bash + make that's a lot of bash + three tools in C + one tool in python } to something a little less absurd
<klange>
anyway, yeah, I'm done with this; got 2.0 out, that's a nice place to end it
<junon>
Congrats Klange :) Good work.
gxt has quit [Quit: WeeChat 3.3]
<klange>
I had all sorts of other stuff I wanted to do but I just can't pull together the motivation any more.
<bslsk05>
oro-os/build - The Oro build system (0 forks/0 stargazers)
gxt has joined #osdev
<junon>
I thought I finished the docs for it but nope, not yet.
stosby has joined #osdev
stosby has left #osdev [#osdev]
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
Burgundy has quit [Ping timeout: 240 seconds]
<zid>
gog: I've not had any pull requests for gb audio, I don't think you offered him enough
<gog>
sorry I'll promise sexual favors next time
<zid>
I keep telling you to stop privmsging me those, you never listen
<gog>
scurrilous lies
<zid>
oh yes, that's it baby, spell those complicated words
<kazinsal>
does mrs. gog know about these scandalous messages
<kazinsal>
or perhaps she is a co-conspirator in crafting lewd imagery
<gog>
she knows about all my scandalous behaviors and exploits and will corroborate my alibi
freakazoid12345 has joined #osdev
ajoberstar has joined #osdev
* kingoffrance
reads scrollback
<kingoffrance>
1) sector lisp interesting they use lowest common denominator to implement lang x inside y 2) overlapping variable length instructions, interesting too; interesting what a cpu and assembler etc. purposely doing that could do to code size; its almost like prefix strings or i forget the names, critical bit trees, julia something or other 3) i knew mary poppins was always trouble
<kingoffrance>
1) i think is obvious, just usually discouraged, normally one tries to be idiomatic inside lang x, not create a new subset "idioms between langs"
<klange>
sector lisp... meanwhile, kuroko-efi is 501K
<blockhead>
sector lisp has 40 bytes for the garbage collector, iirc. damn impressive
<klange>
Even if I just had the runtime VM, required strings for magic methods amount to more than 512 bytes.
<klange>
I don't think 512 bytes would even cover the jump table for my opcodes.
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
thaumavorio has joined #osdev
xing_song has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
ravan has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
sdfgsdfg has joined #osdev
ElectronApps has joined #osdev
nyah has quit [Ping timeout: 240 seconds]
darkstardevx has joined #osdev
darkstardevx has quit [Remote host closed the connection]
darkstardevx has joined #osdev
xenos1984 has quit [Quit: Leaving.]
eryjus has quit [Ping timeout: 240 seconds]
MarchHare has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
m3a has quit [Quit: leaving]
ravan has quit [Read error: Connection reset by peer]
ravan has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
xenos1984 has joined #osdev
mctpyt has quit [Ping timeout: 256 seconds]
wikan has joined #osdev
xenos1984 has quit [Ping timeout: 256 seconds]
xenos1984 has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
xenos1984 has quit [Quit: Leaving.]
wikan has quit [Quit: Ping timeout (120 seconds)]
wikan has joined #osdev
GeDaMo has joined #osdev
wikan has quit [Quit: Client closed]
MarchHare has quit [Quit: Leaving]
sdfgsdfg has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
archenoth has joined #osdev
Oshawott has quit [Ping timeout: 240 seconds]
<geist>
suddenly have the urge for Salmiakki
<geist>
had it once and i remember it being not too bad once you got used to it
* gog
sends some to geist
sdfgsdfg has quit [Quit: ZzzZ]
<gog>
i like it actually, but the smell reminds me of the time i was doing some urban exploration as a child and went to a local farm co-op and got chased off by some employees from the fertilizer shed :p
<geist>
heh
<geist>
yeah i think i know what you mean, that particular fertilizer smell is pretty distinct
Burgundy has joined #osdev
<gog>
yeah ammonium chloride kinda tastes like ammonium nitrate smells
<gog>
very sharp tanginess
<gog>
weird nostalgia about my latchkey childhood and running around with my juvenile delinquent friends lol
<ZetItUp>
i don't have that, but i have a clip of a finnish guy blowing up a Tesla with 30kg dynamite if that is of interest :D https://youtu.be/7_9aVzf5fC4?t=309
<bslsk05>
'Mies joka räjäytti TESLANSA!! Tesla Model S & 30kg dynamiittia.' by Pommijätkät (00:08:27)
<zid>
whois FireFly
<zid>
shit my stalking has been foiled
<zid>
what's a gluehwuermchen anyway
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
* gog
mews at FireFly
xenos1984 has joined #osdev
<FireFly>
zid: ask the germans
* FireFly
pets gog
<FireFly>
(a glühwürmchen is just a firefly, well, I guess more of a glowworm but...)
<FireFly>
same deal with Luciole, except it's more francophone
xenos1984 has quit [Quit: Leaving.]
gog` has joined #osdev
* kingoffrance
pets both gogs while there is a window
gog has quit [Ping timeout: 240 seconds]
wikan has quit [Quit: Client closed]
<gog`>
good timing
sdfgsdfg has joined #osdev
<FireFly>
double cats :o
gog` has quit [Read error: Connection reset by peer]
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
pretty_dumm_guy has joined #osdev
ahalaney has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
nyah has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
TheArcticCat has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
ahalaney has quit [Quit: Leaving]
gog has joined #osdev
Piraty has quit [Quit: -]
xing_song has joined #osdev
ravan has quit [Remote host closed the connection]
ravan has joined #osdev
Piraty has joined #osdev
gog has quit [Read error: Connection reset by peer]
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
zaquest has quit [Remote host closed the connection]
<junon>
so many cats
<junon>
so little scritch
<junon>
my mom sent me cheetos in a care package and I'm in heaven rn. can't get them in europe.
zaquest has joined #osdev
ElectronApps has quit [Remote host closed the connection]
gog has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
<blockhead>
mmm, cheetos!
* gog
chomps
scoobydoo_ has joined #osdev
scoobydoo has quit [Ping timeout: 256 seconds]
scoobydoo_ is now known as scoobydoo
dude12312414 has joined #osdev
xenos1984 has joined #osdev
mahmutov_ has joined #osdev
mahmutov_ has quit [Quit: WeeChat 3.1]
mahmutov has joined #osdev
skipwich has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
Oli has joined #osdev
nyah has quit [Remote host closed the connection]
xenos1984 has quit [Quit: Leaving.]
<junon>
finally got to open that super weird clang bug I found a few weeks ago now that they migrated the bugzilla over
<bslsk05>
github.com: Using an enum constant defined within a struct and brought into scope using a `using enum` statement within a compound expression causes a segfault · Issue #52856 · llvm/llvm-project · GitHub
<junon>
pre-reqs are c++20, `enum` defined within a struct or a class (not a namespace), brought into scope using `using enum foo`, and a constant from that enum being used in a compound expression (parens)
<junon>
which emits a diagnostic about overloaded function addresses
<junon>
bonus points if you do arithmetic on the constant (e.g. `(A|B)`) in which case clang segfaults altogether
<geist>
hmmm that vid with the finnish guy blowing up the tesla. he sounds just like the guy that made the 'my summer car' game a few years back
<geist>
i wonder if it's the same dude
<geist>
hmm it's not. finnish is just such a strange language
Oli has quit [Quit: leaving]
gog has quit []
gog has joined #osdev
freakazoid12345 has quit [Ping timeout: 260 seconds]
freakazoid12345 has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
<junon>
does changing the read/write permissions of a page cost a lot? does it require a TLB flush or something?
<mjg>
fighting cow?
<junon>
crouching tiger
<junon>
jk
<junon>
no not doing cow
<junon>
though similar approach
<junon>
different goal
<mjg>
afair any change to page tables requires tlb shootdown
<mjg>
i presume we are talking x86 here
<junon>
yes
<junon>
though I'll want to do something similar/the same on arm
<junon>
so any extra info there would be cool too
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<junon>
I'm exploring some designs so nothing is being written yet, just trying to understand performance costs
GeDaMo has quit [Remote host closed the connection]
<bslsk05>
developer.amd.com: Developer Guides, Manuals & ISA Documents - AMD
<geist>
junon: it actually depends
mahmutov has quit [Ping timeout: 240 seconds]
<geist>
but in general yes, there can be TLB entries that have RO or RW set. but... in general if you're raising the permission (ie, adding W) then you can most of the time delay doing a TLB flush
<geist>
because probably the cpu(s) dont have a existing RO entry, and next time they hit the page they'll load a new fresh RW entry
<geist>
and if they *do* have a RO entry, they'll worst case page fault and then your code can drill down and decide 'nope this is extraneous' and continue on
misnor has joined #osdev
<geist>
but if you're lowering a permission on an existing page or changing the translation you must flush immediately
<geist>
note the 'raising permission, no need to up front flush' thing is similar to the general reason you dont have to flush when adding a new mapping. there isn't an existing entry in any cpus that is contrary to the new one you added, thus you dont have to TLB shoot down it
<geist>
in my experience all cpus that have a paging MMU use some sort of TLB like scheme, and pretty much they all follow the same rules here: a) only save TLB entries for things they've seen and b) never store 'negative' entries
<geist>
b) is the real key one, since it's the fundamental reason why you can delay TLB flushing in many cases
rorx has quit [Ping timeout: 240 seconds]
<junon>
Good to know, thanks geist. I was hoping that was the case.
<junon>
Though you mention I can decide it's extraneous; do you mean I can ignore the fault and allow the write anyway on a case by case basis? Or would the fault handler have to set the writable bit?
<geist>
you'll pretty much always have to have logic in your page fault path that decides it was an extraneous fault. on a UP system you can probably arrange for that to never happen if you conservatively TLB flush (ie, dont do the optimization i mentioned above) but on SMP you generally have to always be prepared to handle other cpus faulting on things that are being changed
<mjg>
faulting on write to a ro page is the standard cow case
<geist>
so there's lots of cases where you, for example, go to map a page and simultaneously another core page faults on it, but their PF handler hits a lock so it goes into some sort of wait for you to finish mapping the page, then when the cpu triggers it turns out it was extraneous
<geist>
so in that case you always have to be prepared for the PF logic to decide the cpu faulted on something in the past thats no longer truth, and let it retry
<geist>
so, for example for the case of a cpu faulting RW on a RW page, it could be precisely because it raced with a RO -> RW elevation of the same page. that's okay.
<geist>
you just have to handle the general notion that there's multiple timelines operating in parallel on each core, but as long as you establish that there's a point in time for every operation where truth is what is precisely present in the page tables (or VM data structures) you're okay
<geist>
but. even on UP if you dont TLB flush on RO->RW you can get the same thing, due to the optimization above. which would be fine
<geist>
OTOH on single cpu (UP) it's not a big deal to just TLB flush it because local TLB flushes aren't expensive
<geist>
sorry if i'm not explaining it well
<geist>
re: fault handler setting the RW bit that's a different case that mjg alluded to
<junon>
you are, thank you
<junon>
I just had to read it a few times but I understand everything
<geist>
that's a case where the page is marked RO, the cpu trips a RW fault, and then based on previous data structures you set up you decide to COW the page and flip it to RW. though generally in that case you're not so much flipping it to RW but finding a new page, making a copy into it, and then replacing the old mapping with a RW mapping
<geist>
and thats *definitely* a different mapping, and you should probably TLB flush that
<mjg>
but you may be the last user of the page
<mjg>
in which case ou can just continue
<junon>
Interesting okay
<geist>
oh sure, but that's a higher level data structure concern. that gets into high level VM COW optimizations and etc
<geist>
but your PF handler will eventually need to consult the high level VM to make sure it's doing the right thing before it does it
<geist>
or however you decide to structure it
<junon>
you mentioned local TLB flushes are cheap; how cheap? can you measure it in terms of clock cycles?
<geist>
depends on the arch, but yeah clock cycles
<geist>
it almost certainly wouldn't be substantial amount of cycles compared to the entire operation of taking the PF and drilling through page tables and whatnot
<geist>
on lameass arches like x86 though cross-cpu TLB shootdowns are a huge cost, so you avoid them like the plague
<junon>
in this case I'd be constraining the R/W to a single thread
<junon>
so cross-cpu TLB flushing wouldn't need to happen I don't think
<junon>
just local
<geist>
sure. the cross-cpu TLB stuff is just a given based on having SMP or not. not much you can do there
<junon>
yeah
<geist>
and there are various optimizations there, but they're more global, like being careful where you schedule things, or tracking which cpu may have mappings present, or lazy flushing at idle time, etc etc
ravan has quit [Remote host closed the connection]
ravan has joined #osdev
<junon>
gotcha, okay. cool.
<junon>
invlpg from the i486 is used to do a local flush right?
<junon>
then the cr3 register is to do a full flush or something?
<junon>
and to do inter-processor flushing you need something higher level to coordinate that
<geist>
both are local flushes, invlpg is just a single page vs all the pages (minus global pages)
<junon>
Ohh okay I see. I didn't realize you could do just a single page :o
<geist>
yah invlpg <memory address> basically
rorx has joined #osdev
<geist>
reloading cr3 dumps all TLB entries except pages marked global
<geist>
but i think 'g' pages came along around pentium
<junon>
physical address within the page? or the actual address within the page tables?
<geist>
virtual address
<junon>
of the entry I mean
<junon>
Oh! okay.
<junon>
derp
<geist>
virtual address as is currently mapped. think of the cpu as doing a TLB lookup through normal mechanism of matching vaddr -> TLB and then just dumping that entry
<geist>
so that's why it's pretty quick. i dont know what the cycle count is, but it's not substantial
<geist>
note there are newer modifications to this (PCID, Zen 3 cross cpu shootdown, etc) but those are more advanced bits that came along in the 2010s
<geist>
x86 is slowly getting dragged into the 90s of MMU design
<mjg>
if i had a nickel ever time i see people shitting on x86
<mjg>
x86 is like linux of kernels, it's incredibly widespread and people don't know any better
<geist>
heh i know. i like ripping on it. i guess i should stop but i do like to point out that there are better schemes
<geist>
sad to see that riscv is trying the uber simple route so it has basically 486 level mmu optimization possibilities
<geist>
but if you design for exactly current gen x86 (full PCID with cross aspace shootdown and/or Zen 3 style cross cpu shootdown) then it gets pretty nice
<geist>
and it's clear the Zen 3 TLB stuff is a direct descendant of the arm64 work they had done
<geist>
since it's almost precisely the same scheme
<mjg>
i don't mind
<mjg>
shitting on stuff is bread and butter of polish heritage
<mjg>
you may have polish ancestors somehere in the bloodline
<geist>
haha
<geist>
actually my sister just did a 23andme. mostly german and hodgepodge of UK
xenos1984 has joined #osdev
sdfgsdfg has joined #osdev
<zid>
to some 40% confidence interval no doubt :P
<geist>
possibly. actually the results were pretty darn precise