<kaichiuchi>
i ran nvidia-xconfig and now SDDM isn't launching.
<kaichiuchi>
I'm really serious
<kaichiuchi>
I have no idea how you guys use this
<heat>
why did you run that
<heat>
also consider that 1) you're using X11
<heat>
it's as brittle as always
<heat>
KDE can use wayland, i'm on it right now
<kaichiuchi>
there are a shitton of showstoppers
<kaichiuchi>
no
<kaichiuchi>
also for some reason it thinks the maximum refresh rate is 98Hz on both of my 144Hz monitors *before this*
<kaichiuchi>
"this" being "before I ran nvidia-xconfig
<heat>
"The proprietary NVIDIA graphics card driver does not need any Xorg server configuration file. You can start X to see if the Xorg server will function correctly without a configuration file."
<kaichiuchi>
yes and it didn't function correctly because apparently I only had access to 98Hz
<heat>
what xorg video driver are you using?
<kaichiuchi>
i did `pacman -S nvidia nvidia-utils`
<kaichiuchi>
that was my only crime
<heat>
I mean xorg video driver
<heat>
xf86-video-...
<kaichiuchi>
uhhhh
<kaichiuchi>
i'm not
<heat>
termbin your /var/log/Xorg.0.log
<kaichiuchi>
this is too much for me
<kaichiuchi>
ubuntu worked straightaway
<heat>
you're like almost there
<heat>
come on
<sonny>
I knew it was arch
dra has quit [Ping timeout: 252 seconds]
<kaichiuchi>
so I had to remove the xorg.conf that the fucking NVIDIA tool generated for shit to work again
<kaichiuchi>
"ERROR: NVIDIA driver is not loaded"
<kaichiuchi>
my fucking ASS
<geist>
oh are you inflicting arch on kaichiuchi ?
<kaichiuchi>
it's torture
<heat>
it's self inflicted
<heat>
I just encouraged
<sonny>
it's not terrible after you do it 10 times, still forget to do somethings like install grub config, or messing up the paritions
<sonny>
it could be automated though ...
<heat>
arch has an installer now you can use
<geist>
was kinda like when gentoo starting starting with the stage 3. bah!
<kaichiuchi>
isn't it in beta
<geist>
stage 1 or gtfo
<sonny>
*bsd have the best install experience, just hit next
<kaichiuchi>
yes
<kaichiuchi>
this is why I cannot believe BSD didn't win
<sonny>
win what?
<heat>
hit next -> next -> next -> ... -> you boot into a broken system
<kaichiuchi>
sonny: freebsd on the desktop should've been it
<mjg>
bsd have the best install experience for sure
<kof123>
eh, long ago i started with freebsd because mandrake i figured i would not learn anything
<mjg>
fuck around in menus and end up using linux ayway
<kof123>
*mandrake linux
<kaichiuchi>
I give up
<kof123>
i dont mean that in some kind of elitist way, just there needs to be some torture hazing distro somewhere
<kaichiuchi>
"NVIDIA driver is not loaded"
<heat>
fun fact: freebsd devs don't know how to install freebsd
<heat>
kaichiuchi, dude CAN YOU PLEASE SHOW ME SOME FUCKING LOGS
<kaichiuchi>
no
<heat>
ok
<kaichiuchi>
one thing worked (almost) straightaway, this did not
<kaichiuchi>
fine
<kaichiuchi>
i'll humor you
<heat>
this is fucking arch what were you expecting
<kaichiuchi>
what do you want me to give you this time
<kaichiuchi>
following a guide almost verbatim and then having this happen is a them problem
<heat>
termbin your /var/log/Xorg.0.log
gildasio has quit [Remote host closed the connection]
<heat>
just so we're clear, you removed the xorg file?
<kaichiuchi>
yes
<heat>
it's not
<kaichiuchi>
it is
<kaichiuchi>
because nouveau is in /proc/modules
<heat>
oh
<heat>
there you have it
<kaichiuchi>
I never ever installed nouveau
<kaichiuchi>
jesus
<heat>
it's a builtin module
<heat>
"5. Remove kms from the HOOKS array in /etc/mkinitcpio.conf and regenerate the initramfs. This will prevent the initramfs from containing the nouveau module making sure the kernel cannot load it during early boot. "
<heat>
did you do this?
<kaichiuchi>
i want to say yes
<heat>
mkinitcpip -P to regenerate the initramfs
<heat>
mkinitcpio*
<kaichiuchi>
ok I think we're in good shape again?
<heat>
you tell me
<kaichiuchi>
yes
<kaichiuchi>
we are
<heat>
there you have it
<heat>
poggers
<heat>
or pogchamp as we would say here in #osdev
<heat>
"following a guide almost verbatim" <-- key word was almost
chartreuse has quit [Remote host closed the connection]
<kaichiuchi>
nothing plays on youtube
<kaichiuchi>
it endlessly buffers
<heat>
what browser?
<kaichiuchi>
firefox
<heat>
that problem rings a bell
<kaichiuchi>
"error trying to play a test sound"
<kaichiuchi>
"the system said: invalid state"
<kaichiuchi>
thanks. very helpful.
<heat>
OH
<kaichiuchi>
oh hm
<heat>
you didn't install a sound server thing
<kaichiuchi>
I think I know why
<kaichiuchi>
yes
<heat>
very funny
<kaichiuchi>
standby
<heat>
pipewire is the new hot shit
<pogchamp>
lay down that pipe
<geist>
laying cable in your computer. well okay then
<geist>
i mean i'm not judging
<kaichiuchi>
honestly i just hope my cock falls off and the computer blows up so I don't have to deal with this anymore
<pogchamp>
same
<kaichiuchi>
yay sound
<heat>
you literally have a working installation
<heat>
congrats
<heat>
you use arch btw
<kaichiuchi>
it's not working unless youtube is working
<geist>
tiktok or gtfo
<kaichiuchi>
and, that was the problem
<kaichiuchi>
excellent
<heat>
yup
<kaichiuchi>
now
<pogchamp>
why use arch when manjaro exists
<geist>
and what do we say to heat?
<kaichiuchi>
i hate him
<pogchamp>
lmfao
<heat>
pogchamp, >why use arch when manjaro exists
<sonny>
vdamewood isn't the minix book just an implementation of minix?
<vdamewood>
No, it's a book about the implementation of Minix.
<pogchamp>
minix is an implementation of minix
<heat>
big if true
<pogchamp>
i should go to bed
<geist>
just so everyone doesn't misinterpret me, real talk, i'm learning rust though i'm not a zealot
<geist>
yet, as far as i can tell
<sonny>
the design of the unix operating system is a better bible no?
<pogchamp>
should i learn rust too
<sonny>
freebsd has a good once as well
<pogchamp>
before bed
<vdamewood>
sonny: No, that's a book about Unix, not about OS dev.
<vdamewood>
I have the second edition of the FreeBSD book and the 4.4BSD book.
<heat>
what do you think UNIX is?
<sonny>
I don't understand ... it reads like the freebsd book
<klange>
Minix doesn't have a spec defining it as something for which there can be multiple implementations. Minix is Minix.
<pogchamp>
unix is an implementation of minix
<vdamewood>
But they're not generic OS books.
<vdamewood>
heat: One particular operating system.
<sonny>
neither is minix?
<heat>
but they're useful on their own
<klange>
Tanenbaum does have a general OS book, "Modern Operating Systems". I have one of the older editions here in hard cover.
<sonny>
oh
<heat>
a book that describes a large operating system in detail is maybe more important than a generic book that describes aspects of an OS
<klange>
I got it from my high school CS teacher as she was cleaning out a closet, so it's possibly the spark for my OS project?
<vdamewood>
klange: That seemed to read to me like a tour of operating systems rather than a generic os dev book.
<klange>
I would say it's very high-level.
<vdamewood>
Like if Andy wrote a Linux book, a Windows Book, and like two more that I forget, then smashed them together.
<heat>
I'm willing to bet you can gather a lot more information from design and implementation of {UNIX, FreeBSD} and the windows internals book compared to a generic OS book
<sonny>
I did some thought experiments, there isn't really much you can do when designing an OS, you end up with similar choices
<klange>
I keep threatening to write a book myself.
<heat>
do it
<sonny>
unless you don't care about running existing programs
<klange>
Minix was an inspiration for my 2018 pivot.
<heat>
if kaichiuchi can install arch twice you can write a book
<sonny>
lol
<heat>
write it in fucking troff
<heat>
i dare you
<geist>
if you do write an osdev book at least do a good one
<vdamewood>
Still, the way I seethe Minix book is that it's a general OS dev book, that happens to come with an example, Minix.
<geist>
there have been a few pretty crappy ones out there
<kaichiuchi>
i don't even understand the difference between plasma and plasma-meta
<kaichiuchi>
let's see...
<sonny>
troff is easy if you have macros
<sonny>
one is a package group iirc
<sonny>
other is a meta package, check archwiki for the details cause I don't remember
<vdamewood>
I will not strive for POSIX shell compatibility in my OS if I ever start writing it again.
<geist>
heat: re: book that describes large operating system i probabky learned more from the Solaris Internals book i have floating around
<vdamewood>
Maybe API compatibility.
<geist>
was well written and went into some pretty good detail of good decisions
<klange>
I really would like to be able to run `configure` scripts...
gog has joined #osdev
<sonny>
vdamewood it's not like you can't change your shell?
<heat>
kaichiuchi, plasma-meta is a meta package (i.e a package that has nothing itself but depends on N packages)
<klange>
But y'all can install dash, I've tried doing a POSIX shell a couple times now and fuck that.
<heat>
it covers the whole plasma desktop
<vdamewood>
sonny: Sure, but whey would I want to *write* one?
<sonny>
oh I see
<kaichiuchi>
and plasma-desktop is apparently "minimal"
<klange>
(I still need to _package_ dash... it's pretty much all working, even has job control functioning...)
gog is now known as gogchamp
<vdamewood>
sonny: I also wouldn't strive for tools and command-line support either.
<sonny>
I worked a little on oilshell
<heat>
it makes it so if packages are added to plasma-meta everyone that has the meta package installed gets them
<sonny>
was interesting
<vdamewood>
sonny: for example, I have no intention of writing a yacc orflex implementation.
<vdamewood>
or les*
<vdamewood>
lex
<vdamewood>
dammit
<kaichiuchi>
heat i see
<sonny>
I see
<heat>
package groups don't work that way, they just install those N packages and if someone adds to the group you don't see the new packages in your pacman -Syu
<gogchamp>
yaccity yacc
<vdamewood>
Though, I think I will name my commands such that someone could install all the posix tools without a problem.
<sonny>
vdamewood will it be graphical? :P
<klange>
I built my own Python, dammit, that should be enough for anyone.
<vdamewood>
sonny: Probably.
<geist>
klange: RUUUUUUUUUUUSSSSST
<sonny>
nice
<gogchamp>
should i write a rust compiler
<heat>
write your own rust
<sonny>
still have not gotten to graphics somehow
<heat>
i double dare you
pogchamp has quit [Ping timeout: 252 seconds]
<sonny>
they don't have a spec
<vdamewood>
sonny: That's because video card makers want to keep their secrets.
<heat>
that doesn't stop Mutabah
<sonny>
having to guess becuase their is no spec so you copy the existing implementation sucks
<sonny>
s/their/there/
gogchamp is now known as gog
<kaichiuchi>
okay I think looking back now, with the exception of the os-prober bullshit I think I could do it again
<sonny>
but they are doing it anyways, rust is in gcc iirc
<klange>
"Give me a framebuffer and I will draw the world."
<heat>
rust "is in gcc" except the important bit, the borrow checker
<gog>
if you wish to make a programming language from scratch you must first invent the universe
<sonny>
that's quick
<heat>
>troff is easy if you have macros
<sonny>
seems like languages take a while to get into gcc
<sonny>
rust-gcc is like 2 years old??
<heat>
have you ever written a whole book in troff?
<sonny>
no, just a paper
<heat>
the K&R book was written in troff
<sonny>
and the go book
<heat>
pic | tbl | eqn | troff -ms
<heat>
I bet. go also has UNIX geezer energy
<sonny>
lol
<geist>
wow that's 4 programs at once how did they run it with less than 4 cpuS!!!1!!1
<geist>
i heard they had sometimes only 2 cpus and less than 4GB of ram!!
<klange>
very carefully
<kaichiuchi>
heat: I refuse to believe wayland actually works well with NVIDIA though
<heat>
kaichiuchi, try it
<heat>
at least it works for me in my PRIME setup
<gog>
back in my day we had to walk uphill to the internet both ways
<kaichiuchi>
"The VDPAU library, used for hardware accelerated video decoding and presentation, does not have native Wayland support and does not work with Xwayland."
<geist>
gog: and you couldn't even watch youtube at the same time!
<gog>
heat heat heat
<heat>
good news! most shit also has trouble supporting vdpau
<heat>
gog
<gog>
an you play visual entertainment with it
<heat>
GOG
<gog>
zimbabwe
<heat>
bazimba
<gog>
I'm getting sick
<sonny>
how come pausing a process it not a popular idea?
<gog>
a process is paused every time it's not running
<geist>
yeah what do you mean by paused?
<geist>
like SIGSTOP?
<sonny>
yeah, but afer poweroff
<heat>
erm
<geist>
.. hmm?
<heat>
that's hibernation
<gog>
yeaj
<sonny>
yes like sigstop but after power off
<klange>
There have been many implementations of OS / frameworks that maintain application state between power cycles.
<heat>
it's hibernation
<sonny>
oh
<geist>
you mean restoring the process to precisely what it was after reboot?
<sonny>
yeah
<heat>
it's literally how it works
<geist>
process snapshotting is what i'd call that
<heat>
hibernation freezes your process into swap and shuts down
<geist>
heat: i think they're talking about a proper reboot, but snapshotting the process itself instead f the whole ssystem
<sonny>
yes
<geist>
hibernating snapshots the whole OS while it's at it
<heat>
that idea has shades of emacs
<geist>
in the case of lots of distributed OSes that was more of a thing, since snapshotting a process and restoring it on another node was a big component of it
<heat>
unexec is the greatest thing to ever exist
spikeheron has joined #osdev
<kaichiuchi>
fuck it's fucking cold
<gog>
yeh
* sonny
looks up unexe
<geist>
the hard part of course is not snapshotting the memory contents of a process, it's restoring all of the handles it had opened
<gog>
we're gonna get -15 this weekend yay
<geist>
and you probably need kernel support for that
<geist>
gog: eep!
<gog>
yeh
<gog>
my boss is going to Spain on Monday
<gog>
I'ma go witj
<Mutabah>
heat: re rust in gcc - It doesn't even compile libcore yet
<Mutabah>
Not that I blame them, it's HARD
<geist>
i think it's rust rejecting its habitat
<Mutabah>
However, much like upstreaming a linux driver - it ensures that the code won't bitrot
<heat>
no vengas gog, no te quiero aquí
<geist>
aint no rust compiler trust no C compiler
<Mutabah>
geist: Does that make me a mad scientist, forcing these two disparate creatures together?
<Mutabah>
Or a language-wisperer
<gog>
yeh how to restore handles
<heat>
it makes your compiler impure
<klange>
Have you tried turning them off and back on again?
<Mutabah>
gog: What's the context?
<heat>
if your compiler is written in C++ it can have bugs, which means the rust can have bugs, which means we're all fucekd
<gog>
snapshot process
<sonny>
ok time to read
<sonny>
cya
sonny has quit [Quit: Client closed]
<geist>
right, that's why rust will tolerate nothing less than living in a rust world
<Mutabah>
heat: That's why there's a LOT of testing
<geist>
pretty soon rust will start to infect your kernel, written in not rust
<gog>
you're gonna need a way to tell the kernel to serialize their state and check that it's possible to restore it
<geist>
linux is already lost, the rust has gotten in
<heat>
github.com/heatd/Onyx come guys, rust is explicitly banned here
<bslsk05>
heatd/Onyx - UNIX-like operating system written in C and C++ (4 forks/52 stargazers/MIT)
<gog>
we're living in a rust world and i am a rust girl
<geist>
we need to retreat to cpu architectures for which rust cannot reach (yet)
<geist>
like, 68k or 32k or 88k or something
<geist>
get our your i860!
<kaichiuchi>
geist
<Mutabah>
geist: Show me an architecture that supports C, and I'll cram rust into it
* vdamewood
gives gog a rust fish
<kaichiuchi>
when I used to come here when I was like 14
<geist>
noooo Mutabah is the enemy
<Mutabah>
MUAHAHAHAHA
<kaichiuchi>
it still feels like i'm 14
<gog>
iapx432
<klange>
"Give me an architecture long enough, and I'll rust the world..."
<Mutabah>
klange: Ooh, good one
<heat>
can you even?
<geist>
rust is like that guy in that anime that decays everything
<heat>
doesn't rust require 2's complement?
* gog
chomps fish
<vdamewood>
geist: Pokémon?
<geist>
Tomura Shigaraki
<heat>
also, exceedingly fun fact: C doesn't require 2's complement, but stdint.h intN_t does. how can a non-2's complement be C99 compliant? intN_t is optional
<geist>
yeah writing an emulator and seeing something run on it is some sort of primal joy
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<heat>
TWO
<klange>
Writing a language and seeing actual code build and work in it is as well.
<two>
this Nick isn't registered either wtf
<vdamewood>
two: Quick, register it as an alternate.
<geist>
yah totally. similar to the whole 'build a kernel and see it run' sort of thing. it's some sort of joy that's hard to describe to someone that hasn't experienced it
<two>
oh it is
<heat>
writing an os and seeing something run on it is also great
two is now known as pog
<klange>
sometimes i just boot up a vm just for that little bit of pleasure that it works
<pog>
I'll settle for my work projects not breaking the website
<heat>
pog, wanna work on my OS
<heat>
I'll pay you in exposure
<vdamewood>
pog: Are you the drink, or the fad of three months in 1996?
<pog>
i expose myself plenty
<pog>
vdamewood: yes
<vdamewood>
me drinks some pog while playing with pogs.
<heat>
poggers
<heat>
pogs were a fad for way more than 3 months
<vdamewood>
6 months?
<heat>
I had pogs and I was born in 02
<vdamewood>
I'm pretty sure they were dead as a fad by the time Pokémon hit.
<pog>
heat is 15 years younger than me
<heat>
are you having an existencial breakdown
<klange>
There was a brief time when Pokémon existed and pogs were still around.
<kof123>
what came after pokemon?
<klange>
More pokémon.
<heat>
pokémon never stopped
<pog>
pokemon go
<kof123>
"the cat is ra himself" i'm okay with that
<vdamewood>
Okay... now I want to see a Pokémon pog.
<vdamewood>
A Pogémon!
<vdamewood>
Okay, a quick Google image search took care of that.
<klange>
There's an alternate universe out there where the US got an immediate release of Green in 1996 and pogs held on just a bit longer.
<vdamewood>
Green? You mean Pokémon Green? Without Red?
<klange>
The US didn't actually get Red. They got Red flavored Blue.
<klange>
Blue was a different build.
<vdamewood>
I always wondered why the initial release of Pokémon was Red and Green since Red and Blue are grammatically special in Japanese but Green isn't.
<vdamewood>
And yes, I know that the western Red/Blue are based on the Japanese Blue with the Red/Green selection of in-game Pokémon.
<vdamewood>
I have Red and Green by the way.
<klange>
I have a US copy of Blue, Yellow, Silver... Leaf Green? I'm not sure what else from the gameboy* era.
<vdamewood>
My full list is Japanese Red and Green, US Red, Gold and Silver. And I also have US X, Y, Alpha Sapphire, and Omega Ruby.
<klange>
I think I'm mostly missing things from the DS generations, as I never had a DS, but have had many 3DS. Also 3DS is when I would have switched to Japanese copies...
<vdamewood>
klange: Which is kind of ironic since X, Y, Alpha Sapphire, and Omega Ruby are all multi-lingual.
<vdamewood>
When I started them up for the first time, they asked which language I wanted, so I set X, Y, and Alpha Sapphire to English, and Omega Ruby to Japanese.
<klange>
3DS games were region locked, though :)
<klange>
I did play those in Japanese, but I went back to English for the Switch games - primarily because Sword/Shield's locale is based on the UK.
<vdamewood>
the cool thing is that in the US there was a promotion to get all of the Mythic Pokémon, so I got three Mews and a ミュウ
<vdamewood>
So, it's like Playing X and Y in French, if you speak French.
<klange>
I _almost_ did Violet in Spanish - got plenty of Spanish dialogue anyway even playing in English.
<klange>
Per mi español es muy malo.
<vdamewood>
Did they base any region on Rhyykyuu/Okinawa or Just mainland Japan?
<vdamewood>
Ryukyu
sonny has joined #osdev
sonny has left #osdev [#osdev]
<klange>
Hoenn is based on Kyushu and Okinawa.
<vdamewood>
Okay, that works.
<vdamewood>
I wonder what part of Japan Kanto is based on. (Kidding)
<heat>
woah
<heat>
so GNU man still bottoms out in nroff -> groff
vdamewood has quit [Ping timeout: 260 seconds]
vdamewood has joined #osdev
heat has quit [Ping timeout: 252 seconds]
vdamewood has quit [Quit: Life beckons]
[itchyjunk] has quit [Remote host closed the connection]
<Clockface>
test
<Clockface>
what would you want in an instruction set
<Clockface>
it is intended to be JIT compiled to regular machine code (with a focus on x86 computers)
<geist>
Hmm, i wonder if its intended to be jit compiled it’s easier to have less registers
<geist>
so it’s easier to map the smaller registers into a larger register set
<geist>
Ie, like cross hitting x86-64 to arm64 which is a nice fit
<geist>
I’d say one thing you want to avoid is having a condition register. That’s more of a pain to jit
<geist>
Or if you do, make sure all instructions that modify the condition register are optional
<geist>
So the jitter has to do less condition bit lifetime analysis
<Clockface>
i had a bit of an idea for a variable number of registers, where the program file specifies how many it wants
<Clockface>
if its more than the number of registers there are on the physical cpu, it makes fake ones in memory
<Clockface>
so the programmer would have to know to keep the number low enough for it to be mapped to only "real" registers on their intended audience's platform
<Clockface>
but you could still have more registers for your ARM version
<\Test_User>
hopefully if it's going to be jit compiled you wouldn't be dealing with manual register allocation
<Clockface>
no lol
<\Test_User>
so why would the programmer need to keep the number of registers they use low?
<Clockface>
if the program is going to be used by a lot of people on 32 bit x86, then there wont be as many registers
<Clockface>
so faking them in memory would not be optimal at that point
<\Test_User>
if you aren't dealing with the registers yourself... its up to whatever jit compiles it on that host as to how many get used
pog has quit [Ping timeout: 246 seconds]
<Clockface>
they kind of are, kind of arent
<Clockface>
you could write your program to use "all registers from 0 to 15"
<Clockface>
so they will get mapped to 16 general purpous registers on the target platform
<Clockface>
you dont know which ones they are, but if that platform has at least 16 registers you will be using some form of register directly
<Clockface>
if it doesnt, it goes into screwup mode and fakes it in memory
<Clockface>
so at least it will still run
<\Test_User>
purpose to specifying that var x is a register when it may or may not actually be a register?
<Clockface>
pretty much
<Clockface>
you would have to specify "please run this on x86_64 or ARM so it has enough registers"
<Clockface>
it has that as a fallback
<\Test_User>
why not just let the jit compiler decide what is or isn't a register
<Clockface>
because some people have old computers but would still want to use the program
<Clockface>
because regular computers dont have variables?
<Clockface>
i kind of feel like making it a register machine
<\Test_User>
well yes, the compiler decides whether that variable happens to be in a register, memory, or whatever else at the time
<clever>
Clockface: the slack android app basically bricked itself, the new version isnt compatible, and the servers arent compatible with the old app, so they have basically just kicked me out, lol
<clever>
support old shit, forver! :D
<Clockface>
exactly
<Clockface>
a minor advantage of registers: you could specify that lower registers are faster
<Clockface>
lower numbered registers always get priority for how the "fastest" way to implement it would be on that computer
<Clockface>
some microcontrollers do that but with memory
<Clockface>
and i think its pretty neat
<clever>
Clockface: gcc does have a concept of fast and slow registers
<clever>
ive also seen the VPU gcc sorta abusing that, the lower 16 registers can be accessed by 16bit opcodes
<clever>
but the upper 16 registers, need a 32bit opcode
<clever>
so its less about register speed, and more about the resulting opcode size
<clever>
and one complication i dont think gcc is taking into account, certain things cant go into a 16bit opcode, so they get the upper 16 for free
<clever>
and because its also a dual-issue cpu, the weights are context specific
<clever>
certain combinations of opcodes can run in the same clock cycle
<clever>
to fully optimize, you would need to dynamically generate many variants of the code block, and then compute the total cost of it
<clever>
Clockface: register numbers and count is also something llvm hides, llvm IR just has an infinite number of registers, and you use them however you want
<clever>
when something turns that IR into final ASM, it will decide what to spill over into the stack frame, i believe
<klys>
clever, is there a description somewhere of llvm ir? is it multiarch?
<klys>
also would be curious to find if there is a hybrid of ir and tcg
<bslsk05>
revng/revng - revng: the core repository of the rev.ng project (72 forks/658 stargazers/NOASSERTION)
<Clockface>
i dont know where im going with that idea, but it seems like somewhere
<klys>
forth is an interesting direction to take though not entirely in line with the idea of creating an os
<klys>
thanks clever
<Clockface>
my OS's intention is to be something like "fun in kernel mode"
<Clockface>
where when you call the graphics library, its also the driver
<Clockface>
that kind of thing
<Clockface>
i think having the intermediate JIT will make things more stable
<Clockface>
since it could compile things in a safe(r) way
<Clockface>
to provide a bare minimum type of safety layer
<Clockface>
maybe the graphics library and driver shouldent be rolled together
<Clockface>
lol
<Clockface>
but its an example
<Clockface>
right now im writing it as a DOS program since i cant into filesystems
<Clockface>
im kind of getting the JIT thing from templeos
<Clockface>
since thats actualyl pretty cool
<Clockface>
kernel mode JIT
<Clockface>
alright rant done
<Clockface>
must rant into compiler
xenos1984 has joined #osdev
gorgonical has joined #osdev
bgs has joined #osdev
Burgundy has joined #osdev
Starfoxxes has quit [Ping timeout: 255 seconds]
<CompanionCube>
i don't think templeos actually does JIT in the strictest sense, does it?
<Clockface>
it does
<Clockface>
everything in it is done with holyC
<Clockface>
its a cool idea but being templeOS its a bit specialized
bgs has quit [Remote host closed the connection]
<moon-child>
CompanionCube: correct, afaik; it's interactive, but still aot
<CompanionCube>
moon-child: according to the templeos docs it says only the kernel + compiler is aot
<moon-child>
semantics
<moon-child>
to me, 'jit' indicates some form of runtime feedback
<klange>
jit means you have a thing in the middle that you need to convert that _isn't_ your source code
<CompanionCube>
ideally yes, but incremental compiliation at 'runtime' is sufficient i think?
<klange>
No because I'm sure as shit not jitting.
<moon-child>
I would distinguish interactivity from jitting
<moon-child>
interactive means you type some code and it gets compiled
<moon-child>
jitting means you run the code, and _then_ it gets _recompiled_, with tuning based on what happened during the runtime
<klange>
To JIT you need something to recompile, a bytecode that you are converting to machine code based on runtime information. If you are going straight from source to machine code interactively, that's not a JIT, it's AOT with a much shorter 'ahead'.
<moon-child>
you don't need a bytecode
<klange>
I would accept an AST representation.
<klange>
There was an implicit "eg" after that first comma.
<Clockface>
Just In Time Compile
<moon-child>
you also don't need machine code. There was some interesting work recently on formally verifying a jit. It did was adaptive specialisation (which is the hard part to formally verify), but they didn't actually generate any machine code
<moon-child>
if you compile source code to bytecode, and then bytecode to machine code, that's not (necessarily) jit. It's simply staged aot
<klange>
I think, fundamentally, a JIT needs some concept of "I have a thing I am already capable of executing, but to make it go faster I compiler it _harder_".
<klange>
Anything else is just sparkling AOT.
<moon-child>
JIT means you have _runtime_ feedback
<moon-child>
'compiling harder' is just compiling
bgs has joined #osdev
<klange>
"compile it harder based on things I found when executing it"
<moon-child>
sure. But it seems to me that you are implying that any form of 'compiling harder' constitutes jit
<klange>
No I think I fully agree with you.
<klange>
You need some specialization based on runtime information for it to be a JIT.
<moon-child>
ok. :)
<CompanionCube>
hm, i think a close thing to holyc here would be e.g. SBCL repl and i wouldn't call that a JIT so
<Clockface>
in most cases yes
<Clockface>
but the definition is 4 words
<Clockface>
"just in time compiled"
<Clockface>
would include anything that gets compiled right in the nick of time
<Clockface>
including holyC
<Clockface>
since thats how part of the shell works too
<Clockface>
the command gets compiled and then executed
<Clockface>
after being entered
<Clockface>
i would consider that something in its own category from regular compilation
<CompanionCube>
also TIL the templeos compiler has a stack machine IR for optimisation purposes
<moon-child>
interactive compilation is 'normal'. The batch stuff is a bizarre development--useful for bootstrapping, but otherwise a mis-step
<moon-child>
:)
bgs has quit [Remote host closed the connection]
<klange>
"runtime compile and link"
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #osdev
Starfoxxes has joined #osdev
rorx has quit [Ping timeout: 260 seconds]
<epony>
that's why your start times are "normally" in the order of "you're fired"
rorx has joined #osdev
gorgonical has quit [Remote host closed the connection]
lanodan has quit [Ping timeout: 260 seconds]
lanodan has joined #osdev
GeDaMo has joined #osdev
identitas has quit [Quit: You have been kicked for being idle]
pogchamp has joined #osdev
pogchamp has quit [Client Quit]
<ddevault>
aarch64 page tables, my god
hmmmm has joined #osdev
<geist>
yep,.they're a real complicated beast eh?
<ddevault>
anyone have a good reference which shows what parts of a virtual address are mapped by which tables on aarch64
<ddevault>
with the obvious caveat that an arbitrary number of tables can be nested up to some limit
<bslsk05>
docs.kernel.org: Memory Layout on AArch64 Linux — The Linux Kernel documentation
<geist>
no it's not that complicated. do you know x86 page tables that well?
<ddevault>
yes
<geist>
then it's basically that.
<ddevault>
hah
<geist>
the obvious difference is there are *two* root page tables, two CR3 equivalens
<geist>
one that covers 0..2^48 and the other that covers -2^48..0
<geist>
ie, the user space segment, and the kernel space segment
<geist>
TTBR0_EL1 and TTBR1_EL1
<geist>
'translation table base register'
<ddevault>
aye, that much I get
<ddevault>
just planning out my early page tables
<geist>
so it's really much nicer in that regard, you can just map the kernel side and leave it alone
<geist>
ah. well then the nesting of arbitrary isn't really a thing. what there is is you can configure the total size of it in the TCR_EL1 for either half
<geist>
so you can if you want just configure that the bottom part is say 39 bits, or 34, or 42, or whatnot
<geist>
up to a max number (usually 48)
<geist>
so you can get fancy when bootstrapping and just do a small mapping if you want, but it's probably simpler to just treat it like a 4 level 4K page table as you're used to
<geist>
but also another plus is 1GB page support is implicit, not optional like on x86, so you can use that up front if you just need a big unity map
<geist>
and to this day i still forget you are sircmpwn
<geist>
because then yuo can do 32bit sign extension and store smaller pointers for stuff within the kernel
<geist>
though you say not writing C i dunno what that implies
<ddevault>
hrm
<geist>
ah dont worry about it, arm64 has nice instructions for getting large addresses, just a thought
<ddevault>
yeah
<ddevault>
I think I'll pass for now to keep it simpler
<geist>
sure
<ddevault>
but I do have a use-case for that which might come up later, so we'll see
<geist>
-4GB i find nice to work with two because the addresses are obviously
<ddevault>
but for now this keeps things nicely uniform with x86_64
<geist>
0xffff.ffff.xxxx.xxxx
<ddevault>
so for this I'll need five statically allocated kernel page tables
<ddevault>
also: do I need to identity map whatever physical memory my bootloader is running in for when I switch on the MMU
<geist>
one suggestion is for the identity map, reserve a full top level 512GB run so you can have one single page table below it with 512 1GB entries
<geist>
makes for a nice clean break
<geist>
yes you d
<ddevault>
god that's annoying
<ddevault>
okay
<geist>
well, sort of. you can do a trick, actually
<ddevault>
oh? please tell me about the trick
<geist>
though probably not worth it. i have it in LK now. the trick is to enable the mmu and expect the next instruction to fault
<geist>
but have already set up the VBAR to branch to the kernel
<ddevault>
okay yeah trick disregarded
eroux has quit [Ping timeout: 252 seconds]
<geist>
arm64 doesn't have any in memory things like GDT or IDT like x86 does, so once you have the registers set up it has everything it needs within the cpu, sot he VBAR trick works nice there. riscv could do it too
<bslsk05>
github.com: lk/start.S at master · littlekernel/lk · GitHub
<ddevault>
also EFI loaded and started running me from 0x0000*
<ddevault>
should I just quickly jump to 0xFFFF* right away you reckon?
<geist>
well, you have to set up the mmu for that
<ddevault>
ah
<geist>
but sure, getting the mmu on is probably what you want to do pretty quickly
<geist>
but not fundamentally different from other arches. you're running without the mmu on so you have to turn it on and bootstrap past that
<geist>
j`ey: main complaint with the trick is you burn 0x800 bytes to set up a fake vbar
<ddevault>
I guess I can just use the same page tables for both ttbr0_el1 ttbr1_el1 during the bootstrap
<geist>
depending on how loosey goosey you want to make it you could probably trim that
<geist>
sure, that's fine
Ram-Z_ has joined #osdev
Ram-Z has quit [Ping timeout: 255 seconds]
<geist>
especially since you're doing the identity map at the bottom of the TTBR1 page tables it'll double duty for the few instructions you need it for the TTBR0s
<geist>
then once you get up to the high address you can pull up the anchor and zero out TTBR0
<ddevault>
oh yeah I imagine that since I'm doing that identity map if I do it for TTBR0
<ddevault>
I don't need anything special to map my bootloader temporarily
<ddevault>
brilliant
<geist>
bingo
<ddevault>
so I'll need five statically allocated tables
eroux has joined #osdev
<geist>
or 5 pages of bss and you quickly generate the tables in asm
<ddevault>
also just verify my assumption real quick: the tables are the same size as x86_64, i.e. 4096 * 8 byte entries
<geist>
yep
<ddevault>
cool
<geist>
when using 4K page granules, but that's what you want to be using at this point in time
<ddevault>
aye
<geist>
larger page granules is advanced mode stuff, and not always supported on all cpus, etc
<geist>
*though* for things like temporary trampolines, using 64K pagesa re kinda nice. i used to do those in LK until i hit a cpu that doesn't support 64K base pages: apple M1
<bslsk05>
phip1611/paging-calculator - CLI utility that helps you to calculate indices into the page table from a virtual address. For x86, it outputs the indices into the page tables for both, 32-bit and 64-bit paging. (0 forks/1 stargazers/MIT)
lanodan has quit [Quit: WeeChat 3.6]
lanodan has joined #osdev
epony has quit [Quit: QUIT]
bauen1 has quit [Ping timeout: 252 seconds]
<ddevault>
err
<ddevault>
EFI starts with the MMU enabled
<ddevault>
that makes things more complicated
<sham1>
But it's also identity mapped most likely, so that should also eork
isaacwoods has joined #osdev
<ddevault>
just have to rework my MMU initialization sequence
Matt|home has quit [Remote host closed the connection]
Matt|home has joined #osdev
bauen1 has joined #osdev
bauen1 has quit [Ping timeout: 272 seconds]
awita has quit [Ping timeout: 252 seconds]
awita has joined #osdev
zxrom has joined #osdev
bgs has joined #osdev
bauen1 has joined #osdev
<kaichiuchi>
hi
gxt__ has quit [Remote host closed the connection]
gxt__ has joined #osdev
epony has joined #osdev
bauen1 has quit [Ping timeout: 268 seconds]
heat has joined #osdev
bauen1 has joined #osdev
<heat>
kaichiuchi, how's arch?
<kaichiuchi>
nothing fun to report yet
<heat>
it's smooth sailing from here on out
<heat>
you have my Guarantee(tm)
<heat>
the only weird thing you got was honestly that grub thing, it still puzzles me
bauen1 has quit [Ping timeout: 272 seconds]
dude12312414 has joined #osdev
awita has quit [Ping timeout: 252 seconds]
<kaichiuchi>
jesus christ
<kaichiuchi>
"let's go to kaichiuchi for his update on the jira"
<kaichiuchi>
"i'm assigned a jira?"
<kaichiuchi>
"yeah you've been assigned a jira for 3 days now"
<kaichiuchi>
no notifications, nothing on jira, nothing, absolutely *nothing*
<j`ey>
you have to work through the weekend to make up for it
<kaichiuchi>
no i don't
<sbalmos>
it really was someone else's jira, then it got reassigned into your group, so it never fired a create notification
<kaichiuchi>
I'm particularly pissed off because I looked like a dumbass
gog has quit [Read error: Connection reset by peer]
<kaichiuchi>
so
<kaichiuchi>
it turns out that they have... email notifications disabled on jira
<kaichiuchi>
wtf am I supposed to do, hit F5 every 10 seconds?
<sbalmos>
slack? teams? sms? anything else?
<kaichiuchi>
no
<kaichiuchi>
I cannot find any evidence that they have any type of notification system enabled at all
<kaichiuchi>
why is this bug marked minor but it’s critical to the release?
<heat>
is writing a troff(1) hard? or at least something that can render man pages
<kaichiuchi>
i probably shouldn't say too much on here actually
<heat>
I don't understand why everyone uses GNU troff or mandoc or some descendent of ditroff
bauen1 has joined #osdev
<heat>
the format itself doesn't look complex to me
<heat>
I guess that writing a full fledged troff is probably quite a bit harder than writing a man page viewer as you would need to implement the macro fuggery
vdamewood has joined #osdev
xenos1984 has quit [Quit: Leaving.]
eroux has quit [Ping timeout: 272 seconds]
[itchyjunk] has joined #osdev
aliaenor has joined #osdev
bauen1 has quit [Quit: leaving]
<aliaenor>
good morning
bauen1 has joined #osdev
<zid>
Well, my df game ended.
gog has joined #osdev
xenos1984 has joined #osdev
gildasio has quit [Remote host closed the connection]
gxt__ has quit [Write error: Connection reset by peer]
dude12312414 has quit [Write error: Connection reset by peer]
dude12312414 has joined #osdev
FreeFull has joined #osdev
gildasio has joined #osdev
bauen1 has quit [Ping timeout: 268 seconds]
gxt__ has joined #osdev
bauen1 has joined #osdev
jjuran has quit [Ping timeout: 252 seconds]
<epony>
drama fiction
<kaichiuchi>
goodness
<geist>
zid: but the legacy lives on!
<kaichiuchi>
hm i don't remember mirc having shit color schemes
<zid>
geist: The legacy I left was bloodstained walls.
<zid>
The forgotten beast grabs the militia commander by the head with its left wing! The forgotten beast bites the militia commander in the head and the injured part collapses into a lump of gore!
<zid>
x50
* kaichiuchi
slaps zid around a bit with a large trout
<kaichiuchi>
old viruses would actually do things instead of "just give me money"
<kaichiuchi>
recommend that you guys also look at danooct1's videos
gildasio has quit [Ping timeout: 255 seconds]
<ddevault>
hrm
<ddevault>
UEFI for aarch64 does not specify the contents of mair_el1
<ddevault>
it happens to be 0xffbb4400 on qemu but
gildasio has joined #osdev
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
y0m0n has joined #osdev
<geist>
yah i would 100% re-set that up
Burgundy has quit [Ping timeout: 260 seconds]
<geist>
but it does kinda beg a question: switching from one mmu configuration to another is a little dicey, sinc eyou have to configure at least 3 registers (MAIR, TCR and TTBRx) and at any point you can make an existing configuration invalid
<geist>
seems like the safest thing to do is turn it off before turning it back on
<heat>
geist, you sure the new qemu is out? I just see -rc4
<geist>
but then you're immediately exposed to data caching issues
<geist>
heat: yeah the v7.2.0 tag popped yesterday, unless they un-released it
<geist>
yeah it's there
<geist>
or you're using some git mirror that hasn't updated
<geist>
though it's basically the exact same version as -rc4, they just updated the tag and officially released it
Burgundy has joined #osdev
<ddevault>
yeah but if I change it
<ddevault>
I invalidate the EFI services page tables
<ddevault>
which could break EFI services
<ddevault>
I suppose I could just set up my own page tables with the value I expect mair_el1 to have
<ddevault>
then after I exit EFI services
<ddevault>
turn off the MMU, reconfigure it, and turn it on
y0m0n has quit [Ping timeout: 252 seconds]
<ddevault>
EFI only uses low memory so my plan was to configure high memory, load the kernel into it, then jump there and it's off
<zid>
Leave the MMU off until kernel _start :P
<ddevault>
but I think it's safer to prep my page tables for what I want the world to look like, load the kernel into physical memory with the page tables set up appropriately, then exit EFI services, disable the MMU, and reconfigure it to my needs
<ddevault>
my kernel always wants to be in high memory, so
<zid>
just don't let _start know
<ddevault>
fair
<ddevault>
I could make _start PIC and have it do all of the setup work
<ddevault>
ah no
<ddevault>
becuase I do need to map the kernel into its desired virtual addresses
<ddevault>
because*
<ddevault>
and if I have to write a loader I'd rather not do it twice and have the kernel re-arrange itself on the fly
heat has quit [Remote host closed the connection]
heat has joined #osdev
<geist>
No, you won’t invalidate it because UEFI is by definition required to set up identity mapping
<geist>
So as long as you replace it with your own version of it it should be fine
<geist>
But then once you exit boot services you own it anyway
<geist>
You should probably be fiddling with page tables absolutely after exiting boot services, not before
<ddevault>
yeah I think it's cleaner
<geist>
That is probably a really really bad idea to be messing with UEFI page tables while it’s running
<ddevault>
all of this early arm setup is very annoying
<ddevault>
but I suppose that's true of all arches
<geist>
It is. This sort of stuff is not really any different from other arches
<geist>
You have basically the exact same problem coming out of uefi on x86
<ddevault>
I mean paging on x86 is dead simple
<ddevault>
my brain is leaking out of my ears after trying to grok aarch64's stuff all day
<geist>
It’s the same here, for this level of stuff
<ddevault>
I mean you can choose a reasonable subset of it
<geist>
Well, it’s got a lot of features but you dont need those. For the stuff you need it’s not really any more complicated
<ddevault>
the key is identifying the necessary parts which constitute the reasonable subset while reading the manuals
<ddevault>
and at least intel gives us PDFs
<geist>
Or asking irc for help :)
<ddevault>
haha yeah
<ddevault>
I intend to ask for more help :)
<geist>
What do you mean intel gives you pdfs?
gog has quit [Ping timeout: 252 seconds]
<ddevault>
I prefer the intel or AMD PDF manuals rather than ARM's website
<geist>
Why dot you get the arm pdf?
<ddevault>
I could not find the right one
<ddevault>
I found about 30 wrong ones
<geist>
Ah, i am starting to see the problem here.
<ddevault>
do you have something useful handy for that?
<geist>
You’re not looking at the right shit
<ddevault>
please help me find the right shit
<geist>
Yes, look for the armv8 architecture reference manual
<geist>
Sometimes we call it the ARM ARM
<ddevault>
oh god is this The PDF
<ddevault>
the one zathura chokes on
<geist>
*that*S what you want. Probablyyou’re looking at random pieces of stuff, some of which may not be current or accurate
<ddevault>
>11,952 pages
<geist>
And that will make you confused really quickly
<ddevault>
VOLUMES, man, volumes
<geist>
Oh, like the 5 AMD volumes? Or the 3 volumes of intel?
<ddevault>
either really
<ddevault>
split this monster up
<ddevault>
my PDF viewer can't handle it
<geist>
Then get a better one
<ddevault>
zathura is very good imo
<geist>
Okay, look i really dont care. If you dont want help.. i have other things to do
<geist>
If you’re not going to take it seriously, i can stop here
<ddevault>
easy, easy
<ddevault>
I'm just venting
<ddevault>
I appreciate the help, figuring out how to read this PDF is the least of my problems
<ddevault>
thank you
<geist>
Fine, but huge pet peeve is trying to help someone that doesn’t appear to be taking it seriously
<geist>
Kk. Noted.
<ddevault>
I do take it seriously, just use humor to cope with all of the complexity
<GeDaMo>
Firefox's PDF viewer read the ARM OK
<geist>
I dunno what OS you’re on but generally there’s a decent pdf viewer for each of them
<geist>
Evince seems to do an okay job on linux/gtk/etc
<ddevault>
anyway this PDF is exactly what I was trying to find
<geist>
I have never heard of a Thera
<ddevault>
many thanks
<geist>
Zathura stupid thing tries to fix it
<geist>
Note this pdf is complicated as hell, because it describes the superset of all things you’ll need to know
<geist>
So it *may* not help you, but at least it’s the right one
<ddevault>
yeah, used to it
<geist>
You have the armv8 ARM right?
<ddevault>
yeah
<ddevault>
right now just targeting qemu virt
<geist>
Okay
<ddevault>
will be targetting rp4 later
<ddevault>
evince chokes on this PDF too, hah
<ddevault>
pdf.js works
<geist>
Humorous that you say a JavaScript based viewer has better time
<geist>
How does it choke?
<ddevault>
crashes when I open the table of contents
<geist>
Like, takes m,ore than 3 seconds to load?
<geist>
Or swaps the system?
<ddevault>
I might file a ticket with mupdf about this file (mupdf being the zathura backend)
<geist>
I absolutely use evince to view this pdf all the time
<ddevault>
as in window disappears, didn't dig
<ddevault>
segfault, oom, something
<ddevault>
let's see
<geist>
It does a fine job. Run it on the commmand line so you see any prints it may have
<dzwdz>
but once i attach gdb to it, it works perfectly :D
<ddevault>
naturally :P
<dzwdz>
is there a pattern to the crashes?
<Ermine>
Large pdf files are not good anyway.
<dzwdz>
it's only crashing for me once i've already been browsing a single pdf file for a bit
<dzwdz>
but i wasn't able to reproduce it by neither leaving the file open for a while nor quickly jumping between sections
<Ermine>
Initially I thought this crash is related to the fact that musl is stricter regarding memory accesses somehow.
<dzwdz>
oh, i'm on musl too
<dzwdz>
btw - is there some standard placeholder unix timestamp that isn't 0?
<Ermine>
(time_t)-1?
<dzwdz>
i've heard that some software breaks with high timestamps
<Ermine>
This software just gets high.
<dzwdz>
but actually, said software probably won't ever be reading the dtime of files
<Ermine>
(In praise of musl: I've written a program which worked fine on glibc, but crashed on musl. It helped me to find out memory access bugs.)
<Ermine>
dzwdz: apparently any time_t is a valid unix timestamp, so what value do you want depends on your goal.
elastic_dog is now known as Guest9115
<dzwdz>
i need to put something nonzero in an inode's dtime
elastic_dog has joined #osdev
<dzwdz>
but now that i think about it -1 will probably work fine, i was overthinking this
nvmd has joined #osdev
tosemusername has joined #osdev
<mrvn>
Ermine: (time_t)-1 might be someting surprising is time_t is unsigned and you have a one's-complement system. That's not that far in the future.
tosemusername has quit [Client Quit]
nvmd has quit [Client Quit]
<mrvn>
dzwdz: (time_t)~0 might be better
<mrvn>
dzwdz: and shame on you for not having sub-second timestamps :)