klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
Teukka has quit [Ping timeout: 260 seconds]
netbsduser` has quit [Ping timeout: 276 seconds]
karenw has quit [Ping timeout: 245 seconds]
Ryanel has joined #osdev
Ryanel has quit [Quit: Textual IRC Client: www.textualapp.com]
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
cow321 has quit [Ping timeout: 248 seconds]
cow321 has joined #osdev
goliath has joined #osdev
mrpops2ko has quit [Ping timeout: 245 seconds]
mrpops2ko has joined #osdev
\Test_User has quit [Ping timeout: 252 seconds]
\Test_User has joined #osdev
libercv has joined #osdev
vdamewood has joined #osdev
Teukka has joined #osdev
Lucretia has joined #osdev
GeDaMo has joined #osdev
Left_Turn has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]
libercv has quit [Quit: Konversation terminated!]
Left_Turn has joined #osdev
libercv has joined #osdev
karenw has joined #osdev
netbsduser` has joined #osdev
libercv has quit [Quit: Konversation terminated!]
<_Heat> geist: do you do anything to sync the TSC on zircon?
<_Heat> i'm watching time go backwards and i'm wondering if the problem isn't just that...
xvmt has quit [Ping timeout: 272 seconds]
theruran has quit [Quit: Connection closed for inactivity]
<zid> nikolar: Did you enjoy the rain at the F1? kek
<zid> Been sunny and hot for weeks, F1 starts and it rains
Turn_Left has joined #osdev
<nikolar> kek
<nikolar> it was very chaotic
Left_Turn has quit [Ping timeout: 260 seconds]
jcea has joined #osdev
netbsduser` has quit [Ping timeout: 252 seconds]
vai has joined #osdev
netbsduser` has joined #osdev
jcea has quit [Ping timeout: 248 seconds]
<sortie> mjg, heat: https://sortix.org/os-test/#io-open-clofork-fork ← O_CLOFORK data
<bslsk05> ​sortix.org: os-test
<sortie> aix is generally very backwards, while solaris is way more modern
<Ermine> ILLUMOS
<Ermine> anyway, today windows deserves it: MICROSHILL WINCRAP
<izabera> til that linux supports clofork but the man pages don't document
<izabera> it
mrpops2ko has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<zid> your man pages are just too old surely
<zid> o_clofork is from 2024 spec afterall
<\Test_User> why clofork when you could have close_range or the likes? I've never seen CLOFORK as the right option to doing things since it'll be a mess if you try to fork from two threads at once or the likes
<zid> bet it takes a long time
<bslsk05> ​lwn.net: fs: add FD_CLOFORK and O_CLOFORK [LWN.net]
<izabera> was this removed
<izabera> i can't see it in the kernel now
<Ermine> iirc it was nacked on linux?
<zid> that'd explain why it never made it to the man pages
<Ermine> oh. 2011
karenw has quit [Ping timeout: 252 seconds]
<_Heat> izabera: linux does not support clofork
<_Heat> it was nacked by al viro last time it was proposed, in ~2022
<izabera> lol
<mjg> why lol
<mjg> it's a questionable idea from the get go
<izabera> was for zid
<mjg> oh. got the guy on ignore. :P
<izabera> feels like i'm stepping into drama
<izabera> soooo
* izabera grabs popcorn
<izabera> spill the tea
<mjg> meh
<mjg> not much to say, he has me on ignore as well
<mjg> let's say failed vibe check both ways
<mjg> i should probably ignore some WEBDEVS though
* izabera dies of thirst because not enough tea
<zid> where did that weird spill the tea phrase come from
<zid> it just seemingly popped up out of nowhere and every time I see it used I see *other* americans still asking what the hell it means
<izabera> uhhhh ru paul's drag race?
<izabera> wild guess
<zid> oh, very not my crowd then
<izabera> https://english.stackexchange.com/questions/428090/where-does-the-expression-spill-the-tea-come-from seems like it's from drag culture but much older than that particular show
<bslsk05> ​english.stackexchange.com: Just a moment...
<zid> american*
<kof673> eh :/ https://lkml.indiana.edu/hypermail/linux/kernel/2206.3/05525.html Other google employees have a system which > > > has literally millions of file descriptors in a single process. > > > Having to maintain this extra state per-fd is a cost they don't want > > > to pay
<bslsk05> ​lkml.indiana.edu: Linux-Kernel Archive: RE: [PATCH v2] Implement close-on-fork
<izabera> for the record i think close range is useful in practice but it's always the wrong thing to do
<mjg> close range is a pragmatic bandaid over unix breakage
<kof673> i have no position just "it hurts when i do this" doctor: don't do that
<\Test_User> close range does a better job of fixing it than clofork as far as I can see, mostly due to thread usage implications (but something more direct could be great)
<mjg> clofork is trying to fix a different problem though
<mjg> clofork makes sure the child does not get the marked fd to begin with
<mjg> regardless of what other threads are doing
<izabera> i recently had to fight a nodejs thing because the processes it spawns will inherit random sockets that i didn't know about, making it difficult to run things in background
<\Test_User> sure, but if you're using multiple threads doing forking, you're still going to have to deal with fds popping up where they shouldn't be anyways, and clofork won't have saved you any steps (though ig it could have saved the kernel some work not having to dup then reclose them. also it's directly usable for singlethreaded stuff so that usage could be alright)
<izabera> it's a stupid problem to have
<izabera> close range does help solve that, but i would rather not just have random fds
<\Test_User> you're stuck with "random" fds if you want to use `open` and `fork` in multiple threads without additional synchronization
<izabera> is there any os that has a way to preallocate fds? something like open(file, flags|O_PREALLOCATED, mask, 17) -> return 17 or -1
<sortie> I implemented O_CLOFORK because it was easy to implement and could have uses
<izabera> any other api to do that would be fine too
<mjg> \Test_User: the thing is with close_rnage you still transiently have the fd
<mjg> which runs into funny problems
<\Test_User> mjg: ah, so it's mostly for working around oddities in special fds then?
<mjg> it's shit like opening something for writing and then trying execve it from a child
<mjg> if another thread forked off in the meantime, you may get spurious EXTBSY
<\Test_User> ah
<mjg> i think the real fix is to fucking provide a real interface to create a new process
<mjg> personally i was thinking in the lines of creating a handle (maybe even a file descriptor) which you then gradually build up
<mjg> for example setup which fds show up there
<mjg> and with what numbers
<mjg> the signal mask etc.
<mjg> finally you invoke a magic call to exec a fucken' binary with all this setup
<_Heat> *posix spawn noises*
<mjg> no, the point is to allow arbitrary code execution to consturct the fuck
<mjg> liek you literally you do whatever you want
<mjg> and once you are done you hand it over
<_Heat> oh that's too far removed from UNIX
<_Heat> sadly/luckily
<izabera> make every syscall take a pidfd as the first argument
<mjg> remove system calls
<_Heat> that doesn't really work for various reasons
<_Heat> technical ones
<izabera> uhm
<izabera> do explain please
<_Heat> lots of code simply assumes it's using the correct mm_struct/files_struct/wanker_struct because it's the current, and only the current process can change it
<_Heat> you'd need to add locking for all of that
<_Heat> and refcounting and <...>
<_Heat> you already kind of have it, in a limited capacity, for remote accessing an mm or an fd
<_Heat> but it's not ideal nor fast
<izabera> it's not too hard to do imho, just add a queue of operations for each process to execute the next time it's in kernel space
<izabera> so it's done by that process
<_Heat> that's problematic scheduling-wise, i assume
<izabera> just require whatever permission/capability to be able to submit such an operation for a certain process, so you can't have things starve other processes
<izabera> i'm not too serious on this but it's really not that unreasonable.......
<_Heat> > just require whatever permission/capability to be able to submit such an operation for a certain process
<_Heat> that's a gievn
<_Heat> but doesn't really help process exec scheduling being disturbed by the child process needing to run mid-exec
<zid> I love things that didn't used to have locks, now having locks. Works great for my memory and performance.
<zid> so that someone else can write code *easier*, not better or faster
<_Heat> rcu all the things
<_Heat> we're all in a big rcu critical section
<zid> I wish someone would write to heat so we got a new one and he was deleted
<mjg> big kernel lock
<mjg> bring back dos
<_Heat> clameter was right
innegatives has joined #osdev
<zid> is that a thing for measuring clams
<izabera> that'd be a clammeter
mrpops2ko has joined #osdev
edr has joined #osdev
<nikolar> when are we getting the original heat back
<nikolar> instead of _Heat
<zid> C27
<_Heat> yeah typedef _Heat heat; will be an error
<nikolar> oh will it break the existing code using heat?
<zid> defo
<nikolar> nice, exactly what you'd want
<sortie> HEAT25 is wild
<sortie> _Heat({mjg, sortie, openbsd}) ← like it's wild what you can do with the new syntax
<pog> warning: {mjg, sortie, openbsd} has implicit type of 'any'
* pog throws herself out the window
<Ellenor> hopefully a ground floor window?
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #osdev
<pog> sure
<pog> even though typescript makes me crave death
<pog> (it doesn't like function-as-constructor)
mrpops2ko has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
urandom has quit [Killed (platinum.libera.chat (Nickname regained by services))]
urandom_ has joined #osdev
mrpops2ko has joined #osdev
EmanueleDavalli has joined #osdev
<EmanueleDavalli> Managed to complete the dhcp handshake in qemu
<EmanueleDavalli> Now need to figure out an api to configure the network interface with this data
<_Heat> the gang creates AF_ROUTE
<_Heat> or AF_NETLINK
<_Heat> or both
<_Heat> or crummy ioctls
<sortie> cuttle the io
<_Heat> ^^this is a man who went the crummy ioctl route
<EmanueleDavalli> sortie: thank you for sortix btw, its network stack was a great inspiration
<sortie> EmanueleDavalli: I'm happy to hear it :) Networking has been one of the things making Sortix so fun and useful
EmanueleDavalli has quit [Quit: Client closed]
EmanueleDavalli has joined #osdev
<_Heat> i should implement netlink one of these days
<_Heat> all good linux clones like freebsd do so these days
<nikolar> netlink?
gareppa has joined #osdev
<_Heat> man 7 netlink
<_Heat> and then man 7 rtnetlink
goliath has quit [Quit: SIGSEGV]
<nikolar> ah interesting
<_Heat> BSD (like really old BSD, maybe around the 4.4 stuff) had AF_ROUTE
<_Heat> presumably the BSDs still use it or some modification of it
<_Heat> yeah they all do
gareppa has quit [Quit: WeeChat 4.5.1]
<nikolar> kek
c0d3x has joined #osdev
karenw has joined #osdev
<zid> when PF_NETLINK
<zid> heat why is the thing for transfering sockets between processes so insane btw?
<zid> that weird out of band runlength struct using a bunch of macros
<_Heat> i mean it's uhhhhhhhhhhhhhhhhhhhhhhhhhh alright
<_Heat> if you mean SCM_RIGHTS
<zid> yea sendmsg
karenw has quit [Quit: Deep into that darkness peering...]
<_Heat> ancillary data is kind of weird, but there's no sane way you'd do it in-band
<zid> why isn't there
<zid> it could just be exactly what it is, but you make all the flags go away and make it you know, an actual syscall
<zid> so instead of sendmsg(fd, (struct msghdr){NULL, ...}, MSG_OOB); it's just send_socket(pid, 4);
<_Heat> oh ok, for the sending only
<clever> but now what about receiving? or exchanging uid's?
<_Heat> i mean, sending fds to pids directly is not particularly great
<_Heat> especially when you consider that most server/client relationships work with socket paths and not pids
karenw has joined #osdev
vai has quit [Ping timeout: 245 seconds]
jcea has joined #osdev
EmanueleDavalli has quit [Quit: Client closed]
goliath has joined #osdev
jcea has quit [Ping timeout: 248 seconds]
jcea has joined #osdev
vai has joined #osdev
<vai> hi
errno has joined #osdev
errno has quit [Remote host closed the connection]
karenw has quit [Ping timeout: 245 seconds]
netbsduser`` has joined #osdev
netbsduser` has quit [Ping timeout: 248 seconds]
n00by has joined #osdev
Turn_Left has quit [Remote host closed the connection]
Turn_Left has joined #osdev
ian| has joined #osdev
<ian|> is there a highly standard way for dealing with gfx modes "post-VGA"? maybe VESA?
<nortti> if you are on UEFI, you can use GOP as part of the boot services
<_Heat> it's GOP yes
n00by has quit [Quit: leaving]
jcea has quit [Ping timeout: 248 seconds]
<zid> ian|: post-vga was literally vbe, but then dpmi, then gop
<zid> dmpi
<zid> dpmi
tronexte has quit [Read error: Connection reset by peer]
<zid> dos protected mode interface :P
<zid> I think support for the protected mode vesa thing was super uncommon though?
<zid> on actual period correct cards
<ian|> it says VESA Bios Extensions v3.0 had 32-bit (64-bit ?)
<zid> yea that thing doesn't really exist in practice
tronexte has joined #osdev
<zid> regular vbe does though
gog has joined #osdev
<zid> but in Modern Era when we all just use nvidia or integrated intel or both
<zid> your bios includes an uefi module that implements the gop api
<zid> or nvidia provides one off its option rom, in the case of nvidia
<zid> idk what intel does, probably includes it in the ME/bios/etc sdk package?
<zid> can't imagine the cpu has it
tomaw has quit [Remote host closed the connection]
tomaw_ has joined #osdev
<ian|> what do you mean "VBE 3.0" doesn't really exist in practice but "regular VBE" does
<zid> which bit are you not following along with?
<zid> in practice? 3.0?
tomaw_ is now known as tomaw
<ian|> 3.0 was released in 1998 around, so i would think most computers by now have it
<zid> except
<zid> nobody bothered
<nikolar> except that's not how it works
<zid> just because a spec is published doesn't mean everybody implements it
<nikolar> yes
<zid> in practice about the only place you'll see vbe 3.0 is under emulation
<zid> real cards that had roms with support were super rare
<zid> by 1998 basically nobody was doing direct blitting from pmode, customers didn't really care, so vendors didn't really care
<zid> they were running windows, with dedicated 3rd party drivers
<zid> or still running 16-bit DOS
<ian|> that's too bad
<zid> you can just.. emulate the real mode version :P
<zid> or use gop
<zid> or just write drivers for the bochs display driver that bochs and qemu use and leave it there
<zid> because the driver is literally 2 lines
c0d3x has quit [Quit: WeeChat 4.7.0-dev]
<_Heat> or implement enough of linux to run the linux drivers
<zid> kek
<zid> (slightly more than 2 lines)
<_Heat> 3 lines!
<PublicWiFi> I know different OS's do this differently, but as a whole is it usually up to the VFS to parse/tokenize path's when something like vfs_open_dir() is called?
<PublicWiFi> and it (maybe not directly but through syscalls or something) calls the file system over and over to walk through dirs?
<zid> yes
<PublicWiFi> so open_dir "/test/somepath/here/", would the vfs usually tokenize this to "test", "somepath" and "here" and call the filesystem driver 3 times?
<zid> don't put dir walking in filesystem drivers that's insane
<zid> because it'll be replicated per filesystem, and it'd allow them to make up bullshit rules like paths are tokenized /mnt/usb/fred?banana?lol€txt
<zid> as you switch filesystems
<PublicWiFi> oh right
<PublicWiFi> duh lol
<PublicWiFi> the only reason I thought it might be worth it is to pass the whole string at once to the filesystem is all
<PublicWiFi> then you save n number of calls
<PublicWiFi> but yeah you're totally right, thanks for teh sanity check
<zid> it'd *allow* things
<PublicWiFi> right lol
<zid> but it's not useful things :P
<PublicWiFi> i totally get what you mean
<PublicWiFi> so my high level idea is pretty ok? let vfs tokenize and call a dir walk/search/open/whatever for each token until end or invalid etc etc
<zid> sounds fine to me
<PublicWiFi> ok ty :)
<zid> absolute path going to absolute, relative path can have it cached or whatever
<PublicWiFi> exactly
<PublicWiFi> I'm just gonna do absolute to get a rough-in running and to iron out some stuff
<zid> optimization first, implementation.. last
<zid> somehow, done it
<zid> do it*
<PublicWiFi> lol
<PublicWiFi> something I am learning is that osdev can sometimes be a "chicken and the egg" scenario
<PublicWiFi> so many systems that rely on each other
<zid> yea
<zid> most of it, imo
<PublicWiFi> so lots of prototyping and rough-ins
<PublicWiFi> then improvement later lol
<zid> networking and files, being the main ones
<PublicWiFi> right
<zid> network driver no use without a protocol, protcol no use without a driver, neither any use without an api, api no use without a test program
<PublicWiFi> fortunately (kind of...) for me I'm doing an 8-bit system on vintage hardware so a lot of this is pared down and a bit simplier ofc
<zid> end up writing half of apache, a tcp/ip stack and a network driver, just to test opening a socket
<PublicWiFi> lol!
<pog> if you give a browser a cookie
<pog> it's gonna want a CORS allow-origin header
<PublicWiFi> I have a wiznet module im using for network so my network "daemon" will just handle keeping up with the opened/closed sockets and their preferences
<PublicWiFi> since it can only do like 4 at once or something
ian| has quit [Quit: Konversation terminated!]
<PublicWiFi> haven't got that far yet, gotta get vfs running first lol
<PublicWiFi> ty for the help zid
<_Heat> PublicWiFi: in general you avoid the filesystem calls by having a cache
<_Heat> but ofc with 8 bit systems that's different
<PublicWiFi> in a normal situation yes
<PublicWiFi> right xD
<zid> cpu in the hard drive is faster than your cpu :P
<PublicWiFi> I have a paging system but I'm not even gonna try to implement that yet
<PublicWiFi> zid++++
<zid> and a 1ms seek delay is like, 4 instructions ;)
<PublicWiFi> so ima write kernel 1.0 for 64K contiguous memory, then later implement paging support and add cool features like cahcing
<PublicWiFi> :P
<PublicWiFi> i also hope to port this OS to my m68k later in life lol
bliminse has quit [Quit: leaving]
bliminse has joined #osdev
eluks has quit [Remote host closed the connection]
dude12312414 has joined #osdev
eluks has joined #osdev
<izabera> name one reason to not add a counter of how many signals were coalesced when delivering a signal
eluks has quit [Remote host closed the connection]
eluks has joined #osdev
EmanueleDavalli has joined #osdev
eluks has quit [Remote host closed the connection]
<nortti> you'll need an int per signal instead of being able to use a single int as a bitmap, which has overhead if you are targetting extremely embedded systems, and it's marginally slower to check for pending signals
eluks has joined #osdev
<geist> +1 to nortti
<_Heat> That's a moot point if you consider you already have some 32 bytes to carry around in the form of siginfo_t
<_Heat> the real reason why it's not a thing is that simply no one wants this
<zid> heat doesn't believe embedded exists btw
<geist> well, there's a lot more too it too, because it depends on what the api is. if we're assuming precisely posix signals, the count doesn't surface in the api because it doesn't have it, right?
<geist> but if you're doing a signals like thing, then siginfo_t may or may not be the thing you use, etc
<geist> the original question doesn't state what kinda of signals is going on here
<geist> i'd add a count if it serves a purpose, or is part of the whole cohesive mechanism. ie if it's not present you lose edges (and you're counting edges, not levels) then it ends up being a solution to a problem
<geist> i think we have something exactly like this in zircon in the port notification system
<geist> which is sort of our version of signals
<zid> you probably have more than 32 ports though
<zid> so it's a concession potentially
karenw has joined #osdev
<geist> yep it's a totally different system, but my point is not the data costs of it, but that it serves a purpose
Gooberpatrol66 has quit [Quit: Konversation terminated!]
Gooberpatrol66 has joined #osdev
<_Heat> enbedded is not real and cannot hurt me
<Ermine> if one ignores embedded maybe it'll go away
<geist> it's everywhere
<geist> you cannot escape
* Ermine closes eyes and turns head to another side
<zid> oh, the sample from girls by the prodigy is from d-train, you're welcome
<zid> I assume you were all desperately sat by your synths looking through a stack of vinyl, trying to find the things the prodigy sampled. Saved you a job.
<bslsk05> ​gist.github.com: floatcomplex nerd sniped me into testing how many sigwinches i can get per second via terminal resizes · GitHub
<izabera> 99.9% signals non coalesced
* izabera happy
<izabera> still a shitty api tho
n00by_ has joined #osdev
n00by_ has quit [Client Quit]
n00by_ has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 248 seconds]
Turn_Left has joined #osdev
<EmanueleDavalli> my strategy with signal implementation is to ignore them until I'm forced to
<EmanueleDavalli> *not to
<_Heat> signals aren't that hard
<_Heat> luckily
<izabera> all future os please add a counter of how many things you've dropped on the floor when you drop things on the floor
<kof673> eh, very vaguely mainframe -> consumer -> embedded not really but embedded is sort of getting more power, while consumer stuff is vaguely slimmed down from server gear
<kof673> its just one giant bslsk /s
Left_Turn has quit [Ping timeout: 265 seconds]
<kof673> i still have little SOCs with 586 or so 64M ram, this was a fancy desktop at some point
<kof673> or probably a tip-top netware server for some era :D
<n00by_> mold is c++ 20 and still the fastest, isn't that kinda weird :P
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<_Heat> not really
goliath has quit [Quit: SIGSEGV]
netbsduser`` has quit [Ping timeout: 252 seconds]
EmanueleDavalli has quit [Quit: Client closed]
n00by_ has quit [Ping timeout: 276 seconds]
n00by_ has joined #osdev
netbsduser`` has joined #osdev
itrsea has quit [Remote host closed the connection]
eluks has quit [Remote host closed the connection]
eluks has joined #osdev
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
netbsduser`` has quit [Ping timeout: 245 seconds]
Turn_Left has quit [Ping timeout: 276 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #osdev
eluks has quit [Remote host closed the connection]
eluks has joined #osdev
Lucretia has quit [Remote host closed the connection]
netbsduser`` has joined #osdev
n00by_ has quit [Ping timeout: 260 seconds]
Turn_Left has joined #osdev
jcea has joined #osdev
the_oz has quit [Quit: Leaving]
netbsduser`` has quit [Ping timeout: 244 seconds]
eluks has quit [Remote host closed the connection]
melnary has quit [Remote host closed the connection]
eluks has joined #osdev
eluks has quit [Remote host closed the connection]
eluks has joined #osdev
Matt|home has quit [Quit: Matt|home]
eluks has quit [Remote host closed the connection]
eluks has joined #osdev
eluks has quit [Remote host closed the connection]
eluks has joined #osdev
freakazoid332 has quit [Read error: Connection reset by peer]
melnary has joined #osdev
frkazoid333 has joined #osdev
Turn_Left has quit [Read error: Connection reset by peer]