mctpyt has quit [Remote host closed the connection]
mctpyt has joined #osdev
rustyy has quit [Ping timeout: 264 seconds]
rustyy has joined #osdev
Arthuria has quit [Ping timeout: 260 seconds]
ThinkT510 has quit [Quit: WeeChat 4.2.2]
Left_Turn has joined #osdev
ThinkT510 has joined #osdev
GeDaMo has joined #osdev
rustyy has quit [Ping timeout: 260 seconds]
rustyy has joined #osdev
rustyy has quit [Ping timeout: 268 seconds]
alpha2023 has quit [Read error: Connection reset by peer]
alpha2023 has joined #osdev
gbowne1 has quit [Read error: Connection reset by peer]
rustyy has joined #osdev
joe9 has quit [Quit: leaving]
stolen has quit [Quit: Connection closed for inactivity]
teardown_ has quit [Ping timeout: 260 seconds]
<sortie>
<dostoyevsky2> sortie: isn't mounting usually done by the kernel? I never understood so far what the advantage is to do mounting in systemd
<sortie>
In Sortix, filesystems are user-space. init needs to manage the processes so they are SIGTERM'd in the appropriate order after all other processes are gone
<sortie>
<netbsduser> sortie: i prefer "ala SMF" <netbsduser> or even "ala AIX's SRC" <netbsduser> you speak of a graph concept and that is much more like those; systemd is internally structured quite differently
<sortie>
I actually have no clue how systemd works internally. I just built a deamon graph with readiness signaling on the edges.
TkTech6 has joined #osdev
<sortie>
nikolar: Really interesting init discussion last night. I'
<sortie>
(I still want to unify the mountpoints into the daemon system, as there are a lot of similarities here, as I have user-space filesystems each with their own process managed by init)
zxrom_ has joined #osdev
zxrom has quit [Ping timeout: 268 seconds]
Halofreak1990 has quit [Ping timeout: 268 seconds]
zxrom_ has quit [Quit: Leaving]
gildasio has quit [Ping timeout: 260 seconds]
gildasio has joined #osdev
osdev199 has joined #osdev
<osdev199>
Hi, although my kernel found the nvme controller attached to the PCIe bus, yet I'm getting the nvme base (BAR0) address as 0x0. I'm using the -M q35 option with kvm/qemu.
<nikolar>
sortie: I've seen you talking about and I like the whole graph thing
<nikolar>
But I haven't read the man pages yet heh
<sortie>
nikolar: Hehe I just like what I've built, the implementation is fairly neato too :)
<nikolar>
Heh yeah, sounds simple enough
<sortie>
A lot of the best parts of sortix really just boils down to taking some complex feature and implementing it in a straightforward simple way with some level of quality which then in comparison is much nicer than the super complicated Linux alternative
<nikolar>
My os is still non existent heh
<nikolar>
But yeah that's the approach I'd take too
<sortie>
One thing I continue to just adore is actually how fast my init is, or rather the final system's boot time. The login screen actually has no dependencies on anything, so init spawns it immediately, while things like dhclient and such are starting in the background. The subsecond boot times really just blows Linux out of the water
azonenberg has joined #osdev
<nikolar>
One idea I've just had is maybe introducing sigready
<azonenberg>
hey, so if i have a block in a linker script like .data
<nikolar>
So you can tell your parent that you're ready
<azonenberg>
(i.e. is in ram and flash, forming a separate loadable segment)
<nikolar>
sortie: heh smart
<azonenberg>
Is there a way to enforce alignment of the *physical* address?
<azonenberg>
rather than the virtual
<azonenberg>
i tried .= align(8) in the linker script and i'm seeing a nice cleanly aligned virtual address but the physical is on a 4-byte boundary
<azonenberg>
which won't work for me
<zid`>
. inside or . outside?
<sortie>
nikolar: Yeah I thought about that too, a sigready mechanism, but that introduces so many questions. How would it work? Daemons would then need to support a OS-specific interface. Could this be built with more standard primitives? It's why I ended up with the READYFD schema which just needs a pipe. I may very well end up switching to NOTIFY_SOCKET as it's basically similar enough and Good Enough® if a bit more complicated, but most daemons already support it
<zid`>
they mean different things
<nikolar>
sortie you just write to a pipe to signal that you're ready
<nikolar>
That's a better approach than custom signals I, agree lol
<sortie>
The biggest problem is usually getting that pipe through any cloexec logic and finding the right place to hook in the logic to send the readiness signal
<azonenberg>
aha ok i figured it out: .data : ALIGN(16)
<azonenberg>
seems to align the physical address properly
<sortie>
Also a signal wouldn't quite be the right approach if one did this. I would argue that a SIGCHLD condition or rather a waitpid(2) mode much like receiving information about SIGSTOP would be the better approach, something that unaware parents will implicitly discard
<nikolar>
sortie: another idea is that you just work with named pipes
<nikolar>
And the daemon create those per service
zxrom has joined #osdev
<sortie>
Yeah. That is basically Unix sockets though
<sortie>
One nice thing about READYFD is that it cannot fail, because the pipe is paid up front before the fork
<nikolar>
Eh yeah true
<nikolar>
But that requires all of the mess that is fork+exec+fds
<nikolar>
So I was just thinking that passing a string arg would be easier :)
stolen has joined #osdev
<sortie>
That is stuff that init does anyway
<sortie>
To collect stuff like e.g. logs
<nikolar>
Eh yeah guess so
<nikolar>
Not sure init should collect logs though
<sortie>
Oh definitely it should IMO, it's much much simpler for daemons to just write to stderr and then send that to a log file, it cannot fail short of disk space exhaustion, the syslog stuff is so overengineered and prone to errors.
<nikolar>
I guess init could just fork a process to handle all that
<sortie>
Indeed
<sortie>
Log rotation and such
<nikolar>
Yeah basically
<sortie>
Though I just do it in the same process, since it's cheap enough and most of the time init is doing nothing anyway, so it's one big main loop
<sortie>
The main loop is even built to be fair, so no process can starve it
<sortie>
Loop through the incoming events, act on each one with a time bounded action, and then loop
<nikolar>
Yeah but imo, pid 1 should literally be just for(;;) {wait();}
<sortie>
Why?
<nikolar>
Because it just can't crash
<nikolar>
Or it will being down the whole system with it
<sortie>
Well if pid 2 with all the actual logic crashes, then the system is also basically hosed
<sortie>
And pid 1 will exit when it sees pid 2 is done
<sortie>
For me the solution is to just not make init crash lol
<nikolar>
Lol that's obviously a solution
<sortie>
I mean, if init malfunctions at whatever level, the system is kinda fucked
<sortie>
I intentionally built init to be lightweight, to allocate everything ahead of time, to minimize error conditions, and be really carefully coded
<sortie>
Plus to handle all known error conditions where they could happen
<nikolar>
Yeah that's good practice in general to be fair lol
<sortie>
While that is true, most code I actually don't go to this level of extreme in
<sortie>
Mostly just the kernel, libc, and init, I go for levels of perfection
<sortie>
Since higher layers are usually less important to be fail safe
<nikolar>
You can just restart them usually
<sortie>
But what would you do if some component of init crashed? Like, what is the recovery method? What are the boundaries where they can be reasonably restarted, recovered?
<zid`>
there, keyboard fixed
<zid`>
ground wire had broken at the solder joint
zid` is now known as zid
<nikolar>
Lol again, zid
<nikolar>
sortie: yeah for most of the init components, you just can't handle them failing
<nikolar>
But I imagine some can
<nikolar>
Like the logger
<zid>
why lols
<sortie>
nikolar, yeah logger is probably one of the few parts that can fail, although you
<sortie>
'd have to restart the daemon since the pipe is lost
<nikolar>
zid you've just fixed your keyboard
<zid>
why lols
<nikolar>
Good fix
<zid>
not really, I couldn't be arsed to undo it all and shorten all the wires by 5mm
<zid>
so I just glued the one broken wire back
<zid>
it's going to break first again next time, but it lasted like.. a year or two? so whatever, if I have to redo it, I'll redo it
<zid>
once it breaks again it'll definitely be too short to be fixed and I'll just redo it properly
<nikolar>
sortie: eh I'm sure there are ways to do that without restarting
<sortie>
Well if the daemon is sending logs via a stderr pipe, then if the target process dies, that pipe is lost
<sortie>
Unless the original parent init process kept a receiving end around
<sortie>
Even then, some logs may have been lost
<zid>
dbus time!
<zid>
Now it can fail *spectacularly*!
<sortie>
Or you can have a SIGSEGV handler and reexec yourself and preserve the open fds
<sortie>
That feels, uh, nasty.
<zid>
named pipe with special open() flag that makes the kernel buffer a bunch of it
<zid>
so the daemon can quickly restart
zxrom has quit [Remote host closed the connection]
<clever>
sortie: but you need some state intact, to know what to do with those open fd's, and how much of that state is now trashed?
<sortie>
Indeed. That's why I do not like the plan for recovery. I mean you could e.g. say that fd 3 is the pipe and then rely on that on a reexec
<sortie>
I think it's overall simpler to just crash hard but then test it a lot and really fix all the bugs
<sortie>
Tolerate no bugs
<clever>
rather then a crash handler, there is the /upgrade command in issi
<clever>
it will serialize all of the state, and then re-exec itself
osdev199 has quit [Remote host closed the connection]
SophiaNya has quit [Remote host closed the connection]
ptrc has quit [Remote host closed the connection]
<mjg>
"funny": i sent some mail to different threads on linux lists, long CC lists, some of it @google.com addresses
<mjg>
... which bounce
SophiaNya has joined #osdev
ptrc has joined #osdev
<mjg>
layoff is real innit
osdev199 has joined #osdev
zxrom has joined #osdev
osdev199 has quit [Remote host closed the connection]
Halofreak1990 has joined #osdev
netbsduser has joined #osdev
Halofreak1990 has quit [Ping timeout: 268 seconds]
Halofreak1990 has joined #osdev
srjek has joined #osdev
Mutabah has quit [Read error: Connection reset by peer]
Mutabah has joined #osdev
foudfou_ has quit [Remote host closed the connection]
foudfou has joined #osdev
<Ermine>
mjg: are those @google.com adressen nonexistent?
<mjg>
yep
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 240 seconds]
zetef has joined #osdev
<sortie>
Ermine: Mine still works, at least until November
oldgalileo has joined #osdev
goliath has joined #osdev
oldgalileo has quit [Ping timeout: 268 seconds]
<immibis>
I think successful recovery strategies involve putting as little as possible into the top level component which can't fail. You make the logger a separate process. If the logger crashes you restart the logger. Holding the FD open across crashes is reasonable for a logger, but other services might use different strategies.
<immibis>
if the clients already have circuit breakers, like if you are a web server, you can reinitialize the whole web server including the listening socket
<immibis>
the top level *only* has the job of starting and restarting the things below it, and the top top level better have as little intelligence as possible so it can't crash. Lower top levels, like the top level of the web server, can try smarter strategies because then if that crashes, the dumb top top level restarts the whole web server and everything keeps working anyway, just with a slightly worse blip
<immibis>
I think this is how erlang programmers write erlang
<clever>
that is also the general design of systemd
<netbsduser>
that's how it deals with any changes to configuration
<netbsduser>
it serialises some temporary state and then restarts itself (sometimes literally re-exec()'ing itself)
<immibis>
that is not the general design of systemd, is it?
<immibis>
if it was, pid 1 would just launch the actual init system and wait for it to exit, then restart it
navi has joined #osdev
oldgalileo has joined #osdev
oldgalileo has quit [Ping timeout: 264 seconds]
Left_Turn has joined #osdev
Arthuria has joined #osdev
Turn_Left has quit [Ping timeout: 268 seconds]
Turn_Left has joined #osdev
<netbsduser>
immibis: oh, i skimmed much too quickly then
Left_Turn has quit [Ping timeout: 260 seconds]
<netbsduser>
it isn't
<netbsduser>
SMF is and has a chain of supervision concept (kernel supervises init, init supervises svc.restartd, svc.restartd supervises most services, including svc.configd the configuration repository, etc)
joe9 has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 255 seconds]
voidah has joined #osdev
joe9 has quit [Quit: leaving]
Halofreak1990 has quit [Ping timeout: 268 seconds]
zetef has quit [Remote host closed the connection]
Arthuria has quit [Ping timeout: 260 seconds]
oldgalileo has joined #osdev
oldgalileo has quit [Ping timeout: 264 seconds]
foudfou has quit [Ping timeout: 260 seconds]
foudfou has joined #osdev
nur has quit [Read error: Connection reset by peer]
oldgalileo has joined #osdev
node1 has joined #osdev
leg7 has joined #osdev
<leg7>
yoyo
<leg7>
Is there a way to turn down the volume of the PC-speaker in qemu?
<leg7>
I'm getting earraped every time I use it
leg7 has quit [Remote host closed the connection]
leg7 has joined #osdev
<GeDaMo>
"The PC speaker audio device can be configured using the pcspk-audiodev machine property, i.e. qemu-system-x86_64 some.img -audiodev <backend>,id=<name> -machine pcspk-audiodev=<name>" https://www.qemu.org/docs/master/system/qemu-manpage.html
<bslsk05>
www.qemu.org: QEMU User Documentation — QEMU documentation
<leg7>
yeah that's how you enable it
<GeDaMo>
That's how you route it to an audio device which you can then control the volume of through your OS
<leg7>
ohh
<leg7>
ok
zxrom has quit [Quit: Leaving]
Turn_Left has joined #osdev
stefanct has quit [Read error: Connection reset by peer]
Left_Turn has quit [Ping timeout: 268 seconds]
stefanct has joined #osdev
JTL has quit [Ping timeout: 255 seconds]
JTL has joined #osdev
node1 has quit [Ping timeout: 250 seconds]
leg7 has quit [Remote host closed the connection]
heat has joined #osdev
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat_ is now known as heat
goliath has quit [Quit: SIGSEGV]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 268 seconds]
oldgalileo has quit [Ping timeout: 260 seconds]
node1 has joined #osdev
Halofreak1990 has joined #osdev
onering has quit [Ping timeout: 252 seconds]
Halofreak1990 has quit [Ping timeout: 255 seconds]
netbsduser has quit [Ping timeout: 260 seconds]
node1 has quit [Ping timeout: 250 seconds]
Halofreak1990 has joined #osdev
node1 has joined #osdev
netbsduser has joined #osdev
Left_Turn has quit [Ping timeout: 255 seconds]
oldgalileo has joined #osdev
* geist
yawns
<geist>
good afternoon folks
oldgalileo has quit [Ping timeout: 268 seconds]
oldgalileo has joined #osdev
<heat>
hi
<heat>
btw geist it couldn't have been that the BARs were not configured, since they were able to use -M q35
Arthuria has joined #osdev
stolen has quit [Quit: Connection closed for inactivity]
<geist>
yeah, makes sense
<geist>
if it's a PC it's definitely configured
Arthuria has quit [Ping timeout: 268 seconds]
Left_Turn has joined #osdev
Gooberpatrol66 has quit [Quit: Konversation terminated!]
gbowne1 has joined #osdev
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
Halofreak1990 has quit [Ping timeout: 260 seconds]
node1 has quit [Ping timeout: 250 seconds]
leon has quit [Ping timeout: 255 seconds]
simpl_e has joined #osdev
theruran has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]