<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
<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
<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]
<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]
<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>
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
<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
<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
<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
<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?
<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.