channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=24&m=7&d=24
07:09:00 <adder> heat?
10:55:00 <chiselfuse> https://0x0.st/Xp3c.c
10:56:00 <chiselfuse> errr https://0x0.st/Xp3T.c
10:57:00 <chiselfuse> i block SIGINT in thread_function() and yet when i do ^C its handler gets executed instead of main's handler
11:22:00 <goliath> chiselfuse, signal handlers are _per process_, not per thread. When the handler is invoked, the kernel picks a thread to run the handler on.
11:22:00 <goliath> Blocking a signal in a thread simply means "don't pick this one"
11:22:00 <zid> per thread signals would be amazing though
11:23:00 <zid> no idea how you'd determine which thread got which signal, but hey
11:24:00 <nikolar> Unmask the signal only on one thread ¯\_(ツ)_/¯
11:25:00 <zid> I mean as the OS
11:25:00 <zid> if they're per thread and you hit ctrl-c
11:25:00 <zid> which thread gets the message
11:26:00 <nikolar> all of them
11:26:00 <nikolar> Random
11:26:00 <nikolar> I don't know
11:27:00 <zid> Thank you for that useful insight nik :p
11:27:00 <nikolar> You're welcome zid <3
11:29:00 <nikolar> Now I wonder if you could implement signal handling by spawning a temporary thread that would run the handler
11:51:00 <heat> nikolar, iirc thats how windows does it?
11:51:00 <heat> at least for non-synchronous signals (i.e SIGFPE, SIGSEGV)
11:53:00 <nikolar> Oh really
11:53:00 <nikolar> Interesting
11:53:00 <heat> "SIGINT is not supported for any Win32 application. When a CTRL+C interrupt occurs, Win32 operating systems generate a new thread to specifically handle that interrupt. This can cause a single-thread application, such as one in UNIX, to become multithreaded and cause unexpected behavior"
11:54:00 <nikolar> Heh
11:57:00 <Ermine> horrid
11:57:00 <heat> *based
11:57:00 <heat> FTFY
11:57:00 <zid> WM_QUIT
11:57:00 <zid> or riot
12:18:00 <chiselfuse> ahhh i just realized it's per process, makes sense
12:20:00 <zid> I like the idea of ctrl-ding each thread individually in some program though to see how fucked up I can make it
12:20:00 <zid> "oh, the audio just got stuck, and now the menus don't work, and my save game is no longer updating"
12:37:00 <sortie> heat: You are kidding me.
12:37:00 <sortie> Toy OS.
12:38:00 <Ermine> paradoxically enough, it works
12:38:00 <heat> there are two types of systems in this world
12:39:00 <heat> the ones that can't ever be vulnerable to the openssh syslog CVE
12:39:00 <heat> and the UNIX ones
12:39:00 <sortie> heat: Oh hey what's that syslog CVE?
12:40:00 <heat> CVE-2024-6387
12:40:00 <heat> signal programming is brilliant. the kernel people missed interrupts in userspace so much that they added interrupts
12:41:00 <heat> but disabling interrupts in userspace is actually expensive because ofc
12:42:00 <sortie> heat: https://www.armosec.io/blog/cve-2024-6387-regresshion-rce-vulnerability-openssh/ ← Reading this. I did see this CVE and didn't pay much attention cus I was on vacation. It does say syslog which I don't do as such in Sortix. Although my syslog does write to stderr, so my syslog still isn't async signal safe.
12:45:00 <heat> ultimately its hard to exploit but shows a common problem with signal programming
12:45:00 <sortie> Mostly the root problem is people thinking signal handlers are safe places to do stuff which they aren't
12:46:00 <zid> signals are evil
12:46:00 <zid> they make me have to care about EAGAIN
12:46:00 <sortie> EINTR you mean
12:46:00 <zid> probably
12:47:00 <sortie> Only if you don't die on the signals, and don't turn on resuming system calls
12:47:00 <zid> oh you can do the latter?
12:47:00 <sortie> (except a few special cases)
12:47:00 <sortie> Yep
12:47:00 <zid> I'm not much of a posix programmer
12:47:00 <sortie> It's the useful way to do signals
12:47:00 <zid> I honestly know way more about winapi
12:48:00 <sortie> In my programs that expect signals and handle them, I mask the signals at all times, and have ppoll unmask them so the signal handler runs during ppoll at a same point. In a single threaded program, that means doing whatever there is safe.
12:48:00 <zid> Okay keep your secrets as to how to turn on resuming syscalls :p
12:48:00 <sortie> But in these cases, I still only set a volatile sig_atomic_t signal_happened = 1; and return to wake up the ppoll system call (which I don't resume) so it fails with EINTR and I can dispatch the signal straight from the main loop safely
12:49:00 <sortie> zid: I mean it's completely standard signal programming. sigaction(2) .sa_flags = SA_RESTART.
12:49:00 <zid> ah thanks
12:49:00 <heat> isn't it the default too?
12:49:00 <sortie> signal(3) does not do this, it's essentially deprecated.
12:49:00 <zid> I think the last time I dicked with signals was the old interface
12:50:00 <sortie> heat: SA_RESTART is not 0, so no
12:50:00 <zid> yea signal()
12:52:00 <sortie> Hmm musl does set SA_RESTART in signal but I'm not spotting the POSIX text that says to do it
12:53:00 <zid> I'm not sure I was ever actually *interrupted*, but the posix text does not in fact say signal should do it.. so I guess you just have to assume it might
12:53:00 <heat> "In the GNU C Library, establishing a handler with signal sets all the flags to zero except for SA_RESTART, whose value depends on the settings you have made with siginterrupt"
12:53:00 <zid> so my socket app I wrote that handled signals ended up wrapping accept in while != EINTR and stuff
12:53:00 <zid> so that it didn't think the listen socket had disconnected accidentally
12:53:00 <zid> if the syscall failed instead of succeeded
12:55:00 <sortie> "Otherwise, the program shall resume execution at the point it was interrupted." is all POSIX says, whatever that means
12:55:00 <heat> oh this is also interesting
12:55:00 <sortie> I set SA_RESTART in Sortix signal(3).
12:55:00 <heat> "The siginterrupt() function changes the restart behavior when a system call is interrupted by the signal sig. If the flag argument is false (0), then system calls will be restarted if interrupted by
12:55:00 <heat> the specified signal sig. This is the default behavior in Linux."
12:56:00 <heat> linux signal defaults to SA_RESTART
12:56:00 <sortie> siginterrupt was removed in POSIX 2024.
12:56:00 <sortie> Sortix never had it
12:56:00 <heat> posix? what's posix? never heard of it
12:56:00 <FreeFull> Too bad you can't implement posix without implementing unix signals
12:57:00 <sortie> I recommend only using signal(3) if the values you supply are SIG_IGN or SIG_DFL, and you don't have any uses of sigaction (inconsistent but valid to mix them). Otherwise just use sigaction everywhere.
12:58:00 <sortie> FreeFull: Honestly they do get a bit better to implement once you drop all the legacy stuff they removed in POSIX 2024 and honestly they're not too bad. Just a bit to learn and easily misunderstood.
12:58:00 <FreeFull> Still a pain to deal with for the userspace
12:59:00 <heat> i use signal a lot
12:59:00 <sortie> To a large extent, user-space should stop caring so much about signals. No, I don't want your crash handler. It's a bad idea. Just crash.
12:59:00 <FreeFull> But yeah, you can't just not implement them, since then a bunch of software won't work
12:59:00 <heat> sigaction is too verbose for my purposes
13:00:00 <FreeFull> I find it funny that even "Hey, the terminal has resized" is a signal
13:00:00 <sortie> struct sigaction sa = { .sa_handler = HANDLER, .sa_flags = SA_RESTART }; sigaction(SIGINT, &sa, NULL)
13:00:00 <sortie> Not soo bad tbh
13:00:00 <zid> The only valid use of a segfault handler I've seen was that for some reason, some 3rd party .so would crash the first time you ran it, but be fine if you just immediately restarted it
13:00:00 <zid> so they just.. ignored the first crash
13:01:00 <FreeFull> I think some VMs like the JVM rely on being able to handle segfaults too
13:02:00 <heat> forgot the error handling :)
13:02:00 <heat> signal can't even fail!
13:02:00 <heat> ROBUST SOFTWARE DESIGN!
13:02:00 <sortie> sigaction(SIGINT, &(struct sigaction) { .sa_handler = handler, .sa_flags = SA_RESTART }, NULL);
13:03:00 <sortie> Gets a nice neater with modern C
13:03:00 <heat> newer GCs don't need to handle segfaults i believe
13:03:00 <heat> there's a fun madvise call to that effect
13:03:00 <sortie> heat: Oh very interesting
13:04:00 <sortie> heat: Yeah sigaction can technically fail but also it will never fail on good inputs unless you got a shit impl
13:05:00 <sortie> It's one of the few system calls, like fstat, that I never check the error on cus they won't fail
13:05:00 <heat> oh, not madvise, mremap
13:05:00 <heat> fstat can definitely fail
13:05:00 <sortie> NFS is the only case where I think fstat might be able to fail
13:05:00 <zid> ESHITIMPL
13:06:00 <heat> dude, spurious -EIOs, spurious -ENOMEMs (in case your kernel sucks and can't handle an OOM)
13:07:00 <sortie> EIO I'm not quite concerned about, a quality kernel should already have that information cached in vfs for the lifetime of the open file handle
13:08:00 <sortie> That's what Sortix does. You open a file, the stat informaton is populated there and won't fail.
13:08:00 <heat> that doesnt reflect reality
13:08:00 <sortie> (I think. User-space filesystems may roundtrip to user-space to get the information.)
13:09:00 <sortie> ENOMEM can't happen in fstat on Sortix, the drivers have all allocated the information ahead of time
13:10:00 <sortie> I also never check the error value of close(2). There's nothing reasonable that could be done there and the error should have been reported earlier.
13:11:00 <sortie> (write(2) should have failed, or if you're really paranoid, you can call fsync(2) to be sure)
13:11:00 <heat> oh, here's a fun one: -EIO reporting on write is completely fucked on unix
13:12:00 <heat> google completely gave up on reporting that shit back to userspace, they got a daemon that reports and logs this stuff
13:13:00 <heat> i *think* fsync usually reports EIOs, write does not in *any* case
13:13:00 <heat> it's not like sockets where they can return old errors
13:13:00 <sortie> Yeah. Agreed.
13:13:00 <sortie> (idk anything about G's situation here)
13:14:00 <sortie> But write(2) succeeding to me, means a commitment that the data has been accepted by the filesystem and scheduled for writing and all other errors have been checked
13:15:00 <sortie> If the underlying harddisk starts failing after that though, while the writing happens in the background, there's nothing really that can be done about that. A subsequent write could give EIO potentially. Any message on close(2) is a bad idea.
13:16:00 <sortie> A fsync(2) really is the only place where user-space can meaningfully receive these errors, by being willing to wait for the background write to happen
13:16:00 <Ermine> Iirc I've got EIO on write once
13:16:00 <sortie> Yeah it's happened to me a bunch too when my system was hosed when my harddisk was having trouble
13:16:00 <Ermine> But it might me a hallucination on the second thought
13:17:00 <sortie> Most programs should not fsync out because the background writeout is an important optimization. It's up to the sysadmin to decide how willing they are to accept filesystem corruption and what kind and trade off performance and such
13:18:00 <sortie> But if you're doing a database thing or an operating system upgrade or what not and really want to be sure the writeout went through, fsync a good first choice.
13:19:00 <Ermine> There's also sync
13:19:00 <sortie> Or if you're looking to unmount
13:19:00 <Ermine> unmount does sync doesn't it
13:19:00 <sortie> sync also works but it also covers everything, which is a thing you may care about, but often it's also just a single file you care about
13:20:00 <GeDaMo> Are there file systems which support transactions? "all of these writes work or none do"
13:20:00 <sortie> unmount does require the processes to have stopped using the device, so fsync does help processes know it's done, as an extra safety, before shutting down
13:20:00 <nikolar> GeDaMo: you can do something like that in filesystems with snapshotting
13:20:00 <nikolar> Create a snapshot, do whatever, sync, delete the snapshot
13:20:00 <sortie> GeDaMo: Other people definitely know more than me. I imagine you can turn on journaling for data for extra slowness and reliability, or advanced snapshot features, and what not. There's lots of filesystems one can choose
13:21:00 <nikolar> And on failure, if there's a snapshot, just rollback
13:21:00 <Ermine> GeDaMo: ntfs has transactions
13:21:00 <sortie> It's on eof those reasonable sysadmin choices, like whether you only want metadata to be safe, or also file contents
13:21:00 <GeDaMo> I just saw that, but deprecated https://en.wikipedia.org/wiki/Transactional_NTFS
13:21:00 <nikolar> ZFS wins again:P
13:21:00 <heat> sortie, sysadmin knows jack shit about fs corruption
13:21:00 <heat> programs need to fsync what they care about
13:22:00 <heat> or at best fsync under a config option
13:22:00 <nikolar> ^
13:22:00 <sortie> Sysadmins need to know their shit, it's the job
13:22:00 <Ermine> yeah, i don't know why did they deprecate transactions
13:22:00 <kof673> sysadmin does not necessarily make the financial decisions :D
13:22:00 <sortie> Depending on what they're running and of what importance
13:22:00 <nikolar> Underused I guess, Ermine
13:22:00 <sortie> Programs like cp and sort don't need to use fsync. It's overkill.
13:23:00 <heat> but install does
13:23:00 <Ermine> I approved bying those hp servers, is this financial decision
13:23:00 <sortie> But if you got any custom programs working on important data, yeah, you want fsync.
13:23:00 <nikolar> wat
13:23:00 <kof673> no, i mean total budget
13:23:00 <kof673> or "use what we have, good luck"
13:23:00 <heat> you're now responsible for mapping the BIOS and executing it in userspace, good luck Ermine
13:23:00 <zid> don't cp your important data nikolar
13:24:00 <nikolar> I'll rsync it
13:24:00 <kof673> lol @ heat
13:24:00 <nikolar> And snapshot first
13:24:00 <Ermine> heat: yes, I *deeply* regret it
13:24:00 <Ermine> now it's one of those cringe thoughts that doesn't let me sleep
13:25:00 <sortie> It's a reasonable business decision to balance the need for reliability and cost and should be advised by technical leadership
13:25:00 <Ermine> truly horrendous shit
13:25:00 <sortie> If you're running a service that can easily be e.g. reimaged or automatically recover from backups, it can be totally fine to work with servers that can fail at any time
13:26:00 <nikolar> True dat
13:27:00 <heat> Ermine, https://www.youtube.com/watch?v=j5NciKpHZzs this is also a classic by the real mjg
13:27:00 <bslsk05> www.youtube.com <no title>
13:28:00 <heat> caring about firmware and their awful hacks is a it's joever kind of business
13:32:00 <sortie> I probably should not share an office with heat, I imagine we'd have the best discussions but we'd probably just spend all day getting into fights over disagreements
13:32:00 <heat> maybe
13:32:00 <sortie> mremap(2) MREMAP_DONTUNMAP is interesting
13:33:00 <sortie> userfaultfd(2) seems like peak Linux
13:33:00 <heat> userfaultfd is the thing they love to use to make GC fast
13:33:00 <sortie> Note: glibc provides no wrapper for userfaultfd(), necessitating the use of syscall(2).
13:33:00 <sortie> No, that is peak Linux.
13:34:00 <Ermine> what it is even
13:34:00 <heat> userfaultfd basically lets you handle page faults in userspace
13:34:00 <heat> but *all* page faults in a given region, not just SIGSEGVs
13:34:00 <puck> i wanna play with userfaultfd
13:35:00 <Ermine> boehm should use it
13:35:00 <puck> technically you could implement userfaultfd without its existence, actually
13:35:00 <puck> it's just a bit more terrifying
13:35:00 <heat> how?
13:35:00 <puck> ..either fuse, or ublk, then mmap that in
13:35:00 <heat> lol
13:36:00 <puck> <del>now if you do this linus torvalds will come to your house and stare at you while you sleep</del>
13:36:00 <Ermine> it does some shit to provoke SIGSEGV which is handled by boehm
13:36:00 <Ermine> it's UB
13:36:00 <puck> hm, does boehm segfault on purpose?
13:37:00 <sortie> I actually one worked with the Boehm guy
13:38:00 <heat> i wish linus torvalds would stare at me while i sleep 😔
13:38:00 <Ermine> puck: yes
13:38:00 <kof673> who is staring at linus? mjg? j/k
13:39:00 <puck> oh, virtual mprotect, that's funny
13:39:00 <puck> kof673: linus torvalds awakes in the middle of the night. cold chills run down his spine, he flips the light switch. Linus Torvalds is staring at him from the foot of his bed.
13:39:00 <sortie> I occasionally really want to drag Torvalds in front of my livelocked Linux desktop like a misbehaving dog being shamed and be like 'Explain yourself why is it not working'
13:40:00 <Ermine> heat: 'linus torvalds is watching you' poster would be suitable
13:40:00 <puck> sortie: you know what's fun? userfaultfd can catch page faults happening in the kernel
13:41:00 <Ermine> sortie: I think he' the least suitable person for that answer
13:41:00 <sortie> puck: it what
13:41:00 <heat> yeah ofc
13:41:00 <puck> sortie: like. kernelspace reads from userspace at times
13:42:00 <heat> userfaultfd and fuse mapping faults get handled specially to avoid DOS
13:42:00 <sortie> Ermine: I tend to think that if I keep doing it everytime my Linux livelocks on IO due to OOM conditions, there will be accepted patchsets to improve things
13:42:00 <sortie> And/or distros fix their configs
13:42:00 <sortie> The flight home from Aarhus everytime will be so annoying
13:43:00 <Ermine> oh, 12309-like?
13:43:00 <heat> i havent had a good livelock in a good while
13:43:00 <Ermine> I've got it while trying to unrar leaked nvidia sources
13:43:00 <sortie> To trigger a livelock, just do basics like using Firefox for long enough with enough tabs and boom
13:43:00 <heat> sir, i use chrome
13:44:00 <sortie> Don't try to help me here. This is a can of worms.
13:44:00 <heat> i have an SSD, swap, zswap and mglru
13:44:00 <sortie> I honestly *do not* want to tinker with my debian install. It's there to get out of my way.
13:44:00 <heat> works well
13:44:00 <heat> i mean yeah you're using debian chances are you're still on 2.6
13:44:00 <sortie> All of my energy being annoyed with Linux goes straight into Sortix.
13:45:00 <sortie> Debian testing, it's quite up to date tbh
13:45:00 <Ermine> Oh, I've one day had a lock with mglru on
13:45:00 <Ermine> When I was trying to build rust package on my 1Gb vps
13:45:00 <sortie> Hmm I am on Firefox 115 esr
13:46:00 <Ermine> Firefox never caused such issue for me
13:46:00 <Ermine> Btw my linux annoyances energy should go into Onyx
13:46:00 <nikolar> Firefox did cause thrashing for me when it took up too much ram
13:48:00 <heat> Ermine, SEND PATCHEN
13:48:00 <heat> it is after all an excelent system for building software
13:48:00 <Ermine> wifi
13:50:00 <Ermine> Ot
13:50:00 <Ermine> It's on the list of baits I've took
13:50:00 <heat> ot?
13:51:00 <Ermine> not ot, wifi
13:51:00 <heat> wifi is terrible :(
13:51:00 <Ermine> 'Ot' is "I can't type"
13:51:00 <heat> signals in general are terrible. fuck sound, fuck wifi
13:52:00 <Ermine> I need to prove that relevant linux subsystem is crapper
13:53:00 <heat> openbsd wifi OPTIMAL
13:53:00 <Ermine> why all of the sudden
13:53:00 <nikolar> Can you steal a wifi stack heat
13:54:00 <Ermine> now that onyx kernel is GPL, everything can be stolen
13:54:00 <kof673> i didn't know people still used rar (not a criticism)
13:55:00 <Ermine> people still use winrar
13:56:00 <heat> nikolar, if i ever wanted/needed wifi i would most definitely take someone else's
13:56:00 <heat> i am NOT writing sound or wifi stacks
13:56:00 <nikolar> From where though
13:56:00 <nikolar> Like how hard would it be to take that kind of code and adapt it
13:56:00 <heat> linux, openbsd for wifi, linux, freebsd for sound
13:57:00 <heat> it would be hard but probably significantly easier than writing your own
13:57:00 <heat> and par for the course, every self-respecting UNIX has a linux compat layer for DRM to run on
13:58:00 <nikolar> Yeah makes sense
13:59:00 <heat> Ermine, duuuuude i could fucking maple tree now
13:59:00 <heat> MAPLE TREEE
14:00:00 <Ermine> Yeaaaaah
14:33:00 <Ermine> I guess I should start with linux wifi docs
15:08:00 <Ermine> heat: do you like openbsds wifi stack unironically?
15:10:00 <heat> i don't know, i know it's solid and like... the best bit out of openbsd
15:11:00 <heat> no idea if it's technically okay or pure garbage, and tbqh i can't judge wifi stacks
16:13:00 <Ermine> Seems like wifi would require in-kernel crypto...
16:16:00 <heat> oh right that fucking sucks
16:16:00 <heat> on one hand it's probably not too hard to deal with
16:16:00 <heat> otoh, lots of code
16:17:00 <Ermine> I think embedding bearssl would be fairly easy
16:18:00 <heat> bearssl is unmaintained
16:18:00 <heat> everyone's on mbedtls now
16:18:00 <Ermine> yes, that's the sad part
16:19:00 <heat> or GNUTLS
16:19:00 <heat> why sad?
16:19:00 <Ermine> it's permissive
16:20:00 <Ermine> permissively licensed*
16:21:00 <Ermine> If it was maintained and complete, one could write openssl compat level and throw openssl away
16:21:00 <heat> why would you?
16:21:00 <heat> openssl is also permissively licensed
16:22:00 <heat> and mbedtls is also permissively licensed
16:22:00 <Ermine> oh, I thought it's gpl
16:24:00 <heat> apache 2.0 or gpl
16:40:00 <sortie> https://pubs.opengroup.org/onlinepubs/9799919799/ ← POSIX.1-2024 HTML DROPPED
16:40:00 <bslsk05> pubs.opengroup.org: The Open Group Base Specifications Issue 8
16:42:00 <Ermine> openssl is an annoyance
16:42:00 <sortie> Update your bookmarks. I like how you can tell if you reading the old issue 7 specification if the font is green, since Issue 8 from 2024 has a new turquoise color.
16:43:00 <Ermine> yay
16:44:00 <heat> Ermine, openssl is nice
16:45:00 <Ermine> There was a discussion in Alpine to switch away from openssl
16:45:00 <heat> to what??
16:45:00 <sortie> closedssl
16:45:00 <Ermine> to nothing
16:46:00 <heat> libressl lmfao, boringssl isn't ABI stable
16:46:00 <Ermine> every other proposed alternative had its cons
16:46:00 <heat> bearssl and mbedtls have different goals and aren't API compatible
16:46:00 <nikolar> sortie: noice
16:47:00 <Ermine> nobody liked libressl indeed
16:47:00 <heat> do you have a link to the discussion?
16:47:00 <Ermine> boringssl is lul option anyway
16:47:00 <Ermine> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/28
16:47:00 <bslsk05> gitlab.alpinelinux.org: consider LibreSSL as default OpenSSL provider again (#28) · Issues · alpine / TSC · GitLab
16:48:00 <sortie> Sortix was one of the first systems to adopt libressl
16:52:00 <heat> distros trying to move out of openssl is hilarious, it's like they _want_ to have more work
16:52:00 <heat> for very dubious gains
16:57:00 <Ermine> I don't think gains are dubious
16:57:00 <Ermine> but 'more work' is basically why we're still using openssl
16:58:00 <heat> libressl is by no means safer, it's in no way faster, the release schedule is less sane
16:58:00 <heat> no ABI stability!
17:00:00 <Ermine> isn't that what was stated in discussion? Idr details tbh
17:00:00 <Ermine> I agree that libressl is shite option
17:01:00 <heat> yeah but if libressl is a shit option, what other options do you have?
17:02:00 <heat> gnutls!
17:02:00 <heat> apparently there's a compat layer for that, so there you go
17:03:00 <Ermine> no good option, yes
17:07:00 <vin> Is there a way to break down the transparent huge pages to base pages? Will calling MADV_NOHUGEPAGE trigger the breakdown?
17:08:00 <heat> check the code, but looks like it
17:10:00 <heat> actually, no, it doesn't seem to break it down
17:11:00 <vin> https://elixir.bootlin.com/linux/v4.9/source/mm/madvise.c#L658 it kind of says existing pages won't be collapsed, nothing about splitting already collapsed pages
17:11:00 <bslsk05> elixir.bootlin.com: madvise.c - mm/madvise.c - Linux source code (v4.9) - Bootlin
17:11:00 <vin> Yes heat
17:11:00 <vin> Surprising that there is no functionality that supports this
17:19:00 <vin> Since I expect the cost of colapsing base pages to huge pages must be same as spliting them, both will involve in page table updates and TLB shootdowns.
17:54:00 <Ermine> Woo, zoom doesn't immediately crash in wayland mode anymore
17:55:00 <GeDaMo> https://xkcd.com/1172/
17:55:00 <bslsk05> xkcd - Workflow
17:56:00 <Ermine> ?
17:57:00 <GeDaMo> Somebody will complain about it not crashing because they've come to depend on it :P
17:57:00 <Ermine> I've enabled it manually
17:57:00 <heat> yeah i used zoom to check if i was running on wayland
17:58:00 <Ermine> Not perfect, but it's now much more responsive than in xwayland vase
17:58:00 <Ermine> case*
17:59:00 <GeDaMo> "Now I have to talk to my colleagues" :P
18:38:00 <heat> https://x.com/Dexerto/status/1816145914316087649
18:38:00 <bslsk05> twitter: <Dexerto> CrowdStrike, the company that caused the biggest computer crash in history, is offering a $10 Uber Eats gift card as an apology to its clients.   Via TechCrunch https://pbs.twimg.com/media/GTQ_ChgXAAA2MAd.jpg
18:43:00 <netbsduser> about huge pages
18:44:00 <netbsduser> i thought a bit about them and adopted a buddy allocator with a view to the possibility of having transparent huge pages at some point
18:45:00 <netbsduser> but the more i think of it, the more difficult i think it to actually implement them in a manner even remotely sane
18:45:00 <heat> why?
18:45:00 <netbsduser> linux sees a lot of attention paid to them but even on linux they are not particularly popular
18:46:00 <mjg> they are literally transparently allocated
18:46:00 <heat> sure they are
18:46:00 <mjg> for years now
18:46:00 <netbsduser> mjg: and people love to switch them off
18:46:00 <heat> they're a make-or-break for many workloads
18:46:00 <heat> it tends to be on the workloads that are already carefully curated with hugetlbfs support and that shit, that thp sucks
18:47:00 <netbsduser> one thing that bothers me a bit is their interaction with paging dynamics
18:48:00 <netbsduser> they are large but one accessing one byte of them implies the whole thing should stay in
18:48:00 <heat> not quite
18:49:00 <heat> they don't exactly need to or should work like that
18:49:00 <heat> e.g you write to a file thp .data, do you want to Cow the whole 2MB page? probably not
18:49:00 <kof673> and evil^H^H^H^Hexperienced person would say the $10 offer is to say "sorry, you already settled, can't sue" lol
18:49:00 <kof673> *an
18:50:00 <netbsduser> some might argue that the right solution then is to track prospective groupings for upgrade to large page, to check whether a good number of the individual small pages are frequently accessed, and then if they are over some reasonable period, then assume they will remain frequently accessed and upgrade
18:50:00 <heat> nobody got time for that
18:50:00 <netbsduser> but as denning says the working set varies over time
18:51:00 <netbsduser> as a bit of a counterpoint to concerns about thp replacement, it says a lot that in the first days of 4k pages you might only have about 1000 of them in your system
18:52:00 <netbsduser> and nowadays a lot of systems have a lot more than 1000 2mib pages' worth of ram
18:55:00 <chiselfuse> i don't understand what rseq is. i tried searching online but all i got is "used for critical sections that are restartable"
18:55:00 <chiselfuse> when preempted
18:55:00 <netbsduser> restartable sequences
18:56:00 <netbsduser> suppose you have to do something with some data that's replicated per core
18:56:00 <heat> AnonHugePages: 550912 kB
18:56:00 <heat> ShmemHugePages: 647168 kB
18:56:00 <heat> FileHugePages: 129024 kB
18:56:00 <chiselfuse> can you explain what "replicated per core" means?
18:56:00 <netbsduser> you can't be having the CPU your therad is running on change out from under you before you've finished your work
18:57:00 <netbsduser> but to stop that costs dearly
18:58:00 <chiselfuse> netbsduser: so say i have a bunch of instructions that i want to execute. why would i care whether the cpu context switches to another process and comes back in the middle of executing them (assuming that's what you mean by "change out from under you before you've finished your work")
18:58:00 <netbsduser> i mean the thread is moved to another cpu
18:58:00 <netbsduser> so you can instead arrange to have a restartable sequence, meaning the work is carried on and if it's interrupted halfway through, it's noted by the kernel, and it restarts your sequence
18:59:00 <chiselfuse> why would it matter if it's moved to another cpu? don't the register values and other information get loaded in the other cpu so the thread can continue executing there without noticing?
19:00:00 <netbsduser> because you want to access and work with data relevant to the cpu you're currently running on
19:00:00 <zid> L1 cares
19:00:00 <zid> L1 gets lonely
19:00:00 <nikolar> :(
19:00:00 <heat> yeah like
19:00:00 <heat> say you have a cache of stuff per-cpu
19:01:00 <chiselfuse> zid: so you're saying that it would still work if i just switched to the other core but that it cost a lot because i now would have different contents in L1?
19:01:00 <heat> you'd use rseq to make sure you either access that cache or restart (using your new cpu's data)
19:01:00 <heat> note: this also applies if you get preempted, because then some other thread might've run on that cpu and touched the cache
19:02:00 <zid> yes
19:02:00 <zid> nikolar is it monday yet
19:02:00 <zid> (and if you move more than 1 core away, your L2 is probably empty too)
19:07:00 <chiselfuse> can you give me one detailed example? a process can be executing a lot of instructions that read and write to memory and therefore if it changes all of a sudden to a different core, L1 would be different there and cause it to slow down. now with rseq, i can tell the kernel to have a certain sequence of userspace instructions either start and end fully without switching cores. and in case it gets
19:07:00 <chiselfuse> preempted, to restart that sequence of instructions so the L1 cache is rebuilt on the new core? but that 1) doesn't make much difference since if it just carries on executing on the different core it will have to rebuild the cache in the same way. 2) how is restarting a sequence of partially executed instructions safe? i could've already incremented a value in memory and now i'll increment it again
19:09:00 <zid> they don't partially execute ever
19:09:00 <zid> either they executed or they didn't
19:09:00 <chiselfuse> how are they "restartable" then?
19:09:00 <zid> the cpu has buffers and register renaming and all sorts of tricks to *speculatively* do work
19:10:00 <netbsduser> chiselfuse: if they don't execute to completion they are restarted
19:10:00 <zid> and then it copies the results to the 'real' registers afterwards when it confirms they were correct
19:10:00 <netbsduser> you might analogise it to an optimistic approach some database engines use
19:11:00 <netbsduser> they also have "restartable sequences", transactions that, if stuff is modified while it's being applied, they roll back and retry until it is committed
19:11:00 <heat> chiselfuse, this has *nothing* to do with the cpu cache
19:11:00 <heat> like, L1 should not even be in your vocabulary rn
19:12:00 <netbsduser> what i don't actually know is whether any "normal" software is currently using these
19:12:00 <heat> a simple example is a common optimization in malloc where you grab a bunch of memory at once (per thread or per cpu) and progressively take from it, locally, without locking
19:12:00 <netbsduser> as in not database engines and other things with kernel-tier shared state and kernel-tier need to scale
19:13:00 <heat> tcmalloc is using it, glibc ptmalloc uses it too i believ
19:13:00 <chiselfuse> zid: okay, so the cpu will try to speculate which instructions will get executed in the future and execute them internally to later copy results into real registers/memory. where is the part that can get restarted in all this?
19:13:00 <zid> almost none of it
19:13:00 <zid> I'm saying that you can't be in a corrupt state
19:13:00 <zid> either it's retired or it hasn't
19:13:00 <zid> because future stuff is only done speculatively
19:13:00 <zid> it retires in-order
19:14:00 <zid> even if it was computed out of order
19:15:00 <chiselfuse> heat: i don't understand your simple example
19:16:00 <heat> ok so locking inter-cpu is bad and stuff, right?
19:16:00 <chiselfuse> i don't understand what tha tmeans
19:16:00 <heat> because you're serializing and that'll kill your perf
19:16:00 <heat> dude
19:16:00 <heat> you know what a lock is right?
19:16:00 <heat> mutex?
19:16:00 <chiselfuse> yep
19:16:00 <heat> ok, and doing that is bad and slow, right?
19:17:00 <chiselfuse> by locking inter-cpu, you mean that i stop every other process from using the cpu i'm using? can you give an example?
19:17:00 <heat> ignore the inter-cpu bit
19:17:00 <heat> locking is bad
19:17:00 <heat> yes?
19:18:00 <chiselfuse> what if i'm in a critical section, i need to execute without getting preempted
19:18:00 <chiselfuse> why is it bad?
19:18:00 <heat> because it's slow
19:18:00 <heat> if you have 8 threads all hammering a lock, you wont scale
19:19:00 <chiselfuse> i guess that's a downside if my critical section can't use 100% of the cpu?
19:19:00 <heat> no critical sections here
19:20:00 <heat> so the basic observation is: if i keep data thread local, i won't need to lock and therefore it scales well
19:20:00 <heat> so they did this for malloc. now malloc asks for more memory than it needs, and keeps it in the per-thread data
19:20:00 <heat> and carefully hands it out
19:21:00 <heat> the second observation is that keeping this thread local is sometimes too expensive if you have too many threads but not enough CPUs (this only applies to userspace, really). that's what rseq was built to solve, you can now keep data in per-cpu stuff and get notified if you were preempted in the middle of an rseq sequence
20:02:00 <Matt|home> hi.
20:02:00 <kof673> aloha
20:03:00 <Matt|home> very quick question, just want a very rough estimate i don't care about the details i'll look it up myself: on a scale of 1 to 10 or whatever, how difficult is it writing an OS installer for a modern x86 system? obv UEFI install i mean. 10 being like, idk nethack blindfolded
20:04:00 <heat> an installer is just a normal program
20:05:00 <Matt|home> i kinda wanna design my own installer but have it look actually legit good. windows installer has best graphics obv, but it's not remotely verbose or elegant enough
20:05:00 <Matt|home> it's too simplistic
20:09:00 <nikolar> Depends on hot os, for arch you basically do pacstrap and edit some config files
20:09:00 <nikolar> For your own os, you'll have to figure out the details yourself
20:09:00 <Matt|home> yeh
20:09:00 <nikolar> But presumably at first, just copying a few files
20:10:00 * Matt|home is tempted to use something like a 16k 10-minute video during the install.. nfi how many gigs XD
20:10:00 <heat> PACSTRAP!
20:10:00 <heat> nikolar, do yall also have arch-chroot
20:10:00 <heat> or did you rename it artix-chroot
20:10:00 <nikolar> Artix
20:10:00 <heat> lmfao
20:10:00 <nikolar> And basestrap
20:10:00 <heat> ew
20:11:00 <heat> still pacman right?
20:11:00 <nikolar> I am not sure why pacstrap was renamed
20:11:00 <nikolar> As far as I know, pacman is completely unmodified
20:18:00 <nikolar> heat do you have a pacman port or something
20:19:00 <heat> no, why
20:20:00 <nikolar> Just curious
20:20:00 <nikolar> No package managers then
20:25:00 <heat> yeah for now i have cp and tar and make install
20:25:00 <heat> yeehaw
20:25:00 <heat> i was thinking more towards rpm and not pacman
20:26:00 <nikolar> Really
20:26:00 <nikolar> Why's that
20:26:00 <heat> pacman has some... weird choices
20:26:00 <nikolar> Like what
20:26:00 <heat> like data unsafety by default
20:26:00 <heat> and they use the filesystem as the database
20:26:00 <heat> like???
20:26:00 <nikolar> Filesystem as the database?
20:26:00 <heat> BASED choice on a btree fs, weird choice on anything else
20:27:00 <heat> yeah the repo data for pacman is laid out using directories and files
20:27:00 <nikolar> Are you sure, I feel like that's not true
20:27:00 <heat> 100%
20:27:00 <heat> see /var/lib/pacman/local/
20:27:00 <nikolar> Eh oh well
20:28:00 <nikolar> Works fine :P
20:28:00 <heat> the sync'd repos i guess have some file format, but i dunno what that is
20:28:00 <nikolar> It's a tar of something
20:28:00 <heat> yeah works fine-ish but it's all kind of weird data consistency wise
20:28:00 <nikolar> Can't remember what it looks like exactly
20:31:00 <nikolar> I've poked about the pacman dbs but I foegor
20:31:00 <nikolar> Forgor
20:31:00 <heat> 💀
20:31:00 <nikolar> Indeed
20:34:00 <heat> oh yeah it's a weird tar
20:34:00 <heat> yikes its pretty much the same format as the local directory
20:35:00 <nikolar> Guess that makes sense
20:36:00 <kof673> was it nikolar that said phoenix was a good name? make a phoenix pkg manager to carry away the repo elephant
20:36:00 <nikolar> Lel
20:38:00 <heat> just found a terrible memory leak in my slab allocator
20:38:00 <heat> there was one edge case where i just forgor 💀 to actually free the object
20:39:00 <renzei> hey gang and such - i tried setting up my PIT timer (ras syndrome i know lol) but it just triggers once instead of being a timer and it is ! not making any sense :(
20:39:00 <nikolar> Just configure it the same every time it fires, you're welcome :P
20:40:00 <heat> how are you configuring it
20:41:00 <renzei> uhh, using asm outb to send 0x36 to 0x43, then the 1193182/100 in two parts to 0x40
20:41:00 <renzei> i just followed a youtube tutorial tbh "^^ but i do understand what it's supposed to be doing
20:41:00 <renzei> am i allowed to send github links here cause i got the source on there
20:42:00 <nikolar> Why wouldn't you be
20:42:00 <renzei> i don't know !! i'm just checking :p
20:42:00 <renzei> https://github.com/renzei-z/operating-system
20:42:00 <bslsk05> renzei-z/operating-system - Just making a silly OS for fun :D (0 forks/0 stargazers)
20:42:00 <renzei> i got osinted :(
20:42:00 <heat> BANNED FOR SENDING LINKS
20:42:00 <heat> GOODBYE
20:42:00 <renzei> nooooooo !!!!!!
20:43:00 <renzei> the timer code is in kernel/arch/i386/timer.c
20:43:00 <renzei> i
20:43:00 <nikolar> YOU'VE BEEN PWNED!1!1!
20:43:00 <renzei> i also had a weird bug where a div by zero isr actually triggered the invalid opcode (isr6) for some reason - which may be related? i might have set up my isr/irqs wrong
20:43:00 <heat> are you setting command mode 3?
20:44:00 <renzei> i got l33ted and pwned... truly a sad day
20:44:00 <renzei> command mode 3 as in square wave?
20:44:00 <heat> yes
20:44:00 <renzei> yeah i believe so
20:44:00 <renzei> 0x36
20:44:00 <heat> yeah i'm sending 0x36 too
20:45:00 <renzei> it *seems* to all be right but then it just.. doesn't work?
20:45:00 <renzei> and then i also get the weird thing with my isrs where it fires the wrong one for the actual error/kernel panic it should be
20:46:00 <heat> your PIC remapping code might be wrong
20:46:00 <heat> also sounds like you're not EOI'ing the PIC?
20:46:00 <heat> s/PIC/PIT/
20:46:00 <bslsk05> <heat*> also sounds like you're not EOI'ing the PIT?
20:46:00 <renzei> do you mean sending 0x20 to 0x20 to tell it that the interrupt is finished?
20:47:00 <zid> that's the PIC
20:47:00 <renzei> oh right i didn't see the sneaky sed in there
20:47:00 <zid> The devices that are triggering interrupts will also need to be told to shut up
20:47:00 <heat> yes 0x20 to 0x20
20:47:00 <zid> else they'll just immediately retrigger the PIC after you reset it
20:47:00 <renzei> yeah i send 0x20 to 0x20 in kernel/arch/i386/idt.c:171
20:47:00 <heat> the ez way to figure this out: open qemu's monitor, do info pic
20:47:00 <zid> thinking you never bothered to handle the interrupt at all
20:48:00 <renzei> so wait am i supposed to be sending something to the PIC or the PIT
20:48:00 <renzei> cause i already think that i'm handling EOI for PIC
20:48:00 <heat> PIC
20:48:00 <zid> does the PIT do level or edge?
20:49:00 <renzei> heat i'm already EOIing the PIC at the end of the irq handler
20:49:00 <renzei> wym level or edge? as in the kind of wave?
20:49:00 <zid> I mean, in electrical terms, yes?
20:49:00 <heat> do info pic
20:50:00 <renzei> where do i do info pic - in gdb?
20:50:00 <zid> It's whether the device signals the interrupt by giving you a blip, or by just wedging itself high until told to stop
20:50:00 <zid> in the latter case, you need to.. tell it to stop
20:50:00 <heat> qemu monitro
20:50:00 <heat> s/monitro/monitor/
20:50:00 <bslsk05> <heat*> qemu monitor
20:50:00 <zid> else it'll just hold it high forever and keep retriggering the PIC
20:50:00 <zid> never really messed with the PIT much, maybe I should look it up
20:50:00 <renzei> stupid question - how do i access the qemu monitoer
20:51:00 <renzei> monitor*
20:51:00 <zid> -monitor stdio
20:51:00 <renzei> that makes sense
20:51:00 <renzei> which bit of the info pic am i supposed to be looking at here
20:51:00 <zid> yea pit is all edge triggered
20:51:00 <heat> pastebin it
20:51:00 <renzei> one second
20:52:00 <zid> so it should just be a case of telling the PIC that you're done, so that you get future interrupts, and the PIT can be left alone
20:52:00 <renzei> https://pastebin.com/zw7wfM6V
20:52:00 <bslsk05> pastebin.com: info pic - Pastebin.com
20:52:00 <zid> pic1: irr=00 imr=8e isr=00 hprio=0 irq_base=70 rr_sel=0 elcr=0c fnm=0
20:52:00 <zid> pic0: irr=10 imr=b8 isr=00 hprio=0 irq_base=08 rr_sel=0 elcr=00 fnm=0
20:52:00 <zid> is the bit you want
20:52:00 <renzei> ah alright
20:52:00 <renzei> pic1: irr=00 imr=8e isr=00 hprio=0 irq_base=70 rr_sel=0 elcr=0c fnm=0
20:52:00 <zid> interrupt request registers are 00 and 10
20:52:00 <zid> interrupt mask regs are 8e and b8, etc
20:53:00 <renzei> wait no that's before i started the os
20:53:00 <renzei> after i started the os i got everything zero except pic1 irq_base=28 and elcr=0c, and pic0 irr=03 and irq_base=20
20:53:00 <zid> single step through your PIC ACK outb's and make sure they update info pic in a way that makes sense
20:53:00 <renzei> alrighty - gimme a min
20:54:00 <renzei> single step through the PIC initialisation or the resetting after an irq?
20:54:00 <zid> the latter
20:54:00 <renzei> gotcha
20:54:00 <zid> IRR should tell you what's pending, if it never clears then you have a problem, if it clears but you get another interrupt.. then the pit just sent you another interrupt
20:55:00 <zid> but you should get some instructions inbetween, unless you set a really silly mode on the PIT, I hope!
20:58:00 <renzei> okay so - pic goes to irr=01, isr=01 when the timer fires, and then irr stays 01, and isr goes back to 00 when it hits the end of the irq handler
20:58:00 <renzei> but then the timer never fires again
20:58:00 <zid> sounds like you set the PIT to a oneshot mode, or a really really long period then?
20:59:00 <heat> run qemu with -d int and post the output
21:00:00 <renzei> hmm - i mean, the PIT seems to be set to the right mode given the resources i was using, and the period doesn't seem to affect it, since i've tried changing the freq i send to the PIT, as well as leaving it running for like an hour
21:03:00 <zid> what mode are you using?
21:03:00 <renzei> for the PIT?
21:03:00 <zid> yea
21:03:00 <renzei> wait - i quit gdb and it ticked again, but that's all i did wtf
21:03:00 <renzei> @zid i'm sending 0x36 to 0x43 for the PIT
21:03:00 <renzei> which is mode 3 as far as i can tell
21:03:00 <renzei> (square wave)
21:04:00 <zid> oh are we twitter now
21:04:00 <nikolar> @zid apparently
21:04:00 <renzei> this is bullying.. i am a new irc user okay !!
21:04:00 <zid> @nikolar don't forget to renew your subscription to my onlyfans
21:04:00 <renzei> @everyone shut up stop bullying me :((((
21:05:00 <zid> okay so 0x43 is pit command reg
21:05:00 <renzei> yes i believe so
21:05:00 <heat> @mjg sup!
21:05:00 <zid> and 0x36 is.. binary, mode 3, lobyte/hibyte access mode, channel 0?
21:05:00 <renzei> if you try running the os locally does it also not tick there? cause it could be an issue with my qemu not managing to set up the right ports and stuff idk
21:06:00 <zid> and just to super check, you sent 0x36 to 0x43, and not 0x43 to 0x36? :P
21:06:00 <renzei> yeah, 16bit binary, lh, and channel 0
21:06:00 <renzei> yes, 0x43 is the port, and 0x36 is the value sent there
21:07:00 <zid> and what reload bytes?
21:07:00 <renzei> where i have void outb(uint16_t port, uint8_t val) { asm volatile("outb %1, %0" : : "dN" (port), "a" (val)); }
21:07:00 <renzei> reload bytes? is that the stuff sent to 0x40?
21:07:00 <zid> yea
21:07:00 <zid> the way these timers work is that they count, hit 0xFFFF or 0x0 depending which way they go, then load their reload value
21:08:00 <zid> and then it starts counting again, from there
21:08:00 <renzei> i have divisor which is the Hz/freq (1193182 / freq) and i send (divisor & 0xFF) and then (divisor >> 8) & 0xFF as the high bytes
21:08:00 <renzei> byte*
21:08:00 <zid> so if you set a really small value it goes 3 2 1 0 (interrupt) (reload) 3 2 1 0 (interrupt reload) and is fast, or a big value and it's slow
21:08:00 <renzei> yeah i tried sending like.. 20 and it didn't trigger again
21:08:00 <zid> whether this one counts up or down or does strange things to the value idk
21:09:00 <renzei> i still don't know how to reference people here so @heat here is the -d int that i completely missed:
21:10:00 <renzei> https://pastebin.com/JnVm7z3s
21:10:00 <bslsk05> pastebin.com: -d int - Pastebin.com
21:10:00 <zid> with.. their name
21:10:00 <renzei> i mean.. that is what i did!
21:10:00 <zid> nikolar sucks
21:10:00 <zid> no, you HASHTAGGED him :P
21:10:00 <renzei> anyway the os starts after selecting in grub after the spam of servicing hardware INT=0x08
21:10:00 <nikolar> No, zid, you suck
21:10:00 <renzei> um akshaully i atted him
21:11:00 <zid> Then you get a vector=20 once, right at the bottom, which is your IRQ0 and thus the timer, which looks fine
21:11:00 <renzei> yeah, and then no more output
21:11:00 <renzei> i waited like 30 seconds-ish
21:11:00 <renzei> i'm so confused because everything seems right and like it should work.. and then it doesn't!!
21:13:00 <zid> what reload values do you actually send?
21:14:00 <renzei> lowkey no idea because i haven't added printing numbers to my printf implementation yet "^^
21:14:00 <renzei> lemme uh.. gdb it one sec
21:14:00 <zid> breakpoint th- yea
21:14:00 <nikolar> Lel
21:16:00 <renzei> divisor is 11931, so i send outb(0x40, 11931 & 0xFF) and outb(0x40, (11931 >> 8) & 0xFF)
21:16:00 <zid> why are you making me do math
21:16:00 <renzei> so.. 155 then 46 (decimal)
21:16:00 <zid> just look at what's in AL
21:16:00 <zid> also it introduces mistakes
21:17:00 <zid> there's an out dx, al you can stepi to from those breakpoints surely
21:17:00 <renzei> yes there is - which i'm doing rn :p
21:17:00 <zid> There's some assumption somewhere we've gotten wrong
21:17:00 <zid> that the outb code works, that the PIT is not made of cheese, etc
21:17:00 <zid> so it's fine-toothed comb time to try find what
21:18:00 <zid> either that or we bust out the big guns
21:18:00 <renzei> 0x36 first to the 0x43, then 0x9b (-101??) then 0x2e (46) to 0x40
21:18:00 <renzei> so what i assumed to be 155 is actually apparently -101 according to gdb
21:18:00 <renzei> but that might just be an error in displaying hex as decimal
21:19:00 <zid> That seems big
21:19:00 <zid> 0x9b is a lot
21:19:00 <renzei> i mean, the value i'm trying to send is on the order of 10000 which is a lot
21:19:00 <zid> oh it's actually 0x2e right, which is sort of a lot?
21:19:00 <zid> 0x2e.9b time units
21:19:00 <renzei> yeah i believe so
21:19:00 <renzei> no idea if big or little ending tbh
21:20:00 <renzei> s/ending/endian
21:20:00 <zid> hardcode it to outb(0x40, 0); outb(0x40, 10); for now?
21:20:00 <zid> fuck math
21:20:00 <zid> we don't need mathematics where we're going
21:20:00 <renzei> i did that.. alas, no ticking
21:21:00 <renzei> i think it's an issue in the isr/irqs themselves, as there's also that issue of the wrong isr being called when an exception/panic happens
21:21:00 <renzei> which *could* be related
21:21:00 <zid> okay now make main a program that reads the latch in a loop and copies the data to the serial port tx and -serial file:log.txt in qemu? :P
21:21:00 <zid> (slightly bigger gun)
21:21:00 <renzei> the latch?
21:22:00 <renzei> you're gonna have to explain a little more in detail what you mean (this is my first time trying to os dev)
21:22:00 <zid> When the latch command has been sent, the current count is copied into an internal "latch register" which can then be read via the data port corresponding to the selected channel (I/O ports 0x40 to 0x42)
21:22:00 <zid> You send it a command and it copies the current state to a latch
21:22:00 <zid> that's what 0x40 reads
21:23:00 <renzei> so what am i putting in kernel_main? reading 0x40-0x42 and outputting them to a serial port?
21:23:00 <renzei> (sorry if i'm slow - i'm also a little drunk :p)
21:24:00 <zid> write to 0x40, read from 0x40, write it to.. 0x3F8?
21:24:00 <zid> if memory serves
21:24:00 <zid> you'll wanna outb "meow" or something first to make sure it works
21:24:00 <renzei> okay i gotta implement inb real quick
21:24:00 <zid> then add the 'reading from the latch' part on top
21:26:00 <renzei> so basically - while (1) { uint8_t res = inb(0x40); outb(0x3F8, res); }
21:26:00 <renzei> ?
21:26:00 <zid> you need to write to 0x40 first
21:26:00 <zid> to get it to latch the deets
21:26:00 <renzei> yee, i mean after calling timer_init
21:26:00 <zid> no
21:26:00 <zid> in the loop
21:26:00 <renzei> isn't the loop after timer_init
21:26:00 <zid> You want a new value every time, not the old stale one
21:27:00 <renzei> okay i see
21:27:00 <renzei> what am i sending to 0x40 every loop iteration?
21:27:00 <zid> writing to it tells it "copy the info to the latch" reading is "read the latch"
21:27:00 <renzei> 0x00 0x10?
21:27:00 <zid> erm.. I think 0?
21:27:00 <zid> not sure
21:27:00 * zid finds out
21:28:00 <renzei> does this look good
21:28:00 <renzei> https://pastebin.com/YKz4PUSH
21:28:00 <bslsk05> pastebin.com: waow - Pastebin.com
21:28:00 <zid> ah it's a write to 0x43
21:29:00 <zid> but read from 0x40
21:29:00 <renzei> gotcha
21:29:00 <renzei> okay imagine that with outb being 0x43, 0x00
21:29:00 <renzei> is that correct?
21:29:00 <zid> yea
21:29:00 <renzei> then how do i run qemu to output the serial port 0x3F8?
21:29:00 <zid> -serial file:log.txt
21:29:00 <zid> https://cdn.discordapp.com/attachments/417023075348119556/1265782952139296928/image.png?ex=66a2c3bc&is=66a1723c&hm=e63696b96775ce73a6229ea2755b3169a7fb43ca2f9b9fd34333319eb02b0336&
21:30:00 <renzei> lowkey.. log.txt is blank after that
21:30:00 <zid> okay might need to init the com port then, boo
21:30:00 <zid> did you meow
21:30:00 <zid> like I said
21:30:00 <renzei> i'm sorry i didn't meow.............
21:30:00 <heat> meow
21:30:00 <renzei> meow
21:31:00 <renzei> i can't outb meow cause outb takes a uint8_t :( unless you mean send each letter individually
21:31:00 <zid> yes I do
21:31:00 <zid> because of course I do
21:31:00 <renzei> but that seems not to work since nothing was printed anyway
21:31:00 <zid> https://gist.github.com/zid/64682f4ca9e4efba9eb29da4907bfa5f steal this to init com port if you can't get it to meow
21:31:00 <bslsk05> gist.github.com: gist:64682f4ca9e4efba9eb29da4907bfa5f · GitHub
21:31:00 <zid> should work
21:31:00 <renzei> is PORT here #define PORT 0x3whatever it was
21:31:00 <zid> 3f8
21:32:00 <zid> oh then at the end, PORT+4, 0x0F
21:32:00 <renzei> do i do that init stuff before or after gdt and tty and stuff
21:32:00 <zid> wherever you like
21:32:00 <zid> as long as it's before the loop
21:32:00 <renzei> log is still empty :(
21:32:00 <zid> did you read the 0xF part
21:33:00 <renzei> yes i did thank you very much
21:33:00 <zid> I forgor to read all of the random thing I stole, and it was 4 lines down, the bastards
21:33:00 <zid> why does nothing work for you
21:33:00 <renzei> https://pastebin.com/gfEVj0Zt
21:33:00 <bslsk05> pastebin.com: buh - Pastebin.com
21:33:00 <renzei> i dont KNOW i just want to make an os :(((((
21:33:00 <renzei> i put the command i ran at the bottom
21:35:00 <renzei> i can't tell if i'm missing something really obvious or if for some reason C and assembly just want to be different for me than everyone else
21:35:00 <zid> I think you slipped into a slightly different reality to the rest of us
21:35:00 <zid> I really need to pee
21:35:00 <renzei> that's so real so do i i'm rather drunk
21:36:00 <renzei> i think i'm in another reality bc i haven't found ANYONE else with the same issue as me
21:38:00 <zid> all I can think of is
21:38:00 <zid> delete that 0xAE line cus it might be breaking the com port
21:39:00 <zid> and do two prints per iteration of the loop btw cus we're in hilo mode
21:39:00 <zid> so we need to read it twice
21:39:00 <zid> I am going to bed
21:39:00 <renzei> still no output :c
21:39:00 <renzei> thank you for your help anyway!!
21:39:00 <renzei> i should sleep too
21:39:00 <renzei> goodnight kind irc user zid
21:40:00 <zid> I'm going to wake up to a "actually I was running a 2 day old iso cus it never updated properly oops" message, calling it now btw
21:40:00 <heat> you forgot the @
21:40:00 <nikolar> Wow someone called zid kind
21:40:00 <renzei> i'll have you know i've tried doing make -B so therefore it can't be 2 days old
21:40:00 <renzei> excuse you zid is very kind D:
21:41:00 <renzei> anyway goodnight chat
21:41:00 <zid> we're twitch now
21:42:00 <zid> I bet heat says "CHAT IS THIS SEAT TAKEN?" on the bus
21:42:00 <nikolar> Lel
21:43:00 <kof673> "i'm going to bed" <other user parts> </jedi mind trick>
22:02:00 <heat> mjg, i'm adding maple tree to my vm btw
22:03:00 <heat> and then i'll be benchen
22:03:00 <heat> you don't actually need to be turning on rcu mode until you get more threaden, it's pretty nice
22:04:00 <nikolar> RCU-IZE IT RIGHT NOW
22:04:00 <heat> not sure how that'd look, i hate the skunkworks vma locks they came up with in linux
22:05:00 <nikolar> Kek
23:33:00 <heat> nice maple tree is working
23:35:00 <nikolar> That was fast
23:38:00 <heat> the api itself is pretty well designed and easy to use
23:38:00 <heat> as for maple tree deps itself, i already have most of them
23:38:00 <heat> linux _is_ an onyx clone after all
23:39:00 <nikolar> Did you already have the maple tree implemented
23:39:00 <nikolar> I thought you were writing it right now
23:39:00 <heat> oh i'm not writing a maple tree, i took linux's
23:39:00 <heat> the maple tree is hugely complex and awful lol
23:40:00 <heat> almost 8KLOC
23:40:00 <nikolar> Oh you just took the whole thing
23:40:00 <nikolar> Lame
23:40:00 <heat> fair
23:41:00 <nikolar> Lol
23:41:00 <heat> i have little interest in spending ages writing one, i really just want to use it
23:41:00 <heat> i got to look at a horrible SLAB api too
23:41:00 <Matt|home> hi..
23:42:00 <heat> kmem_cache_alloc_bulk takes a size_t, it's supposed to *always* return that argument, and returns 0 on error
23:42:00 <heat> the best bit is that the return type is an int, not a size_t
23:42:00 <nikolar> Lel
23:42:00 <nikolar> Why
23:43:00 <heat> i dunno, i tried searching on lore but couldn't figure it ut
23:43:00 <nikolar> Maybe just an oversight
23:43:00 <nikolar> Who needs to allocate more than 2gb at once anyway
23:44:00 <heat> the current impl does not check for arg > INT_MAX, so if you ever get linux to allocate more than INT_MAX there... you get it to error out erroneously
23:44:00 <nikolar> Heh nice
23:44:00 <nikolar> Someone should report that
23:45:00 <heat> hmm
23:45:00 <nikolar> What
23:45:00 <heat> int < size_t, do they promote to size_t or do they demote size_t to int?
23:45:00 <heat> i think they demote the size_t?
23:46:00 <nikolar> What do you mean by int < size_t
23:46:00 <nikolar> A normal comparison?
23:47:00 <nikolar> int should be promoted to size_t iirc
23:49:00 <heat> oh, the loop will never end then
23:49:00 <nikolar> Heh nice
23:50:00 <nikolar> Yeah, no bueno
23:52:00 <nikolar> Btw a rule od thumb, c never demotes times to smaller sizes
23:52:00 <nikolar> Implicitly
23:53:00 <nikolar> In binary ops
23:54:00 <heat> i have realized it not only will never end, but the int will underflow
23:54:00 <heat> fuck me
23:54:00 <nikolar> Yes, the int will underflow
23:54:00 <nikolar> Report that
23:54:00 <heat> i'll send a patchen
23:55:00 <nikolar> Do indeed send patchen
23:56:00 <nikolar> Though probably not a bad idea to report first and see the feedback
23:56:00 <nikolar> Maybe they are aware of it :/