<heat>
you know what it's not running? openrc that's what
<GeDaMo>
What comes out of that tap? :|
<Ermine>
should have been using linux instead!
<Ermine>
oh wait
<zid>
The real question is mainly why the fuck is it a screen
<Ermine>
true
<zid>
Changing the flavours but not wanting to change a piece of card stock at the same time, seems worth an lcd kek
<GeDaMo>
All the taps provide the same liquid, only the pictures are different :P
<Ermine>
do they dilute drinks too
<heat>
of course
<heat>
dilluted.service
<Ermine>
you see
<heat>
anyway sd card seems to have gone bust, what a shame
<Ermine>
your drinks wouldn't be diluted it ran s6
<heat>
yeah because no one wrote the init script! genius shit
<Ermine>
if it ran*
<Ermine>
its all Poettering's fault
<heat>
apparently it's using NFS too
<zid>
init failed because the drink daemon microservice in the cloud was offline because it threw an 'we must verify this vending machines is over 18+' alert
<zid>
heat: most things do
<zid>
rather than every random device having a hard drive
<heat>
yeah but now you need a NIC and a small LAN
<zid>
You need to do logging and payment auth and shit anyway
<heat>
why is every drink thingy its own device again
<Ermine>
if you plunk raspi you have both sd and nic
<zid>
because internet of sh- jellybean part
<zid>
from the vendor
<zid>
they sell you the entire module n wide I assume
<zid>
and they just slot it into a rail
<Ermine>
also
<Ermine>
a lot of iot stuff is running android
<zid>
iotas of talent system
<Ermine>
and turnstiles in Moscow Metro run GNOME
<heat>
wow
<heat>
does the ICC know about this?
<Ermine>
they will
<heat>
so a problem i'm facing is that login spawned from /etc/local.d services has SIGINT and SIGQUIT masked
<heat>
s/masked/ignored/
<bslsk05>
<heat*> so a problem i'm facing is that login spawned from /etc/local.d services has SIGINT and SIGQUIT ignored
<heat>
and that's problematic
EmanueleDavalli has joined #osdev
<Ermine>
geez
<Ermine>
they shouldn't mess with signals
<Ermine>
maybe i should work on my init system take
<heat>
I mean, i suspect it's pretty standard and I just don't know what I'm doing
<sortie>
hello heat
<sortie>
What is your problem?
<sortie>
signals and init systems and such, you may be talking to the right person :)
iAPX has joined #osdev
<Ermine>
i think it shouldn't mess with signal disposition
<sortie>
It's more complicated than that. shells also technically also block SIGINT and SIGQUIT. I need more information
<Ermine>
unless posix mandates daemon's environment and you love posix
<sortie>
Ermine, it very much doesn't mandate daemons
<sortie>
There may be valid reasons for login to ignore SIGINT/SIGQUIT, such as an person at the keyboard not being able to kill it early on with ^C or ^\
<Ermine>
finally, some good fucking news
<heat>
openrc has a /etc/local.d facility where you can just get it to run shell scripts. I'm doing /sbin/login &
<sortie>
Is login(8) your own program?
<sortie>
Or an existing one?
<Ermine>
aren't you supposed to run getty?
<heat>
what's happening is that I'm getting a SIG_IGN disposition way down the shell
<heat>
yes my own
<heat>
Ermine: i dont have getty (and, frankly, i find the getty mechanism in openrc insanely primitive)
<sortie>
daemons aren't really supposed to receive SIGINT or SIGQUIT directly.. but rather terminate on SIGTERM
<sortie>
I'd argue that ignoring or blocking SIGINT or SIGTERM is a feature here. Once login becomes the foreground process group, the user may be able to kill it early on, at an unexpected time
<sortie>
I'm unclear if openrc has a feature to put login in the foreground on a tty session, or if your login does that itself
<Ermine>
so maybe it's time for getty?
<heat>
i can compile it off of utils-linux i guess
<sortie>
Normally getty would do the tty session dance and spawn login
<sortie>
I would venture that login(8) could unmask/set a signal handler for SIGINT/SIGQUIT when it's up and running. I see login restarting on those systems, at least after a delay. But it may also just be getty doing that
bauen1 has joined #osdev
<zid>
Imagine if you could just brick windows' bootup by mashing ctrl-c, kek
<zid>
"nope, you killed winlogon.exe, black screen and a mouse for you, nothing else"
<sortie>
I mean that is a valid concern for inti systems
<sortie>
*init
<sortie>
My kernel explicitly unsets the termios CREAD bit before spawning init, so keyboard input is _not_ being processed until init is ready for it
<heat>
init doesn't have a ctty
<sortie>
init has a controlling tty on Sortix, which is where boot messages are displayed (the kernel console)
iAPX has quit [Quit: _Exit]
<heat>
that's a bug boss
<sortie>
It's also a valid design to do as heat says, no controlling tty for init, but then init has to figure out what tty to use
<sortie>
heat, how's that a bug?
<heat>
/dev/console isn't really a tty
<heat>
Or shouldnt be
<sortie>
I don't have /dev/console
<sortie>
When you boot the Sortix kernel, you can select what tty to use as the kernel tty, such as tty1 (framebuffer) or comX (serial lines). Then the kernel log messages goes there
<heat>
OMFG SORTIX NOT POSIX COMPLIANT
<heat>
WRITE OS-TEST IMMEDIATELY
<sortie>
POSIX says absolutely nothing on this topic
<sortie>
The semantics of pid 1 is well outside of POSIX, intentionally
<heat>
POSIX requires /dec/console
<heat>
/dev, /dec is for dave cutler
<zid>
I thought it was for pdps
<sortie>
I'll fact check you on that lol
<sortie>
Let's see.. yes I believe you're at least partially right, let's read
<sortie>
Chapter 10 Directory Structure and Devices
<sortie>
/dev Contains /dev/console, /dev/null, and /dev/tty, described below.
<zid>
wouldn't wanna upgrade him to full right too soon, I agree
<sortie>
/dev/console The /dev/console file is a generic name given to the system console (see Section 3.376, on page 86). It is usually linked to an implementation-defined special file. It shall provide an interface to the system console conforming to the requirements of Chapter 11 (on page 199).
<sortie>
The standard file /dev/console has been added for alignment with the Single UNIX Specification. ← very sus
<sortie>
And those are all the mentions of /dev/console in POSIX
<sortie>
Chapter 11 General Terminal Interface ← and /dev/console has to follow this
<sortie>
So /dev/console has to exist, it has to be a tty (chapter 11), and otherwise it's implementation defined as a special file, which is the system console.
<sortie>
3.376 System Console: A device that receives messages sent by the syslog( ) function, and the fmtmsg( ) function when the MM_CONSOLE flag is set.
<sortie>
So syslog messages can go there. That's about all that POSIX requires
<sortie>
I should probably just hardlink whatever the system console tty is as /dev/console and that does the trick
<sortie>
<heat> /dev/console isn't really a tty ← POSIX does actually require it to be a tty (chapter 11)
<zid>
heat: SERVICE FAULT
<zid>
ten love to sortie
<heat>
Yes but in practice it's not a tty in the controlling sense
<zid>
rally going on now, good play
<heat>
You're supposed to be able to open it, write, close and not have a ctty attached
<zid>
In other news, I think nikolar died
<sortie>
heat, it says that nowhere, you have O_NOCTTY for that
<heat>
Sure
<heat>
I'm talking about sane semantics here
<heat>
It's a tty in the chardev sense, it's not a tty in the job control sense
<sortie>
Sane semantics is that open doesn't give you a controlling tty. I have TIOCSCTTY for that
<heat>
Against UNIX tradition? Smh
<sortie>
I mean it's such an obvious surprising edge case that can cause problems
<zid>
'obvious surprising' :D
<sortie>
Obvious how it is surprising :D
<sortie>
but you only ever want to get a controlling tty explicitly
<sortie>
Sortix init has a concept where it receives the kernel console as its controlling tty, but when it spawns a foreground daemon (such as login), it gifts that tty to that session
<zid>
That whole thing is conceptually weird
<sortie>
init stops writing messages to the console at the point, because now an application has taken control of the screen
Turn_Left has joined #osdev
<zid>
I like the idea of 'kernel has just pre-opened a real tty which it then donates' though
<zid>
conceptually clean
<sortie>
It makes more sense if you realize that Sortix inits can be recursive with chroot. You can have one tty, and then that tty is given to sessions down the nested init tree
<sortie>
Much like job control giving foreground to a process group
Left_Turn has quit [Ping timeout: 248 seconds]
aejsmith has quit [Quit: Lost terminal]
aejsmith has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 245 seconds]
<heat>
zid: yeah but real ttys have hacky concepts tacked onto them, like job control
<heat>
So then you ^C and your boot process dies
<Ermine>
s6 doesn't like having ctty
<zid>
heat: hence the signal masking
c0co_ has joined #osdev
c0co has quit [Ping timeout: 276 seconds]
FreeFull has joined #osdev
dennis95 has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 276 seconds]
<kof673>
i'm pretty sure in "bsdland" ttyv0 or whatever is virtual terminal 0 ...receives "console messages"..and also probably runs getty...so it just continues plastering messages over your "application" if you login on it :D
<heat>
in linux too
<heat>
apparently you can redirect it, but /dev/console points to the boot console (which is a tty)
<Ermine>
just symlink it
<Ermine>
oh, it's not a symlink
<kof673>
that is "console" i mean "after init" yeah you are supposed to not run getty i believe lol
<kof673>
or view them in xconsole or whatever lol
<kof673>
default is "shared" though it seems lol
<kof673>
this can mess up the login prompt even too sometimes lol
criswell has quit [Remote host closed the connection]
c0co_ is now known as c0co
fgarcia has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 248 seconds]
criswell has joined #osdev
FreeFull has quit []
FreeFull has joined #osdev
antranigv_ has joined #osdev
antranigv has quit [Ping timeout: 272 seconds]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 276 seconds]
netbsduser has joined #osdev
<zid>
nikolar sent me a message to inform me that he is infact, not dead
<zid>
I disagreed
<zid>
He's now back to being dead
<zid>
(that may or may not be causally linked)
<nikolar>
I am not dead
<zid>
sometimes I think I can still hear his voice :'(
ninemmilly has joined #osdev
<nikolar>
Dang
ninemmilly has quit [Client Quit]
milly has joined #osdev
nitrix has quit [Ping timeout: 248 seconds]
nitrix has joined #osdev
Left_Turn has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
Turn_Left has quit [Ping timeout: 265 seconds]
xenos1984 has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 248 seconds]
k0valski18891621 has quit [Ping timeout: 245 seconds]
antranigv_ is now known as antranigv
jcea has joined #osdev
xenos1984 has quit [Ping timeout: 276 seconds]
xenos1984 has joined #osdev
xenos1984 has quit [Ping timeout: 260 seconds]
<chiselfuse>
a week ago i was able to do `b mmap` after `starti` for `/lib64/ld-linux-x86-64.so.2` (no other images were loaded in memory) and it had the symbol for it somehow. now i can't anymore and i checked it hasn't been updated by my package manager and older versions on archive also don't have the symbol i feel like i'm going insane
<chiselfuse>
like `gdb /lib64/ld-linux-x86-64.so.2` and then `(gdb) set args ...` `(gdb) starti` `(gdb) b mmap`
<chiselfuse>
it set the breakpoint at a symbol called __mmap iirc
<chiselfuse>
and i'm fairly certain it was in the region of ld-linux.so's text
xenos1984 has joined #osdev
<chiselfuse>
i'm so upset
<chiselfuse>
i have no way to reproduce it
<chiselfuse>
i would just like to eliminate the suspicion that __mmap was never in ld-linux.so to begin with
<heat>
you can catch system calls in gdb
<chiselfuse>
last i did that for a multi fork process it had a bug where the write() syscall (and on the write() syscall) didn't get caught. just wanted to mention this.
<heat>
that sounds unlikely
<chiselfuse>
just the fact it fails for a particular syscall is a bit weird
<heat>
it's entirely possible you were trapping on the wrong syscall
<chiselfuse>
i could try to find the bug report that already existed before i found it
<chiselfuse>
1 minute
<heat>
many "system calls" don't call the similarly-named syscall
<chiselfuse>
but ld-linux.so does have mmap wrappers or syscall mmap, right?
<heat>
yes and yes
<heat>
i don't know what the mmap wrapper is called, though
<chiselfuse>
heat: i remember specifying the number and also i could observe it happen in strace with the args that i wanted (the catchpoint i set was a conditional one)
<chiselfuse>
it's just so weird, i remember vividly the symbol existing, i even took notes of it
<chiselfuse>
i was trying to fix something not working with debuginfod a year ago and i remember concluding the utility for it was very not well written and buggy
<chiselfuse>
heat: well, try it for ld-linux.so, cat works for me too
<chiselfuse>
you might want to `set args --argv0 /bin/cat /bin/cat` if you'll try stepping or something
<heat>
yeah that doesn't work for me either
<chiselfuse>
it used to 2w
<heat>
there was a glibc update some days ago
<heat>
try downgrading
<chiselfuse>
nah idc, i'll catch the syscall directly now. i was just suspecting that the symbol i was breaking at was never in ld-linux.so to begin with which upset me because i'd have to repeat a lot of work i did
<heat>
what are you doing anyway
ruvam has joined #osdev
<chiselfuse>
idr, i went on some tangent trying to fix something and now i'm learning stuff for no reason
dude12312414 has joined #osdev
dennis95 has quit [Quit: Leaving]
<geist>
that's how you learn stuff
<Ermine>
is hugetlb related to hugepages stuff?
<heat>
yes
<Ermine>
nvidia uses that
<heat>
hugetlb/hugetlbfs is basically a pseudo-filesystem where everything you allocate is hugepage-sized
<heat>
and in hugepage chunks
<heat>
(you can't mmap MAP_HUGETLB a 12KiB mapping, or munmap it partially such that it isn't aligned in hugepage chunks)
<heat>
then there's a separate mechanism called thp where they try to transparently do things, but the code paths are somewhat completely different
<heat>
it's nuts
<geist>
yah fresh in my mind. been working the last few weeks on getting 16kb page support in zircon
<geist>
actually works quite well, but then all those user space programs with assumptions about how things are mapped...
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<heat>
linux arm people have a long standing effort for variable page sizes
<nikolar>
variable page sizes?
<heat>
PAGE_SIZE stops being a compile-time constant, and those crazy generic page table macros will get even crazier to support the variable paging structure layouts
<heat>
point being that distros don't want to ship a kernel for every page size
<nikolar>
so you can change PAGE_SIZE at runtime?
<heat>
yeah
<nikolar>
sounds very cursed
<heat>
well, at boot time
<nikolar>
still
<nortti>
no mixed page sizes still, I guess?
<heat>
what do you mean?
<nortti>
from what I followed from the asahi linux project, xnu allows you to have both processes with 4K pages and processes with 16K pages on the same system simultaneously
<heat>
oh yeah no that's just not possible
<nikolar>
i assume 4k is for x86 compat
<heat>
the 4K stuff on XNU is an insane vm pager hack where they re-page files
<nortti>
heh
<nikolar>
re-page files?
<heat>
i don't remember
<heat>
the exact details
<heat>
but it was stupid and hacky
<Ermine>
Now on second sight, it was just a leftover include
<Ermine>
linux/hugetlb.h that is
Left_Turn has joined #osdev
sortie has quit [Quit: Leaving]
sortie has joined #osdev
EmanueleDavalli has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
<geist>
damnit, i went to the reycling ccenter to drop off some stuff and ended up coming back with 2 more computers
<geist>
daaaamnit
<geist>
mac g3 bondi blue and some sort of mac g4 tower. no idea if they work
<geist>
but the fact that they're uniformly covered with dust means they were sitting in someones garage for 10 years, and they didn't even bother firiding it up
<geist>
which *probably* means they still work since they were probably not broken when they stopped using them
<heat>
geist: do you use hugepages in zircon at all?
<heat>
for !kernel purposes
Lucretia has quit [Remote host closed the connection]
<geist>
and yep they both work totally fine
c0co has quit [Ping timeout: 240 seconds]
<heat>
how are you allocating them?
<heat>
transparently?
<geist>
we do not
<geist>
though the mmu code does the usual 'if you give me something that maps and would allow me to use a large page use it'
<geist>
so stuff ike the kernel's physmap ends up being 1GB/2MB pages most of the time
Turn_Left has joined #osdev
* heat
nods
<heat>
if im not mistaken linux's direct map isn't usually mapped with huge pages on arm64
<heat>
because of BBM requirements :)
<heat>
though (IIRC) there's a semi-new feature that basically says "yeah no need for that BBM bs"
Left_Turn has quit [Ping timeout: 244 seconds]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 276 seconds]
<geist>
yah we basically enable BBM after some point in the boot
<geist>
prior to that we break up the physmap
<geist>
but in general physboot is taking over most of the role of setting up the kernel aspace, so we probably wont need tha tmuch longer
<geist>
ie, the kernel starts with the physmap arleady in place, and all of the holes cut out of it, etc
<heat>
yeah
<geist>
but yeah BBM is a bitch
<heat>
big problem with linux of course is that this carving out of the physmap is done on-demand
<heat>
for e.g new .text mappings or whatever
<heat>
for SECURITEH
<geist>
yah we've been avoiding this like the plague, any situation where we need to do run time carvings
<heat>
ah ok, linux has a mode where they disable this strict security stuff, it seems