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
<klange> heat: obviously the frist step in running Word is to port Wine.
<klange> moon-child: I could understand notepad for a particulalry masochisticly nostalgic sort, but wordpad was always an rtf with silent wysiwyg functionality and thus has always been horribly inappropriate for code editing
<klange> True coding gods obviously use their own editors, and code in their own languages, all on their own OSes.
<klange> That's why we're all here, right?
Matt|home has joined #osdev
<klange> No? Just me?
<heat> i write cheap linux
<heat> cheaper than free? yes
<gog> i'm on hiatus again
<gog> so yeah just you :p
<klange> "_we_ pay _you_ to run it"
<heat> mr gog pls do the coding
<heat> thank
<gog> mrs*
<moon-child> klange: yeah I have no idea why she does it
<heat> sorry goggers
<heat> bad mistake
<gog> we're good
<kingoffrance> +klange story of mel ...
scripted has quit [Ping timeout: 256 seconds]
scripted has joined #osdev
scripted has quit [Ping timeout: 240 seconds]
heat has quit [Remote host closed the connection]
scripted has joined #osdev
<gog> mew
* moon-child pets god
<moon-child> if n is a power of two, and you need to align something to it, do you prefer &-n or &~(n-1)?
<moon-child> I find the latter clearer, but have been seeing the former a bit recently
<gog> i don't like the former because if i'm doing my mental bit twiddling correctly it's not the same as the latter
<moon-child> I'm pretty sure it's the same
<moon-child> python sez ~15 is -16
<gog> oh
<gog> i wasn't doing my mental bit twiddling correctly
<gog> disregard
<gog> idk then
<gog> (i am a cat not a computer)
<zid> I prefer & ~0xF
<zid> cus it's bits, not representation based
<gog> F in the chat for Fifteen
<gog> Eourteen, Dhirteen, Cwelve, B'leven
<zid> If you force me to think of it in terms of aligned to 16 not 'bottom 4 bits clear' I'd go &~(n-1)
scripted has quit [Ping timeout: 240 seconds]
mahmutov has quit [Ping timeout: 256 seconds]
Likorn has quit [Quit: WeeChat 3.4.1]
mahmutov has joined #osdev
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
terrorjack has joined #osdev
mahmutov has quit [Ping timeout: 246 seconds]
bradd has joined #osdev
srjek has quit [Ping timeout: 250 seconds]
gog has quit [Ping timeout: 250 seconds]
<kazinsal> grabbed a displayport to HDMI 2.0 cable and hooked my 4K TV (which is mounted on the wall above my desk) to my PC. why have I not done this before
sonny has joined #osdev
vdamewood has joined #osdev
sonny has quit [Ping timeout: 250 seconds]
sprocket is now known as sprock
sonny has joined #osdev
sonny has left #osdev [#osdev]
GeDaMo has joined #osdev
ravan has joined #osdev
ravan has quit [Remote host closed the connection]
elastic_dog has quit [Ping timeout: 248 seconds]
elastic_dog has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
bschnepp has joined #osdev
bschnepp has left #osdev [Leaving]
mahmutov has joined #osdev
<mrvn> moon-child: &-n is only correct in the latest C standard
vimal has joined #osdev
vimal has quit [Remote host closed the connection]
mahmutov has quit [Ping timeout: 256 seconds]
<kingoffrance> how'd you get to be so correct mrvn? i thought i was the only crazy person
kingoffrance has quit [Quit: Leaving]
Likorn has joined #osdev
freakazoid333 has quit [Read error: Connection reset by peer]
sortie has quit [Quit: Leaving]
sortie has joined #osdev
pretty_dumm_guy has joined #osdev
bradd has quit [Quit: No Ping reply in 180 seconds.]
bradd has joined #osdev
pg12 has quit [Quit: pg12]
ss4 has joined #osdev
wootehfoot has quit [Ping timeout: 256 seconds]
Burgundy has joined #osdev
pg12 has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
<bslsk05> ​www.theregister.com: Apple dev logs indicate nine new M2-powered Macs – report • The Register
<mrvn> Is the disk size still locked in with those?
kingoffrance has joined #osdev
<mrvn> kingoffrance: I have to make up for all the non correct stuff I do in RL
darkstardevx has quit [Ping timeout: 248 seconds]
Ali_A has joined #osdev
Ali_A has quit [Client Quit]
Ali_A has joined #osdev
mahmutov has joined #osdev
gog has joined #osdev
eryjus has quit [Read error: No route to host]
vin has quit [Remote host closed the connection]
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 246 seconds]
srjek has joined #osdev
Benjojo has quit [Ping timeout: 245 seconds]
relipse has quit [Ping timeout: 250 seconds]
relipse has joined #osdev
Brnocrist has joined #osdev
Benjojo has joined #osdev
abbix has joined #osdev
<abbix> hi, I'm currently trying to relocate an ELF object file and I don't understand what is the r_offset field exactly. When running a readelf on the file I get that I need to relocate offset '0x20' with '.text+0' but like the size of '.text' is 0x1e so it's not in the text section?
<zid> what kind of relocation is it
<zid> and it matters whether it's a shared object or not I think
<abbix> R_X86_64_PC32
<mrvn> what arch and endian and all the other header fields
<zid> Elf32_Rel then I guess
<abbix> zid: it's just an object, not shared
<abbix> it's a x86_64 object, so Elf64_Rel
<zid> err yea 64
<zid> I cannot math
<zid> for executables or shared objects r_offset is the vaddr, for relocatable files it's an offset into the section
<zid> readelf output might be useful
<abbix> in this case, the section = .text, right?
<zid> sh_link tells you which
<abbix> https://envs.sh/ENz.txt here's the readelf -r output
<zid> which is in the section header for the relocation section I think
<zid> I meant.. like.. readelf -a
<abbix> oh yeah, sorry
nohit has quit [Ping timeout: 260 seconds]
<zid> and possibly objdump -d just for kicks
<zid> given it's so small
<abbix> https://envs.sh/EN3.txt here is readelf -a
afarrag has quit [Ping timeout: 260 seconds]
<abbix> https://envs.sh/ENY.txt here's objdump -d
nohit has joined #osdev
<zid> what are the relocations.. for?
<zid> oh, the string on 11?
afarrag has joined #osdev
<abbix> wait weird, looks like the output got modified while pasting the output
<abbix> lemme produce a new one
<abbix> https://envs.sh/ENC.txt ah here it is
<zid> these are different? :P
<abbix> well looks like when I pasted it a "/usr/bin/zsh" got added to 11
xenos1984 has quit [Read error: Connection reset by peer]
<zid> I think maybe this is actually linked to symtab
<zid> look at the bottom of readelf
<zid> 7 and d look familiar
<zid> it's patching the address .text+0 *to* symtab offset 20, to resolve where 'fisix_module_exit' is, etc
<zid> .text+7 to symtab 40 to resolve where test is, .text+d to symtab 5c to resolve where fisix_module_init is
<abbix> oh so offset is an index into the symbols?
<abbix> wait no
<zid> it depends which section it's linked to via sh_link
<zid> this isn't relocating your program's code
<zid> it's relocating the *symbol table* so that dynamic linking will work *on* it
<zid> if someone needs to call these functions (given they're global symbols), there has to be a table somewhere that the dynamic linker can look at to get those addresses
<zid> so you've essentially got a table that looks like [<fisix_module_exit: .text+0> <test: .text+7> <fisix_module_init: .text+d>]
<zid> called .symtab
<zid> which gets filled in via those three relocations
<zid> in a non-relocatable object they'd just have numbers in
<zid> (0x40000, 0x40007, 0x4000d or whatever)
<abbix> ok so like it means that I need to change sections[sh_link]+offset to their new value?
<abbix> or am I understanding this wrongly
<zid> yea it means you need to write to offset 20 40 and 5c in .symtab
<zid> with the value .text+0, text+7 and text+d respectively
<abbix> yeah
<zid> I think technically 'add' .text+7, and it'll start with a 0
<zid> because it's an addend
<abbix> yeah
<zid> That was fun to figure out
xenos1984 has joined #osdev
heat has joined #osdev
abbix has quit [Quit: Leaving]
freakazoid333 has joined #osdev
Likorn has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
hodbogi has joined #osdev
<hodbogi> You know, I was wondering- Do you think I coulf abuse upward and downward segment types to create FIFO stack segment flip buffers between processes?
<hodbogi> could*
<hodbogi> Not whether I should or not but it was a random thought I had recently.
ss4 has quit [Quit: Leaving]
wootehfoot has joined #osdev
eryjus has joined #osdev
hodbogi has quit [Ping timeout: 248 seconds]
hodbogi has joined #osdev
<mrvn> hodbogi: a downward segment I believe does not reverse the byte order in memory. And if it did you wouold switch endianess.
<hodbogi> Well I'm not talking much about byte order, more about stack growth direction which I would thinj wouldn't cause any endianness- perhaps segment growth order doesn't work the way I think it would on x86.
<mrvn> unless I'm wrong a downward growing segment is just end+size instead of start+size. Also note that segments other than 0 - ~0 are slower.
<hodbogi> I was thinking about it since my architecture on CPLD has hardware FIFO, and I thought about how I could trick x86 to do the same thing. I could achieve the same effect with some instructions entirely with software.
<mrvn> just make a pointer to the start and to the end.
<hodbogi> right
<mrvn> You can map the ring buffer twice so push/pop of data that crosses the end of the buffer still works trivially.
<mrvn> Personally I would forget about segments. They are a bad hack to add memory protection to the old "I own all memory and will split it into code, head and stack" view of the system.
<mrvn> s/head/heap/
<mrvn> Builoding a MPU or MMU isn't that hard. Better use those.
<mrvn> Plus compilers really don't like far pointers anymore.
<moon-child> mrvn: lol, good point. But as that one paper demonstrates, oses are not written in standard c
<hodbogi> Here we go
<hodbogi> Another 3 hour conversation on C/C++ standards
<hodbogi> :P
<bauen1> at least pick C++, you'll have a lot more weirdness to discuss about :D
<heat> standards are stupid
<hodbogi> Situation: We have a bazillion competing standards. Let's all come up with something that will standardize all of the standards.
<mrvn> moon-child: well, that statement is easy to disproove. Mine is.
<bauen1> on a related note, is there somehow a magic option that gets g++ to dump me a list of every overriding function for a virtual function ? or do i have to manually parse the .class dump to figure out all classes that could potentially override a particular method, guess potential symbol names and see what I end up with ?
<heat> volatile uint8_t *ptr = (volatile uint8_t *) 0xA000; <-- fairly sure this isn't standard C
<mrvn> bauen1: mark the function final in the base class and make -k?
<jimbzy> If there's one thing I've learned after messing with C/C++ over the course of twenty years it's that I'm always "doing it wrong" :P
<mrvn> hodbogi: perfectly standard C, just implementation defined what it means.
<mrvn> heat: ^^
<heat> ah, so the "not standard" part of the standard
<hodbogi> How about we just write everything in Prolog and call it good.
<heat> write it in php
<bauen1> or to formulate it differently, i want a list of all functions that dynamic dispatch could potentially call
<hodbogi> phpinfo() segfaults
<hodbogi> XD
<jimbzy> Hah
<heat> bauen1, seems like a job for libclang
<mrvn> heat: it's not UB, it's not correct but it's perfectly fine code
<mrvn> heat: you also don't have to do that
<bauen1> mrvn: tbh, I've thought about using some grep magic to figure out the function name an indirect call is trying to call, because gccs -fcallgraph-info=su doesn't give me that, so that's not that far off
<mrvn> bauen1: I don't think gcc is designed for that
<mrvn> bauen1: you also might have to consider member function pointers.
<mrvn> (if you want to check what actually might get used and not just exist)
<moon-child> mrvn: the proposition is not 'there exist oses not written in standard c', but 'there do not exist oses written in standard c' (or, perhaps, 'can not')
<mrvn> moon-child: and I have one so there you go, disprooven.
<moon-child> you have an os written in standard c?
<mrvn> yes
<moon-child> it relies on no implementation- or platform-specific behaviour?
<klange> Even if you have a pure memory-addressed hardware platform, you can't write an OS in true, pure standard C.
<mrvn> only in so far as that bootloader passes a device tree to the kernel
<mrvn> So no hardcoded physical addresses, they are dynamically read from the device tree.
<klange> But it's all technicalities of the standard - it's "illegal" to refer to arbitrary addresses, for example. You can write true standard C and bolt it to assembly shims.
<heat> mrvn, is your entry point named "main"?
<mrvn> heat: it's freestanding
<klange> Reading from the device tree and treating its contents as pointers is illegal :)
<heat> "5.1.2.2.1 Program startup"
<heat> "The function called at program startup is named main"
<mrvn> klange: why? it's a union { uint32_t i; void *p; }
<mrvn> heat: not for freestanding
<mrvn> iirc
<bauen1> mrvn: true, i'm already abusing gcc beyond what I should be doing, but for stack usage and the code base i'm looking at it would be good enough to know all possible targets of a dynamic disptach (but there are some cases where a human or a better compiler could deduce the exact type a call will resolve to), limiting the dynamic dispatch targets to symbols actually found in the final binary will probably
<bauen1> bring it to a usable level already
<bauen1> mrvn: thankfully no member funtion pointers are used in the code base (yet) :D
wootehfoot has quit [Quit: Leaving]
<mrvn> klange: you have to start with the assumption that the device tree is a valid object and the addresses in it are valid pointers to objects in the implementation defined format. But you always have that in the C runtime.
<klange> If that's how you're reading the spec, then maybe... but it's all thin ice, and I'm wary of calling anything that heavily implementation defined as "standard C".
<mrvn> klange: you always need to have something that sets up the C environment that's outside/before C. You have to fudge that part a bit.
<gog> i prefer nonstandard c
<mrvn> By the way, so far the OS only printes hello world. No IRQs or exceptions. That can't be done in C on nearly every CPU too.
<klange> C as She is Writ
<heat> k&r c best c
<mrvn> only with one-s complement
<heat> write code like it's 4.4bsd
<heat> comments? bruh
<heat> descriptive names? bruh2
<heat> void*? don't make me bruh again
<mrvn> convention: all variable names must be 8 chars or less.
<mrvn> did I say 8? I mean 6.
<gog> 6? too many
<gog> 4 is good
<mrvn> gog: i123 for integers?
<gog> yes
<gog> type names should be as unclear as possible
<klange> hey even if you stick to just letters, 4 is enough for 500k-ish variables, that should be good enough for any program
<gog> all symbol names
<gog> not just variables
<gog> funcs, types and tags
<mrvn> function names start with f, so no problem there. :)
<gog> f for function in the chat
<mrvn> gog: tags? what are tags?
<gog> mrvn: struct and enum
<gog> those are _not_ types
<gog> sort of
<mrvn> upper case for enums?
<gog> yes
<mrvn> struct/union members can follow the variable/function naming conventions.
<gog> yes, enum values are constants and should be all caps
<heat> how will we do hungarian notation with 4 chars?
<klange> if you want enums you should just write them down on sticky notes
<gog> we're not doing hungarian notation
<heat> that only works for hWnd
<heat> why are we not doing hungarian notation
<klange> don't have enough room for i
<gog> because none of us is hungarian afaik
<heat> can't we be inclusive?
<heat> hmmm but if we do hungarian notation what will the romanians and the czechs think
<gog> what is romanian notation
<heat> curvă
<mrvn> all varibales must be a type followed roman numerals
<CompanionCube> inb4 further restrict yourself to the 12 letters of rotokas
<mrvn> iXI
<gog> coucescau (sp?) notation, the palace of notation. every name must be as large as possible and there needs to be excessive padding on all structs
<gog> and every program needs to take 30 years to complete
<heat> ceaușescu
<CompanionCube> isn't that just java lol
<gog> oh i need to go dog walk
<gog> byeee
<heat> cat doing dog walk
<heat> sus
<geist> Yawn, good morning
<jimbzy> I tried taking my Yorkie for a walk this morning and he refused because there was a menacing squirrel in the driveway.
<mrvn> don't disrespect the squirrels, they will pown you.
<bslsk05> ​'Backyard Squirrel Maze 1.0- Ninja Warrior Course' by Mark Rober (00:20:20)
<jimbzy> I don't mind them, but my dog thinks they are out to get him.
<mrvn> they are, for sure.
<jimbzy> I think this is due to him meeting my friend's pet raccoon a while back. Her little hands were all over him and it made him extremely uncomfortable.
<jimbzy> He hasn't been right since.
<mrvn> animal cruelty, by other animals. Welcome to Animal Farm.
<jimbzy> I'm about 80% through the question pools for my ham exam and I'm getting around 82% correct. I need a 74% to pass, so I'm feeling pretty good.
<heat> does anyone have a comprehensive ABI spec for svr4?
<heat> like syscalls included
<mrvn> .oO(that guy over there on the internet)
<heat> the 386 abi mentions a "UnixWare 2.0 Operating System API Reference: System Calls" which I can't find
<heat> i'm reinstalling my svr4 installation
<heat> let's see if this has any man pages
<geist> awww man
Likorn has quit [Quit: WeeChat 3.4.1]
nur has quit [Remote host closed the connection]
nur has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
<heat> i can't find any man pages
<heat> i did find a /bin/vax
<heat> wonder if it's a vax emulator
<heat> huh no it's a script with exit 255
<mrvn> what about true/false?
<heat> ohhhhhhhhhhhhhhh I see
<heat> it has a bunch of /bin/$(arch)
<heat> they're all symlinks to true or false
<heat> you'd run /bin/vax and if it returned true, you knew you were executing on a vax
<heat> same for i386, i486
<jimbzy> geist, How goes the rosco board experiments? Did you ever get your 4MB board assembled?
<jimbzy> Erm expansion board
<geist> yep! thought it was broken but turns out it was operator error
<geist> i was running a memory test in LK at 0x1000000 instead of 0x100000
<geist> and since 68010 only has 24 bits of address line that means it wraps at 16MB so the memory tester was overwriting 0
<jimbzy> Aha
<jimbzy> Nice
<geist> looks like i got it at just the right time, since rosco isn't going to sell any more of the boards in kit form. but of course it's entirely open source
<geist> i had to source the ram chips from mouser, etc
<jimbzy> Oh damn. I didn't hear about that.
<heat> fuck sake, no manpages
<geist> what about /usr/src?
<heat> nope
<geist> all this aside i suspect the syscall format is push a bunch of crap on the stack, int instruction
<heat> no
<mrvn> syscall number on stack or register?
<heat> the syscalls use ljmp to a call gate
<heat> eax contains the syscall nr
<GeDaMo> heat: I found this book unfortunately not freely downloadable https://archive.org/details/isbn_9780131771307/mode/2up
<geist> oh ljmp sure
<heat> this is documented on the 386 sysv abi
<heat> GeDaMo, noice
<geist> i kinda wonder in that era of machine if ljmp or an int is faster
<heat> try it!
<geist> i might, even
<geist> though actually you can just read the instructino timing sheet, as you could in the Old Days
<geist> my guess is the ljmp is mayybe a bit quicker? seems like it'd have to go through the same microcode when you think about it
<GeDaMo> "UnixWare 2.0 Software Development Kit"
<geist> ends up consulting the idt, loading a new cs reg, which consults the GDT and loads a new segment, then does the interrupt logic, etc
<geist> if it's a call gate that is
<heat> GeDaMo, thanks!
<heat> the download is going to take a while but it looks promising
<geist> i wonder if it uses the arg copy logic in the call gate(?). i forget about it, since nothing modern uses it and it's an often forgotten feature
<bslsk05> ​opennet.dev: UnixWare Frequently Asked Questions (Developer)
<geist> but tehre's some field in there somewhere that says copy N args
<geist> i forget if it's on call gates or what
<geist> if it's what i remember and its using that then that's the big win
<heat> i was thinking about challenging myself to create the simplest svr4 clone
<heat> that's why I want all of this
<geist> actually run the user space programs directly? that'd be fun
<geist> how does program loading work on it? is everything static?
<heat> no
<heat> it has shared libraries
<geist> if not, where did SVR4 implement the loader? kernel space or a user space loader?
<heat> kernel probably
<heat> this even has loadable kernel modules
Ali_A has quit [Quit: Connection closed]
<geist> if you have the SVR4 source i'd probably just start from there to figure out how syscalls work
<heat> but I can't look too deep into this since I don't have standard toolchain utils there
<heat> oh I do
<heat> but I wanted to avoid looking at code
<heat> also because it's illegal
<heat> actually I think I lost it
<heat> oh well xD
<heat> anyway clean room seems more fun
<mrvn> maybe just run some binaries and see what they call
<heat> i'm waiting for the archive.org goodness to download
<geist> well, just looked at it. i can give you hints as to how it works
<geist> (the SVR4 source)
<geist> (hint: nothing fancy, pretty much what you'd expect)
<geist> also gosh this looks really slow, but then i think even if you spent 50% of the cpu doing kernel context switching and whatnot, it's still potentially a win because you actually have a working multitasking system
<geist> i think that's a thing thats lost in modern osdev thinking: everything has to be so fast and minimal, but imagine being presented with the option in the 70s or 80s where you could either buy a machine and use it for some single tasking thing, or use it in a multitasking environment, with a fair amount of overhead
xenos1984 has quit [Read error: Connection reset by peer]
<mrvn> geist: what's the switching frequency? 100Hz? 10Hz?
<heat> HZ=100
<heat> in the svr4 env
<geist> depending on the situation, the latter is still more useful in a lot of cases even if the overhead is high
<mrvn> geist: you can always do batch processing
<geist> or that, yes
<mrvn> or 1Hz, 0.1HZ, 0.001HZ switching
<geist> now this sort of thinking isn't really there anymore, since multitasking systems are just assumed to be what you have installed. but back in the day it might be a real decision
<mrvn> Given the amount of ram you can do full swapping every 10 minutes.
<geist> but especially in the case of something like 386: run some dos thing on it, or xenix. i'm sure xenix feels 'slower' for a lot of cases, but it's potentially much more powerful. so you have tradeoffs
<geist> similar feeling at the time NT was coming out: you can run NT on the same machine as win95, and for a while it definitely felt like it had more overhead
<geist> until hardware caught up and you didn't notice as much
<mrvn> without remote access there isn't that much point in multitasking.
<geist> not true: you could have tasks in the background while doing work
<geist> stuff that is now taken for granted
<geist> like you could process some docs while working on a new one, etc. real thing syo might actually have a reason to do in an office
<mrvn> you can, but not a lot. And you can do that with DOS by the way.
<geist> well, fine. i'm just trying to make a point. if you want to just argue it into the ground. i'm out
<mrvn> Althouth it took ages for someone to figure out how to do it with DOS.
<bslsk05> ​roelandjansen/pcmos386v501 - PC-MOS/386 v5.01 and up, including cdrom driver sources. (54 forks/355 stargazers/GPL-3.0)
<geist> it was an era just before i started really using multitasking machines. my first time i truly experienced multitasking was linux/win95 around 1995. prior to that it was mostly win 3.1 stuff
<geist> but even at the time it was pretty nifty to actually see mor ethan one thing doing something at the same time
<mrvn> geist: that was when I was laughing my ass off having near real time multitasking + multiuser on my Amiga while you had DOS prompts.
<geist> so i honestly dunno what unix installations on 80s era PC/68k hardware was like at the time in the real world
<geist> yes i served yo uthat softball mrvn
<geist> i knew you'd pounce on it
<mrvn> I tried installing xenix at school around that time but we had an i486 and xenix was for i386 so it didn't work. :(
<geist> but maybe that's why the bit is still in my head that multitasking is still kinda neat
<geist> like i still get a ittle piece of joy every time i see a system truly doing that even though it's totally ubiquitous now
<geist> possibly because my childhood was using single tasking systems
<mrvn> geist: at the times you have win95 you also hjad enough ram for it.
<geist> what do you mean?
<GeDaMo> I used to get suspicious if the disk light was blinking when I wasn't doing anything :P
<mrvn> Kind of hard to enjoy multitasking with <1MB.
<heat> why would i386 code not work on an i486?
<geist> mrvn: oh absolutely. 4MB was pretty much the minimum
<mrvn> 640k should be enough for anyone
<geist> in fact i remember upgrading my p90 pretty quickly to 8MB or 16 i think because win95 was pretty tight in 4
<mrvn> heat: don't ask me but it didn't.
<geist> heat: off the top of my head possibly because of the addition of invlpg
<geist> though i think if you dot know about it it is just more inefficient
<geist> possibly some caching bugs that 486 had?
<geist> well, i mean bugs that the software had that didn't know about caching
<geist> becuase 386
<mrvn> that would be my guess too
<geist> my first true dedicated linux machine was an am486-133 i believe. built it from parts in first year college, 1995
<geist> had slakware on it
<geist> that's honestly about the tiem i really got interested in system programming, etc. prior to that DOS/windows was just meh. didn't want to hack it
<mrvn> it was a time of fractals
<heat> oh wow svr4.2 had privileges
<heat> kinda like linux has now with capabilities
<mrvn> it should have command_fds, because everything is a file
xenos1984 has joined #osdev
<heat> the man pages GeDaMo linked don't seem to have syscall numbers
<mrvn> should have looked at the womand pages
<GeDaMo> heat: sorry about that :(
<heat> don't worry it's pretty useful anyway haha
<heat> geist, yeah these things are dynamically linked
<heat> cc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /usr/lib/libc.so.1, stripped
<mrvn> you should go back to something with aout
<heat> svr4 is all elf
<mrvn> but a coff is so much better for your (h)elf, NOT.
* gog PEs on the floor
<mrvn> you dog
<heat> get aout, stupid dog
<gog> :D
<gog> gog -> dog
<heat> gog reversed is gog
<gog> yes
<mrvn> if cat is dog then what is tac?
<gog> god
<heat> god
<heat> aha
<heat> i'm looking at a libc++
<heat> compiled in Nov 23, 1994 I think
<Ermine> Where coff is used?
<heat> no this is elf
<mrvn> heat: 4 years pre standard?
<heat> yup
<mrvn> fun
<heat> it was called libC.a
<heat> i confused it for the actual libc
<mrvn> that makes more sense
<gog> coff was introduced by SysV but they moved on to ELF p quick. PE is derived from COFF
Oshawott has joined #osdev
archenoth has quit [Ping timeout: 240 seconds]
<bslsk05> ​fxr.watson.org: fxr.watson.org: FREEBSD-8-3 sys/compat/svr4/syscalls.master
roan has joined #osdev
GeDaMo has quit [Remote host closed the connection]
Likorn has joined #osdev
<heat> oh hold the fuck on
<heat> the svr4 syscall numbers are the same as linux's
<jimbzy> They must have stole them from Linus.
<jimbzy> Jerks...
<roan> :o
<heat> something something tivoization
<mrvn> jimbzy: syscall numbers are pretty compatible across unix systems
<mrvn> Linux on Alpha has OS1 syscall numbers
unlord has joined #osdev
<nomagno> ... Why is Alpha still used again?
<nomagno> I don't know if it has any advantage nowadays other than being able to run VMS
<nomagno> And OoenVMS has x86_64 support now
<nomagno> OpenVMS*
<mrvn> who said it's still used?
<nomagno> mrvn: It IS still used, for whatever reason. But thankfully not for new systems
<nomagno> I guess mission critical stuff running on VMS is either stuck on VAX or on Alpha
<nomagno> But seriously, there are NO good Alpha arch VMs!
<nomagno> There's one open source one that is just good enough to run VMS, but still extremely buggy
<mrvn> I still have a board here somewhere
<nomagno> mrvn: the prices are bonkers last I checked
Gooberpatrol66 has quit [Read error: Connection reset by peer]
hodbogi has quit [Ping timeout: 246 seconds]
netbsduser has quit [Ping timeout: 246 seconds]
netbsduser has joined #osdev
<heat> i can't fucking install this crap ahhhhhhhh
<sortie> I just added a "VMS" column to my ps(1) :)
<heat> congrat mr sort
<gog> i added a cheeseburger to my stomach
<heat> i tried to install old svr4 releases for like 3 hours
<gog> why are you doing this to yourself
<heat> "me: hey you should write a minimalist svr4 clone"
<heat> >spends 3 hours trying to install unixware 2.0
<heat> >turns out it doesn't even run in virtualbox
<heat> >could've just opened the iso and extracted the programs I want
<heat> mfw
<gog> oof
<heat> i also need to implement a whole lot of stuff
<heat> tl;dr i'm probably not going to do it
<heat> maybe i'll start smaller
<heat> these systems were already really complete
Retr0id8 has joined #osdev
<mrvn> heat: have you tried bochs?
<heat> nop
<heat> and i'm not going to do that fuck that shit
<heat> 1) eww bochs; 2) i've spent way too much time in this already
<mrvn> or qemu without kvm. Tune the cpu to i386.
<heat> qemu doesn't even boot the floppies
<mrvn> ouch
<heat> virtualbox hangs while accessing the cd I think
Retr0id has quit [Ping timeout: 256 seconds]
Retr0id8 is now known as Retr0id
m5zs7k has quit [Quit: m5zs7k]
heat has quit [Remote host closed the connection]
heat has joined #osdev
<sortie> https://paste.ahti.space/2fa6469.html ← I built some new memstat -a and ps -v statistics to help debug the memory leaks I got on my IRC server :)
<bslsk05> ​paste.ahti.space <no title>
pretty_dumm_guy has quit [Ping timeout: 240 seconds]
<sortie> ^ Just me casually ssh'ing into my OS to debug my production load. It's a big reason why I prioritized putting my OS to actual use, because then I'll build the features I actually need to make it succeed, such as system maintenance tools
<sortie> I mean normally I'd just focus on whatever features feels nice when I boot my up OS locally in a VM for completely casual use, but not actually using it for something, so it can be a bit aimless or shiny what I focus on. Actually using it for something gives a good clarity what can help real use cases succeed
<heat> sortie, do you know what happens if you call listen() on a connected socket?
<heat> on most systems
<sortie> https://sortix.org/os-test/#udp-connect-send-error-listen ← A little bit of data for UDP but no I don't have any data for that on TCP
<bslsk05> ​sortix.org: os-test
<sortie> Sortix TCP listen(2) on a connected socket will EINVAL
<sortie> https://pubs.opengroup.org/onlinepubs/9699919799/functions/listen.html POSIX says [EINVAL] The socket is already connected.
<bslsk05> ​pubs.opengroup.org: listen
<sortie> Assuming no POSIX deviations, which I don't really expect on the major systems, it's EINVAL
<heat> thanks posix man
<heat> my linux man page was super vague
<bslsk05> ​pubs.opengroup.org: The Open Group Base Specifications Issue 7, 2018 edition
<heat> i have it in pdf
<sortie> The search is more handier than pdf
<sortie> Protip: Search for "foo -" to avoid too many answers if the prefix is commobn
<heat> syn doesn't get replied to until accept(2) right?
<heat> yeah that should be right
<sortie> Wrong
<sortie> accept is not about accepting the command, it just delivers the FD to the process
<heat> oh
<sortie> The connection is established in the background and passed to accept whenever it's already ready
<heat> so each socket needs a list of sockets?
<heat> yucky
Matt|home has quit [Ping timeout: 256 seconds]
<sortie> Well you'd need that anyway if accept acked your sins
<sortie> That's what the backlog parameter to listen(2) is about, btw
<heat> i was going to queue syn packets
<sortie> Now what you can do is implement stateless SYN cookies where basically you let the caller prove they got a SYN from you
<heat> yeah but I want a simple POC rn
<heat> you got me inspired to try to add server capabilities to my TCP stack
<sortie> That way you don't don't spend memory on background internet radiation SYN packets that don't actually belong to the source IP
<sortie> Woohoo
<sortie> Federation of Independent Hobbyist IRCDs
<sortie> *OS
<sortie> Well accept is simple enough to implement as an API. You keep a backlog-sized queue of established connections and signal availability through poll(2) when there's some ready
<sortie> The TCP states is a bit more tricky but overall it's not thaaat more complicated than the client side connections
<sortie> You got the state machine documented in the RFCs so it's really just doing that
<heat> my tcp stack right now is a mess
<sortie> One thing you wanna be careful about is that multiple addresses and source ports can talk to the same address and port
<sortie> (source_ip, source_port, destination_ip, destination_port) is the tuple that must be unique for each socket
<heat> i know
<sortie> But they can conflict and so on when you listen
<heat> currently each proto family implements bind() which checks for sockets bound to the same port
<sortie> Yeah telling you this since that address reuse logic and routing to the right socket was a little bit tricky to figure out exactly
<heat> that works I think
<heat> now I need to add an accept() which checks the dst address too
<heat> (or change bind())
<heat> i can't just mindlessly check the dst address too
<heat> or can I
<heat> i should be able to
<heat> for non-connected sockets that are calling bind(), they'll have a dst of 0.0.0.0:0 (or the ipv6 equivalent)
<heat> sortie: can i have two outgoing connections from the same addr:port?
<heat> like int fd = socket(...); bind(fd, any:80); connect(fd); int fd2 = socket(...); bind(fd2, any:80); connect(fd2);
<sortie> As far as I know, no. The kernel doesn't let that happen. At least on Sortix.
<heat> i don't think that works because you might connect to the same dest addr
<heat> but is that second bind() legal?
<sortie> Well as long as the dest ip and port aren't already used, and the tuple is unique, I think the kernel COULD get away with allowing it
<sortie> heat, it's certainly a case I wanna os-test
<sortie> I *really* need to rebuild that VM lab
<sortie> I'll probably do that when I some day get to actually finish my TCP stack
troseman has joined #osdev
Gooberpatrol66 has joined #osdev
Burgundy has quit [Ping timeout: 256 seconds]
Likorn has quit [Quit: WeeChat 3.4.1]