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
thinkpol has quit [Remote host closed the connection]
thinkpol has joined #osdev
deriamis has quit [Quit: ZNC - https://znc.in]
deriamis has joined #osdev
gildasio has quit [Ping timeout: 252 seconds]
gildasio has joined #osdev
frkzoid has joined #osdev
MiningMarsh has joined #osdev
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
MiningMarsh has joined #osdev
goliath has quit [Quit: SIGSEGV]
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
MiningMarsh has joined #osdev
CaCode_ has joined #osdev
CaCode has quit [Ping timeout: 245 seconds]
stolen has joined #osdev
Hammdist has joined #osdev
fkrauthan has quit [Quit: ZNC - https://znc.in]
fkrauthan has joined #osdev
gbowne1 has quit [Quit: Leaving]
netbsduser` has quit [Ping timeout: 264 seconds]
nyah has quit [Quit: leaving]
agent314 has joined #osdev
rustyy has quit [Ping timeout: 246 seconds]
ExclamationPoint has joined #osdev
<ExclamationPoint> i'm not sure if this is the right place, but anyone here try flashing a BIOS chip over SPI? I'm trying to find the details of the CH341A and whether I can just use my own SPI interface
gorgonical has joined #osdev
<gorgonical> currently trying to decide if the hassle of implementing virtio over a channel is worth it
<gorgonical> or if i should just roll my own, simpler system without that much abstraction
<zid> yea you can flash bios chips with made up hw
grumbler has quit [Quit: It's time]
<zid> (precisely because they're bios chips, the mobo needs to be able to update them, and doesn't wanna have to generate complicated voltages and properly clocked busses and stuff)
<zid> so they're all spi, which you can bitbang
<zid> you could technically do it with tweezers, if you had a few months
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
<ExclamationPoint> zid, that's exactly the answer I was hoping for
<ExclamationPoint> so I have an arm devboard with spi pins. i've also done SPI EEPROM read/writes before using a PIC16 and MircoChip's C.
GreaseMonkey has joined #osdev
<ExclamationPoint> the EEPROM i worked with was an LC24 or some such
<ExclamationPoint> 24LC, my bad
<ExclamationPoint> anyway, what I was hoping for is someone who knows the right datasheet or spi format and addreses, etc.
<zid> that would depend on the chip
<ExclamationPoint> herm, this is why I wonder how they all work with this CH341A programmer if they're all different chips
netbsduser` has joined #osdev
stolen has quit [Quit: Connection closed for inactivity]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
netbsduser` has quit [Ping timeout: 245 seconds]
Arthuria has joined #osdev
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
Arthuria has quit [Ping timeout: 240 seconds]
divine has quit [Ping timeout: 240 seconds]
agent314 has quit [Ping timeout: 245 seconds]
netbsduser` has joined #osdev
netbsduser` has quit [Ping timeout: 240 seconds]
divine has joined #osdev
rustyy has joined #osdev
netbsduser` has joined #osdev
Osmten has joined #osdev
valshaped742488 has quit [Ping timeout: 258 seconds]
netbsduser` has quit [Ping timeout: 258 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
valshaped742488 has joined #osdev
zxrom has quit [Quit: Leaving]
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
xenos1984 has joined #osdev
cloudowind has joined #osdev
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
netbsduser` has joined #osdev
Osmten has quit [Quit: Client closed]
netbsduser` has quit [Ping timeout: 252 seconds]
danilogondolfo has joined #osdev
GeDaMo has joined #osdev
zxrom has joined #osdev
Burgundy has joined #osdev
Left_Turn has joined #osdev
tixlegeek has joined #osdev
frkzoid has quit [Ping timeout: 248 seconds]
Hammdist has quit [Quit: Client closed]
Hammdist has joined #osdev
asarandi has quit [Quit: WeeChat 4.0.4]
nuvls has quit [Ping timeout: 246 seconds]
asarandi has joined #osdev
tixlegeek has quit [Quit: tixlegeek]
Osmten has joined #osdev
netbsduser` has joined #osdev
orccoin has joined #osdev
<cloudowind> which ones
nuvls has joined #osdev
<GeDaMo> They are UNKNOWN! :P
gog has joined #osdev
tixlegeek has joined #osdev
asarandi2 has joined #osdev
asarandi has quit [Ping timeout: 240 seconds]
Left_Turn has quit [Remote host closed the connection]
Left_Turn has joined #osdev
heat has joined #osdev
blop_ has quit [Ping timeout: 252 seconds]
rustyy has quit [Quit: leaving]
kof123 has quit [Ping timeout: 252 seconds]
<cloudowind> at least something known about them that they are unknown
Osmten has quit [Ping timeout: 245 seconds]
asarandi has joined #osdev
asarandi2 has quit [Ping timeout: 258 seconds]
heat has quit [Ping timeout: 240 seconds]
tixlegeek has quit [Quit: tixlegeek]
Hammdist has quit [Quit: Client closed]
tixlegeek has joined #osdev
tixlegeek has quit [Remote host closed the connection]
asarandi2 has joined #osdev
Vercas2 has joined #osdev
asarandi has quit [Ping timeout: 258 seconds]
goliath has joined #osdev
gxt has quit [Ping timeout: 252 seconds]
Vercas has quit [Ping timeout: 252 seconds]
Vercas2 is now known as Vercas
cloudowind has quit [Quit: Lost terminal]
gxt has joined #osdev
asarandi has joined #osdev
asarandi2 has quit [Ping timeout: 240 seconds]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 248 seconds]
nuvls has quit [Ping timeout: 246 seconds]
Nixkernal has quit [Quit: No Ping reply in 180 seconds.]
Nixkernal has joined #osdev
asarandi2 has joined #osdev
asarandi has quit [Ping timeout: 260 seconds]
asarandi has joined #osdev
asarandi2 has quit [Ping timeout: 264 seconds]
asarandi2 has joined #osdev
asarandi has quit [Ping timeout: 258 seconds]
asarandi has joined #osdev
asarandi2 has quit [Ping timeout: 258 seconds]
tixlegeek has joined #osdev
<gog> one cpu at at ime
<zid> reference to the old BLK
<zid> BKL*
<zid> was removed with 2.6
<zid> hence.. 2.6
nuvls has joined #osdev
[itchyjunk] has joined #osdev
utzig has left #osdev [#osdev]
skipwich has quit [Ping timeout: 252 seconds]
grumbler has joined #osdev
tixlegeek has quit [Quit: tixlegeek]
<mcrod> hi
skipwich has joined #osdev
joe9 has joined #osdev
<gog> hi
orccoin has quit [Quit: Leaving.]
<mcrod> gog may i hug you
<gog> yes
* gog hug
* mcrod hug
heat has joined #osdev
<heat> HELLO
<heat> netbsduser`, zid fyi that's not the BKL, but dcache_lock, which was a really big lock around the whole dcache that got torn down like 15 years ago
<zid> oh it's fucking written on him
<zid> bkl basically just continually split into smaller locks was my understanding
<heat> yeah
<zid> we now have big_kernel_dentry_inode_read_block_percpu_perbyte lock
<heat> oh, it's worse than that
<heat> dentry lookups are best case lockless
<heat> using r c u
<heat> ref-walk (the backup to the RCU walk) does use per-dentry spinlocks however
<zid> when are you inventing a new heatlock
<zid> there's a zidlist
<heat> erm, i dunno
<heat> i don't have good ideas for locks
Nixkernal has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<heat> maybe heatlock is just a no-op lock that doesn't do anything
<zid> no, it should be much more pessimal than that
Nixkernal has joined #osdev
<heat> your program scales perfectly until it crashes AKA NOT MY PROBLEM
<zid> a lock that assumes contention
<heat> heatlock() {usleep(rand());}
<zid> bogolock
<mcrod> i have another idea
<heat> is that idea "hi"?
<zid> mcrod lock, it's quadruple buffered and complains when you take the lock
<mcrod> heatlock() { hi_fo-
<zid> and complaints when you unlock it
<mcrod> i hate you.
<mcrod> i don’t complain that much
<zid> just like that yea
<zid> you already know all the words
<zid> I am the haskell of locks, I do no visible work but the cpu gets hot
Hammdist has joined #osdev
<ChavGPT> why are rb trees not named white-black :X
<heat> least racist pole
<ChavGPT> t in poland stands for tolerance
joe9 has quit [Quit: leaving]
edr has joined #osdev
dude12312414 has joined #osdev
arminweigl has joined #osdev
<mcrod> i’m bored
tixlegeek has joined #osdev
blop_ has joined #osdev
<ExclamationPoint> I think I found my new favorite IRC channel
blop_ has quit [Ping timeout: 252 seconds]
<GeDaMo> Which one? :|
ExclamationPoint has quit [Remote host closed the connection]
<gog> i'm struggling with react
<heat> dont use react
<heat> use angular
<heat> or electron
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<heat> use vue.js
<heat> use svelte
<heat> try polymer
<heat> haaaaaaaaave you tried flutter
<gog> i have to make it work with what we have i can't just rewrite everything this is real life heat
<gog> legacy and shit
<heat> you're not web deving hard enough
<heat> LEGACEY is C
<heat> rewrite in new thing is web dev
<gog> ok heat
<gog> i'll do it your way
<gog> i'll just fucking dlete it all and start again and my boss will have to deal with it taking a month
<heat> good
<heat> perdon jefe pero a mi no me encanta el reacción
<heat> if you want legacy you might as well use gets
<heat> gcc -traditional too
<heat> gosh why is gets so fucking stupid what were they on
<heat> read() takes a len, fread() takes a len, gets() doesn't
<bslsk05> ​i.imgur.com <no title>
<heat> fgets() takes a len
<heat> im gog
freakazoid332 has joined #osdev
<netbsduser`> c is a nice legacy which its authors have left the world
PublicWiFi is now known as SovereignCitizen
<ZipCPU> What do you think, C or C++ for OS development? I might argue C++ handles classes and objects better, both of which are required for OS development. Otherwise you have a lot of C structs with function pointers in them and ... that's just not that pretty.
<heat> they're both fine but C++ is harder to use properly
<ZipCPU> Go on .. ?
<heat> C is simpler hence less abusable
<ZipCPU> Are there particular features of C++ that are harder to use properly?
SovereignCitizen is now known as PublicWiFi
<heat> C++ has exceptions and RTTI and the C++ standard library
<heat> which are all unusable or unadvisable to be used
<heat> freestanding C++ headers are almost a no-show
<heat> like If You Know What You're Doing it's not a bad choice
xenos1984 has quit [Read error: Connection reset by peer]
<heat> but it is tricky
<ZipCPU> Yeah, I was wondering about how the exceptions would get handled ...
<heat> and then the typical C++ problems "don't abuse templates" and stuff, or you suffer the consequences of 40s file compile times
<heat> (overusing templates can also lead to code bloat, which isn't good for a kernel)
<gog> you can use exceptions in bare metal code bt you need a lot of support code
<ZipCPU> That's fair, but ... those templates do offer some very valuable capabilities. They'd be nice to have
<gog> and it's not performant
<gog> performant!!!
<heat> the only thing I'd ever miss from C++ in C would be RAII wrappers
<heat> because sometimes gotos get hairy and annoying
<gog> __attribute__((cleanup))
<heat> nothing in the C++ standard library is actually reusable in a kernel setting
<heat> you can __attribute__((cleanup)) my ass
<gog> fuck you heat
<heat> OH and lambdas too, lambdas are nice
<heat> fuck you gog
<gog> why are you being mean to me today
<heat> wdym
<heat> i'm being nice to you
<gog> :(
<heat> i searched for react alternatives
<heat> it's not easy
<heat> you should realize i got way too many results
<netbsduser`> ZipCPU: i opted for c and objective-c since message passing is integral to my kernel (e.g. in the i/o stack)
<heat> >objective-c
<heat> you're a funny individual
<netbsduser`> like many people i have experimented with C++ and enjoyed the experience, but i just can't keep track of that language at all
<heat> my C++ is very C-like anyway
<heat> im very very picky in what i like to use for C++, particularly in a low-level setting
<ZipCPU> netbdsuser`: Sigh. It has gone a bit off the rails with new features, now, hasn't it? I do like the basic class structure it offers though.
<heat> userspace is whatever, i keep exceptions on and std::vector that shit and whatnot
<heat> if it's not for its standard library i wouldn't really use it in userspace
<netbsduser`> there are a few things i quite like the look of in C++, like the way automatic variables invoke their destructor on scope exit (good for lock scoping and such)
<ZipCPU> I just feel that, when I develop my OS in C, I'm building C++ structures in a backwards manner
<heat> are we just skipping over the fact that YOU'RE LITERALLY USING OBJECTIVE C
<netbsduser`> and the coroutines would be useful (i have to hand-roll state machines for async i/o and the result is that i give up and post complicated things like disk fs reads to worker threads)
<heat> ZipCPU, yeah and that's fine
<heat> it also gives you *more control*
<netbsduser`> objc was a logical choice, i know the language, i once maintained and extended a compiler for it, and it gives me the meta layer that i like
<heat> netbsduser stole from apple which stole from netbsd
<heat> sgtm
<heat> ok heat@
<heat> oh and netbsd stole lua, everything flows back to lua at some point
<Ermine> gog: may I pet you
xenos1984 has joined #osdev
<gog> Ermine: yes
<gog> omg i found a way to make it work
<gog> yes
<gog> fuck yes
<gog> thanks for nothing #oswebdev
Hammdist has quit [Quit: Client closed]
* Ermine pets gog
* gog prr
<gog> thank you Ermine
<gog> you've been of great help to me today with pets alone
kof123 has joined #osdev
ExclamationPoint has joined #osdev
zxrom has quit [Quit: Leaving]
<Ermine> gog: you're welcome :)
blop_ has joined #osdev
Turn_Left has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
Hammdist has joined #osdev
<sham1> heat: could be worse, netbsduser` could be using swift
<ChavGPT> bro
<ChavGPT> netbsduser could be using netbsd
<ChavGPT> which i suspect they don't
* ChavGPT unpets gog
* Cindy pets gog :3
* ChavGPT unpets gog
<Cindy> my pets are unpettable
<Cindy> because my pets are owned by me
<sham1> Stop unpetting gog
<ChavGPT> and my pets cannot be masked
* Cindy pets gog
<Ermine> nodisard
* Ermine thinks of joke with 'Lego C' and 'legacy'
<gog> dw y'all template<> bool unpet<gog_t> { return true };
<gog> i cannot be unpetted
zxrom has joined #osdev
<mcrod> hi
blop_ has quit [Ping timeout: 252 seconds]
blop_ has joined #osdev
tixlegeek has quit [Quit: tixlegeek]
gog has quit [Quit: Konversation terminated!]
<Ermine> I think it's good idea to write stuff in c and making c++ bindings
* ChavGPT says FUCK IT and writes RUST
<GeDaMo> Why has C++ still not defined a standard name mangling?
<nortti> aren't there several in-use in the wild?
<GeDaMo> Is it not still compiler specific?
<nortti> I'd presume gcc and clang use the same mangling at least on popular targets like amd64 and arm64 linux
<netbsduser`> i experimented with swift but found it a bit of a hassle to figure out how to use swiftc in a sane, sensible way
gog has joined #osdev
jeaye has quit [Quit: WeeChat 3.7.1]
levitating has quit [Ping timeout: 264 seconds]
levitating has joined #osdev
jeaye has joined #osdev
tixlegeek has joined #osdev
<gorgonical> who knew that the virtio spec was designed decently, huh
<gorgonical> I spent all last night accidentally re-designing it while trying to avoid designing it
<gog> oops
<ChavGPT> :P
* ChavGPT pets gorgonical
<gorgonical> It happens I guess lol
<gorgonical> My notes: "I don't have time to implement virtio so I'll hack up something simpler as a proof of concept."
<gorgonical> oops
<netbsduser`> gorgonical: implement a storport shim and use the windows drivers if you really want to avoid it
<geist> yeah it's not bad
<geist> only thing i've seen that's 1 notch slightly better in the way it deals with command buffers is nvme
<geist> but i forget precisely what it was, but pretty similar when it comes to it
<geist> there's only so many ways to queue up little transfer block
<gorgonical> for now I have given up and have resorted to a 1-slot ring buffer that blocks when there's no slots left. Research :)
<geist> all this aside i do recommend writing a virtio library or whatnot to deal with the command queues, once you get that nailed you can pretty easily build a whole pile of pretty useful drivers
<geist> though of course only in emulators
<gorgonical> I don't know why I started with such an aggravating driver/service first
<gorgonical> I started with an mmap service so I have all these weird behaviors with zero-copy I'm tryign to design in from the get-go
<netbsduser`> virtio isn't so bad
<netbsduser`> for zero-copy it's ideal
<netbsduser`> and geist is right
<gorgonical> yes the scatter-gather thing is interesting
<netbsduser`> you implement it once and, by god, you have a fast path to 25 or so different devices
<geist> also notably vidro and nvme and whatnot are designed around having a minimum amount of doorbell writes, so the number of VM traps is at a minimum
<geist> iirc that may be the thing that nvme does one better. maybe one less doorbell? something like that
gog` has joined #osdev
gog has quit [Killed (NickServ (GHOST command used by gog`))]
gog` is now known as gog
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
<heat> yeha i mean not only vm traps
<heat> the more hw register writes the slower your request is (they're serializing, need to go through PCIe, etc)
MiningMarsh has joined #osdev
levitating has quit [Ping timeout: 244 seconds]
levitating has joined #osdev
FreeFull has joined #osdev
<heat> ChavGPT, fyi they're really wanting full PREEMPT solutions and want to kick cond_resched off of linux in the future
<heat> so your worst nightmare innit
Left_Turn has quit [Ping timeout: 240 seconds]
<ChavGPT> wut
<bslsk05> ​lore.kernel.org: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED - Ankur Arora
<heat> lots of reading to do
<ChavGPT> you do realize freebsd is liek this
<heat> like what
<ChavGPT> preemptible at any point
<ChavGPT> modulo when explicitly disabled
<geist> re that fixed preemption point thing i've never really considered it, and dunno if it's more or less a good idea nowadays
<geist> i've only ever worked with systems that are fully preemptible except where disabled
<geist> instead of the other way around
<ChavGPT> i think this boils down to how good your scheduler is
<geist> i had just learned that from beos. for better or worse, really
<heat> yeah i agree
<ChavGPT> i'm confident linux started like this because it is the easy way out
<ChavGPT> note same thing happened in unix
<geist> yeah i think that was also a fairly standard way to do it back in the 90s
<geist> being fully kernel reentrant would have been pretty edgy tech back then
<heat> i think it makes a lot more sense to have full preemption instead of sprinkling cond_resched() fucking everywhere in a stupidly unscientific way
<geist> *early* 90s too
Left_Turn has joined #osdev
<ChavGPT> i also note linux injects cond_resched by hand ot this very day
<ChavGPT> as in they keep getting reports of stalls without it
<ChavGPT> linux devs inject*
<heat> and for desktop, mobile, RT PREEMPT=y is freaking essential
<ChavGPT> pretty caveman
<geist> but i'm sure there are lots of scenarios where the full preemption is a hinderance
<ChavGPT> again i'm confident it boils down to your scheduler settigns mate
<heat> yeah i mean, on server workloads it's slightly worse for throughput
<ChavGPT> then you could tweak to "this is a server bro"
<ChavGPT> except scheduling keeps being bad
<Ermine> Injections of cond_resched are like slapping flex tape
<geist> you probably avoid a fair amount of lock contention which is the hidden cost
<heat> well yes but no
<geist> since you can hand tune exactly whre preemption happens you can avoid a fair amount of nested locks and whatnot situations
<heat> linux is like 80% spinlocks anyway
<geist> this is true
<ChavGPT> this one is not a problem dawg
<Ermine> heat: I used to run RT PREEMPT kernel with ubuntu, noted no difference
<ChavGPT> you can /count/ held locks
<ChavGPT> and decide whether to preempt based on it
<geist> well, if they're spinlocks. if they're preemptable style locks you have to deal with priority inheirance or whatnot
<heat> Ermine, probably not perceptible to a hooman no
<heat> but there absolutely will be throughput differences
<ChavGPT> they are all spinlocks cause it was the easy way out
<ChavGPT> note they are defo not spinlocks when running with the rt patchset
<heat> throughput will be ordered like: PREEMPT=n > PREEMPT=y > RT_PREEMPT
<geist> yah for better or worse i never design systems that way, i tedn to build kernels as sort of an extension of the user space programming model
<ChavGPT> you know who did that?
<geist> ie, mutexes, full preemption, threads in the kernel, as if they were a user process somewhat
<heat> mutex_enter!
<ChavGPT> no joke, a positive remark:
<ChavGPT> they have full prio propagation throughput userspace locks to in-kernel mutexes
<ChavGPT> thorought
<heat> but yeah spinnies are not spinnies in RT, raw spinnies are still spinnies though IIRC
<geist> sure. that's not a particularly unique design
<Ermine> and fedora's kernel is PREEMPT_DYNAMIC
<geist> lots of systems are fully preempt like that. it's the only way i really ever do things, seems natural to me
<ChavGPT> i have no opinion
<heat> Ermine, that's funny, they discussed it in that thread i linked
<heat> PREEMPT_DYNAMIC still has unconditional preempt count maintenance
<heat> the only thing patched out by default is the actual preemption code
<ChavGPT> linux preempt code is a total f-worded mess anyway
<ChavGPT> they have 2 different ways to check for it and they are not compatible afaics
<ChavGPT> also __might_sleep checks if you can sleep
<geist> yah seems like a lot of this, and the maintenance of the 3 separate mechanisms always seemed like it works well due to sheer force of will
<ChavGPT> but __might_resched PERFORMS THE RESCHED
<ChavGPT> gg
<heat> yeah thats weird
<ChavGPT> i *suspect* this is to reduce the number of hand-rolled cond_resched's
<Ermine> so, how desktop is supposed to benefit from rt?
<heat> you're not
<heat> RT isn't for desktop
<ChavGPT> better interactivity mon
<ChavGPT> well in this context i think the q is about preemption
<ChavGPT> not rt guarantees
<heat> RT is for realtime systems, industrial shit and whatnot
<Ermine> > and for desktop, mobile, RT PREEMPT=y is freaking essential
<geist> also very low latency stuff like this can help for things like audio mixing and whatnot
<geist> which linux has been traditionally bad at
<heat> Ermine, sorry, my bad
<ChavGPT> ye i poked on linux a bit in recent days
<heat> I meant RT/PREEMPT=y
<ChavGPT> i'm very negtiavely surprised by the internal state
<heat> PREEMPT=y is perfectly great for desktop and mobile
<ChavGPT> tons of churn all over adn total crap remains intact
<heat> yes
<ChavGPT> :O
<heat> i picked that up from the osdev wiki/general osdev wizardry knowledge early on
<geist> like i said it's not that weird to have a fully preemptable/reentrant kernel. if you design it that way from the get go it makes sense
<heat> and i like it
<heat> the only thing is that i do abuse spinlocks
<geist> you can later on add preempt_disable/enable via some counters or whatnot to avoid some negative cases, but by default having it on is a fine solution
<geist> also for SMP
<heat> and i still don't have a preemptible RCU
<ChavGPT> ya sak bro
<ChavGPT> geist: arguably you run into the opposite case than linux
<ChavGPT> preemptible lock have the problem of degrading into next to no throughput
<geist> indeed
<geist> that's the fun part
<heat> what
<heat> that's the unfun part
<ChavGPT> *un*
<ChavGPT> too much netbsd heat
<heat> defun
* heat turns into a legacy K&R C codebase
<ChavGPT> noice
<heat> or lisp
<heat> but lisp is irrelevant
<ChavGPT> btw do you know what one of the biggest bottlenecks is on linux
<ChavGPT> when doing make -j $BIGNUM bzImage?
<ChavGPT> same shit as on freebsd!
<ChavGPT> fucking pipe poll handling
<ChavGPT> which on freebsd gets even worse cause preemptible
<heat> cheers geoff
<ChavGPT> btw i figured i'm going to patch bsd make to use eventfd instead
<heat> pipe_poll is lockless btw
<ChavGPT> and then i figured i'm going to patch gnu make to do the same
<heat> why eventfd?
<ChavGPT> but then i remembered gnu make advertises "jobserver" outside of itself
<ChavGPT> so the idea does not work
<ChavGPT> heat: after you poll and find nothing you queue yourself up for sleep 'n shit
<heat> just use epoll
<ChavGPT> there is a patch to use kqueue for bsd make
<ChavGPT> it does help but not anywhere near as much as necessary
<heat> given the pipe_poll impl is lockless it *should* eliminate all problems
<ChavGPT> one thing you are probably not aware of here is how stupid the make's of the world are about the pipe
<heat> if not, you're screwed
<ChavGPT> ultimately using pipe here is an obsolete model to begin wit
<ChavGPT> with
<heat> unix tradition!
<heat> go write win32 code if you don't want pipes
<bslsk05> ​learn.microsoft.com: Named Pipes - Win32 apps | Microsoft Learn
<ChavGPT> do you know what ntebsd has
<ChavGPT> unnamed pipes
<ChavGPT> :X
<heat> WHAT
<heat> shame that linus torvalds invented fork()
<ChavGPT> knowing openbsd if they had to invent in the area it would be trident
<ChavGPT> like fork, except you spawn one extra to waste more time
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<heat> like fork but you wait politely for the child
<heat> oh wait!
<Ermine> no, those people like fork too much
<Ermine> so they made the most pessimal posix_spawn implementation possible
<Ermine> heat: is scoped_mutex taken once it's created?
* kof123 makes note trident sounds awesome
<heat> Ermine, yep
<heat> it's just a RAII wrapper
<Ermine> Also, what is the difference between filp-f_flags and flags argument of read_iter?
<Ermine> regular read doesn't take flags argument
<heat> f_flags = flags passed on open()
<heat> read_iter's flags are a no-op atm I think
<heat> yeah
<Ermine> oookay
<bslsk05> ​github.com: Onyx/kernel/kernel/fs/pipe.cpp at master · heatd/Onyx · GitHub
<heat> not really
<heat> can_read_or_eof() may just be true because of eof, so you fall on if (!can_read()) again
<Ermine> oic
<Ermine> Ah, actually I thought that this continue was in the end of the cycle
danilogondolfo has quit [Quit: Leaving]
cloudowind has joined #osdev
* cloudowind greets everyone
<netbsduser`> Ermine: this is always an odd one
heat has quit [Remote host closed the connection]
heat has joined #osdev
<netbsduser`> some people implement posix_spawn as nothing but a cheap, fake, plastic wrapper around fork
<netbsduser`> and then they complain it's "slower than fork"
<heat> OPENBS
<heat> D
<heat> linux uses clone
<heat> i hope freebsd uses rfork but i never checked
<heat> yeah htey use rfork
<netbsduser`> does linux avoid the hateful savaging TLBs and page tables without mercy?
<ChavGPT> it is doing rfork-like behavior
<bslsk05> ​grok.dragonflybsd.org: posix_spawn.c (revision 1d386b48) - OpenGrok cross reference for /freebsd/lib/libc/gen/posix_spawn.c
<heat> netbsduser`, yes, they use clone
<ChavGPT> mate, of all the systems, you expect linux to have it slow?
<netbsduser`> ChavGPT: yes
<ChavGPT> are you for real mate
<ChavGPT> are you larping 00s?
<ChavGPT> linux is the least non-scalable kernel for over a decade now
<netbsduser`> it takes time to outgrow old bad decisions
<heat> linux uses clone(CLONE_VFORK | CLONE_VM) while setting the stack in assembly
<heat> this is all in userspace
<heat> freebsd's solution is also entirely in the libc with rfork
<ChavGPT> see the above remark
<heat> netbsd has a syscall I think? weirdos
heat has quit [Remote host closed the connection]
<ChavGPT> syscall is the right choice
<ChavGPT> even if it ends up doing vfork
<Ermine> netbsduser`: such an implementation is pointless
<ChavGPT> Ermine: openbsd has one
<ChavGPT> :d
<netbsduser`> Ermine: what, an implementation in terms of fork()?
<Ermine> Yes
<netbsduser`> that regrettable choice is what openbsd made
<Ermine> in the other news, a new guy in #minix really wants clone() in minix
heat has joined #osdev
<netbsduser`> by god, minix has not seen a new commit in over 5 years
<ChavGPT> :)
<netbsduser`> if he wants it so much he should send his life savings to Andrew Tenenbom
<heat> ChavGPT: i don't think it should be a syscall
<heat> it's too complicated
<ChavGPT> look fuckwadddD
<heat> doing it in the libc is fiiiiiiiiiine
<ChavGPT> a day may come where it is reimplemented to be fast
<ChavGPT> then there wont be a need to fuck with userspace binaries, it will just work
<ChavGPT> you can hide it in vdso for the time being, point is to have it in a way which can be optimized
<ChavGPT> without having everyone update their libc, which they wont
<heat> it's too complex for the vdso
<heat> if you're already putting it in the vDSO you might as well do an actual syscall
<ChavGPT> now im mildly curious how it looks like in net
<ChavGPT> it is guaranteed to be slow, but maybe it is not complicated
<heat> Ermine: clone is really nice btw
<ChavGPT> you need your taste checked mate
<bslsk05> ​github.com: src/sys/kern/kern_exec.c at trunk · NetBSD/src · GitHub
<heat> ChavGPT: what's the problem with clone
<heat> "it's not rfork" is not a problem btw
<ChavGPT> it's a tumor on the old hack
<ChavGPT> people did not have threads, only processes
<ChavGPT> then they added threads as special-cased processes
<heat> well, yes but no
<ChavGPT> this is your rfork and clone
<heat> 1) it's not required
<heat> 2) i've grown to somewhat enjoy that threading model
<ChavGPT> i am saying clone is a result of histerical problems
<heat> even if its somewhat hacky
<netbsduser`> threads aren't special cased on netbsd
<ChavGPT> which went unfixed
<ChavGPT> and are probably unfixable
<netbsduser`> the traditional process/thread separation is implemented as proc/lwp
<ChavGPT> netbsduser`: they are not special cased on freebsd and solareis either
<netbsduser`> ChavGPT: it is known
<ChavGPT> it is mostly linux which never fixed that
<netbsduser`> they say on gnu/linux they used to have an elaborate system of tricks in glibc to implement green threads that acted as best as they could as true threads
<netbsduser`> this solution involved much signals and other such things
<ChavGPT> mate early linux was a clusterfuck of epic proportions
<netbsduser`> supposedly they never solved the problem of how to make a synchronous system call without blocking the whole set of fake threads
<ChavGPT> today it is half whiped into shape
grumbler has quit [Quit: It's time]
grumbler has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 246 seconds]
<cloudowind> whenever i need to turn left i will remember you Turn_Left
FreeFull has quit []
<Turn_Left> sure thing cloudowind :) ... off to bed... night :)
Turn_Left has quit [Read error: Connection reset by peer]
<Ermine> heat: probably, but it'll be major change to minix process model anyway
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
goliath has quit [Quit: SIGSEGV]
<ChavGPT> who is proposing
<ChavGPT> and more importantly why would you even do it
* cloudowind wondering if tanenbaum still alive
<Ermine> but at this point any movement forward would require major changes
<Ermine> cloudowind: he is
<cloudowind> good thing then
<Ermine> ChavGPT: one guy likes it and he wants to do this
<ChavGPT> is that an established contributor
<Ermine> No
<ChavGPT> ye did not think so
<ChavGPT> fuck him
<ChavGPT> is my professional opensource dev opinion
Burgundy has quit [Ping timeout: 248 seconds]
<Ermine> so far there's more talks than deeds, so I'll just watch
MiningMarsh has joined #osdev
<cloudowind> Ermine: his os book was my first os book that i bought like 20 years ago
<cloudowind> then i oepned #minix on freenode
<ChavGPT> Ermine: this is one known problem iwth users
<ChavGPT> another one is complaining about "removal of working code"
<ChavGPT> usually happens when you drop something obsolete for 10 years and not even working for 8
<Ermine> Maybe it worked for that one...
<ChavGPT> probably not mate
<ChavGPT> there is a contingent of people who like to argue against change
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
terrorjack has joined #osdev
netbsduser` has quit [Remote host closed the connection]
netbsduser` has joined #osdev
tixlegeek has quit [Quit: tixlegeek]
\Test_User has quit [Quit: \Test_User]
\Test_User has joined #osdev
gog has quit [Remote host closed the connection]
gog has joined #osdev