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
<heat> we could live in a world of limited unlimited extensibility
<geist> i dunno, in the twenty something years i've been here no one has ever spoken ill of solaris until recent
<zid> because nobody cares about it
<geist> at least not consistently. i remember some grumblings about having to administer a bunch of them
<zid> (because it's bad)
<mjg_> geist: in my youth i used to follow pl.comp.os.advocacy
<geist> but the general idea was they're fairly solid machines at the time
<geist> if not pricey
<mjg_> geist: non-linux systems, most notably oslaris, kept being shat on a lot
<geist> yeah which is IMO lame. shitting on things is like level 1 discussion
<zid> we were all too busy shitting on windows previously
<geist> anyone can do it, it's what people do when they have nothing else to do
<geist> or anything more interesting to contribute
<mjg_> point being it was spoken ill of
<heat> haha m$ windoze bad
<mjg_> heat: high school me would shit on windows a lot man
<geist> oh yea i was talkinga bout in *here*, as in osdev
<zid> developers developers develoeprs
<mjg_> geist: oh ok
<geist> and yeah i participated in shitting on windows a lot back in the 90s too
<geist> M$FT was the bad guys
<heat> ballmer's peak was wrong all along because he used coke, not alcohol
<geist> microsloth winblowz, etc etc
<mjg_> $ sign mandatory
<geist> was of course part of the reason i joined up with Be and worke don BeOS
<geist> down with microsoft!
<mjg_> f-you bill
xenos1984 has quit [Read error: Connection reset by peer]
<heat> how many beekeepers have tried to hire you over the years
<heat> "you worked with bee? yeah we work with bees a lot here"
<geist> i like bees
<geist> i'd like to keep some bees
<mjg_> bees? geez
<geist> bees are good
<kof123> "anyone can do it, it's what people do when they have nothing else to do" eh, i always wonder where did these ppl work as CEO and management where their word got to choose what is used? i always put them in "noob" category until further evidence lol
<heat> hmmm idunno man
<heat> they sting
<geist> kof123: oh heh there's no requirement you know what you're doing when you're a CEO
<kof123> really, there's a sysadmin company, running the show?
<kof123> not dictated by application requirements?
<heat> except pat gelsinger
<heat> and lisa su
<geist> I guess what i was really making a point is i pride myself a but on this channel at least having a more ... refined discussion of these opics
<zid> that's why mjg is ceo of poland!?
<geist> topics. shitting on things is easy but doesn't bring anything to the table
<heat> and the man himself mr leather jacket
<geist> unless it's reasoned and interesting
<kof123> the wise man will find magical osdev powder in dos, while the fool will not believe it exists in plan9
<kof123> change to suit tastes lol
<heat> i find the plan9 circlejerk mildly annoying
<zid> when am I allowed to dereference pointers to structs with incomplete members in normal C though
<mjg_> geist: well, modulo certain language choices, i'm pretty sure i can make a solid case for solaris not living up its scalability hype even when adjusted for whatever time period
<zid> godbolt needs to add plan9 so I can try it
<mjg_> :>
<geist> yah it has generally speaking gone away. the plan 9 thing was super strong in the late 90s/early 2000s
<geist> mjg_: sure but then so what?
<geist> well i mean it's okay, just trying to balance things a bit
<mjg_> another me, not familiar with solaris, but familiar with the hype, would find it of interest
Matt|home has joined #osdev
<heat> solaris in 2000 scaled better than net or openbsd right now
<heat> osdev hottakes
<mjg_> than open? probably true
<geist> yeah it's basically different expectations
<geist> also nothing else ran on the same hardware at the time, so in general you needed solaris to get advantage of the hardware you bought (some bigass sparc box)
<geist> so there was nothing to compare it with
<geist> ergo it was more scalable than anything else on the same hardware
<geist> since it was a sample size of 1
<zid> It was the worst OS though
<zid> slowest, largest install, biggest memory footprint
<zid> most crashy
<geist> that's not generally what i remember folks saying at the time
<mjg_> geist: you could still aks if it was making good use of it, which would be answerable with a profiler :>
<mjg_> you doing your 20% in marketing dept ?:)
<geist> in general i remember it being expensive to own the hardware but if you needed it you needed it
<zid> sadly it was also the fastest, smallest install, least memory footprint, and least crashy
<zid> via that same sample size
<geist> and then you put what ran on it because that's what you did. you couldn't directly compare it
<geist> oh heh okay i get your point zid
<mjg_> i don't know if the old time solaris was stable
<geist> i mean i dont know why i'm defending 90s era solaris, i just generally believe it wasn't terribad at the time, and it's a bit unfair to judge things back then based on modern ideas
<mjg_> i definitely give them props for cming up with dtrace
<mjg_> not necessraily dtrace as it came out, but a productoin quality instrumentation framework
<mjg_> years before linux
<mjg_> which already had way more manpower
<geist> hell go back to the mid 80s. there were MP machinse that were AMP. by definition that's terrible by todays standards
<heat> haha ebpf go brrr
<kof123> well i think tehre was also (right or wrong) bsd linux etc. are hobbies and not Real Enterprise Unix (TM)
<zid> asymmetrical multipajillion dollar servers
<mjg_> geist: 2010 solaris was also crap, so... :)
<kof123> *perception that
<geist> mjg_: i'm fairly certain by the late 2000s solaris had peaked. i'm not interested in defending that era solaris
<geist> it was aready dead by then
<mjg_> kof123: ye there was also a lot of shitting of REAL UNIX admins on the linux and bsd crowd
<geist> the rigor mortis started setting in in the mid 2000s, especially x86
<heat> communist unix >> enterprise unix
<geist> i'm thinking more back in the 90s when it was The Solaris that ran on big sparc boxes
<zid> communist unix is my favourite unix
<heat> those damn socialists with their GPLv2 and their patch sharing and their pansy-ass forking
<geist> i think it's only really fair to compare it up to the point at which it peaked and then from then on out it was not catching up
<geist> and i'm not sure it ever ran that well on x86. aways a problem for things that lived on non x86 then had to switch to it at the last minute. aside from maybe OSX that almost never works
<mjg_> geist: i do note there were claims of > 100 thread scalability in mid 2000s or so
<geist> okay fine. i've said my peace
<mjg_> and i said mine
<geist> why i'm defending this i dont know. i really dont care about solaris much at all
<heat> life is about conflict
<geist> anu more than AIX or HPUX or TRU64 or whatnot
<heat> red vs blue, linux vs bsd, solaris vs mjg
<geist> haha
<mjg_> would be fun to get an old commerical unix operational
<mjg_> and bench
<geist> i mean like i could run solaris 2.7 on my sparcstation 20
<heat> you know there are unixware images out there
<geist> works okay.
<mjg_> imagine booting the different systems which support, say, vax
<mjg_> and bench them
<mjg_> :)
<geist> sure.i have a microvax, it runs things
<geist> i have a VMS install and a netbsd install
<zid> Nobody bought me a pencilcase with the xeon logo on it again this year
<geist> answer is: it's hella slow
<zid> try again next year
<mjg_> i have no clue about vms
<geist> but thats what 1990 era machines were
<mjg_> is there a way to write a bench which would be fair vs unix?
<geist> depends on what you're trying to bench
<geist> and probalby not, not
<geist> and probalby not, no
<mjg_> say open, reading and closing a file
<heat> we've established that isn't fair
<mjg_> vs vms?
<heat> (see winblows)
<mjg_> well ye, part of it would be finding out what profilng tooling is avaiable (if any)
<heat> microshit winstupid was designed by the same guy
<geist> it'd probably be slower i suspect. but then it also depnds on what unix you compare it with. may be that VMS is actually more clever about caching
<mjg_> and getting said profile
<mjg_> mroe interesting than whatever numbers come out
<geist> i mean if you run a mid to late 80s unix you're not exactly going to be in the same ballpark as modern stuff
<heat> did you see the sysv unix profiling article i posted a few weeks back?
<mjg_> geist: i guess a fun test wold be just syscall performance
<geist> ie, filesystems were generally intriniscally synchronous, etc
<mjg_> heat: i don't think so
<geist> so it's possible VMS would actually do better, since t had a big iron journalled fs, etc
<mjg_> do you know what would be a dirt cheap syscall to call?
<mjg_> a'la getpid, getuid etc
<geist> yeah but what's the point of doing that? you're just testnig the hardwares ability to syscall?
<mjg_> you don't think the way systems implement it may affect perf?
<geist> not when the systems are wildly different
<geist> what if, for example, syscalls were 20% more expensive on system A than B, but system A's syscalls allow you to make 50% less of them to accomplish the same task
<mjg_> i don't buy that bit for a bare minimum syscall (so to speak), provided one exists
<geist> most likely the only really interesting benchmarks on two wildly different systems are high level things, like some database's ability to serve data, etc
<bslsk05> ​ieeexplore.ieee.org: A performance study of the UNIX® System V fork system call using CASPER | Nokia Bell Labs Journals & Magazine | IEEE Xplore
<heat> here's the cute profiling system they got
<geist> sure i mean you can test the bare minimum syscall but it's such a microbenchmark it doesn't really mean much except to establish the baseline for the cost of a syscall
nyah has quit [Quit: leaving]
* kof123 .oO( sees a MISS metric, millions of syscalls/second )
xenos1984 has joined #osdev
* kof123 .oO( that was sarcasm, second geist's comments )
<mjg_> geist: well the problem with somerthing bigger is that you can easily argue that the software at hand does not utilize the sytsem in an optimal manner
<mjg_> and so on
<geist> in the case of comparing unices i think the syscall stuff makes more sense, because yo can generally assume that between any two unix oses the number of syscalls is roughly equivalent
<mjg_> basically anyhting non-trivial is a huge problem to compare
<geist> yeah
<mjg_> heat: oh, schimmel
<mjg_> 's actually may be good
<geist> i mean i'm all for benchmarks. you just have to be careful what you read out of em. i think when comparing linux systems or even linux to bsd or whatnot it is a fairly level playing field, so folks have gotten used to the notion that any benchmark is valid
<mjg_> did they?
<mjg_> most benchmarks happen to bei nvalid :p
<geist> but i've also seen microbenchmarks misused constantly, so i'm always aware of making sure the context is fully known
* mjg_ glares at phoronix
<geist> sure. ie, bad benchmarks
<geist> but... you did at least get me interested in how fast my vax can context switch, but most likely since it's a low end vax from the late 90s, it's slow as hell
<geist> much like if you go to say a 386 or 486 and read the cycle count for things you'll be aghast compared to modern stuff
<geist> one did not generally use IPC as a number, it was CPI
<mjg_> you reminded me of alpha
<mjg_> in my youth i heard running i386 binaries on it would kick ass
<mjg_> excellent claim to test
<heat> i heard running i386 binaries on itanium would kick ass
<heat> excellent claim to test
<geist> yes alpha no itanium
<mjg_> i never heard anyeone sayanything positive about itanic
<mjg_> maybe apart frmo it being gone now
<heat> new 64-bit architecture by intel? more low level so compilers can take advantage of it? what can go wrong
<geist> the x86 emulator on alpha DEc had written was fantastic. and since early alphas came out the gate really kicking ass they had the headroom
<gog> it was a cool architecture with good ideas
<mjg_> so that was real?
<mjg_> sounded highly suspicious
<geist> itanium had native x86 compatibility for a few revisions, but it was dreadfully slow
<kof123> are you guess talking alpha nt running x86 stuff, or for other os?
<geist> i think more useful for running bioses and whatnot
<heat> the itanium manual says we'll stop using 4KB pages in a few years
<klange> > mjg_ glares at phoronix
<klange> I miss the days when Larabel wrote articles about my OS.
<geist> yes i've personally seen it. NT for alpha could run x86 binaries, and it did it quite well
<mjg_> klange: ? :DD
<heat> oh shit re: phoronix do you want to see the clickest bait article
<mjg_> klange: i guess i don't want to know
<gog> i do
<bslsk05> ​www.phoronix.com: Linux TUN Network Driver May See A "1000x Speedup" With New, One-Line Patch - Phoronix
<mjg_> heat: the clickbait is from the commit though
<mjg_> so not his fault on this one
<geist> "hey i'm just passing the clickbait on!"
<klange> mjg_: He wrote three articles - in 2014, 2016, and when 1.0 was released in 2017, and they were all quite nice! And he took his own screenshots so I know he actually used it.
<mjg_> klange: well let me tell you one anecdote real quick
<mjg_> klange: i was hanging out on #dragoflybsd and prodded dillon about something, then he did it that evening or so
<mjg_> klange: soon after there was a phoronix article claiming dillon reacted to *their* feedback
<mjg_> :)
<heat> and as you and dillon made fun of both phoronix and openbsd, you and him locked eyes, the love was in the air, as you started passionately making out
<kazinsal> I like reading Phoronix's benchmarks for new CPUs because they tend to be wildly different from other benchmarks because most of their testing software is so terribly specific that the benchmarks end up being meaningless
<heat> ok fuckers, a real osdev question now
<heat> how do you effectively quarantine memory in an allocator
<zid> free it
<gog> quarantine as in it might contain sensitive information?
<kazinsal> "hmm yes I'm going to get the new Ryzen 6969X instead of the Intel i9-1337KF because it's 2% faster at LZMA decompression" said no one ever
<zid> I thought he meant badblocks it
<heat> quarantine as in "avoid giving it back to the caller as much as possible"
<heat> for ASAN
<gog> kazinsal: i was saying because it's 2% faster at LZMA
<kazinsal> >:(
<gog> heat: least recently used
<heat> yea but what's the heuristic
<gog> idk
gxt has quit [Remote host closed the connection]
<heat> you know, maybe you could do something stupid like using up 64-bit virtual memory and avoiding reuse until you really needed to
epony has joined #osdev
<heat> but then shadow memory is an issue, hmm
<gog> no use as little of the address space as possible
<gog> never map anything
<heat> i know that's a joke but it's genuinely the objective eventually
<heat> just use the direct map and an allocator based on friendship
<gog> yes
<heat> or comradery if you're in commie unix
<gog> worker threads of the world unite
<pounce> heat: don't think you'd need a heuristic for this
<pounce> just write the empty page table entry with a quarantine flag
<heat> what empty pte
<heat> i give out chunkz in alloc()
<heat> i get chunkz back in free()
<heat> i want to avoid giving back the same chunk(z) in alloc while not increasing memory usage by a shitton
<mjg_> avoid or postpone
<pounce> err, is this malloc?
<heat> yes-ish
<heat> slab
<pounce> ahhh
<pounce> sorry thought virtmem
<heat> but the point stands for any allocator
<heat> well, i can play around with virtual memory
<heat> that's the nice part about am become the kernel, the destroyer of worlds
<mjg_> free to a dedicated bucket
<mjg_> and dn't alloc from it
<mjg_> when the time comes you need a newb ucket to alloc from, pick oldest unused free bucket
<mjg_> as your new alloc bucket
<pounce> heat: do you only care about sequential alloc() free() alloc()? when would you be ok about getting the memory back
gxt has joined #osdev
<heat> when i really need to
<pounce> and you would rather fragment first?
<heat> but then again i could probably get to allocate some pages from the allocator and keep the memory quarantined in a kasan build
<gog> just grow the heap's vm size forever
<gog> pick random addresses in the heap
<heat> yes
<pounce> you could map the heap's physical mem to multiple virtmem locations
<heat> as i was saying, that's not a bad idea
<pounce> and then always give out the subsequent location
<gog> yes balloon your page tables
<pounce> :p
<heat> like if I had the guarantee the slab is at least 8*page_size sized, this would easily work
<gog> give all your applications huge pages
<heat> free slabs would get freed and the virtual memory would remain delay-freed, and its shadow backing would get replaced by a page full of "FREED" bytes
<pounce> this sounds like a skill issue
<pounce> why not just stop reusing pointers
<heat> great idea
<heat> this will never be an issue if you never reuse anything
<heat> unlimited memory ftw
<pounce> sorry, I've run out of useful ideas :p
<gog> i don't have useful ideas
<gog> i'm a cat
* pounce pounces
<heat> ah ok the comrades seem to have a 1MB quarantine size + a percpu 1MB quarantine
<heat> idea being that kmem_cache_free "frees" objects to this quarantine which sit until you actually free them
<heat> due to the q overflowing or memory getting tight
<heat> stupid sexy linux
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
dennisschagt has quit [Quit: No Ping reply in 180 seconds.]
dennisschagt has joined #osdev
* moon-child pets gog
MiningMarsh has joined #osdev
<klange> Okay, binutils cross-built... gcc, though, is missing a few things...
<klange> Going to need to get libstdc++ built, in particular - I removed it from my normal toolchain a long time ago, since none of my own stuff was C++ :)
<klange> > /bin/bash: ../libtool: No such file or directory
<klange> whyyy
<klange> how did you fail to produce a libtool for this...
valerius_ has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
gildasio has quit [Ping timeout: 258 seconds]
gildasio has joined #osdev
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
terrorjack has joined #osdev
heat has quit [Ping timeout: 240 seconds]
<klange> why the !@#$ do i have ilp32 multilib builds enabled for my aarch64 stack, I don't use that shit...
<klange> and then none of it works
<geist> yeah i get the vibe that ilp32 is not getting that muh love
<CompanionCube> isn't aarch64 ilp32 just armv7?
<CompanionCube> (renamed to aarch32, of course)
gildasio has quit [Ping timeout: 258 seconds]
gildasio has joined #osdev
gxt has quit [Ping timeout: 258 seconds]
<klange> I think I will just... not block the 2.1 release on having gcc for aarch64 packaged, because ugh. I'll revisit this later. It's not like these aarch64 builds are useful on real hardware, so having an independent compiler toolchain isn't high priority - you want to code, use Kuroko.
gxt has joined #osdev
<klange> I'll finish package SDL1.2 + sdlquake, the doomgeneric build, and maybe dash (which I just packaged for x86-64)... I'll see if mupdf builds later this afternoon as well...
gog has quit [Ping timeout: 250 seconds]
mavhq has joined #osdev
gxt has quit [Ping timeout: 258 seconds]
gxt has joined #osdev
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
scoobydoob has joined #osdev
scoobydoo has quit [Ping timeout: 240 seconds]
scoobydoob is now known as scoobydoo
bgs has joined #osdev
epony has quit [Ping timeout: 252 seconds]
<geist> CompanionCube: no not at all. it
<geist> it's the arm64 instruction set but with all the addreses limited to 32bit. just like x32 or whatever people call it
<geist> but the ARM64 ISA is definitely different from arm32/thumb2
epony has joined #osdev
bgs has quit [Remote host closed the connection]
Burgundy has joined #osdev
<CompanionCube> geist: wait there's genuine toolchain support for that? huh
<CompanionCube> i knew it was a thing but i would have thought 'ilp32' was something more common
<klange> And unfortunately it seems to be enabled by default 'cause I know I didn't specifically include it when configuring my aarch64 targets...
<klange> Maybe it's time for a full toolchain update...
<CompanionCube> the only other time i heard of 'x32 for aarch64' was a unmerged patch to support it on linux like x32 is supported
<klange> I am on gcc 10.3, which was outdated almost immediately after I started using it because 11 came out
<geist> yeah we've talked about it a bit for fuchsia from time to time, but i think clang/llvm has some work
wand has quit [Ping timeout: 258 seconds]
Burgundy has left #osdev [#osdev]
<CompanionCube> seems kernel still doesn't do it, and i don't think glibc does either
<geist> yah not sure it's getting a lot of love. may not be as big of a win as x32 (if x32 is that much of a win)
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
<klange> I did a reconfig with --disable-multilib and I seem to have been successful in building libstdc++, and now my cross-compiled compiler build also looks to be progressing...
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
m5zs7k has quit [Ping timeout: 250 seconds]
m5zs7k has joined #osdev
wand has joined #osdev
gxt has quit [Ping timeout: 258 seconds]
<klange> I tell this to build shared... and I swear these are all still statically linked to libstdc++ and... ugh. whatever
<klange> I blame libtool, probably sitting there saying it doesn't know how to do that...
SGautam has joined #osdev
<klange> Well that was a pain in the ass, but we got there in the end!
<klange> It did not install any of the crts or libgcc but that's probably my fault, so I just copied them from the host build, and I did need to do one other thing to get gcc to build for an aarch64 host - tell it to include driver-aarch64 which it only does by default on linux/bsd/fuchsia (lol)
<klange> (despite calling a function in that that isn't guarded behind the same conditions)
gxt has joined #osdev
ChinUndercover has joined #osdev
GeDaMo has joined #osdev
scoobydoob has joined #osdev
gog has joined #osdev
scoobydoo has quit [Ping timeout: 240 seconds]
scoobydoob is now known as scoobydoo
<geist> ooooh so you are running with arm64 ilp32?
<klange> no, I am not
<klange> but it wanted to build for it by default anyway, among other issues
ChinUndercover has quit [Ping timeout: 272 seconds]
gorgonical has quit [Remote host closed the connection]
Burgundy has joined #osdev
epony has quit [Ping timeout: 252 seconds]
Rubikoid has quit [Ping timeout: 260 seconds]
kof123 has quit [Quit: Leaving.]
epony has joined #osdev
Rubikoid has joined #osdev
hmmmm has joined #osdev
gildasio has quit [Remote host closed the connection]
<klange> packages uploaded, minor changes pushed, cdn cache purged
gildasio has joined #osdev
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
fatal1ty has quit [Read error: Connection reset by peer]
epony has quit [Remote host closed the connection]
epony has joined #osdev
epony has quit [Max SendQ exceeded]
epony has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
Matt|home has quit [Ping timeout: 272 seconds]
epony has quit [Client Quit]
epony has joined #osdev
gog has quit [Quit: byee]
fatal1ty has joined #osdev
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
gildasio has quit [Remote host closed the connection]
Ram-Z has quit [Ping timeout: 272 seconds]
[itchyjunk] has joined #osdev
epony has quit [Remote host closed the connection]
epony has joined #osdev
Ram-Z has joined #osdev
gildasio has joined #osdev
pbx is now known as pbx_linux
pbx has joined #osdev
<pbx> hello all :)
<pbx> sending this from my OS
<zid> neat
<pbx> my TCP implementation is still pretty half-assed, but aparently good enough to join an IRC room
<j`ey> pbx: ping
<fatal1ty> he`y
<j`ey> hi
<pbx> does look like it drops some messages on the floor, but that might be the crappy client
eroux has quit [Ping timeout: 272 seconds]
<zid> channel :P
<pbx> specifically can't see j'ey's messages
<zid> haha
<zid> test
<zid> I wonder if it's the backtick
<j`ey> pbx: wait actually?
<pbx> yeah
<j`ey> happy to be a test case
<pbx_linux> test
<pbx_linux> test 1'2
<zid> doesn't respond to ctcp either
eroux has joined #osdev
<zid> :bob!bob@bob.com PRIVMSG #osdev :testing for this specific parse bug
<zid> non-greedy parsers can fall for that one occasionally
<pbx> seems like theres definitely some flaking going on
<zid> missing random messages, j`ey just happened to trigger them by chance?
<pbx> can't imagine it actually being in the TCP as that would probably result in desynchronization entirely
<pbx> i think so yeah
<pbx> although there's definitely parsing weirdness too
<pbx> (i quickly ported irc.c, a very simple curses irc client)
<zid> nice monitor
<pbx_linux> ?
fatal1ty has quit [Quit: gotta go ..]
<zid> 2766x1614 at least
<pbx> yeah, 4K
<pbx> got a downside too: it forces me to use truetype fonts
<zid> that's a downside?
<pbx> (i had been using a MS Sans Serif ported to X11 font for crisp small fonts on my old hd laptop)
<pbx> (i hate the fuzzy edges on modern font rendering)
<zid> I love AA'd fonts, I hate cleartype though
<zid> who doesn't want rainbows
untitled has joined #osdev
wolfshappen has joined #osdev
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
<pbx> i'm pretty happy with having TCP working to this extent already
<pbx> and stable enough that i've been in this room for about 15 minutes already
<pbx> no panics, no connection drops
<pbx> this is only the second outbound connection this stack has ever made :)
<j`ey> pbx: now fire up chromium!
<zid> channel
<pbx> that'll take a while :)
<pbx> still need to implement netdb
<pbx> and finish implementing and testing the tcp code
<pbx> maybe also add ip fragmentation support
pbx has quit [Ping timeout: 272 seconds]
<Mutabah> soooo... hack update, anyone know how to force an ELF dynamic file to be loaded to a fixed address?
<Mutabah> maybe I can just convert the driver to a .o and statically link to it... but would that put it where it expects...
<Mutabah> OR, convert to an executabl and LD_PRELOAD
awita has joined #osdev
<zid> hex edit the fuck out of the header?
<Mutabah> I'm creating the header
heat has joined #osdev
<Mutabah> but ld.so still wants to relocate it
<zid> unmark it as dynamic then?
<Mutabah> can't dlopen
<Mutabah> ... I think?
<zid> elf is kinda weird about what dynamic and object file and crap mean
<zid> at least in practice on linux
<heat> does it work if you set the addresses in the phdrs to where you want them to be
<heat> i think that's how you prelink in ELF
<Mutabah> heat: Already set to what they should be
<GeDaMo> Something to do with address randomization?
<Mutabah> Yeah, aslr
<heat> and does it not get loaded to that place?
<Mutabah> nope, aslr runs and shuffles it with the rest of the shared objects
<GeDaMo> Can you disable aslr?
<zid> yea it's just a thing in proc afaik?
<zid> you can echo 0 it
<bslsk05> ​askubuntu.com: kernel - How can I temporarily disable ASLR (Address space layout randomization)? - Ask Ubuntu
<Mutabah> Found that, there's a nice snippet down in it that claims to do per-process
<heat> "aslr runs" would make me believe ld.so is not loading it to the correct place
<heat> aslr only takes effect if you mmap(NULL, ...)
<Mutabah> Seems to also apply to shared library locations
<Mutabah> LD_PRELOAD seems like it might be the way to go
<Mutabah> (switch roles between the host/shim code and the driver)
[itchyjunk] has quit [Remote host closed the connection]
<heat> what are you trying to do
<zid> time to boot my vm and run some printf main %p
<zid> stuff
<zid> make an executable and a .so and stff and see which are stable
<Mutabah> heat: Run a driver in userspace
<zid> mine is perfectly stable with aslr off
<Mutabah> a driver never intended fot userspace
<Mutabah> or for linux :D
<zid> lemme do linker script to load to specific base addr
<zid> unexpected PLT reloc type 0x08.. I guess that makes sense, seeing as I am doing printf("%p", main); in the actual code..
lte678 has joined #osdev
SpikeHeron has quit [Quit: WeeChat 3.7.1]
<zid> oh it's just in general cus of shared libs
<zid> -shared fixes it
<Mutabah> hmm... another alternative: custom PE loader
<zid> I always hated dealing with loaders, makes it hard to debug
<Mutabah> yeah, my current translator approach means that gdb can see everything
epony has quit [Remote host closed the connection]
Goodbye_Vincent has quit [Quit: Ping timeout (120 seconds)]
<sham1> The all-seeing debugger
FreeFull has joined #osdev
Goodbye_Vincent has joined #osdev
awita has quit [Ping timeout: 250 seconds]
pbx has joined #osdev
<mjg_> geist: https://imgur.com/a/q8oScJx not my picture ;)
<bslsk05> ​imgur.com: Imgur: The magic of the Internet
pbx has quit [Ping timeout: 272 seconds]
<sham1> It hurts
dude12312414 has joined #osdev
SpikeHeron has joined #osdev
terminalpusher has joined #osdev
pesdauskes has joined #osdev
awita has joined #osdev
awita has quit [Ping timeout: 250 seconds]
pesdauskes has quit [Remote host closed the connection]
pesdauskes has joined #osdev
xenos1984 has quit [Ping timeout: 276 seconds]
xenos1984 has joined #osdev
pesdauskes has quit [Remote host closed the connection]
pesdauskes has joined #osdev
orthoplex64 has quit [Read error: Connection reset by peer]
orthoplex64 has joined #osdev
terminalpusher has quit [Remote host closed the connection]
lte678 has quit [Quit: Leaving.]
gog has joined #osdev
xenos1984 has quit [Ping timeout: 276 seconds]
pbx has joined #osdev
xenos1984 has joined #osdev
<pbx> fixed a few more bugs in the tcp implementation
<pbx> lets see if messages still get dropped now
<heat> where are you testing
<heat> when*
<GeDaMo> `åಠ
<pbx> right now :)
<pbx> typing this from my OS
<pbx> did already test earlier today but had an off by one in recv() causing bytes to fall out of the stream
<gog> :(
<pbx> seems to be working fine so far
<gog> i have to fix a thing again that i thought i fixed
<heat> quick, get j`ey to say something
<pbx> hahaha
<heat> h`ey what's up
<bslsk05> ​'8xznncetn2w91' by [idk] (--:--:--)
<j`ey> hello is this thing on
<pbx> j`ey: check check check 1 2 1 2 3
<pbx> ;)
<j`ey> yay
rpnx has joined #osdev
<pbx> this irc.c client is pretty cool
<pbx> really barebones thing, but does have tabs, line editing, window resizing, scrolling
<mjg_> is that from suckless?
<pbx_linux> don't think so https://c9x.me/git/irc.git/tree/irc.c
<bslsk05> ​c9x.me: irc.c - irc.git - Minimal curses irc client.
<pbx> dont have VM copy/paste buffer or a web browser on my OS yet
<j`ey> what about lynx?
<j`ey> no idea how big/hard that is to port
<pbx> not yet. need to implement netdb first
<mjg_> it is
<bslsk05> ​tools.suckless.org: tools | suckless.org software that sucks less
<mjg_> same code
<heat> sic is legitimately a shitty irc client
<heat> irssi is good
<heat> i rate irssi
<mjg_> bro
<mjg_> suckless is like... "we can but lol why would you use it"
<kazinsal> sic exists to be so minimalistic that people become plan9 addicts and start huffing raw fifos with ii instead
<mjg_> wmii was a shit wm, fight me
<mjg_> i thought it is brilliant back in the day
<heat> that reminds me, i should try and port the plan9 utilities
<bslsk05> ​tools.suckless.org: tools | suckless.org software that sucks less
<bslsk05> ​9fans/plan9port - Plan 9 from User Space (292 forks/1372 stargazers/NOASSERTION)
<kazinsal> look at this hilarious garbage
<pbx> mjg_: doesn't look the same
<heat> aw shit
<heat> i can legitimately see the use of it
<heat> but why
<pbx> similar, yes. but the thing i linked has a bunch more features
<mjg_> well i did not look *that* closely
pesdauskes has quit [Remote host closed the connection]
<mjg_> dial et al was a give away for me
<heat> echo "i haf i915 porblem" >> in; dmesg | grep i915 >> in; echo "halp" >> in
<heat> poor man's clipboard/paste service
<pbx> mjg_ its interesting for sure, cause looking at both their commit history they seem to evolve seperately but similarly
<pbx> but yeah, i normally use irssi, and i should port that at some point
<heat> its gr8
<heat> it uses glib so you know it's good shit
<pbx> oof
<bslsk05> ​github.com: onyx-package-tree/irssi at master · heatd/onyx-package-tree · GitHub
<heat> not actually a hard port in my case
<heat> ncurses, openssl required some patches
<heat> glib required a trivial one
<heat> irssi has no patch!
<mjg_> team irssi
<mjg_> right here
<heat> team meson
<mjg_> but mostly because it was the first console lcient i used
<mjg_> and now can't be arsed to even try any alternatives
<heat> i use hexchat
<mjg_> i hear weechat is the client to use if using terminal
<heat> it's the GNU nano of irc clients
<mjg_> you know
<mjg_> here is a funny thing which happened to me years back
<mjg_> i approached a guy who was way better than me
<mjg_> about a problem i had difficulty solving
<mjg_> then he used mcedit to open the source file
<mjg_> and i was liek "wut is this a twilight zone episode?"
<heat> what
<heat> the minecraft save edtior?
<heat> i bet that's linus' editor
pbx has quit [Remote host closed the connection]
<gog> parody redacted in minecraft
<mjg_> wut
<mjg_> well if you don't know what mcedit is, then good for you
pbx has joined #osdev
<bslsk05> ​linux.die.net: mcedit(1) - Linux man page
<heat> see, this is why i use gnu nano
<heat> fuck your weird editors
<heat> i'm too young for crippling-depression-caused-by-an-editor
<gog> i have too much crippling depression caused by other sources to be depressed about my text editor
<clever> somebody i know has recently gotten into linux, after his all-in-one nas died and you cant access the data without a replacement of the same model
<clever> he got stuck in vim while i was away, and :q didnt exit, because he had unsaved changes
<clever> first time somebody i know has gotten stuck in vim, lol
<gog> i tap escape reflexively in all my text editors
<heat> :wq gang baby
<clever> heat: he eventually found :q! on his own
<gog> i tried to install vsvim but it doesn't work with vs2022
<gog> :(
<heat> >vs2022
<heat> grave mistake
<bslsk05> ​hakluke/how-to-exit-vim - Below are some simple methods for exiting vim. (299 forks/6221 stargazers)
<gog> i have to use it at work
<gog> i'm not proud of it
<heat> i use vscode and i like it
<gog> i need the full beast
<gog> can't run our debug environment without it
<heat> use ed
<heat> its a great editor
pesdauskes has joined #osdev
<heat> and, as all editors should be, line-based
<gog> 69 0a nice
pesdauskes has quit [Remote host closed the connection]
pbx has quit [Remote host closed the connection]
<mrvn> echo ":q!" >>.exrc
<mrvn> vi exits itself.
<mrvn> you don't exit vi, *
Matt|home has joined #osdev
vdamewood has quit [Quit: Life beckons]
pesdauskes has joined #osdev
wand has quit [Ping timeout: 258 seconds]
GeDaMo has quit [Quit: Physics -> Chemistry -> Biology -> Intelligence -> ???]
freeload7 has joined #osdev
<freeload7> heat: what about ed do you like? I've heard of it but never used it before
pesdauskes has quit [Remote host closed the connection]
pesdauskes has joined #osdev
wand has joined #osdev
<heat> freeload7, i like this feature the best: https://en.wikipedia.org/wiki/Irony
<bslsk05> ​en.wikipedia.org: Irony - Wikipedia
gorgonical has joined #osdev
kof123 has joined #osdev
<gog> we're irony-poisoned
SpikeHeron has quit [Quit: WeeChat 3.7.1]
pesdauskes has quit [Quit: joins libera]
romzx has quit [Ping timeout: 276 seconds]
dutch has joined #osdev
romzx has joined #osdev
Burgundy has quit [Ping timeout: 255 seconds]
gog` has joined #osdev
gog has quit [Ping timeout: 240 seconds]
<gorgonical> oh my god
<gorgonical> the fucking interrupt flag
<gorgonical> clears backwards
<gorgonical> it drives sda/scl low when the interrupt flag is set to pause the transaction and let you process. you clear the flag by WRITING ONE back to the control register
<gorgonical> NOT ZERO???
<heat> that's not that weird
<heat> usually there's a good reason for ti
<gorgonical> i have never seen such an abominable design
<gorgonical> before
<heat> ahci interrupts is an example that comes off the top of my head
<heat> its so you don't lose interrupts in AHCI's case
<gorgonical> Is the idea that you must write a 1 intentionally?
<gorgonical> That is, you cant write a zero from e.g. a cached configuration?
<heat> yes
<gorgonical> it makes more sense but i am still very angry
<heat> if 0 cleared it, read(reg), reg &= ~handled; write(reg) could lose interrupts in between
FreeFull has quit []
<mxshift> W1C is very very common
<klange> Since my editor is largely a clone of vim (though not really an implementation of vi, my operation syntax is a bit different), it naturally has the same exit pattern, and can also be exited in fun ways such as abusing the fact that the command input mode parses Kuroko, so you can do it to the python-y way and `:import os; os.kill(os.getpid(), 9)`
<heat> import os; os.kill(os.getpid(), 9) is p y t h o n i c
<klange> :qa! is still the better choice, though
<heat> but it's not p y t h o n i c
<klange> (which, of course, also works in vim as `:py3 import os; os.kill(os.getpid(), 9)`)
<heat> actually, it's not pythonic
<heat> the pythonic solution would be an obtuse one-liner