<kof123>
and...i would say inevitable too. higher level languages, quicker iteration perhaps...more throwaway code, because easier to throw it out and start over/make changes, at least marketing-wise.
netbsduser has quit [Ping timeout: 255 seconds]
<gog>
i'm going to reimplement openbsd in uefi
elastic_dog has quit [Ping timeout: 260 seconds]
<moon-child>
i'm going to reimplement plan9 in java
gbowne1 has quit [Quit: Leaving]
<kof123>
that's good, you can use all the OO java plan9 libraries
<kof123>
save you tons of work, rapid development!
gog has quit [Ping timeout: 240 seconds]
<kof123>
actually that paper could be a subtle reference to lost in the supermarket, perhaps that is the digging
elastic_dog has joined #osdev
sbalmos has joined #osdev
admiral_frost has joined #osdev
Affliction has quit [Quit: Read error: Connection reset by beer]
Affliction has joined #osdev
admiral_frost has quit [Quit: It's time]
Turn_Left has quit [Read error: Connection reset by peer]
[itchyjunk] has quit [Remote host closed the connection]
joe9 has quit [Quit: leaving]
<geist>
i'm going to reimplement minecraft in cobol
rustyy has joined #osdev
Vercas has quit [Quit: Ping timeout (120 seconds)]
Vercas has joined #osdev
bliminse has quit [Remote host closed the connection]
<kazinsal>
I made a joke the other day about Final Fantasy XIV mods in cobol so I'm expecting someone to do it within a few weeks
<kazinsal>
still need to sort out the vax. power supply seems to be hosed, probably some filter caps going bang
Left_Turn has joined #osdev
<kazinsal>
these days I have such little drive to fiddle with osdev stuff. I need something novel to be attracted to and we're in the era of everything being so homogenous again sadly
<kazinsal>
makes me wish I was able to do kernel hackery in the late 80s/early 90s
Left_Turn has quit [Max SendQ exceeded]
Left_Turn has joined #osdev
Left_Turn has quit [Max SendQ exceeded]
Left_Turn has joined #osdev
flx has quit [Quit: Leaving]
Burgundy has joined #osdev
remexre_ has joined #osdev
remexre has quit [Ping timeout: 260 seconds]
remexre_ is now known as remexre
gog has joined #osdev
air has joined #osdev
admiral_frost has joined #osdev
janemba has joined #osdev
goliath has joined #osdev
Burgundy has quit [Ping timeout: 272 seconds]
Turn_Left has joined #osdev
[itchyjunk] has joined #osdev
Left_Turn has quit [Ping timeout: 260 seconds]
<mcrod>
hi
netbsduser has joined #osdev
admiral_frost has quit [Quit: It's time]
[itchyjunk] has quit [Remote host closed the connection]
[itchyjunk] has joined #osdev
Burgundy has joined #osdev
Nixkernal has joined #osdev
vai has joined #osdev
bliminse has quit [Quit: leaving]
Bonstra has quit [Quit: Pouf c'est tout !]
Bonstra has joined #osdev
antranigv has quit [Read error: Connection reset by peer]
antranigv_ has joined #osdev
admiral_frost has joined #osdev
bliminse has joined #osdev
heat has joined #osdev
antranigv_ is now known as antranigv
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 264 seconds]
netbsduser has quit [Ping timeout: 258 seconds]
netbsduser has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 252 seconds]
Arthuria has joined #osdev
Matt|home has joined #osdev
linear_cannon has quit [Read error: Connection reset by peer]
linearcannon has joined #osdev
Hammdist has joined #osdev
Hammdist has quit [Ping timeout: 245 seconds]
admiral_frost has quit [Quit: It's time]
Hammdist has joined #osdev
Hammdist has quit [Ping timeout: 245 seconds]
Arthuria has quit [Ping timeout: 258 seconds]
Arthuria has joined #osdev
FreeFull has joined #osdev
Arthuria has quit [Ping timeout: 248 seconds]
wand has joined #osdev
tomaw has quit [Remote host closed the connection]
tomaw_ has joined #osdev
xenos1984 has quit [Ping timeout: 240 seconds]
tomaw_ is now known as tomaw
Left_Turn has joined #osdev
xenos1984 has joined #osdev
Turn_Left has quit [Ping timeout: 255 seconds]
Arthuria has joined #osdev
Arthuria has quit [Ping timeout: 240 seconds]
[Kalisto] has joined #osdev
betabube has joined #osdev
<betabube>
hi
<betabube>
was thinking about if i could just use emacs as an os
<zid>
emacs is already an OS
<betabube>
<3
betabube has left #osdev [WeeChat 4.0.5]
<heat>
top 10 #osdev exchanges
<zid>
sometimes it's best to just humor them
<zid>
(also it's a 100% true fact)
<kof123>
i will remember the guy who came in hey @$##$@$#@$#$@# or similar. surely that made the list
wand has quit [Quit: leaving]
wand has joined #osdev
wand has quit [Client Quit]
xenos1984 has quit [Ping timeout: 245 seconds]
wand has joined #osdev
wand has quit [Client Quit]
wand has joined #osdev
netbsduser` has joined #osdev
xenos1984 has joined #osdev
netbsduser has quit [Ping timeout: 272 seconds]
Hammdist has joined #osdev
Hammdist has quit [Ping timeout: 245 seconds]
Matt|home has quit [Quit: Leaving]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 240 seconds]
<geist>
kazinsal: yah that power supply in the microvax is a total unit
<geist>
i haven't opened mine, but it's a serious piece of work
FreeFull has quit []
<sham1>
Emacs!
<heat>
vim!!!!!!!!!!
<heat>
quick vim vs emacs
<heat>
mac vs windows
<sham1>
You can have vim in emacs, but you can't have emacs in vim
<heat>
is that a vim bug or a vim feature?
<sham1>
It's a deficiency
<Ermine>
is 'mac vs windows' holywar a thing
<heat>
yep
<Ermine>
$OS vs linux is much more common
<sham1>
That Moolenaar (PBUH) never fixed
<heat>
no, linux vs $other is a thing only for linux basement dwellers
<sham1>
Well as a certified basement dweller...
<sham1>
Anyway, I'm writing C++
<heat>
windows basement dwellers do windows vs mac
<heat>
actually even normal people kinda do
<Ermine>
Did you see windows basement dwellers?
<sham1>
Nah, normal people seem to do blue bubbles of iMessage vs green bubbles of actual SMS
<Ermine>
Usually windows users have more important stuff to do than caring about OS
<heat>
sham1, normal people kinda do apple vs everything else, I guess
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<Ermine>
I see more HW oriented stuff at this subreddit
<heat>
everyone there uses windows
<heat>
believe me, LINUX GAMING LOL
<sham1>
Well yeah, it's full of gamers
<Ermine>
Happy people who can buy stuff without worrying whether it will work with Linux
<heat>
happy people that don't dive into xorg configs to enable V FUCKING SYNC
<Ermine>
There are no usb wifi adapters in common stores that would work with linux without hassle
<Ermine>
heat: true
<Ermine>
So I had to fetch one from China
<heat>
that sux
<heat>
fwiw most desktop hardware things work with linux
<heat>
even nvidia works fine. no, don't use nouveau
<sham1>
Absolutely proprietaryu
<Ermine>
I had bugs and annoyances with proprietary nvidia driver
<Ermine>
So, no, not fine
<zid>
ah so like windows then
<mcrod>
nouveau routinely died for me
<Ermine>
mcrod: kepler/maxwell card?
<mcrod>
virtually no problems with the proprietary driver for me
<geist>
yah basically functional nvidia drivers on linux is why it's more or less the only non windows os i can run on my workstation
<geist>
since i actually want good support for my nvidia card
<mcrod>
Ermine: ampere
<Ermine>
Ah
<heat>
i found memory bugs yesterday when running eglinfo in the nvidia shared objects
<mcrod>
sometimes I’ll get a kpanic due to the driver
<heat>
that said, nvidia proprietary is far better than the nouveau garbage
<mcrod>
but that’s like.. once, twice a month
<mcrod>
shouldn’t happen at all but whatever
<mcrod>
consistent with windows
<Ermine>
nouveau being garbage is nvidia's fault
<heat>
is it?
<zid>
50/50
<Ermine>
yes
<Ermine>
because of all that fw stuff
<heat>
nvidia sell hardware, they even gave you a driver
<zid>
Drivers are bad even on windows and takes millions of dollars of development to not suck, don't forget
<geist>
at least in my experience nvidia > amd > intel in terms of driver stability, on windows
<mcrod>
the day NVIDIA is significantly more open with their specs is the day the internet will break
<zid>
They also have to jump through lack of docs hurdles, sure, but, I wouldn't expect them to make a decent driver regardless
<sham1>
Just get AMD
<geist>
as in i rarely get any sort of issue with my nvidia setup on windows
<heat>
mcrod, what specs?
<geist>
and AMD was historically pretty unstable
<Ermine>
I had kepler, and nouveau freezed because of some bug in nouveau-provided fw and nouveau devs have no clue what's wrong since 2014
<zid>
geist: yea it's been up and down as to how close people were, but that's the general rule
<mcrod>
heat: hardware documentation
<heat>
you are assuming there indeed is a spec, and that's hilarious
<mcrod>
you know what I mean
<mcrod>
i don’t see why that’s hilarious
<geist>
the last time i tried to use amd drivers on linux it was a disaster. crashing the card is not *so* bad on windows becuase it just restarts, but crashing xorg every time the driver goes down takes out your whole session
<heat>
if there's no public spec i'd wager it's pretty likely that there's no spec at all
<geist>
but to be fair i think that was a good 10 years ago. may be more stable now
<zid>
yea amd is one of the ones where sometimes they're fairly close to nvidia, other times they're a dumpsterfire
<heat>
just like there's (AFAIK) no NTFS spec for the windows teams
<zid>
intel is pretty consistently "meh" but sometimes have a shocker
<mcrod>
AMD is more open with the Linux people at least
<zid>
nvidia are fairly consistently "well, it works, but"
<heat>
mcrod, it's not.
<Ermine>
geist: writing this from amd-powered machine. I have almost no issues with it. It's old though (rx470)
<mcrod>
are you kidding me
<heat>
AMD publishes huge blobs of firmware and auto-generated header files
<mcrod>
Ermine: i had an RX 570 way back yonder
<zid>
I've seen some of those headers they're great
<mcrod>
Linux was okay on it
<geist>
Ermine: are you using the amd proprietary drivers?
<zid>
a bunch of names are santitized
<heat>
it's not better than the nvidia open kernel gpu shit except that nvidia wrote it to be portable between OSes in their own style
<geist>
nvrm!
<Ermine>
No, I'm using in-tree amdgpu driver
<zid>
nvidia *did* try to drop an in-kernel driver but it was like 20MB of HAL to make it run the windows driver :p
<geist>
ah yeah that's probably pretty stable. i'm talking about the official drivers from the company
<zid>
so nowwe just do that but out of tree
<geist>
it was historically unstable on linux
<Ermine>
heat: as a programmer, it's probably bad
<Ermine>
heat: as a customer, idc how those drivers are structured, workitude is what is important for me
<zid>
Expecting nvidia to provide enough support to allow you to write 'proper' drivers is a *big* ask that would probably cost them literally billions
<heat>
yeah and nvidia works fine for most customers
<zid>
because it's very unlikely even *they* know how much of their shit even works
<geist>
i've had to deal with nvrm before, it's their OS abstraction layer. basically just imagine 400 something calls to completely abstract everything from the host os
<zid>
a few people will know a few parts of it
<geist>
and also allow some amount of it to be proxied over an ioctl/etc so you can write the same driver in user space or kernel spae
<Ermine>
I cannot judge for the whole thing, but for me, amd works better than nvidia
<zid>
a lot of the information will jus tbe encoded in various employees' heads
<heat>
like AMD actually publishes no docs for their hardware, just code, but GPL ponies eat it up becuz muh linux muh GPL
<geist>
in a past life i had to write a nvrm shim for LK to load an nvidia driver. it was not fun
<heat>
haha
<zid>
i'd make jon mayo do it, he seems like the person to ask
<geist>
basically had a .o file from nvidia to intiialize one of their mobile gpus, and needed to provide enough nvrm for it to boot and initialize the gpu to just show a dang logo, for a bootloader
<Ermine>
I guess intel publishes both code and docs
<heat>
john mayonaise
<zid>
like the mayo clinic, where they treat people by rubbing mayonnaise on them
<Ermine>
but, here's the next step: docs are not enough
<heat>
they're not
<geist>
what was even worse was their .o file relied on a bunch of jam tables that you needed for specific cores. it wasn't even compiled for a particular core, there was some sort of 'oh this is a X, here, take this binary blob and feed it to the driver'
<zid>
They have a huge engineering staff they pay millions of dollars to answer *precisely* the questions a 3rd party would need to ask
<zid>
but for themselves
<zid>
cus it's their job
Arthuria has joined #osdev
<geist>
so it was multiple levels abstracted. the nvrm had this whole notion of abstract enum based handles to particular gpios and whatnot, which is dynamically redirected, based on these tables you feed it
<heat>
providing comprehensive docs for super complex hardware is really hard so it turns out most info just lives on people's heads
<heat>
or spread out docs i assume
<geist>
which makes sens.e one of the reasons their driver can work with multiple familes of gpus
<heat>
maybe even a bug tracker!
<zid>
"hey, how do the command buffers act on kepler when an underrun happens during irq starvation?" is some guy's full time job for 2 weeks after it gets asked internally :P
<zid>
expecting them to provide that *externally* just means doubling all their staff
<geist>
so basically even their own driver has some sort of layering where you feed the bottom layer effectively some sort of device tree from the upper layers, once its detected which kind of core it is
<geist>
in my case i was providing the bottom layer (nvrm) so i had to parse enough of that shit to make it work. it was no fun. i'm having ptsd flashbacks now
<heat>
hahaha
<heat>
i mean all their drivers drive a bunch of hardware isnt it?
<heat>
assuming this is tegra, tegra's driver handles a whole bunch of SoCs
<Ermine>
So, conundrum is how to have good open gpu drivers
<zid>
You don't, basically
<zid>
It's like asking how to have a good open source desktop environment
<zid>
it's an intractable problem
<geist>
yeah i mean to a certain extent it's fairly elegant and probably solves the problem fairly well, it's just a *lot* of layers of abstraction
<heat>
you can have good open gpu drivers but it involves you starting from the ground up
<geist>
and i guess they really want to avoid having a separate .dll for every variant of every device
<heat>
switching from closed to open is not very profitable
<heat>
sometimes legally impossible/impossibly hard
<zid>
nvidia has big internal issues with legally impossible
<heat>
yeah i mean, intel too with its firmware stuff
<geist>
yah instant you license something and then rely on it you're hosed
<zid>
trying to clear everything at this point would probably cost more legal fees than they have money
<heat>
"when is memory training code getting opened?" never
Arthuria has quit [Ping timeout: 260 seconds]
<zid>
even if it all checked out fine
<heat>
when's memory training code getting rewritten from the ground up and opened? never
<zid>
just the process of asking the lawyers about every single thing would take a black hole amount of gold bars
<geist>
i remember being very very sad the beos source code was never released in the early 2000s when Access ended up owning it
<zid>
that's why the amd stuff is just.. sanitizd
<zid>
that's much easier to deal with
<geist>
from what i heard it got >< this close, but the legal issues were all of it
<Ermine>
At this point, by open I mean 'open but probably closed firmwares'
<zid>
#define HWREG7 0x14782
<geist>
since there was some copyright intel, etc in the kernel, and someone would have to track all that down
<heat>
AMD and NVIDIA (now) just moved all the legally dubious bits to firmware
<geist>
and it was probably no sweat, just cost >$0 dollars
<geist>
like access themselves had no issue with the open sourcing, it was useless to them but it was nonzero effort to do it
<geist>
mcrod: oh yeah it is caturday
<Ermine>
So, alright then, have closed fw and keep your secrets
<heat>
moving all the garbage to a separate coprocessor is actually a genius solution
<heat>
you can open things on the other end and help those people out, and still not break/rewrite shit/break the law
<Ermine>
it is easier to establish communism than to get those secrets disclosed
<geist>
and t's really not like they invented that, pretty much all mobile socs have piles of secondary processors now, each with theor own firmware. lots of times you're basically seeing the org chart of the company that makes the soc
<geist>
each division has their own core(s) and their own software stack
<zid>
one big reason they did that I heard was just to make bringup internal
<zid>
so you could just have the card "work" in clusters
<heat>
Ermine, even communism had their own firmware (politburo)
<zid>
without having to keep drivers up to date and shit
<geist>
oh speaking of chips and cheese has a pretty interesting writeup about Hexagon (Qualcomms DSP). it's more whacky than i though
<bslsk05>
chipsandcheese.com: Qualcomm’s Hexagon DSP, and now, NPU – Chips and Cheese
<Ermine>
heat: communism implies no state, hence no politburo
<geist>
also has a whacky thing i hadn't thought of: it has imprecise exceptions, since it allows the instructions to commit first before delivering them
<geist>
which keeps it from having to need to unwind everything. i wonder what that looks like in reality
<zid>
how are you going to make your communism work without a politburo
<heat>
actually i have no idea how to do safe code patching in userspace
<heat>
hopefully without signals
<gog>
i'm serializing
<heat>
grog
<gog>
heato
<heat>
bugzilla
* gog
emits a laugh track that increases in volume steadily
<zid>
just patch it ATOMICALLY
<zid>
done
<Ermine>
lists.gnu.org works through vpn, so
<zid>
Pencils? In my pencilcase? it's more likely than you think
<mcrod>
DICKS!
<Ermine>
wat
<niceperson>
so what's the sanctioned way of patching
<Ermine>
why do you patch
<heat>
avoid branches
<niceperson>
PERFORMANCE
<heat>
or sometimes you have no choice if its shit like patching the lock prefix in/out
<heat>
niceperson, the intel sanctioned way is to serialize all CPUs on a patch_in_progress flag, then execute a serializing instruction
<Ermine>
So in kernel you see that you're going to have a branch and you change the code to have no branching?
<zid>
I mainly use it to eliminate function pointers
<heat>
you should look at my static keys and the associated commits
<zid>
cus function pointers can dick my pencilcase
* niceperson
burps
<sham1>
That burp was pessimal
<niceperson>
heat: where is the intel sanctioned way described
<heat>
8.1.3
<niceperson>
what does amd say
<heat>
Ermine, so a trivial idea behind code patching is that instead of "if (cpu_has_feature_a()) insn_a(); else insn_b();"
Burgundy has quit [Ping timeout: 260 seconds]
<heat>
you have insn_a and insn_b in the same IP, and you patch the location to have the correct instruction
<heat>
then you can have more advanced usage like annotating call sites/jump sites and then patching those out, or patching them to point somewhere else
<heat>
niceperson, no idea
<Ermine>
ic
<heat>
i'm fairly sure this is the technique you should use and that most people use
<heat>
Ermine, my static_key stuff allows me to have ZERO COST branches for shit that never changes/changes regularly
<heat>
where i keep the likely case inline in the function and the unlikely case at the end, with a jmp. the common case has a nop instead of a jmp, so you never pay the cost of branching or jumping
<heat>
if you look at your Local Onyx(tm) Build you'll notice some int3's where the branches/nops go, in those functions
<heat>
that's also how i do ZERO-COST tracepoints
<Ermine>
Like in kernel/arch/x86_64/boot.S, line 289?
<heat>
no
<Ermine>
ok
<heat>
see save_fpu's disassembly for a simple (although PESSIMAL) example
<heat>
(pessimal because it's just instruction replacement, could be done directly with code patching instead of a static branch)
termin has quit [Read error: Connection reset by peer]
heat_ has quit [Remote host closed the connection]
<netbsduser`>
on nvidia and linux, i'm not sure what all the fuss is about
<netbsduser`>
they publish a driver for gnu/linux as well as freebsd and solaris
<netbsduser`>
i understand the linux people think it should be part of the linux tree but it's a portable driver and it's not gnu/linux so it doesn't belong in there
<geist>
oh well ther eyou go. now you have every possible os in the planet
<netbsduser`>
i would appreciate if they published a driver for my OS too but what can a man do
<geist>
but you're right, they do have freebsd drivers. i thought they stopped that a while back
<netbsduser`>
reportedly freebsd is quite favoured by nvidia engineers
<geist>
if nothing else because it's probably not changing out from underneath them as much
<gog>
that's because freebsd is good
<geist>
may be a good fairly stable testing environment
<netbsduser`>
they are quite opinionated and are also known to have technical objections to wayland
Turn_Left has quit [Read error: Connection reset by peer]