<devcpu>
kazinsal: reread it twice and did not get it =) you scp iso, then power cycle the vm? then vm loads new kernel from tftp?
<klange>
ESXi host is presumably running the tftp server and just has a 'reload' command.
<klange>
My only experience with ESXi is from my uni days when our ACM student chapter migrated a rack of a dozen servers to a single Dell blade running ESXi, which marked the end of our days of having our own server room (which we mostly used as a refigerated storage for soda).
vdamewood has joined #osdev
srjek has joined #osdev
<kingoffrance>
parsed output: ( instead of [...], I just [...] ) there's 2 branches there :)
<kingoffrance>
or is it one branch, two twigs? 2 paths
vinleod has joined #osdev
vdamewood has quit [Killed (iridium.libera.chat (Nickname regained by services))]
vinleod is now known as vdamewood
nyah has quit [Ping timeout: 268 seconds]
isaacwoods has quit [Quit: WeeChat 3.3]
mahmutov_ has joined #osdev
gog has quit [Ping timeout: 252 seconds]
<kazinsal>
devcpu: my old method is to power the VM off (because having the VM on locks the .iso file), scp over the new .iso file, start the VM again, and connect to the serial console over TCP from PuTTY
<kazinsal>
the serial console that is my OS's, not ESXi's
<kazinsal>
the new method is to just add "update-tftp" to my build command and then punch "reload" into the serial console of my OS to reboot from TFTP
<kazinsal>
update-tftp copies the new boot images to the TFTP root, archives the old ones, and updates grub.cfg to point to the new ones
<clever>
kazinsal: ive been using the netboot support in the rpi for similar reasons, i dont have to constantly re-flash the sd card
<klange>
I've got all my stuff ready, I need to set up a development workflow for that...
<klange>
Got my Pi, got the TTL-to-RS232 serial thing going (one of my adapters was DOA, but the package I bought came with two, and the other one worked)...
<clever>
for the whole pi0-pi3 lineup, an sd card with only bootcode.bin will let it network boot with the latest version of that code
<clever>
with the pi3, the bootrom also can do netboot if you set an OTP fuse, but that code may be older and buggy
<klange>
This is a Pi400.
<clever>
pi400 has all of that code in spi flash, and you just enable it with the BOOT_ORDER
<clever>
the spi config on the pi400 also lets you set the tftp server ip
<clever>
so the dhcp server doesnt have to agree to things
<clever>
that tftp dir, needs all of the firmware files you would normally have had on the fat32 partition
<devcpu>
kazinsal: i see, thanks!
YuutaW has joined #osdev
srjek has quit [Ping timeout: 245 seconds]
dutch has quit [Quit: WeeChat 3.3]
<kazinsal>
interesting. never actually looked at the e820 map on my ESXi VMs before but there's exactly one 4096-byte entry after the last usable RAM entry marked as bad memory
<[itchyjunk]>
Someone told me a GPU "basically runs it's own OS" and this has been bugging me a bit
<Mondenkind>
[itchyjunk]: your [intel] CPU runs its own OS, too!
<[itchyjunk]>
right, but CPU already has an OS and in my head, CPU told GPU what to do etc
<[itchyjunk]>
But if GPU ran it's own OS, my model of the world is shattered and i am back to square one
<Mondenkind>
no, the CPU has two OSes
<Mondenkind>
one of its own and one that came with the CPU
<[itchyjunk]>
@_@
<[itchyjunk]>
how is that possible?
<kazinsal>
GPUs can run code independently of the host ass soon as the code is uploaded to them
<kazinsal>
the hard part is uploading the code to the host
<Mondenkind>
it runs minix
<[itchyjunk]>
oh the one that starts it up and does the basic input out put test?
<kazinsal>
er, to the GPU
<Mondenkind>
[itchyjunk]: also see microsoft's recent thing, directstorage. GPU can talk directly to your ssd over pcie, decode textures without getting the cpu involved
<[itchyjunk]>
Okay, CPU has this basic input output test stuff, sure GPU doesn't get its own?
<[itchyjunk]>
GPU can talk to my storage without taking to the CPU? that sounds .. hmm
<Mondenkind>
bios most likely comes as part of the motherboard firmware, not the CPU. But yeah GPU has its own firmware
<Mutabah>
BIOS/firmware is different to the SMM/IME code
<[itchyjunk]>
the more i think i learn, the less i seem to know
<Mondenkind>
whether you want to call the code that runs on the GPU an OS or not is...ehh it's iffy
<[itchyjunk]>
is this "model" of GPU being it's own thing, CPU being it's own thing etc related to high performance computing model?
* [itchyjunk]
has been curious about HPC ever since overhearing some conversation on the trian
<[itchyjunk]>
since HPC is a lot of different CPU talking to each other right?
<kazinsal>
I'd hesitate to call anything running a GPU an OS since it's not going to be providing I/O services etc
<[itchyjunk]>
and here, we have GPU / CPU taking to each other in the same way
<Mutabah>
I'd guess (with minimal evidence) that modern GPU drivers upload a small kernel/OS that handles scheduling of GPU tasks
<Mutabah>
e.g. if you're running a 3D application along with a 3D-accelerated window manager
<[itchyjunk]>
It's hard to believe humans have figured out this level of complicated stuff
<[itchyjunk]>
and i was even using it blissfully unaware!
<kazinsal>
we figured out how to get sand to do trillions of computations per second and then used it to burn down the planet generating tokens used for money laundering and illegal pornography
<Mondenkind>
:D
<[itchyjunk]>
you can't design modern CPU's by hand? even with a lot of smart people in the same room?
<kingoffrance>
i dont know, dinosaur says no
<[itchyjunk]>
learning about computers is a good way to have existential crisis
<[itchyjunk]>
My idea of OS is too narrow i guess
<kingoffrance>
it was a supposed cray joke
<Mutabah>
You could probably design a modern-ish CPU by hand, but not a fast one
<kingoffrance>
apple just bought a cray to design their new computer. cray just bought an apple to replace his pen and paper
<Mutabah>
On the other hand, bootstrapping is interesting
<clever>
pipelines, prefetch, jump prediction, those all make things faster, and much more complex
<kazinsal>
bootstrap a new CPU by bribing Jim Keller
<[itchyjunk]>
bootstrapping.. i came across that concept when i asked about compilers. who compiles the compiler type thing..
<[itchyjunk]>
so for cpu's , i guess it's who starts the os that starts the computer?
<kazinsal>
who hand assembles the assembler
<[itchyjunk]>
is that how you make the first one?
<kazinsal>
though these days if you're designing a CPU you can just simulate the instruction set on an existing OS
<clever>
[itchyjunk]: the PSP (amd's version of management engine) starts first, brings ram online, and copies the bios from flash->ram, then enables the x86 cores
<kingoffrance>
previously computers were people (look up in dictionary, or "when computers were people"), but thats getting philosophical.
<clever>
[itchyjunk]: the bios on the x86 core then brings the rest up (pci-e and such), then loads the bootloader from your boot disk, and the bootloader loads the os
<kingoffrance>
i mean, you can argue hand toggling is still one computer starting another :)
<[itchyjunk]>
is the PSP considered OS?
<[itchyjunk]>
and the GPU would have a PSP equivalent that performs something similar
<clever>
[itchyjunk]: i think it is running its own os, and the code must be signed by amd, so you cant modify it
<clever>
there is both a PSP rom, and that validates what is in flash, and then executes that
[_] has joined #osdev
<[_]>
dang it, computer is dying i think
<[_]>
so nothing is needed for this PSP to get started. as soon as electricity is coursing through the veins of a computer, PSP starts doing it's job
<[_]>
immutable firmware is to protect the user or companies secret sauce?
sts-q has joined #osdev
[itchyjunk] is now known as Guest1997
Guest1997 has quit [Killed (cadmium.libera.chat (Nickname regained by services))]
[_] is now known as [itchyjunk]
<clever>
[itchyjunk]: possibly both, its also part of the trust chain for secureboot
<kazinsal>
both, but honestly even if you had enough evidence that it was protecting the user most foss nerds would still think you're worse than the KGB for defending it
divine has quit [Remote host closed the connection]
divine has joined #osdev
<[itchyjunk]>
ah, are there system where such a blob doesn't exist?
<[itchyjunk]>
riscv doesn't need such a blob?
<kazinsal>
risc-v just specifies the ISA
<kazinsal>
the internals of the CPU are up to the designer/manufacturer
<[itchyjunk]>
ahhh
<[itchyjunk]>
i guess this would make those "foss nerds" even madder
<kazinsal>
I have interest in RISC-V but it's probably going to be another five years before off-the-shelf hardware reaches the "couple hundred bucks on amazon.ca" point
<[itchyjunk]>
i thought arduino equivalent of riscv things already existed
<[itchyjunk]>
riscv microprocessors is the word i guess?
<kazinsal>
production volumes are pretty low is one of the problems
<kazinsal>
according to mouser they've got 46 HiFive Unmatched boards in stock, with another 360 expected 2022-02-11 and another 720 expected 2022-07-06
<kazinsal>
unfortunately they're also $700 USD or thereabouts
<kazinsal>
PC Engines has no stock of *any* of their apu series boards, which deeply sucks... expected availability is a nebulous "2022"
<klange>
Bit more pricey than exploring ARM with a Pi...
<kazinsal>
though the AMD GX-412TCs in those are getting quite long in the tooth anyways
elastic_dog has joined #osdev
<clever>
[itchyjunk]: in the case of the rpi, the maskrom can be dumped and decompiled, and the 1st stage it loads is on SD card for most models, so it can be replaced
<[itchyjunk]>
ah, interesting
mahmutov_ has quit [Ping timeout: 252 seconds]
<clever>
[itchyjunk]: i have been investing a lot of time into the open pi firmware, and ive re-created enough features that you can boot a pi2 to an xfce desktop, with ntsc video out
<[itchyjunk]>
hmm sounds complicated
<[itchyjunk]>
so you've been reverse engineering some boot up blob?
<clever>
yeah
<[itchyjunk]>
do you need to just look at the blob on some other computer or do you poke at the rpi hardware itself?
<clever>
bit of both
<[itchyjunk]>
oh very interesting
<clever>
the 2d pipeline is entirely undocumented, but has linux drivers
<[itchyjunk]>
i imagine its similar to what a neuroscientist would do. see some signal and try to figure out what that signal does to the hardware etc
<clever>
[itchyjunk]: with a baremetal arm kernel, looking at the linux source, and letting the closed firmware initialize the system, i can do https://www.youtube.com/watch?v=JFmCin3EJIs
<[itchyjunk]>
there should be one logo but you can get multiple to appear?
<clever>
its fully hardware accelerated sprites
<clever>
so i can move them around with zero cpu cost
<clever>
you could then use that to make any 2d sprite based game
<[itchyjunk]>
pi comes with a "hardware accelerator" which just means another processor?
<clever>
this is a dedicated core, specifically designed to only do sprite rendering
<[itchyjunk]>
ah
<clever>
it will parse the list of sprites, fetch image data from ram, scale the image data, alpha blend the layer stogether, and generate 1 scanline of image
<clever>
then repeat, forever
<clever>
https://www.youtube.com/watch?v=u7DzPvkzEGA is the result of reading the linux source more, i can now bring the ntsc generator online, and repeat the same demo, without the closed source firmware being involed
<geist>
kazinsal: at some point when i still had esxi running i figured out how to create a shared disk image between two vms
<geist>
could then have VM A directly write to VM Bs hard drive
<kazinsal>
yeah, that's a thing you can do. never actually found a *use* for it mind you
<geist>
well this whole reboot the OS in test
<clever>
[itchyjunk]: https://i.imgur.com/Yeh6wEr.jpg is then the next logical step, just doing that as fast as possible, 0.61 seconds from power-on to video output, and a working command prompt
<kazinsal>
ah yeah I guess that would work, use one VM to write to the other
<geist>
right
<geist>
and you could even get the serial port of one routed to the serial of another
<[itchyjunk]>
wait so you can completly talk to the hardware accelerator without needing their blob?
<clever>
[itchyjunk]: correct
<clever>
[itchyjunk]: but ive not entirely figured out hdmi init yet, and the linux drivers fail because of undocumented security features
<[itchyjunk]>
is one of the core dedicated to 3d rendering?
<clever>
[itchyjunk]: the pi2/pi3 have ~18 cores
<clever>
12 cores purely for the 3d rendering
<[itchyjunk]>
wth
<clever>
and thats probably small, compared to modern GPU's
* geist
eyes roll
<geist>
yeah that is
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<clever>
the 12 cores, are each 16 wide vector only cores, so you can kinda count it as 192 cores
<clever>
geist: what are modern gpu's up to?
<geist>
4000, 5000? i think a rtx3090 crossed 10k
<clever>
i can see why you rolled your eyes, lol
<geist>
my older 1080ti seems to have 3584
<geist>
but of course a lot of that is just artificial stuff. how many have to be ganged together in a wavefront, etc limits the amount of independence
<geist>
much like how you pointed out that a lot of the cores there are 16 wide
<Affliction>
geist | 4000, 5000? i think a rtx3090 crossed 10k
<Affliction>
isn't that more, the total number of SIMD lanes?
<geist>
i dont think so. nvidia and AMD both moved back to lots of scalar cores a while back
<geist>
they're not VLIW or very wide individually like they were in the 2000s
<clever>
if we are just counting how many parallel lanes can be running at once, i think you could slap a 384 on the rpi, with the exception that exactly half are only capable of addition, and exactly half are only capable of mults
<Affliction>
hm
<clever>
the v3d on the pi avoids a lot of stalling issues, by just interleaving different threads on the same pipeline
<clever>
kinda like hyperthreading?
<Affliction>
I think that's pretty common
<clever>
even if the pipeline is 4 clock cycles long, you only execute 1 opcode every 4 cycles, for a given thread
<Affliction>
don't recall the source, but I've heard AMD's modern scheduler can juggle 128k threads
<Affliction>
Given the memory latency within GPUs, that makes sense
<geist>
yah and having 10k cores or whatnot to assign them to
<clever>
for the rpi, its less of a scheduler, and more just a fixed rotation between 4 threads
<[itchyjunk]>
how many cores was pentium I ?
<Affliction>
1?
<geist>
1
<clever>
each core has 4 identical sets of registers, and 1 shared pipeline
<geist>
again, clever is very good at hyping things up a bit here. rpi is not a particularly special arm soc, but if you start adding up gpu cores and whatnot you can find that almsot everything has something like 20 nowadays
<geist>
but cpu cores, 4.
<Affliction>
There could be additional cores hidden away in the hardware too
<geist>
what's a bit different about rpi is the GPU is somewhat more general purpose than usual
<[itchyjunk]>
hmm, are all the cores of rpi "printed" at the same time? same dye i guess?
<geist>
and so there's a default binary blob that runs on it that gives you a fairly high level gpu interface
<geist>
yeah
<Affliction>
I hear the apple M1 has a cortex-m4 coprocessor in the GPU, which itself has a cortex-m0 coprocessor
<Affliction>
there are CPUs all over the place
<Affliction>
for every one you know about, there's probably 10 you don't
<geist>
that's very very common nowadays. you'll find random cortex-ms as little assistant or power management processors on all sorts of things
<clever>
the wifi and bt also have their own dedicated arm cores on the rpi
<[itchyjunk]>
right, this is the "apple phone charger has a cpu" thing
<Affliction>
My HDD has 5 cores!
<[itchyjunk]>
that was shocking too
<geist>
right plus things like SD cards, etc all have little cpus on them
<geist>
running little rtoses
<clever>
and the sd card firmware can even crash, leaving the card unreadable, yet the data is still perfectly intact
<[itchyjunk]>
those tiny sd cards that you can put in phones have cpus on them?
<clever>
[itchyjunk]: yep
<geist>
sure
<[itchyjunk]>
i imagined SSD's to have it.. but not an sd card
<[itchyjunk]>
yikes
<geist>
absolutely
<Affliction>
That was a thing with some samsung phones, the firmware tripping itself up resulting on phones not booting
<clever>
[itchyjunk]: that cpu and rtos manages the wear leveling and translation between sd commands and raw nand flash
<Affliction>
Amazing the abstractions we build so we can pretend flash is spinning rust
<Affliction>
but then, HDDs themselves are pretty much completely dependant on FEC these days too
<geist>
yah totally
<geist>
and the shingled stuff too
andydude has joined #osdev
<geist>
even does a RMW cycle and supports trim!
<Affliction>
just reading the backlog
<Affliction>
Mondenkind | no, the CPU has two OSes
<Affliction>
since it's there in the background, possibly emulating legacy hardware interfaces
<Affliction>
Isn't it though?
<kazinsal>
it's no more of an OS than the 16-bit BIOS is
<Affliction>
I figure, it runs in the background, providing services to the running main OS
<Affliction>
To me, that's pretty much what an OS does, provide services to running software
<kazinsal>
the point of SMM is that the actual OS doesn't even know it's doing stuff
ElectronApps has joined #osdev
<kazinsal>
the software on the machine isn't making library calls or whatnot to SMM code because SMM code is just doing things. maybe. sometimes.
<kazinsal>
that honestly makes it *less* of an operating system or kernel or whatever you want to call it than BIOS ISRs
<Affliction>
In that case, the intel ME wouldn't count either
<Affliction>
Since the running OS doesn't have to call into it, either
<clever>
what do you even define as an os?
<clever>
something that provides services to another piece of software?
<Affliction>
as a generalisation, sure, with the extra caveat that it abstracts hardware
<clever>
and isnt that exactly what the SMM is doing?
<Affliction>
pretty much
<kazinsal>
by that definition the microcontroller firmware in my mouse that lets iCUE change the LED colours is an operating system
<kazinsal>
as it abstracts the underlying LED GPIO hardware and provides that abstraction to my PC over USB
<clever>
kazinsal: probably!
<kazinsal>
kinda makes the phrase "operating system" useless
<Affliction>
I would consider the mouse another node on the network that forms your computer
<clever>
drawing the line between firmware and os, gets kinda fuzzy
<Affliction>
pretty much
<kazinsal>
if everything from Boondoggle GNU/Linux v4.20(69) to the scancode translator in a model M is all just considered an "operating system"
<Affliction>
since a lot of 'firmware' is indeed an OS
<kazinsal>
the firmware loaded into the DSP in the mixer my SM57 plugs into isn't an OS
<kazinsal>
it's DSP code
<Affliction>
I mean, your mouse' firmware probably has a trivial scheduler to share its CPU resources between the LED code, button sampling, sensor reading, and communication
<Affliction>
Even if that 'scheduler' is just a loop
<clever>
Affliction: i think the stage-1 loader in the rpi (brings ram up, loads the next thing) has full context switching in its scheduler, but that code is hard to make sense of
<Affliction>
The firmware in your router probably runs a full multitasking kernel
<kazinsal>
my router is a virtual machine running OpenBSD
<clever>
Affliction: routers are often just embedded linux
<Affliction>
pretty much
<kazinsal>
and a router is a much more complex appliance that runs much more complex code than a mouse.
<Affliction>
Perhaps, I haven't designed a mouse
<kingoffrance>
" the mouse another node on the network that forms your computer" yeah, but now you have a mainframe </disappears, like waldo>
<Affliction>
I mean, computers haven't been 'one computer' in a long time
<Affliction>
ANd, the microcontroller in some mice can probably outperform mainframes of decades ago
<kingoffrance>
true
<Affliction>
I hear some of them run multi-MHz ARM cores, not sure what that says about the state of their code :)
<kingoffrance>
and various nasa or other spacecraft
<Affliction>
Though I suppose, sampling effectively a camera at up to 1KHz probably does require a fair amount of compute
dormito10 has joined #osdev
<Affliction>
So yeah, I'd agree my definition of OS might be permissive, but, I don't think it's wrong
<Affliction>
I can see why some might disagree
<geist>
yah generally to count as an OS to me it needs to be logically separate from the task itself, and provide some functionality in a semi generic way
dormito has quit [Ping timeout: 252 seconds]
<geist>
ie, a single embedded thing that just runs a loop and has no real distinction between the OS and the application doesn't count
<clever>
geist: so LK without a userland, isnt an os? more of a firmware?
<geist>
OS
<geist>
because it's logically different from the app that runs on it
<geist>
even if it's same address space, etc. like PC-DOS
<clever>
guess that works
<Affliction>
I can agree with that
<clever>
though DOS had loadable apps
<Affliction>
I would go further, compiling your app into the linux kernel would still count as an OS, they are still separate code
<geist>
right, but LK is a project you can build stuff on top of. it provides OS like functionality, even if you mostly use it as a single binary
<Affliction>
Sure, same binary blob but, so is most firmware
<geist>
exactly
<geist>
most rtoses are that way, freertos, threadx, etc
<clever>
ive heard that the threadx based rpi firmware, still has the ability to load modules at runtime
<clever>
but the symbols are all missing, so the runtime linker cant do very much of use
<geist>
right
<clever>
you kinda need more of a checklist of features
<clever>
because id generally consider anything with threads and context switching to be an os
<geist>
to me it's all about intent and purpose and separation
<Affliction>
still reading up
<clever>
but dos lacks those, and is still an os
<geist>
technical details have changed over the years
<Affliction>
kazinsal | both, but honestly even if you had enough evidence that it was protecting the user most foss nerds would still think you're worse than the KGB for defending it
<Affliction>
Man, I had that debate with the TPM
<Affliction>
It's just a chip
<geist>
truying to make a list of concrete features for OS stuff i think is a moving target
<Affliction>
If you have it, why not make use of it
<Affliction>
But, apparantly the TPM is hitler-enshrined-in-silicon
<kazinsal>
people angry about windows 11 because of the TPM need some medication
<Affliction>
And the arguments are about what proprietary software might do with it
<Affliction>
Proprietary software might do evil with your CPU too!
<geist>
2 pieces of windows 11 stuff i learned lately: a) my threadripper isn't eligable. i guess only Zen2 are eligable? WTF?
<geist>
b) i upgraded a mostly irrelevant cheapo machine and it's not half bad
<geist>
ui is clean at least. runs fairly smoothly
<Affliction>
geist: at work, the shiny 2400Gs and 2500Us we rolled out a couple of years ago are nope, so we're sticking with 10 'til 2025
<kazinsal>
I feel like they're going to drop the eligibility requirements a bit soon
<kazinsal>
it's probably hardware speculation exploit mitigations that it's looking for
<geist>
yagh my main desktop i'm sure is eligable but no way am i upgrading until at least they fix the zen slowdowns
<Affliction>
That's the general rule with windows, always wait :)
<Affliction>
I only use it for gaming, leave the serious work for a serious OS
<kazinsal>
if I tried to do my job on Linux I'd probably be fired for not being able to use half the tools I need
<Affliction>
Naturally, Office is still important
<Affliction>
Because the trainwreck they call file formats are damn hard to implement all the details of, properly
<Affliction>
"but it's open! and xml!" sure, an XML mapping of the binary format
<kazinsal>
a lot of remote access VPNs don't have linux clients because most of the enterprise world doesn't realize that $currentYear+1 is the year of linux on the desktop
<Affliction>
That has an ISO standard that they don't implement
<Affliction>
no no kazinsal, I think 2022 will really be it this time! /s
<kazinsal>
my desktop runs windows. my laptop is an m1 macbook. the only linuxes in my apartment are virtual machines on a server that lives under my desk and keeps my feet warm
<Affliction>
My laptop is ancient and was hopeless running windows 7, it's pretty much a thin client these days.
<Affliction>
Curious about Alder Lake, and what it could do in a laptop if it doesn't suck
<Affliction>
Otherwise, I might get a zen3 one
<Affliction>
Either way, holding off
<geist>
yah i'm waiting for the next line of macbooks and will probably get one to replace my aging 2014
<geist>
but on the flip side i dont really use laptops right now becuase that involves going outside
<kazinsal>
work sent me a new laptop and it's a dell with an alright screen an ddecent weight but the worst keyboard and trackpad I've used in years
<kazinsal>
I have not actually done anything on it yet
<Affliction>
sounds about right
<kazinsal>
I'm still remoting into my desktop at the office
<geist>
hah yeah like the first dell i got at my current job. it was so terrible i swapped it with a macbook
<geist>
it was only usable with external keyboard and mouse
<Affliction>
I'm hoping to pick up something decent, that I can get another 10y out of
<kazinsal>
they gave me the option of either a 13" or a 15" dell and I just told them to give me the 13" because I knew I wasn't going to use it unless I have to go on site somewhere
<kazinsal>
and even then it's my second laptop, because I'll just bring my macbook
<kazinsal>
weighs less, better screen, better battery life, better trackpad, better keyboard... probably faster than an 11th gen mobile i5 as well
<geist>
yah usually i get a fairly high end mac laptop and then milk it for 5 or 6 or 7 years
<geist>
the fact that my 2014 mbp is still going okay without any major malfunctions is pretty good
<Affliction>
Well, I went low end and cheap back in 2009 and, given only a memory upgrade, it's still alive!
<Affliction>
Single core non-HT celeron @ 2.5GHz, woo!
<geist>
most annoying part is some sort of antiglare covering on the screen is starting to wear off in parts. where it has rubbed against the keys
<Affliction>
as I said, thin client... Even modern websites are too much for it
<geist>
yah that's what the 2014 is starting to feel like
<Affliction>
that said, given the shortages, made even worse by Microsoft obsoleting a bunch of otherwise perfectly good chips...
<Affliction>
We'll see
<sham1>
Morning all
<kazinsal>
hmm. hasn't started raining yet
<kazinsal>
I should go for a quick chronic walk and then read through the PXE spec once I'm nice and relaxed
<kazinsal>
trying to de-gnuify my setup as much as possible and apart from the obnoxious ones (gcc -> clang, gnu make -> posix make) all I've got left is grub -> not grub
<kazinsal>
for my OS project, that is
<klange>
I should poke at llvm again. I had a working clang build of toaru32 but never really touched the userspace aspects...
xenos1984 has quit [Read error: Connection reset by peer]
<klange>
Meanwhile, re: gnu make → posix make... my aim is to implement my own make that's sufficiently gnu-compatible ;)
<klange>
I'm also working on porting Python scripts to Kuroko; the last notably one I have is essentially a wrapper for making tarballs suitable for use as ramdisks...
<sham1>
Make a thing that generates posix makefiles or even ninja
<klange>
I have my own ISO generator as well, written in Python but definitely portable to Kuroko... and most of my build is actually Kuroko-driven magic dependency detection.
ZetItUp has joined #osdev
xenos1984 has joined #osdev
jjuran has joined #osdev
andydude has quit [Quit: andydude]
[itchyjunk] has quit [Remote host closed the connection]
transistor has joined #osdev
eremitah has joined #osdev
eau has joined #osdev
vancz has joined #osdev
dormito has joined #osdev
dormito10 has quit [Ping timeout: 252 seconds]
<geist>
well, been watching the Evangelion movies. this is something
<geist>
been years since i saw the series, but the second half was such an incomprehensible mess it didn't make an impression then
<zid>
I know, great isn't it
<zid>
EoE is still one of my favourite things ever
<zid>
3.0+1.0 existing is kind of.. sad in a way, end of an era
nyah has joined #osdev
Vercas7 has joined #osdev
Vercas has quit [Ping timeout: 276 seconds]
Vercas7 is now known as Vercas
GeDaMo has joined #osdev
dormito has quit [Quit: WeeChat 3.1]
gog has joined #osdev
<klange>
Experimenting with some startup changes that integrate kernel log messages (mostly so I can nicely say that I'm decompressing a ramdisk, which can take a few a second or two under TCG, or quite a bit longer under Bochs) https://klange.dev/s/Screenshot%20from%202021-10-15%2019-01-32.png
Arthuria has joined #osdev
kingoffrance has quit [Ping timeout: 245 seconds]
dormito has joined #osdev
dormito10 has joined #osdev
Retr0id8 has joined #osdev
Retr0id8 is now known as Retr0id
dormito has quit [Ping timeout: 252 seconds]
dormito10 is now known as dormito
eau has quit [Quit: bleh!]
eau has joined #osdev
rorx has quit [Ping timeout: 260 seconds]
Oli has quit [Ping timeout: 252 seconds]
Oli has joined #osdev
anon16_ has quit [Read error: Connection reset by peer]
dormito10 has joined #osdev
rorx has joined #osdev
dormito has quit [Ping timeout: 265 seconds]
dormito10 has quit [Ping timeout: 245 seconds]
anon16_ has joined #osdev
transistor has quit [Read error: Connection reset by peer]
anon16_ has quit [Ping timeout: 252 seconds]
X-Scale has joined #osdev
qookie has joined #osdev
ahalaney has joined #osdev
anon16_ has joined #osdev
diamondbond has joined #osdev
wgrant has joined #osdev
andydude has joined #osdev
sprock has quit [Ping timeout: 252 seconds]
tpefreedom has joined #osdev
tpefreedom has left #osdev [Leaving]
qookie has quit [Quit: leaving]
qookie has joined #osdev
[itchyjunk] has joined #osdev
pretty_dumm_guy has joined #osdev
diamondbond has quit [Read error: Connection reset by peer]
diamondbond has joined #osdev
ElectronApps has quit [Remote host closed the connection]
diamondbond has quit [Ping timeout: 265 seconds]
sonny has joined #osdev
h4zel has joined #osdev
sprock has joined #osdev
gdown has joined #osdev
qookie has quit [Ping timeout: 260 seconds]
srjek has joined #osdev
diamondbond has joined #osdev
wgrant has quit [Ping timeout: 252 seconds]
sonny has left #osdev [#osdev]
wgrant has joined #osdev
h4zel has quit [Ping timeout: 252 seconds]
<[itchyjunk]>
yesterday we said pentium one was 1 core processor and a rpi might have a 4core arm processor. but does that mean a rpi is multiple times more "powerful" that pentium one? i guess there is this weird bias in my head that makes in think of desktop as "real computers" and everything else as toy computers
<j`ey>
you can have 4 slow CPUs slower than 1 fast CPU
<[itchyjunk]>
ahh, so is that the case here?
<j`ey>
I dunno about pentium 1
<kazinsal>
the pentium 1 is *slow as hell*
<[itchyjunk]>
hmm pentium I through V are the only ones i really remember
<j`ey>
what makes you call a computer a desktop?
<[itchyjunk]>
yes but i think pentium 1 was the full blown desktop where i saw GUI? i can't remember
<[itchyjunk]>
i remember lotus,dos and some gui
<kazinsal>
it's hard to effectively compare speeds between architectures, and still kind of hard to compare between microarchitectures because of differences in out-of-order execution and speculation and such
<kazinsal>
and instruction latencies etc
<[itchyjunk]>
moniter, that big white box containing motherboard with a fan on the back etc
<[itchyjunk]>
take pentium II for example, i could play Aegis of Empire: Rise of rome on it smoothly. could rpi outperform that easily?
<kazinsal>
by a longshot
<kazinsal>
just on pure clocks (a terrible benchmark, but for comparison) alone the highest clocked Pentium II was something like 450 or 500 MHz and a Pi 4B has a 1.5 GHz quad-core 64-bit ARM CPU
<[itchyjunk]>
oh interesting, so that board you linked to runs windows 3 smoothly
<[itchyjunk]>
wonder how many core it has
kingoffrance has joined #osdev
<GeDaMo>
1
<[itchyjunk]>
oh..
<[itchyjunk]>
1 150Mhz is all it takes?
<GeDaMo>
Well, the 386 only went up to 25MHz I think
<[itchyjunk]>
What happens with all this extra compute in modern computer? It ocassionally gets used to loading things and rest of the time it's idle?
<GeDaMo>
Modern machines are doing a lot more
<GeDaMo>
Not necessarily useful things, of course :P
<[itchyjunk]>
lol
<zid>
Mine's mostly always idle
<zid>
graphics being hw accelerated accounts for most of that
<zid>
no need to redraw the screen every frame by hand
<[itchyjunk]>
doesn't hw accelerated mean there is some processers dedicated to redrawing the screen constantly?
<zid>
yes, it's called an nvidia 1050 ti in my case
<[itchyjunk]>
so someone else is busy all the time?
<zid>
it's busy.. for a small fraction of the time, 60 times a second
<zid>
unless I've told it to figure out which of these 14 million points lie inside this cube and then connect them with triangles and shade them according to this bytecode
<[itchyjunk]>
what happens if you have some inbuilt hardware accelerator and also a GPU? the cpu will have to decide what to use?
<zid>
accelerator for what
<zid>
either it talks to the cpu in order to function or it doesn't, if it talks to the cpu.. then the cpu has to talk to it
<zid>
which takes up some amount of cpu time
<zid>
you're overthinking this I feel
mahmutov_ has joined #osdev
jimbzy has joined #osdev
mahmutov has joined #osdev
mahmutov_ has quit [Ping timeout: 252 seconds]
diamondbond has quit [Quit: Leaving]
mahmutov_ has joined #osdev
sprock has quit [Ping timeout: 265 seconds]
mahmutov has quit [Ping timeout: 245 seconds]
sprock has joined #osdev
vin has joined #osdev
Arthuria has quit [Ping timeout: 252 seconds]
Oli has quit [Quit: leaving]
<catern>
hmm I hope I didn't just screw up my interview, I said spinlocks were useful in single-core situations
<catern>
they are in userspace, right? like you can just yield every time you fail to take the lock, that seems useful right?
<zid>
there's no point spinning
<zid>
if nothing could possibly change the state while you spin
<zid>
They're *possibly* useful as hw access primitives, but then you wouldn't call it a spinlock
<zid>
just a busy wait
<catern>
zid: sure, I'm saying in userspace, where you could get interrupted and switched out
<sortie>
Honestly on single core a proper futex thing that wakes the other thread exactly is the only thing I can see make sense, and no cases where spin locks make sense in user-space
<sortie>
This obviously changes on multi-core where it can in fact reduce latency if the threads actually run concurrently
<geist>
hmm, looks like aquantia AQN-107 based 10gbe ethernet adaptors are pretty decent
<geist>
i wonder how the chipset itself compares with equivalent intel ones
<geist>
a bit cheaper, but seems to have a similar number of features, for basic 10gbe at least
<sortie>
I'm afraid my inner interview would deduct a point on that answer, although not flunk you just on that since spin locks do have their very special purpose uses and perhaps you knew about one
<geist>
agreed re: user space spinlocks
<sortie>
If only because you explicitly stress single-core here, totally different story on multi-core
<sortie>
I had a nice conversation a while back with geist iiirc about spin locks in a multi-core setting
<geist>
i've seen folks try to use them in user space and a lot of the time it's kinda a bad idea
<geist>
if anything because you end up slamming the kernel with yield() syscalls
<catern>
well I mean, if all you have is a sys_yield, rather than a proper futex thing...
<zid>
catern: who are you spinning for
<geist>
it's actually a thing we found folks doing in fuchsia that we redirected. someone had dome basically something like this
<sortie>
catern: Well yes they can be used as a basic threading primitive
<catern>
but I agree that for sure in a single-core setting futex kind-of-thing is better
<geist>
and suddenly we were seeing 100k syscalls in short order
<geist>
turns out someone had rolled a spin/yield user space lock
<geist>
when they really wanted a futex
<geist>
it was causing some issues because it was stressing out the scheduler locks
<sortie>
Futexes are a quite brilliant design that does very much the right thing that one needs, though their actual design and implementation is probably not usually taught
<raggi>
Golang yields rather a lot in it's runtime
<geist>
of course that was sort of our problem, due to less than ideal locking in scheduler stuff
<geist>
raggi: yah go too :)
<sortie>
I very much loved getting my OS to stop spinning altogether
<sortie>
It's a beautiful thing to be idle.
<catern>
so I actually feel more confident in my answer then - obviously futexes (futices) is what you would use on real Linux but in an imagined "my OS sucks and just has yield, not futexes", spinlocks are your only choice
<zid>
Mine doesn't spin, but it also doesn't do any real work sooo
<zid>
A spinlock is a userspace wait, where you pray some variable in your address spaces changes before you finish waiting, to avoid having to do a syscall. Who is going to change that variable? You have *one* cpu.
<geist>
clever: but you *did* at least get the yield() part. whats worse is when folks roll spinlocks with no yield
<zid>
You will *always* wait the full amount and *never* get the lock
<sortie>
catern: Well what was the question and context of it?
<sortie>
futexen
<zid>
you will only get the lock by yielding to whoever has it, because they are /not running to release it/, you have one core.
<geist>
oh sure if you have no futex then user space spinning + yield is about all you get
<zid>
'just spin until I get scheduled out' is also, not, a spinlock
<zid>
it's a spin.
<geist>
correct. and there's basically no reason for that
<catern>
sortie: just some "how would you protect some memory from concurrent modification in a low-latency way" basic thing, and I answered spinlocks, but then they asked about single-core vs multi-core so I think they were trying to elicit me saying "uh well actually you wouldn't use a spinlock on a single core"
<sortie>
Though spinning is not quiiiite correct in principle because there's a risk it doesn't terminate due to poor scheduling / starvation
<geist>
in the Old Days, before futexes were the default thing, say the 90s, usually you just always blocked on something
<zid>
WaitForSingleObject or select for life
<catern>
instead I said "well um on a multi-core system you'd want a cache-coherent spinlock which creates annoying bus traffic, and so on a single-core system you can use a nice unlocked non-cache-coherent spinlock"
<catern>
which, in retrospect, is... a weird thing to say...
<sortie>
catern, in the context of standard programming or operating systems programming?
<catern>
userspace
srjek has quit [Ping timeout: 264 seconds]
<catern>
(er, not on a single-core system, on a single-core datastructure, you can use non-cache-coherent CAS)
<sortie>
Eh you pass my buzzword test
<catern>
I assume there must be some non-cache-coherent CAS in x86 right
<catern>
in one of the many extensions
<sortie>
Start talking about cache coherence and bus traffic and so on, the candidate knows some stuff, might get a detail wrong or so
andydude has quit [Ping timeout: 268 seconds]
<sortie>
I assume this question wasn't load bearing on the entire interview
<catern>
\( ﾟヮﾟ)/
<zid>
that's what the nops are for
andydude has joined #osdev
anon16_ has quit [Ping timeout: 252 seconds]
sprock has quit [Ping timeout: 264 seconds]
<gorgonical>
This might be a dumb question. It was something I was thinking about in the shower today -- when you dd some data to a USB drive for booting or something and you run "&& sync" to make sure it's fully copied, where is that data being buffered? There's the VFS system, the block device interface, the USB driver. What buffer exactly are you waiting to flush when you run && sync?
<zid>
Yes :P
<zid>
but mainly the vfs
<zid>
it'll absorb write() and return early for performance
<gorgonical>
I thought it would probably be vfs
<zid>
then block once the buffer fills up
<sortie>
I believe sync is supposed to make sure it all bubbles down
<gog>
it's buffers all the way down
<gorgonical>
And you can probably tune this buffer size in vfs, right?
<sortie>
It may vary how much of an effort sync does on your particular system, I expect there to be settings about this
<zid>
the writes should have at least been issued, they m ight still be clogged up in the usb host or whatever though
<zid>
so I wouldn't pull the power that quickly
<sortie>
On Linux you can basically tune all of these parameters, I expect, there's always loads of settings
anon16_ has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
<sortie>
Ah right, yet another case where object and A and B need to access each other asynchronously without deadlocking
mahmutov_ has quit [Ping timeout: 264 seconds]
mahmutov_ has joined #osdev
sprock has joined #osdev
Oli has joined #osdev
<riverdc_>
where would yall recommend looking for (cheap) x86_64 boards to test on? I'd like to try implementing a PS/2 driver for keyboard input and run it on real hw
<GeDaMo>
Do new machines even have PS/2 interfaces nowadays?
<GeDaMo>
Maybe second hand?
<riverdc_>
definitely not new machines, but USB seems like a ton of work to get working
<jimbzy>
Why is USB so funky?
<jimbzy>
I mean, I get that anything universal is going to be complicated, but it's one of those technologies I just haven't been able to really dig into.
<zid>
literally anything :P
<riverdc_>
I don't know enough whether to judge the design, other folks here would be better qualified. I just know the spec is insanely complicated
<jimbzy>
It's like the PDF of hardware or something. :p
qookie has joined #osdev
wootehfoot has joined #osdev
wootehfoot has quit [Client Quit]
wootehfoot has joined #osdev
GeDaMo has quit [Quit: Leaving.]
sprock has quit [Ping timeout: 264 seconds]
<geist>
not entirely true, some new gaming mobos still have ps2
<geist>
i looked into how it's done. usually those are attached to a SuperIO chip, usually made by Nuvoton, sitting on the LPC bus
<geist>
if you look up the data sheet for those, they basically just implement a bunch of legacy ISA stuff. com ports, parallel, ps2, etc so the mobo vendor can still stuff them if they want
<geist>
but those things are no longer present in modern intel/amd socs or chipsets anymore
<zid>
That's what I have, but it's 2011
<zid>
nuvoton superio, with a ps/2
<geist>
yah i've bought machiens as recently as 2019 that still have ps2, like my ryzen 3950x
<geist>
reason that has hung on is because there's a subset of gamer types that still believe it is lower latency than usb
<j`ey>
it's polling!!!
PyR3X_ is now known as PyR3X
<geist>
yes. though also modern usb stuff can poll at higher speeds such that ps2 doesn't really have an advantage
<geist>
there's a pretty good Ben Eater vid where he compares on the wire the polling intervals of various usb keyboards against ps2
<geist>
kidna interesting
<geist>
TL;DR a proper USB2 keyboard with say 1khz polling is at least as good as ps2, since the clock rate of the data is much faster than ps2
<geist>
so though there may be up to 1ms jitter of when the packet starts, the packet itself is much faster and completes at or before the best case ps2 packet
<geist>
that being said the usb stack as it processes the hid events may still add more delay
<zid>
yea I was messing porting an arcade machine to PC
<zid>
and it uses 115200 baud serial for its control panel
<zid>
that's 1ms just to clock it out
<geist>
yah i forget the clock rate of a ps2 packet. it's at least fixed length, so the latency is more or less fixed
<geist>
but it takes some amount of non trivial time
andydude has quit [Quit: andydude]
<zid>
I wrote hid code to replace it
<zid>
I am never touching the windows hid api ever
<zid>
ever again
<geist>
haha yeah hid is a disaster i think everywhere
<geist>
the fuchsia hid is complicated too and i think it only pretends to handle a subset of things
<zid>
It's not a bad api once you figure it out
<zid>
but holy shit do they not make it easy to figure out
<zid>
the msdn pages are literally "Returns the report collection status page of a hid device collection object"
<zid>
x20
anon16_ has quit [Read error: Connection reset by peer]
srjek has joined #osdev
ahalaney has quit [Quit: Leaving]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dormito has joined #osdev
anon16_ has joined #osdev
andydude has joined #osdev
wootehfoot has quit [Quit: Leaving]
Oli has quit [Remote host closed the connection]
Oli has joined #osdev
andydude has quit [Quit: andydude]
Terlisimo has quit [Quit: Connection reset by beer]
Terlisimo has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
<sortie>
Unix sockets file descriptor passing is complicated to implement correctly. Implementations even have to use garbage collection to handle special cases. I'm trying to see if I can avoid that if I can get away with a few restrictions:
<sortie>
1. A Unix socket (with file descriptors currently sent on it) cannot be sent over another Unix socket.
<sortie>
2. A Unix socket (currently being sent over another Unix socket) cannot send file descriptors.
<sortie>
3. A Unix socket cannot be sent over itself.
<sortie>
These are the three laws of Unix sockets and they prevent reference cycles and the robot uprising.
sprock has joined #osdev
srjek has quit [Ping timeout: 264 seconds]
C-Man has joined #osdev
<Mondenkind>
what's wrong with cycles?
<Mondenkind>
Embrace the cycles!
<sortie>
Break the cycle!
<sortie>
HACK THE WORLD
<sortie>
cd /usr/src && make world!
<Qubasa>
I just discovered that my grub memory map does not describe the memory region 0xFEE0_0000 where the APIC is located. Is this normal? Does this mean the grub memory map can be incomplete?
<sortie>
I don't have the knowledge to definitely answer your question, but in principle, yes, I believe GRUB is asking the BIOS (or through UEFI if UEFI) about the memory map and it may be incomplete if the firmware isn't great
<Qubasa>
shit
<sortie>
(usually not much to do in that situation than just to use less memory)
<sortie>
(Not really a problem in practice though, I believe)
<Qubasa>
well and if my APIC is located in that missing memory? :(
<sortie>
As for the APIC, I don't have the knowledge to say for sure, but I think it might be special memory
<Qubasa>
ahhh
<Qubasa>
i see
<Qubasa>
thanks ^^
<sortie>
I don't believe the memory map necessarily contains all the places where hardware memory regions are mapped (it's more designed to tell you about regular memory)
<sortie>
In any case, you should generally not be poking at any hard-coded memory location without something telling you something is supposed to be there.
elastic_dog has quit [Ping timeout: 268 seconds]
<sortie>
I haven't done APIC so I don't know what is supposed to tell you it exists at any given location, but if the firmware/hardware registers/whatever in-memory tables you are using/standards hard-coding an address/whatever tells you it's there, then it seems fine to trust that
<sortie>
That's generally a good design to avoid hard-coding addresses or assuming the physical memory layout of things, instead one should prefer to dynamically learn the layout of things at runtime and figure things out (sounds like you're trying to do that, which is great)
<Qubasa>
Hmm yeah I'm checking a register that tells me where the APIC lies, however I trusted the memory map too much regarding hardware devices and generated a page table that seems unfitting now :)
<Qubasa>
sortie: Really big thanks!
<sortie>
Qubasa, OK so that was just my non-authoritative answer as I'm not too knowledgeable here to tell you a definitive answer, but hopefully my incomplete knowledge helps and someone can get us both a more definitive answer
elastic_dog has joined #osdev
<Qubasa>
It definitely does it also aligns with what I faintly remember hearing a longer time ago~
<sortie>
:)
<zid>
yea just bear in mind the physical address space isn't just for ram
<zid>
so poking it at random may.. brick your e1000 ;)
<Qubasa>
I will keep that in mind ^^
<_eryjus>
the IA32_APIC_BASE_MSR should have the address of the APIC
<Qubasa>
yup I do check that
<zid>
Trying to enumerate all the devices listening to the memory bus would be a fun challenge
<qookie>
that MSR and also the MADT has it iirc
<_eryjus>
qookie: i believe you are correct, but it has been a while
dutch has quit [Quit: WeeChat 3.3]
Vercas has quit [Quit: Ping timeout (120 seconds)]