klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
<kaichiuchi> hm
<kaichiuchi> RTOS stuff is kinda interesting
<kaichiuchi> I've never really thought about _really_ good RTOS application design
<mrvn> do you want swap or mmap?
<mrvn> hard real time and disk IO is basically a no go unless you exclude errors
<kaichiuchi> nono, I mean I've never thought about RTOS application design in the sense "i'm using FreeRTOS, what's the best way to implement stuff"
<kaichiuchi> at work, we have ~10 tasks each with a state machine and that seems horribly wrong
<kaichiuchi> it definitely seems like the whole point is to NOT need a state machine
<clever> kaichiuchi: one crazy idea, could you use vector opcodes to do a single step on 16 state machines at once?
<clever> then your doing a step in less time, and they are in lock-step
<mrvn> nothing wrong with a state machine
<kaichiuchi> no :p
<mrvn> clever: realtime doesn't mean fast
<clever> mrvn: yeah, its more about low latency and/or low jitter to the latency
ZombieChicken has joined #osdev
<kaichiuchi> yes, for this application performance is not critical at all
<mrvn> clever: bounded latency
<clever> yeah
<kaichiuchi> it just feels like the whole point of the RTOS is so you can organize shit into tasks and thereby avoid state machines
<mrvn> with disk I/O having error timeouts in minutes the latency bounds simply are unacceptable.
<mrvn> kaichiuchi: no, the point of realtime is that you have an upper bounds till something happens.
<clever> with LK, the "realtime" threads are more just threads that cant be pre-empted
<kaichiuchi> okay, rephrase
<clever> so once a thread starts running, it must yield
<kaichiuchi> it just feels like state machines can be avoided if you're thinking in terms of tasks in a (free)RTOS like way
<mrvn> if you use a state machine to implement co-routines then yes.
<kaichiuchi> coroutines are deprecated in freertos
<clever> kaichiuchi: by state machines, you mean where you call a function to advance the state by 1 step, and then you go thru every state machine, sleep, repeat?
<kaichiuchi> put it this way
<kaichiuchi> (I really want to be more specific, but I'm under NDA so I cannot be THAT specific): we have sensors, and when those sensors are triggered, depending on the current state of some motors something needs to happen
<kaichiuchi> we use state machines for that
<mrvn> perfectly valid use case
<kaichiuchi> right
<kaichiuchi> I would find it hard to conceptualize this as separate tasks
<kaichiuchi> there'd be like 923749273429
<mrvn> because they aren't separate jobs
<bslsk05> ​gamozolabs.github.io: Vectorized Emulation: Hardware accelerated taint tracking at 2 trillion instructions per second | Gamozo Labs Blog
<kaichiuchi> I just find it a bit strange that we group related functions as one task, and then water them down to state machines
<kaichiuchi> I *get it*, it makes sense
<kaichiuchi> but I just think if you do that, then those tasks have too much responsibility
<kaichiuchi> put it this way: there's no case *ever* in FreeRTOS land where any of our tasks are ever anything but the Running state
<clever> an issue i could see there, is how do you decide which task to run next, and when?
<kaichiuchi> in my "design" I see a sensor polling task, an LED task
<mrvn> clever: hence the need for RT so you have an upper bound and all tasks will run in time before it's too late. :)
<kaichiuchi> and when the sensors detect something they create a bunch of other tasks and then when their responsibilities are done they get deleted but that isn't great either
<kaichiuchi> clever: apparently (in freertos land) you can use direct task notifications
<clever> personally, i would use an interval timer, to run a handler at regular intervals, LK runs timer callbacks in an irq context
<clever> that can then flip a bunch of tasks into runnable state, and prod the scheduler to context switch
<kaichiuchi> you see, unfortunately I have a lot of questions that cannot be answered because freertos's stupid book is outdated
<kof123> "create a bunch of other tasks" that sounds like a need for...rtinetd <stick figure running, one hand in air>
<clever> and realtime tasks/threads in LK cant be pre-empted, so they will each run in turn (based on priority flags), and return to sleeping when they finish their job
<kaichiuchi> this is the closest place I could think of
<kaichiuchi> heh
<kof123> (i should clarify, i am the stick figure running away from the idea)
<mrvn> kaichiuchi: unless you run a nuclear reactor or medical equipment just test if it works.
<kaichiuchi> well our current design works
<kaichiuchi> I'm just trying to think if we could simplify our design considerably
<clever> mrvn: that reminds me, i wrote a control loop for a reactor (in minecraft) and it ran for a few days, then the data feed went silent
<clever> i popped open the client, and all i found was a smoking crater
<mrvn> clever: well, minecraft glitches on it's own. no way to fix that really.
<clever> yeah, there wasnt enough data logging, so i cant really say what the cause was
<kaichiuchi> I think I need to think about this more
<clever> and at the sample rate, i would have lost some data to the explosion
<mrvn> clever: on servers event processing simply gets put off some ticks when there is too much load
<clever> which reminds me, ive heard something crazy about nuclear testing cores
<clever> where they replace the uranium core, with a computer covered in pressure sensors
<clever> and its supposed to log, and transmit the pressure data, as its being implodded
<clever> transmit fast, because the computer is going to be a smear of atoms in a few nanoseconds
<mrvn> so you just test the timing on the normal explosives?
<clever> how well synchronized the shockwave is, from every direction
<clever> so it implodes evenly
<clever> but its only an accurate test, if you dont have holes in the explosives for the sensors
<clever> so the data logging, has to be entirely self-contained, replacing the uranium core
<mrvn> and you can't have some fibre optic cables going out because that would interfer with the explosived or get exploded first.
<clever> yeah
<mrvn> plus all those nuclear test agreements.
<clever> without the core, does it count?
<clever> and its far harder to detect, because its not creating the same shockwaves
<mrvn> also you can repeat the test many times without destroying the lab
<clever> yep
<clever> its more like missle testing, just need a small live-fire range
<ZombieChicken> reminds me of that video of the manhole cover during some underground nuclear testing
<clever> nuclear canon
<clever> ZombieChicken: theres also this: https://en.wikipedia.org/wiki/Project_Plowshare
<ZombieChicken> Yep. They had a high speed camera pointing at it. It was there one frame, and gone the next
<bslsk05> ​'Battleship New Jersey - Home' - 'Battleship New Jersey is the world's fastest and longest battleship and the most decorated battleship in American history. Join us 5 nights a week at 1900 ET for stories of the ship's history, dives into the ship's 1600 compartments, and for discussions of how we are preserving this mighty ship.
<mrvn> project orion / the orion spaceshit drive is a much better use.
<clever> ZombieChicken: and this channel has a video talking about the different 16" shells, and one of the reported variants was nuclear
<clever> but the US military will neither confirm nor deny that it has ever been on a ship
<mrvn> clever: so obviously it was or they would have denied it. :)
<clever> mrvn: but you really dont want to use an onion drive for launch!
<mrvn> clever: that's the time you really need it.
<mrvn> when the aliens come on independence day do you really care about a little nuclear winter?
<ZombieChicken> Project Orion was certainly an interesting idea, though I don't think I'd want to be in the same hemisphere as that thing when it launches
<ZombieChicken> At this point that might be the best option to offset global warming...
<clever> mrvn: oh, and how different is the fusion drive from the expansive, vs project orion?
<mrvn> ZombieChicken: modern tech can build some quite clean bombs
<mrvn> the axpansive?
<clever> its basically just a bunch of lasers blasting a fuel pellet and causing fusion
<clever> the expanse*
<mrvn> clever: fission vs. fusion. totaly different
<ZombieChicken> hydrogen bombs are fusion devices
<clever> but some nuclear bombs yep both
<mrvn> blasting a hydrogent pellte into hellium is basically harmless.
<mrvn> ZombieChicken: yeah, they use the nuclear bomb to explode some hydrogen just like they use normal explosives to explode the uranium.
smach has quit []
<clever> i think thats more because they dont have good enough explosives to fuse hydrogen
<clever> so they are abusing a fission bomb to create fusion
<mrvn> if you can go laser -> hydrogen -> booom then you skip the dirty step.
<clever> exactly
<mrvn> hence the nice space drives in "the expanse"
<clever> i think there is an extra step that is often missed in the expanse, water
<clever> they just inject water into the chamber, and use the heat from fusion to boil the water
<clever> and then that converts heat into thrust
<mrvn> That's just some extra mass to make it more efficient
<clever> yeah
<clever> in the show, they call it reaction mass, i believe
<mrvn> Not sure if the water->steem even adds significantly. It's turned into plasma at insane temps. That little steam bump is probably nothing.
<clever> yeah, its basically liquid->plasma at that point
<mrvn> a million degrees gas expansion just packs more punch than a little bit of bolling 1g water.
<clever> should still have pressure, and you can also use magnetic fields to keep the chamber from melting
potash has joined #osdev
<clever> hmmm, can water "fall apart" with enough heat?
<mrvn> totally
<clever> but isnt burning an H2/O2 mix, also producing water?
<mrvn> I believe there is no such thing as water plasma.
<ZombieChicken> clever: "Can X turn into plasma?" is, to my knowledge, always a "yes"
<mrvn> it's not burning, can't combine at those temps
<clever> but then as it cools down after being ejected from the engine?
<clever> or would it disperse into too low of a density first?
<mrvn> that is a good question
<clever> another question, does temperature even exist, when the particles of gas dont have anything to bump into?
<mrvn> each other?
<mrvn> temperature is just speed. no bumping needed
<clever> temperature/pressure, is just sub-atomic jiggling, high speed movements, bumping into other atoms
<clever> but if the density is low enough, that an atom can fly for several km before hitting another atom
<clever> then its less jiggling and more just plain moving?
<mrvn> m v^2
<Mutabah> Rough theory: Temperature is a function of a collection of particles, a single particle doesn't have temperature - it has a kinetic engergy
<mrvn> clever: when they bump then you get pressure
<clever> Mutabah: yeah, thats what i was thinking
<Mutabah> ... wait, this is #osdev
<mrvn> Mutabah: we simulate such things here
<clever> oh right, and that law about how temp changes with pressure
<clever> that fits in, as pressure increases, your bumping into more things, and it counts as a higher temperature
<mrvn> only in a perfect gas :)
<mrvn> clever: no. it's you pushing down on the plunger to increase the pressure that speeds up the gas :)
<clever> what if i had a collection of atoms, all fired to meet at a single point in a vacuum, when they bump into eachother at the center of the sphere, it switches from kinetic engergy in free space, to a pressurized gas
<Mutabah> The act of restricting the space adds energy to the system, thus increasing the temperature
<clever> until the pressure wave passes thru, and it expands back outwards
<mrvn> space has a temp.
<clever> even in a perfect vacuum?
<mrvn> no such thing, violates quantum mechanics.
potash has quit [Read error: Connection reset by peer]
<mrvn> but besides the point. you measure the radiation, not particles.
<clever> oh, that reminds me, about where IR radiation comes from
<clever> i think its electrons dropping drom a high orbit to a low orbit?
<mrvn> clever: yes
<clever> and when atoms are bumping into eachother, it can add energy to the electrons and knock them into a higher orbit?
<clever> so over time, an object in a vacuum can convert atomic jiggle into IR radiation
<mrvn> something has to bump them back into higher orbits
<clever> the heat/jiggle within the object?
<mrvn> or some IR ration hits an electron
<clever> yeah
<clever> assuming its in the shade
<clever> mrvn: but what if you have a plasma? isnt that when there is so much energy, the electrons basically fly off and do their own thing?
<clever> how does that then produce any light?
<mrvn> capturing and loosing electrons?
<clever> i could see that
<clever> and then things start to get quantum? the bit about how electrons can only orbit at specific levels, wave/particle stuff
<mrvn> but what if you add an electric field and separate the electrons and positrons. Do the positrons then still produce light?
<clever> and when an atom captures an electron, any excess energy that doesnt fit into the next orbit down, is radiated
<mrvn> clever: yeah, explain those orbits to me please. It's like the moon orbiting the earth except with electric force instead of gravity, right? So shouldn't the speed of the electron determine the orbit and be arbitrary?
<clever> basically, picture the orbit, as a sine wave, bent into a circle
<clever> and the orbit is only valid, if that sine wave lines up
<mrvn> and as you go down the periodic table the whole orbit model breaks down.
<clever> so the circumference of the orbit, must be a multiple of the wavelength
<clever> the thing i dont understand, is the limit on how many electrons can be in each orbit
<ZombieChicken> are you two discussing ye olde "the atom is a solar system" model?
<mrvn> we are mixing and matching models
<clever> the mix comes when you think of the electron more as a wave, and an orbiting electron, must orbit a path that is a integer multiple of its wavelength
<mrvn> clever: the computer simulating the universe only has so many array elements in the atom struct. :)
<clever> so only certain distances are valid orbits
<mrvn> clever: only so many bits to specify the distance
<ZombieChicken> that would explain the plank length
<clever> mrvn: that reminds me of another sci-fi show, where an alien race discovered, if the density of inteligent life goes over some limit, it rips a hole in the fabric of the universe
<clever> almost like a buffer overflow, corruption the local state
<clever> but the alien lifeform then discovered, by basically poking the hole in the universe, that there was another plane of existance on the other side
<clever> a code execution explit
<clever> exploit*
<mrvn> clever: the IQ of a group is inverse to it's size. can't buffer overflow.
<clever> mrvn: in this show, it was a hive-mind
<clever> and it was basically turning into a planet sized brain
<clever> but, because the plot says so, if the lifeform goes into a dormant state, it doesnt cause that problem
<clever> and then 1000's of years later, humans land on the planet sized lifeform, and colonize it
<clever> un-aware of what it is
<clever> carving into its flesh and building sky-scrappers on it
<mrvn> what show is that? Now I want to watch it.
<clever> eureka 7
[_] has joined #osdev
[itchyjunk] has quit [Ping timeout: 248 seconds]
<immibis_> geist: most cellular networks are IPv6 with some kind of NAT or translation service for IPv4 only
varad7 has joined #osdev
varad7 is now known as varad
varad has quit [Read error: Connection reset by peer]
notdzwdz has quit [Remote host closed the connection]
sonny has joined #osdev
<sonny> If permissions are part of the parameters for your kernel api, are they capabilities?
notdzwdz has joined #osdev
smach has joined #osdev
smach has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 256 seconds]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 252 seconds]
<gog> looks wrong tho
<gog> how to kern'
<Mutabah> Force a 1px gap is the easy way
<Mutabah> or use a font that leaves a 1px gap
<Mutabah> (more fancy methods would assign each character a width, so `i` and `j` kern properly
<gog> this is a fixed width bitmap font that i grafted from 30 year old code
<gog> i'll go with forcing since i don't need fancy
<geist> immibis_: yeah that's what i'd assume
<moon-child> variable-width type is for CHUMPS
<gog> that's right
<klange> If you want to be able to do nice line drawing, include the extra column in the glyphs so you can use it with the box characters.
<moon-child> box characters? You mean IN-BAND SIGNALLING?
<moon-child> heresy
<klange> I see that your characters are already 8 pixels wide though, so that'll be un-fun...
<gog> i'm not necessarily tied to this font, it's just something i'm working with right now
fedorafan has quit [Ping timeout: 248 seconds]
<moon-child> proggy
<gog> progchamp
<gog> progechamp too
<moon-child> goggy
<immibis_> sonny: a capability is more-or-less like a file descriptor. Are your permissions like that?
* gog pets moon-child
* moon-child purrr
* moon-child curls up in gog's lap
<sonny> immibis_ what I'm thinking of isn't like an fd I was just wondering about ways to have all the functions in one space
<immibis_> what are you talking about?
<sonny> monolithic vs microkernel
<immibis_> what are you talking about?
<sonny> privilege escalation
<immibis_> what are you talking about?
<sonny> ok hint taken
fedorafan has joined #osdev
notdzwdz has quit [Remote host closed the connection]
notdzwdz has joined #osdev
<gog> mewo
<immibis_> sonny: no hint, you just didn't really say what you were talking about
<immibis_> sonny: "If permissions are part of the parameters for your kernel API, are they capabilities" <- what are permisisons? what are parameters? what is the API?
<immibis_> passing DeleteUser(username, Permissions::DeleteUser) <- is not a capability
<immibis_> int n = openUserByUsername(username, Permissions::Delete); delete(n); close(n); <- is capability-like (although you are not gaining anything in such a simple example)
<immibis_> (I don't feel qualified to say it "is a capability" :) )
<gog> cat_handle h = get_cat_by_name("gog"); pet(h);
sonny has quit [Quit: Client closed]
<gog> catability
<moon-child> I refuse to use any OS which isn't equipped with a full complement of cats
<Jari--_> dogs not good?
[_] has quit [Read error: Connection reset by peer]
bradd has joined #osdev
gog has quit [Ping timeout: 268 seconds]
<sakasama> They lack the manual dexterity and disposition needed for proper cable management.
<energizer> so do i, but that doesn't stop me
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #osdev
<immibis_> sakasama: foreshadowing
<immibis_> you broke the dog's internet
<sakasama> Better? Are you now sated?
<moon-child> ohai
slidercrank has joined #osdev
CryptoDavid has quit [Quit: Connection closed for inactivity]
Matt|home has quit [Quit: Leaving]
craigo has joined #osdev
craigo has quit [Ping timeout: 252 seconds]
fedorafan has quit [Ping timeout: 248 seconds]
fedorafan has joined #osdev
<sham1> And with that one word I'm now just imagining someone writing an OS in lolcode
danilogondolfo has joined #osdev
qubasa has quit [Ping timeout: 256 seconds]
bgs has joined #osdev
chibill has quit [Quit: You have been kicked for being idle]
gildasio1 has joined #osdev
gildasio has quit [Remote host closed the connection]
ZombieChicken has quit [Remote host closed the connection]
fedorafan has quit [Ping timeout: 248 seconds]
fedorafan has joined #osdev
<mjg> moon-child: loller
<mjg> moon-child: looking at the code it seems yolo quality
<bslsk05> ​reviews.freebsd.org: ⚙ D34097 Solaris doors IPC implementation
elastic_dog is now known as Guest5516
Guest5516 has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
elastic_dog has joined #osdev
unimplemented has joined #osdev
fedorafansuper has joined #osdev
fedorafan has quit [Ping timeout: 252 seconds]
GeDaMo has joined #osdev
gog has joined #osdev
kpel has joined #osdev
kpel has quit [Client Quit]
<moon-child> 'I stopped reading the patch after my error counter overflown'
kazinsal_ is now known as kazinsal
gog has quit [Quit: byee]
gog has joined #osdev
heat has joined #osdev
<heat> henlo
<heat> i heard we were talking about doors
<gog> henlo
<gog> heat heat heat
<heat> goggers
gera is now known as gera_
gera_ is now known as gera
unimplemented has quit [Read error: Connection reset by peer]
<heat> i show up and everyone stops talking about doors
<heat> fucking seriously
<gog> that's a door able
<heat> no ur a door able
<bslsk05> ​'The Doors - Light My Fire' by TheDoorsVEVO (00:09:23)
<epony> the solution: show up when they talk about Windows
<heat> something cool i found out about yesterday: https://github.com/facebook/folly/blob/main/folly/synchronization/Rcu.h
<bslsk05> ​github.com: folly/Rcu.h at main · facebook/folly · GitHub
<heat> facebook has an epoch-based apache-2.0 licensed RCU implementation
<epony> Remote Code Uxecution?
<heat> they seem to mostly try to implement the C++ standard RCU proposal
<moon-child> doors in onyx when
<epony> when the framebuffer gets blit support
<heat> when freebsd send pr
<epony> the first thing to draw is a sware portal to the wormhole of kernel modesetting
<moon-child> also why rcu and not hazard pointers
<heat> I think hazard pointers are worse?
<epony> "sQuared" tunnel waveguide for the Windowed light
<epony> from the other side
<moon-child> 'An std::scoped_lock costs about 5 ns'
<moon-child> assuming that's 15 cycles
<moon-child> so probably an atomic
<moon-child> ie strongly ordered
<epony> does not seem cheap and accurate
<moon-child> hazard pointers don't need an atomic. just a membarrier
<epony> 1 cycle is more than one instruction on modern CPUs
<epony> and the ns are for memory access times but that's system / hardware specific
<epony> cycles are in ps times
<bslsk05> ​pvk.ca: Flatter wait-free hazard pointers - Paul Khuong: some Lisp
<epony> yeah, vomit
<kaichiuchi> hi
<heat> moon-child, i don't think you necessarily need an atomic, at least in the read path
<heat> linux rcu certainly doesn't have an atomic in the read path
<heat> linux rcu does a pcpu non-atomic add plus compiler barrier
alpha2023 has joined #osdev
<heat> plus freebsd findings seem to indicate epoch-based RCU is better than linux RCU, at least in their tests
<heat> https://people.freebsd.org/~jeff/smr.pdf note that I have 0 idea what this means as this lacks LITERALLY ANY CONTEXT but haha line go more up
<gog> line go down actually
<moon-child> lol
<gog> i am very smart
<moon-child> well I'll maybe take another look in a bit. I had the impression that rcu requires more (essential) overhead on read side, but maybe I misunderstood
<heat> mjg, hello budget paul mckenney, pls help
gabi-250 has quit [Ping timeout: 255 seconds]
gabi-250 has joined #osdev
<mjg> heat: what now mofo
<mjg> heat: oh the above, i would put 0 stake in that result
<mjg> heat: in principle it may happen to be faster for specific cases because of one simple trick(tm): batching frees
<heat> fake news
<mjg> what the author neglects to mention is seere overhead for cases which don't bmbard you with freeing
<mjg> and other problems
<heat> ok so epoch-based rcu vs the quiescent state shit rcu
<heat> which one sucks the most
<mjg> i'm confident i already said that whenver someone publishes a paper
<mjg> they are probably lying
<heat> this isn't even a paper, just a vague graph
<mjg> same diff
<mjg> people warp reality to what they want to see
fedorafan has joined #osdev
fedorafansuper has quit [Ping timeout: 248 seconds]
<heat> ok
<heat> so does ebr suck or what
<mjg> yes and no
<mjg> it's a complicated matter with many moving parts
<mjg> ebr has a high entry cost for its consumers
<mjg> due to a full barrier
<mjg> but will be able to free shit sooner
<mjg> than rcu
<mjg> whether it is a win or not for your magic workload remains a mystery
<heat> ah so you need a full memory barrier for epoch-based rcu?
<mjg> it is not strictly needed, but it is how it is implemented
<mjg> another variant is you count epoch fuckery as you go on/off cpu, but that would be rcu
<mjg> well closer to it
<mjg> the primary selling point for rcu is that in the common case rcu_read_lock or whatever the name expands to nothing
<mjg> but as soon as you need to free stuff in more than loller quantities things become very murky
<mjg> one thin they don't tell you on opsters is that there are consumers which need to call synchronize_rcu and it *costs*
<mjg> but tl;dr i would not dig into it unless you have a kink
<heat> dig into what?
<mjg> rcu and other shitters
<mjg> if you want to use any of it you don't have options anyway
<heat> but 1) it's cool
<heat> 2) fazt
<mjg> *something* which delays memory reclamation is necessary for mulitcore perf
<mjg> as for cool, it is a patent minefield even though many of them lapsed
<heat> the epoch stuff isn't
<mjg> while i have not seen them (on purpose), i can virtually guarantee any obvious improvement is probably also patented
<mjg> epoch indeed is not
<mjg> and there is an imlementation in concurrencykit
<heat> i could just relicense my kernel (L)GPLv2 couldn't I :v
<mjg> for rcu, true
<mjg> good news for you mofer is that you have problems which don't need it yet
<heat> but then you tell me my path lookup sucks and I should git gud
<mjg> im pretty sure i told you what your other stuff sucks and which can be fixed withour rcu-eesque solutions
<mjg> including your lolcking primitives
<mjg> you wont know what's treal impact until you unfuck them
<mjg> if you want an exercise, openbsd locks probably remain totally broken from perf standpoint
<mjg> i can outline how to fix them and then you can have code in a real project
<mjg> if they take the patch
<heat> ok so every patent listed in https://www.kernel.org/doc/Documentation/RCU/RTFP.txt seems to have expired
<heat> mjg, im not interested in contributing to fake projects
<mjg> OH
<mjg> i would not consider the above list to be complete
<mjg> anyhow if there is one bit of advice i can give, it would be this: *never* take perf claims at face value, regardless of who maeks them
<mjg> people rarely know what they are talking about and even when they do they love to lie about it
<kaichiuchi> hi
<heat> even paul mck?
<mjg> i don't know the guy, i would not put any exemptions
<mjg> the claims he made that i know of i tested and they were true
<mjg> but they were not rcu-related for example
<mjg> a day may come someone is genuinely going to do better
<mjg> are you going to blindly trust his rebuttal, if any?
* kaichiuchi is sad that people don't care about code size as much as they should
<kaichiuchi> (on embedded platforms)
<mjg> i can vouch for general smp remarks in perfbook
<mjg> kaichiuchi: do they ever?
<kaichiuchi> we might be moving to an MCU that is 2MB flash size
<kaichiuchi> and the first thing people have said is "we don't have to care about code size now"
<mjg> :]
<kaichiuchi> it's a bit distressing
<heat> mjg, can I ever trust yours? :v
<mjg> heat: no! test and profile yourself, motherfucker
<kaichiuchi> also in relation to the current discussion: can't we just say that no one can ever agree on anything
<heat> for all I know you're lying to me
<mjg> i stress the need to profile
<heat> I do not have the sort of profiling tools you have :(((
<phr3ak> what causes the system to run the task scheduler after an interrupt? eg. is every interrupt handler required to include an SVC call at the end?
<mjg> heat: then get them mofo
<heat> phr3ak, nothing. that doesn't reflect reality
<kaichiuchi> mjg: would you kill me if I said I don't really whip out a profiler too much
<mjg> kaichiuchi: no, but i would probably call you a webdev
<kaichiuchi> i'm not a web dev
<mjg> then don't act like one
<kaichiuchi> hey
<kaichiuchi> :(
<heat> phr3ak, the scheduler runs if you need to schedule (i.e if the scheduler timer fires and it says you ran out of time slice, or you got an disk IRQ and woke up a higher-prio thread due to IO completing)
<kaichiuchi> that's a curse
<heat> svc also has nothing to do with interrupts so
bradd has quit [Ping timeout: 252 seconds]
<heat> (or the scheduler)
<kaichiuchi> i think I just have PTSD from everyone always equating not doing stupid things to premature optimization
<netbsduser`> phr3ak: i use the interrupt priority level approach
<kaichiuchi> and every time I hear the world "measure" or 'profile', which are not the wrong things to do, I wince a bit
<phr3ak> I thought that the scheduler wanted to immediately run the task that is waiting for the interrupt
<heat> mjg, am trying. I have a cBPF interpreter, probably want eBPF for better tracing
<heat> or dtrace, etc but fuck that honestly
<mjg> you can trivially get a poor heat's profiler for smp
<netbsduser`> the scheduler is invoked if interrupt priority level drops below a certain IPL, if a request to reschedule has been enqueued
<mjg> you just check what instruction got interrupted
<mjg> dragonflybsd has one in systat
<heat> phr3ak, no. you want to run it on $scheduler conditions after waking it up. but usually you only switch tasks if the woken up task has higher prio than current
<heat> mjg, I have that homie, remember?
<netbsduser`> the request to reschedule is made when a thread's timeslice is over, or when another thread was awakened and should preempt the current thread (higher priority)
<mjg> heat: no. you have shit flamegraphs
<heat> do you think I hand-draw my flamegraphs?
<mjg> heat: not an instruction profiler
<heat> erm what
<heat> wtf do you think I sample?
<mjg> i think you sample and unwind the stack and then lose the sight of what instructions were executing
<mjg> but possibly can recover that from raw dump
<heat> the instruction that was executing is the top of the stack trace
<mjg> except if you have more than one in the same func
<mjg> is not that just merged?
<heat> no
<mjg> wut
<mjg> well then you did flamegraphs worng :p
<heat> unless I severely misremember how my fgs work
Burgundy has joined #osdev
<mjg> bottom line though, just catching problematic instructions as you interrupt them is fine enough for basic profiling
<mjg> i mean you are going to go way further than netbsd on this alone dawg
<heat> e->rips[0] = regs->rip;
<heat> stack_trace_get((unsigned long *) regs->rbp, e->rips + 1, 31);
<heat> e->rips[1] = 0;
<heat> and then
<heat> userspace is_same_stack compares the whole stack
<phr3ak> you mentioned disk IRQ. the processing will go back to the interrupted task first and not for the scheduler directly. so I don't understand what can fire the scheduler if not the systick or call the SVC or similar at the end of the interrupt handler
<mjg> well then instead of an excusse to not profile you have the tooling
<bslsk05> ​github.com: Onyx/traps.cpp at master · heatd/Onyx · GitHub
<bslsk05> ​github.com: Onyx/traps.cpp at master · heatd/Onyx · GitHub
<heat> line 280 has a pretty simple NEEDS_RESCHED moment, when getting an IPI from another thread suggesting that this one should resched (because i.e it woke up a thread on this cpu that has higher prio than the current one)
<heat> (or if it got a signal or something)
<heat> and no you don't need an svc, you just... you know... normally call the scheduler functions
<phr3ak> I'm afraid that this is very different from a cortex m system and maybe even more complicated :(
<heat> mjg, btw have been kind of wanting to understand the linux perf dump format. cuz the tooling would be really great
<heat> phr3ak, I don't see how it would be. interrupt saves context, runs C, restores context, ret
<heat> the idea is still the same
<phr3ak> ok, so a task running, interrupted, the processing goes back to interrupted task. what will call the scheduler and when in this case?
<heat> the interrupt handler
<heat> literally just gave you an example
<phr3ak> ok but that was my first question
<phr3ak> thanks
<heat> unless you do not control that. if so, there's nothing you can do ever.
<heat> and when? depends
<heat> more of an IF really
<heat> IF any code (probably some scheduler thing when waking up a thread) thinks it needs to switch the current thread, flags |= NEEDS_RESCHED;
<heat> and then after handling the interrupt you do if (flags & NEEDS_RESCHED) resched();
fedorafan has quit [Ping timeout: 246 seconds]
fedorafan has joined #osdev
<heat> mjg, smr looks like a cool idea. what's the drawback they're hiding from me?
<mjg> 1. high entry point cost
<mjg> 2. 0 numa support
<mjg> [not inherent, but it does not have it]
<mjg> 3. workloads which alloc/free in moderation get shafted by mandatory batching
<heat> numa is for losers anyway
<mjg> among other things
<mjg> you can't chose to free on the spot *or* through smr
kpel has joined #osdev
<Ermine> heat: kinda hot take
<heat> what take
pounce has quit [Remote host closed the connection]
<Ermine> "numa is for losers"
pounce has joined #osdev
<heat> numa sucks is the coldest take ever
<heat> I have never heard someone say "you know what this needs? NUMA."
<kaichiuchi> I regret this mini keyboard
<kaichiuchi> it's an excellent keyboard for someone who is not a programmer
<kaichiuchi> but programming isn't enjoyable anymore with this keyboard
<bslsk05> ​www.duckychannel.com.tw: Ducky One 3 series, the successor to our renowned One 2 - Exclusive QUACK Mechanics design philosophy, for everyone to feel the incomparable typing experience from the moment you touch the keyboard!
<kaichiuchi> try living with this every day, knowing that you need to hold the Fn key for everything
<heat> programming is not enjoyable with any keyboard
<kaichiuchi> i can pretend
kpel has quit [Ping timeout: 252 seconds]
unimplemented has joined #osdev
slidercrank has quit [Ping timeout: 268 seconds]
[itchyjunk] has joined #osdev
kpel has joined #osdev
dude12312414 has joined #osdev
<zid> numa sucks.
rwxr-xr-x has joined #osdev
<zid> why did nobody tell me ddr3 comes in 1066 btw
<rwxr-xr-x> did you ever ask?
<rwxr-xr-x> that would be the first problem :p
<zid> That's not how finding out that things exists works though :(
<rwxr-xr-x> lol
<zid> Just in case
<zid> rwxr-xr-x: Do strawberry cows that give strawberry milk exist?
<rwxr-xr-x> of course
<rwxr-xr-x> don't ask stupid questions
<zid> I can't win
<rwxr-xr-x> nope!
<rwxr-xr-x> funny you thought you could
<rwxr-xr-x> also, ddr3? get into the future old man, ddr6X
kpel has quit [Quit: .]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<mrvn> You only have to feed the cow milk-strawberries
slidercrank has joined #osdev
mctpyt has joined #osdev
<rwxr-xr-x> exactly
mctpyt has quit [Ping timeout: 252 seconds]
SGautam has joined #osdev
gog has quit [Quit: Konversation terminated!]
[itchyjunk] has quit [Ping timeout: 260 seconds]
rwxr-xr-x has quit [Quit: Lost terminal]
<mrvn> You could just drink some milk, eat some strawberries and then jump around like you don't care to make it a proper shake.
xenos1984 has quit [Ping timeout: 248 seconds]
xenos1984 has joined #osdev
immibis_ has quit [Read error: Connection reset by peer]
unimplemented has quit [Read error: Connection reset by peer]
gog has joined #osdev
unimplemented has joined #osdev
dutch has joined #osdev
spikeheron has quit [Ping timeout: 248 seconds]
unimplemented has quit [Read error: Connection reset by peer]
* geist yawns
<geist> cold snap here, my house is cold inside again because heat pump is insufficient
<mjg> compile some chrome
<geist> this is actually not untrue
<geist> like in the next few hours my office will warm up because of computers
rwxr-xr-x has joined #osdev
<epony> and from the yesterday's dinner on afterburner warm fuzzy farts
<gog> mew
<gog> we're having a winter storm
<gog> it's unpleasant
<rwxr-xr-x> yeah, it's cold
<rwxr-xr-x> hopefuly power stays
dutch has quit [Quit: WeeChat 3.7.1]
<epony> 755, hopefully
<rwxr-xr-x> fuck
<rwxr-xr-x> just had to didn't you
<epony> yep.. flicking the power breakers is always funnier when you hope it does not happen
<gog> hi 755
<rwxr-xr-x> hey gog!
<rwxr-xr-x> how's life
<gog> long boring and painful
<rwxr-xr-x> valid
<gog> but also ok
<epony> that can always be fixed
<rwxr-xr-x> oh shit
<gog> i'm actually not as depressed as it sounds
<rwxr-xr-x> im high on life
<rwxr-xr-x> so the opposite
<gog> nice
<rwxr-xr-x> yup, could be worse
<rwxr-xr-x> only downhill most likely
<rwxr-xr-x> shit, now im sad
<gog> could be a lot fucken better
<Ermine> gog: may I pet you
<gog> yes
* Ermine pets gog
* gog prr
* Ermine awws
gorgonical has joined #osdev
<gorgonical> You know what would be cool is if keyboards had a feature where your hands and wrists would magnetically snap into place over the keyboard to provide optimal ergonomics. You could always find the home row
<mrvn> that's why f and j have bars below it
<gorgonical> But I mean like how superconductors get locked in 3d space. Literally *over* the keyboard
<zid> there's no home row if you type in an ergonomical manner
<rwxr-xr-x> i like the idea gorg
<rwxr-xr-x> also sounds like a saw trap
<gorgonical> a little bit
<mrvn> implant some magnets in your fingertips and put some below the keycaps
<gorgonical> I wonder if the same could be accomplished by tying rope to your wrists and anchoring it to the ceiling
<rwxr-xr-x> that's a bad idea
<mrvn> rope?
<gorgonical> String/whatever
<epony> faceID
<mrvn> if you have strings on your fingers then skipe the keyboard and detect key presses by the tension in the strings
<gorgonical> the conclusion of this is a backwards keyboard
<gorgonical> except you still press downward, but the whole contraption is the other way around
<epony> ^ modern variants of this don't have the hyper key
<gorgonical> did the space cadet have buckling springs? I wonder what the switches were
<mrvn> if you have a realy strong magnetic field you can float a frog. should work for fingers too.
<gorgonical> Oh what could also work is a spring-powered exoskeleton like the ones they use for warehouse workers
<mrvn> simple gloves with haptic feedback would work too
<GeDaMo> Apparently the Space Cadet keyboard used Hall effect switches https://www.youtube.com/watch?v=oDozftThFMw
<bslsk05> ​'Symbolics Space Cadet keyboard review (Honeywell Hall effect 4B3E)' by Chyrosran22 (00:15:14)
<bslsk05> ​www.researchgate.net: Just a moment...
<bslsk05> ​hackaday.com: Mag-Lev Switches Are The Future Of Clacking | Hackaday
jjuran has quit [Ping timeout: 252 seconds]
<epony> I like reed switches better than hall ones..
demindiro has joined #osdev
<demindiro> I've finally finished v0.2 of my filesystem
<demindiro> Which was far more painful that it should've been
SGautam has quit [Quit: Connection closed for inactivity]
<rwxr-xr-x> i'm still trying to get limine to shut the fuck up and give me a framebuffer
<rwxr-xr-x> in asm
jjuran has joined #osdev
bgs has quit [Remote host closed the connection]
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<heat> use grub
<heat> best bootloader
* raggi recoils
<heat> ok sorry, when in doubt use EFI
<gorgonical> heat you'll be delighted to know my forth is self-hosting and nearly complete. The core is, anyway
<heat> nothing better than a kernel that support N different boot protocols cuz why not
<raggi> in zircon we ended up making "shims" that were small executable stubs that can front the kernel to map bootloader protocols to one standard kernel protocol, and that reduced a bunch of craziness
<heat> very annoying fact: qemu refuses to boot your efistub kernel with an initrd if it doesn't think you're x86 linux
<zid> very annoying fact: heat
<zid> heat is too busy to play games with me, find him talking about EFI on irc, ofc
SGautam has joined #osdev
<heat> raggi, yeah but at the end of the day what does that get you? more complex booting?
<heat> the zbi stuff is also full of weirdness because everyone is alergic to device trees
<demindiro> heat: I do something similar (for GRUB) and I find it simpler than parsing multiboot stuff directly in the kernel
<heat> i mean, instead of, what, 2+ boot paths per architecture, you get 1 .... plus 2+ boot paths per arch because I you still need those
<mrvn> heat: with bootloaders in the firmware you might not have a choice.
<heat> i feel like it's a sort of fake unification unless you want your own boot protocol.
bauen1 has quit [Ping timeout: 252 seconds]
bauen1 has joined #osdev
<raggi> heat: well there is a zbi-native boot protocol and some bootloaders that speak it (the efi one in tree, and coreboot and fastboot ones), but the shims are used to map qemu's linux native thing and a multiboot one. it depends how you measure complexity, having stages in the process that _complete_ rather than spreading their tendrils through later and later stages reduces a fair amount of complexity, but yes, you also add a stage
Matt|home has joined #osdev
theWeaver is now known as transbee
<SGautam> Is anyone writing their own bootloaders anymore?
<SGautam> UEFI seems way more complicated and non-standard than good old BIOS.
<SGautam> I'm wrong on the non-standard bit I guess.
<clever> SGautam: i have been working on a custom bootloader, but its non-x86, and it deals with everything from ram-init to loading a kernel
<SGautam> Which architecture, if you don't mind specifying?
<gog> i use UEFI to load things and then forget about it
<gog> it's actually trivial and straightforward
<gog> the spec has waaay too much
<gog> there should be a subset for just getting binaries and stuff loaded off of disk and jumped into
<gog> but one can rougly define their own because you need only a few protocols
<clever> SGautam: the vpu+arm on the rpi
gabi-250 has quit [Remote host closed the connection]
gabi-250 has joined #osdev
epony has quit [Quit: QUIT]
<clever> SGautam: its basically 3 stages of bootloader, the first just brings the dram online and runs the 2nd, the 2nd turns the arm core on so the 3rd can run, and the 3rd then boots linux
<mrvn> SGautam: way too many people do and fail
epony has joined #osdev
<mrvn> SGautam: beware that on x86 bootloader literaly means loader of the boot (kernel) code while on other archs it often means: firmware that initializes all the fiddly bits of the hardware before loading the kernel as a minor finishing touch.
<SGautam> I didn't know that, interesting.
<SGautam> What architecture you had in mind while typing that (as an example)?
<mrvn> ARM
<gog> ARM is like that basically
<gog> conveniently some SoC's are shipping EFI now too
<SGautam> There's no firmware on ARM like UEFI/BIOS?
<mrvn> I would say every SoC is that way.
<gog> there's lots of firmware on arm
<moon-child> I thought strawberry milk is cows' blood
<mrvn> SGautam: some arm servers might have UEFI. But generally the BIOS is the bootloader, most likely uBoot
transbee is now known as sweet_lovely
<heat> raggi, sure. but because of all that, fuchsia booting kinda sucks. it's very much not designed as a "build it and install manually" kind of thing IMO. easy to underestimate the power of e.g efistub where you cp vmlinuz /boot and it Just Works(tm)
<heat> also hard to port, etc
<heat> and from a holistic system PoV, I would favour having ""everything"" on the same kernel image. ideally you could even theoretically burn it to flash and run as firmware although we're much farther away from that
<raggi> heat: the multiboot shim works with lots of bootloaders. I had a grub wrapper in the tree for a while, but maintenance is a crapshoot because building grub images using the grub tools while avoiding them trying to slurp up random crap from the host is damn near impossible, and basically impossible when you include random distro patches that change behaviors for the worse - nonetheless grub works fine w/ the shim
<raggi> heat: and as for the more general boot path, fuchsia's aiming to do a/b and verified execution in most places, so the "scp random binary and expect it to run" is a poor match for the OS goals
<raggi> it's aiming to be a production os, not a tinker os
<heat> if you pay attention, you've described like 5 different boot paths for fuchsia, a system that runs very much in a limited set of hardware
<raggi> i've also booted it via pxeboot
<raggi> heat: i don't agree with limited set of hardware, i think you're conflating lack of drivers with numeracy of places that it boots
<heat> well, "officially supported" or whatever they use as terminology
<raggi> this also shouldn't be conflated with support
<raggi> booting up on gce for example, which i did a lot of the early work on, shook out a bunch of new efi details and some address space allocation stuff that later fed into other design considerations
<raggi> that might not be "officially supported", but it was worthwhile work that led to good changes, and i think they might be using it for CI these days, certainly there's always been a desire to do so
<heat> also oh wow fuchsia does support the actual x86 linux boot protocol
<heat> with the zero page and stuff
<raggi> yes
<heat> my condolences for having to make this work
<heat> probably the worst boot protocol I've ever seen, ever
<raggi> that worked pretty early on, even before i joined the team
sweet_lovely is now known as Amorphia
Amorphia is now known as aaaaaaaaaaaaaaaa
<heat> anyway, I tend to value simple booting. the arm64 and riscv64 linux boot protocols are IMO ideal
aaaaaaaaaaaaaaaa is now known as IdentityInFlux
<heat> "magic val, sizeof image, base address, flags"
IdentityInFlux is now known as Amorphia
<heat> if you need anything else, get a bootloader! or use whatever the firmware dumped onto its firmware volume
<heat> the situation around booting atm is not ideal to say the least. two huge ass operating systems (EFI and GRUB/your bootloader) before you even boot the actual OS
<heat> i've looked at EFI from way too upclose to ever trust anything coming from any sort of UEFI fw engineers. GRUB also sucks and said EFI firmware has a bunch of workarounds because GRUB sucks
<heat> ideally we would boot a holistic system like bryan cantrill suggested but we're too far removed from that
danilogondolfo has quit [Remote host closed the connection]
<epony> you're forgetting there is core that runs in the BIOS / POST Firmware on the mainboard that has compilers and payloads and runs programs too
<epony> and SoCs include firmware in their integrated modules
nanovad has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
<epony> your BMC onboard and the HDD / SSD have their internal on device microcontroller that is a full SoC with its own operating system (mostly Linux)
<epony> parts of the SoC run small operating systems too
<epony> so that "ideal" is full of false coceptions
<epony> "running a user provided program"
<epony> or parts you can not "reprogram yourself" but someone else can
<epony> and "the machine awaits its programming" in contrast "has already ran more than you could provide later"
<epony> software people are so "smart" and "advanced".. in their strong opinions
* raggi chuckles
<epony> "I was fired by the end of the Bell Labs, so I can tell you systems research is irrelevant" --Rob Pike
<raggi> i had someone last weekend insisting to me that the first thing that ever runs on a x86 cpu is the bios and they were so strong in the belief i completely gave up on explaining
<mrvn> well, it is. the NSA backdoor has it's own cpu.
<epony> "I was fired by the demise of the SunOS, so I can tell you that you can't program better than we can so your programs are full of shit" --Bryan Cantrill
<heat> absolutely, the firmware is the first thing that ever runs on the *x86 cpu*, not the ARM one ;)
<heat> or the hidden 486, or the 5 or 6 different co-processors around your mobo
<linearcannon> pentium, not 486 :) or the ARC coprocessor, or...
<epony> the first thing that runs are a lot of chips booting up from their self-check and internal start sequences with various load programs
rwxr-xr-1 has joined #osdev
<epony> and the modern microprocessors have functional blocks that are only similar in purpose to the classic definitions but internally are microprossors of their own complex design
<epony> so at some concise system documentation it's all available for reference
<linearcannon> intel's ME has been a modified pentium core since 2016 afaik, AMD has ARM. POWER is usually booted by an external ARM SoC running Linux, which may or may not have a fully open source boot stack depending on your vendor. many ARM SoCs have all sorts of nasty boot blobs to handle proprietary ip core blocks
<epony> your chipset boots too
<heat> actually if you want to be precise technically the CPU does a bunch of tasks including updating microcode based on the FIT (Intel) before running the first instruction
<heat> so not even there is the reset vector the first thing to "do stuff"
<epony> and that's not necessarily the same between Intel CPU models between themselves, and different with Amd CPU models by generation
<gog> not invented here
<mrvn> heat: doesn't that count as part of the bios?
<heat> the FIT and microcode itself, yes. but the process of loading them happens before you even enter the reset vector
<heat> it's all internal microcode goo
<mrvn> microcode is a separate blob here
<mrvn> but I guess that's only the blob loaded later
<heat> here where?
xenos1984 has quit [Ping timeout: 256 seconds]
<mrvn> They had a hydrogen spring leaks and ignite all over the place for days? Did they have burning candles every meter in a grid to ignite any new leaks?
zaquest has joined #osdev
xenos1984 has joined #osdev
gabi-250 has quit [Ping timeout: 255 seconds]
gabi-250 has joined #osdev
demindiro has quit [Ping timeout: 260 seconds]
<immibis> the pinephone SoC (Allwinner A64) contains an extra RISC core (MIPS I think) mostly for detecting when to wake up the main CPU when it's asleep
<immibis> [22:58] <heat> ideally we would boot a holistic system like bryan cantrill suggested but we're too far removed from that ← non-PC platforms are less removed
<epony> that's as vague as the "I'm a Mac" burger campaign
<gog> i'm a cat
<mrvn> immibis: to me that seems rather insane. You pay for an ARM license just to turn around and also pay for a MIPS license instead of adding tiny ARM core.
<immibis> oh it's actually OpenRISC
<geist> ah interesting. didn't know openrisc actually shows up anywhere
<zid> I showed you my png pls respond
SGautam has quit [Quit: Connection closed for inactivity]
<heat> immibis, less removed sure, but they also have other problems
<heat> very hard to be truly even semi-holistic. are the riscv platforms even open-ish?
archpc has joined #osdev
archpc has quit [Client Quit]
archpc has joined #osdev