<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)
<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.]
<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
<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
<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
<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
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?
<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