<heat>
less data than requested if a signal is caught, an error
<heat>
or disconnect occurs, or the next data to be received is
<heat>
of a different type than that returned.
<heat>
"call may still return less data" sounds pretty much like an OK here
<pbx>
heat: my idea was to just need a lock on the rq pop_packet operation, but now that we're talking, i think recv guarantees that the order of the bytes is correct (no half eaten out of the middle by another reader)
<pbx>
i mean, i need a lock on that either way, for consistency of the data structure across reads/writes.
<heat>
yeah i was wondering about that rn
<heat>
i dont... know
<pbx>
and in that case i can have a lock on recv/read calls in general, to make sure that across the call it shouldn't need to worry about packets being dequeued elsewhere
<heat>
in general? no
<heat>
that is needlessly slow
<pbx>
per socket, i meant
<heat>
i've also infected my brain with linux networking
<heat>
still, per socket locking everywhere is slow
<heat>
linux's socket locks are non-trivial things that also handle socket backlog, etc
<pbx>
why? multiple read()s across threads/processes on the same socket object should be a big edgecase either way
<pbx>
poorly defined, hard to reason about, no good reason to do it
<pbx>
well, not for SOCK_STREAM sockets, for DGRAM i could see some usues
<pbx>
uses
<pbx>
but there isn't an issue for those
<heat>
dgram will still have the same problem
<heat>
if you have a socket lock and mindlessly lock_sock(); sock->sendmsg(); unlock_sock();, it's a very very bad idea
<heat>
makes sense for TCP, but UDP sends will inevitably get serialized
<heat>
and UDP sends only require locking in some specific cases
<heat>
mainly, IIRC corking
<pbx>
nah, no reason for that stuff, although deep down the stack something like that will happen as soon as they need to be added to the interface tx queue
<heat>
wanna compare a stupid simple spinlock to append to a list with full blown packet crafting and memory copying (which may fault!)
<pbx>
nah what i'm thinking is semaphore_down(&sock->read_lock); sock->ops->read(...) semaphore_up(&sock->read_lock);
<heat>
but you don't know if reads need a lock, or a big lock, or a small lock, or if they could use a rwlock, or RCU, or whatever
<heat>
it depends on the protocol and your code
<pbx>
true.
<heat>
UDP recvmsg only needs a very small lock to dequeue the packet
<pbx>
exactly, which is what i have right now.
<heat>
serializing those would mean that you could never run a dns server in your OS
<heat>
those 6 segments could totally be on a generic queue
<heat>
but the FIN?
<heat>
you *need* to keep it
<heat>
but there's no easy way to represent it in a simple way
<pbx>
wait, why? i haven't gotten to the TCP part at all yet
<heat>
FIN = EOF
<pbx>
but was assuming that in the TCP code i could just flag it on a bitfield somewhere
<heat>
you can
<pbx>
and never let that packet hit the socketland queue
<heat>
so what happens there in your code? try and pop a packet, and if you fail, check EOF? does that mean you wait outside the rcv queue code?
<heat>
what if you try and represent all these conditions in generic stuff? does this mean your list stops being a list of packetbufs, but something generic?
<heat>
is this generic stuff actually pleasant to work with?
<pbx>
already gave me some headaches for the pbuf structure in the low level parts of the networking stack
<heat>
the general idea behind existing big networking stacks is to KISS
<pbx>
KISS in code size or in concepts :)
<heat>
a good chunk of linux's tcpv6 code is copied from tcpv4
<heat>
hopefully that answers your question :v
<pbx>
generic stuff means less repeating yourself, so smaller code
<pbx>
fair.
<pbx>
which is actually why i moved back to manual linked lists
<heat>
but less optimal code, and maybe way more complex because you need to go around your fancy abstractions to implement X
<heat>
that was ultimately what made me think it's not worth it
<heat>
i was going around the rcv queue abstraction way more than actually using it effectively
<pbx>
meh. i have the recv() callback delegated to the socket af/protocol either way
<heat>
my solution: inet sockets have a spinlock and a linked list of packets
<pbx>
and unix sockets?
<heat>
inet sockets have a function to append a packet
<heat>
not there yet, they will require something similar
<heat>
any logic to read from the queue, poll the queue, wait for the queue is implemented by the specific inet protocol
<pbx>
yeah, i implemented most of ipv4,ethernet,arp and some basic icmp but decided i want to have my sockets stuff in place before i start writing UDP, then TCP
<pbx>
and i figured that unix sockets were the proper way of testing the general sockets code
<pbx>
much less complexity on the protocol end of things, for one
<heat>
i have some unix sockets, but not much
<heat>
haha have you seen fd passing? glhf
<pbx>
yeah. that stuff's
<pbx>
special
<heat>
what garbage collector algo are you using?
<heat>
:P
<pbx>
didn't figure i needed one yet. but yeah if fd's aren't strictly owned by processes anymore and can be in flight i guess that could be necessary
<pbx>
right now it's just refcount and destroy when counter hits 0
zaquest has quit [Remote host closed the connection]
<heat>
to be clear, that's only used in unix sockets code
<heat>
not struct files themselves :)
<pbx>
what for then? don't really see where it comes in precisely?
* pbx
feels unknowledgeable for once. makes me happy i picked up work on the kernel again.
zaquest has joined #osdev
<heat>
i create a unix socket, and then send a bunch of fds over it, but they remain in flight
<heat>
then i create another unix socket and send that unix socket over it
<heat>
then i send the 2nd unix socket over the 1st one
<heat>
etc
<heat>
:)
<heat>
you can get a big mess of loopy bois
<pbx>
eek
<heat>
traditionally unix systems implement a mark and sweep gc over the sockets
<kof123>
<reads backlog> heat: kof123, when you mean "rangelist" don't you mean partition? its just a made-up word. it is just a "list" or array, whether linked list or whatever else can be accomplished by sticking "pointers" inside that "extra data". yes, there's actually a "header" in front, and will want some MBR type thing or whatever else if using on a real disk. but would you "partition" your ram? its just a made-up term meant to
<kof123>
be generic.
<heat>
sure I can partition my ram
<heat>
creating new terms sucks :) being familiar is good
<pbx>
i had gotten so comfortable in my niche of security research and reverse engineering. hated being the subject matter expert
<kof123>
let me rephrase that, would a non-heat person partition their ram?
<heat>
if you said you're about to rangelist the shit of my ram i would be clueless
<heat>
yes! block devices don't necessarily involve blocks or devices
<heat>
such as files and directories not involving files or directories in any way shape or form :)
<pbx>
heat: great. now you reminded me of my os's other big overdue rewrite: the virtual memory manager and block cache
<heat>
that's probably the problem you should tackle first :D
<pbx>
meh. current stuff works
<pbx>
just not future proof- no way i can realistically add true shared mappings and CoW to it
<heat>
that's pretty important
Burgundy has quit [Ping timeout: 246 seconds]
<heat>
fork is already bad enough with CoW ;)
<pbx>
shared memory exists and works, in the form of SysV shm objects,
<pbx>
yeah fork is not great on my system atm
<heat>
>sysv shm objects
<heat>
that's my cue to BLOCK YOU
<pbx>
hahaha
<pbx>
i managed to build a working display server on sysv ipc
<pbx>
that was a big inspiration back then :) i basically did a speedrun to crappy userland
<heat>
i'm entirely convinced any of these IPC mechanisms posix has are crap
Vercas6 has quit [Remote host closed the connection]
<heat>
pipes are good, unix sockets are good, shared memory is good
<heat>
the rest is poopy
<pbx>
meaning that the upper layers of my kernel are decent-ish, but the deep stuff is rushed crap designed by a teenage pothead
Vercas6 has joined #osdev
<heat>
>rushed crap designed by a teenage pothead
<heat>
hey have you met 4.4BSD and CSRG
<kof123>
"pipes are good, unix sockets are good, shared memory " those a re also things i want to stick in that "extra data" but i can horrify you one better
<heat>
oh, please do
<pbx>
still surprises me i managed to port the piece of shit that it was back then to ARM
<kof123>
an "entry" is 2 addresses. an "address" is a multiple of a c89 type. and then there is an "index" which is also a multiple of a c89 type. so really there is a header in front that says which of known c89 sizes of types/etc. so there's about 23 and 54 or something of each. i will probably implement a few :D
<kof123>
so its really just 2 types: an "index" and an "address" all defined as multiples of c89 types lol
<kof123>
its meant to bridge bootloader/nasm code and jump into c lol
<zid>
heat: IPC is bad
<zid>
making it good is a fool's errand
<heat>
kof123, huh?
<zid>
keep it bad to discourage its use
ThinkT510 has quit [Ping timeout: 246 seconds]
<heat>
confused.jpeg
<heat>
IPC IS BAD
<heat>
REFUSE COLLABORATION
<zid>
My process, my data, my rules
<zid>
If you want something from me, send a letter.
<zid>
With return postage.
<heat>
sounds like unix sockets to me
<heat>
hrm, postalfs time?
<heat>
send a letter through great Everyting Is A File mechanisms
<zid>
we already have a transactional database for sending data between processes
<heat>
but the reset vector is still the reset vector
<heat>
based counting
<heat>
my experience with the reset vector is that there's a lot of fuckery involved to get to 32-bit because of the weird code location and shit
<heat>
i struggled to convince gas to give me useful instructions
<pbx>
heat: idk. my brain's been poisoned by retro and hobby architectures, where the reset logic bootstraps the pipeline into fetching that first real instruction
<pbx>
heat: that's mostly outside the core though
<clever>
pbx: the arm reset vector on the rpi is also a pretty big lie
<clever>
given that there is a whole other dual-core processor that does a crap-ton before the arm even gets power
<clever>
and the arm reset vector is just pointing into ram, so something has to write to that ram
<mxshift>
in PHBL's case, PSP has done a bunch of work but x86 cores have not. PHBL's entrypoint should be the first x86 instruction executed
<heat>
still did some uops probably
<pbx>
mxshift: idk shit about how AMD does things, unfortunately
<heat>
at least intel auto applies microcode from the FIT
<pbx>
especially considering that is what i'd be allowed to talk about if i knew
<heat>
you must PROTECT THE SACRED INTEL IP
<mxshift>
PSP is a cortex-a5 that starts up first. Similar to ME but it also does DRAM training and a bunch of other things.
ThinkT510 has quit [Ping timeout: 252 seconds]
<pbx>
must be on the CPU/IO die then, right?
<mxshift>
yup
<mxshift>
it sits on the SoC's internal management network (SMN)
<bslsk05>
doc.coreboot.org: AMD Family 17h in coreboot — coreboot 4.17-1748-g6ae4d2e0a6 documentation
<clever>
this explains how the amd PSP works
<pbx>
i work in whatever :) breaking things when needed, be it in the CPU in the firmware agents or wherever
<heat>
they need your help in uefi
<clever>
similar here, one day i'm working on rpi firmware, the next day i'm working on zfs drivers in linux
<CompanionCube>
or lk :p
<clever>
yeah, also doing zfs in lk as well
<heat>
zedfs should be illegal
<heat>
crimes against sane fsync
<mxshift>
as for when the rest of the Oxide boot software will come out, definitely by the time we ship product
<clever>
heat: but muh checksums!, i need zeefs! :D
<heat>
>zeefs
<mxshift>
that includes tools to set/modify APCB, package into EFS, and all the platform init stuff in illumos
<clever>
heat: canadian :P
<pbx>
but yeah, if you guys ever wanna see how this all works, i did release most of the info you'd need to disassemble pentium II ucode before.
<heat>
mxshift, how does amd let you release TOP SEKRIT code like that?
<pbx>
before I ever joined the company that is. all clean RE :)
<clever>
pbx: how much do you know about the rpi hw?
<pbx>
not much, i know that the arm core is an afterthought next to the mediasomething
<clever>
videocore
<klange>
i know that it does not taste like raspberries
<mxshift>
heat: I don't deal with the legal parts
<pbx>
my arm boards of choice were always TI things, because they at least had some real docs
<clever>
pbx: the VPU on the rpi is a dual-core processor, with scalar and vector opcodes, out of reset, only 1 VPU core is running code from a maskrom
<heat>
klange, tastes like wafers maybe
<clever>
pbx: that rom loads bootcode.bin, which does ram init and loads start.elf, which does more init, loads kernel.img, and turns on the arm core
<pbx>
fun :)
<heat>
but HAVE YOU HEARD OF UEFI
<heat>
when your bootstrap processor bootstraps your real bootstrap processor, you go through a 5 phase extravaganza
<clever>
pbx: and ive been working on replacing the firmware
<heat>
ALL THE EXTENSIBILITY YOU'LL EVER NEED
<zid>
heat: Did you manage step 2 are you still ruminating on it?
<heat>
ALL THE F E A T U R E Z
<heat>
zid, oh yeah fuck ipc
<pbx>
i've never really got why the Pi is so popular, with it's terribly closed architecture
<heat>
cheap
<clever>
yeah, cheap i think is the key factor
<pbx>
(at least where i live) it was not much cheaper than the beaglebone black back in the day
<clever>
i think a RPF blog had said, they are taking moores law in the other direction
<clever>
instead of getting double the compute for the same price
<clever>
why not get the same compute, for half the price?
<pbx>
but idk. TI SoCs have always had way more useful docs, NXP wasn't terrible either
<heat>
because rpi are slow?
<clever>
if you only want to fiddle with gpio and learn coding, you dont need more compute
<geist>
pbx: also notice that the BBB is gone
<geist>
TI got out of the biz of making consumer stuff
<clever>
heat: more, that its enough to write simple code and blink LED's
<heat>
clever, you can use a pi zero for that
<clever>
yep
<geist>
i would have loved it had TI stayed around and was the general ARM supplier of good solid cheap SOCs. they had fantastic docs
<heat>
you don't need a 4 core 8GB thing to flash LEDs
<heat>
that's not why it exists :)
<pbx>
geist: is it?
<clever>
heat: exactly, which is why they are able to get away with such a weak cpu, which is then cheap
<pbx>
both board and soc still seem available
<geist>
BBB is ancient. there are no new socs that TI has put out in consumer space for years
<pbx>
true. which is why my surprise was at the stuff back in the day
<geist>
they basically decided to only go for high margin markets. military, cars, etc
<heat>
graphing calculators
<klange>
the rpi was originally pushed as actually being a computer, over non-competitor arduino products
<pbx>
still prefer BBB to pi's for my purposes. don't need a ton of compute, but being able to work with the HW more closely is worth a lot
<pbx>
also the PRUs are awesome
<geist>
sure. it is however at least 10 years old now. Cortex-a8, 32bit only, etc
<clever>
pbx: the PIO's on the rp2040 can do similar, but thats got far less ram
ThinkT510 has joined #osdev
<geist>
cortex-a8 was state of the art circa 2008 or so
<heat>
the ti nspire cx II supports python
<heat>
see, high perf
<pbx>
yep. but it fit a niche in my use cases. having a real os at my disposal, but also powerful IO
<heat>
i wonder if they disected the shit out of it yet
<heat>
the old nspire CX had linux support *in-tree*
<bslsk05>
lolpro11/linux - Arch Linux on the TI-Nspire CX II CAS (0 forks/6 stargazers)
<clever>
pbx: there is also a lot of untapped peripherals on the rpi soc, that could help certain use-cases
<clever>
pbx: ive been trying to document all of those undocumented bits
<pbx>
yep. but docs, or lack thereof
<heat>
CompanionCube, perfect
<pbx>
for my projects i needed to be able to spec how the IOs would perform
<heat>
no TI-nspire shall be unlinuxable
<klange>
I have an original nspire CAS I should do _something_ with...
<clever>
pbx: the DPI peripheral on the rpi is meant to be a video output, pixel clock, hsync, vsync, 24bit parallel digital video
<heat>
port toaru to arm32
<clever>
pbx: but it could be abused for non-video things, its just taking 24bits from each slot in a bit `uint32_t[]` and presenting them on 24 pins, at a defined rate
<klange>
_no_
<heat>
hater
<clever>
heater :P
<heat>
heat
<heat>
wow they did not upgrade the II's hardware did they
<heat>
it's still an armv5
<PapaFrog>
Whoever LittleFox is, thank you.
heat has quit [Ping timeout: 260 seconds]
<geist>
hmm, what cpu is it?
<geist>
arm9tdmi?
<geist>
yah looks like some arm9
<pbx>
thats always confused me about arm
<pbx>
the core vs chip names
<pbx>
sorry, core vs arch names
<pbx>
arm9tdmi being armv5 etc
<zid>
yea fuck that noise
<zid>
I didn't actually know there was an arm9tdmi, can I mod one into my gba
<clever>
pbx: i think names like armv6, armv7, armv8 are overal classifications, like x86-32 or x86-64, and then cortex-a7 is a specific implementation of one of those, and people like apple can also pay a license fee and make their own implementation from scratch
<clever>
and arm has a range of pre-made implementations (the cortex-a and cortex-m lines) you can also license out
<pbx>
yup
<pbx>
but for the older stuff you get cores still named ARMn implementing ARMvm with n!=m
<clever>
yeah, arm1176 and such, are just a mess
<geist>
indeed. but then i think it's pretty easy to grok armvN is a version of the spec, everything else is.... well look it up
<geist>
but yeah i think they switched to cortex kinda for that reason at the start of the armv7 'reinvention'
<geist>
armv7 (about 2008) was when they started getting interested in being a real open architecture and whatnot, and a bunch of stuff changed simultaneously
<geist>
cortex, more open specs, better documentation site, etc
<geist>
release of the embedded cores
<geist>
prior to that they were more just licensing cores and maybe giving you docs if you signed an NDA or whatnot. kinda like getting something from designware or synaptics
C-Man has quit [Read error: Connection reset by peer]
h4zel has quit [Quit: WeeChat 3.0.1]
srjek has quit [Ping timeout: 260 seconds]
bgs has joined #osdev
<joe9>
ori, I am sorry but I am confused. Would you mind sharing your workflow when you commit to a public repo? I have a new repo that I want to host on git.9front.org.
<joe9>
when I created 9ferno, I think you set it up for me.
<joe9>
and I would just push to it.
<joe9>
now, I am trying to do it all from scratch.
<joe9>
I read through the file /bin/newrepo
<joe9>
that does has git/init and adds contact and description.
<zid>
do they not have a page telling you how to make a repo on their site
<joe9>
wrong channel, sorry.
<zid>
for github you click a button and it makes an empty repo for you
<zid>
then you can clone it which makes it a remote
<zid>
and you have push access because it has your ssh key
SpikeHeron has quit [Ping timeout: 268 seconds]
<zid>
mjg: You love freebsd right?
<zid>
might be past your bedtime though
<zid>
wtf is pouderie
<zid>
poudrierer
<CompanionCube>
isn't that a tool to build ports for you?
<klange>
github's instructions have historically been to `git remote add` and then push a repo, with the created repo being uninitialized - nothing to clone
<pbx>
hmm. anyone know what the expected behaviour for connected DGRAM sockets is on recv(): drop misaddressed packets, or keep them queued
<pbx>
?
tomaw has quit [Quit: Quitting]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
tomaw has joined #osdev
<sham1>
Probably dropping, since there is no guarantee that the datagrams ever get to you
<sham1>
As per POSIX: Provides datagrams, which are connectionless-mode, unreliable messages of fixed maximum length.
<sham1>
Unreliable
<sham1>
As opposed to something like SOCK_SEQPACKET which is somewhat similar but reliable
<sham1>
Although that of course is closer to SOCK_STREAM than DGRAM
<pbx>
pbuf_free(pbuf); goto retry; it is
clever has quit [*.net *.split]
sm2n has quit [*.net *.split]
MrBonkers has quit [*.net *.split]
k0valski1889 has quit [*.net *.split]
Arsen has quit [*.net *.split]
qookie has quit [*.net *.split]
gjnoonan has quit [*.net *.split]
bombuzal has quit [*.net *.split]
remexre has quit [*.net *.split]
DonRichie has quit [*.net *.split]
ckie has quit [*.net *.split]
basil has quit [*.net *.split]
ephemer0l has quit [*.net *.split]
ElementW has quit [*.net *.split]
Arsen has joined #osdev
remexre has joined #osdev
gjnoonan has joined #osdev
sm2n has joined #osdev
<mjg>
ddevault: luller
ElementW has joined #osdev
<ddevault>
wut
MrBonkers has joined #osdev
basil has joined #osdev
bombuzal has joined #osdev
ckie has joined #osdev
DonRichie has joined #osdev
vdm has quit [Quit: Client closed]
Arsen has quit [Quit: Quit.]
qookie has joined #osdev
clever has joined #osdev
Arsen has joined #osdev
<mrvn>
What do you mean with misaddressed packets?
<sham1>
Probably means ones where the machine receives it even though it shouldn't according to the IP. (I'm assuming they're not just gonna drop broadcast UDP because that there would be silly)
vdamewood has joined #osdev
<ddevault>
anyone know if it's possible to convince objcopy to create an ELF file with a custom section name whose contents are an arbitrary file, and put nothing else in the file?
<ddevault>
basically --add-section without an input file
<ddevault>
objdump -I binary -O elf64-little --rename-section .data=.foo foo.input foo.o almost works but creates symbols
<mrvn>
as soon as you have a netmask you should have a broadcast I figure
<clever>
thats what i expected as well
<mrvn>
ip/31 might be tricky
<clever>
i set the ip and prefix length, it should have figured the rest out, but it didnt
<mrvn>
clever: broadcast you be .0 or .255 or anything really.
<clever>
inet 10.0.0.1/24 scope global enp4s2f1
<mrvn>
not the most common prefix length for 10.x.x.x
<clever>
mrvn: i believe sending to the broadcast 10.0.0.255 would still work, but software i use isnt auto-detecting that
<clever>
i was 192.168.2.0/24, until i upgraded the modem last week
<clever>
the old setup, has an ONT that did fiber<->ethernet conversion, the ethernet had vlans, dhcp on one vlan, and boom, internet
<clever>
the new "modem" is an SFP module...
<clever>
and its currently slotted into the ISP router, which was already 192.168.2.x, clashing with my personal router
wand_ is now known as wand
<ddevault>
finally I can start writing drivers
<mrvn>
Interesting is also what to do with packets with the MAC of one NIC and the IP of another.
<mrvn>
or 127.x.x.x
<pbx>
mrvn: i meant when you have connect()ed a DGRAM socket, recv() should only receive packets from the peer
<pbx>
but it is not specified what happens to the other packets after you connect({AF_UNSPEC}) again
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
<mrvn>
pbx: If you bind then you get everything with destination your socket. If you connect then you only get packets with source+dest matching. You can't do bind and connect.
<mrvn>
That's what I expect.
PapaFrog has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
<pbx>
mrvn: you mean connect, right?
<pbx>
afaik, at least on AF_UNIX, bind() sets the local address for the socket, and connect() the peer
PapaFrog has joined #osdev
<pbx>
and setting a peer on a DGRAM means only getting it's messages
ephemer0l has joined #osdev
PapaFrog has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
Vercas6 has quit [Quit: Ping timeout (120 seconds)]
heat has joined #osdev
<heat>
pbx, im fairly sure you can't connect twice
<heat>
unless there's something *big* I've missed
<heat>
aha, i did miss something big
<heat>
"If the sa_family member of address is AF_UNSPEC, the socket's peer address shall be reset."
<heat>
pbx, reading the fineprint, it's pretty clear what happens
<heat>
"For SOCK_DGRAM sockets, the peer address identifies where all datagrams are sent on subsequent send() functions, and limits the remote sender for subsequent recv() functions."
<heat>
if the peer address is reset, it's no longer limiting
xenos1984 has quit [Ping timeout: 250 seconds]
<heat>
in reality this AF_UNSPEC trick doesn't seem to be very well specified
<heat>
the linux manpage for connect says "Some protocol sockets"
jjuran has quit [Ping timeout: 264 seconds]
<heat>
freebsd has funnier behavior
<heat>
"Datagram sockets may dissolve the association by connecting to an invalid address, such as a null address."
jjuran has joined #osdev
Vercas6 has joined #osdev
kindofwonderful has joined #osdev
<kindofwonderful>
Operating System Development
<kindofwonderful>
you guys are the real Gangstas
<heat>
absolutely fucking not
<heat>
no one here is a gangster
<kindofwonderful>
you are
<zid>
idk, I've seen heat popping a cap in a foo
<heat>
we're pussy ass nerds
<heat>
that occasionally pop a cap in dem fools yo
<GeDaMo>
Straight outta coredump :|
<kindofwonderful>
and here's the head of the Family ^
<kindofwonderful>
GeDaMo Soprano
<heat>
stop snitchin yo
<heat>
the sopranos were definitely not gangsters either
<j`ey>
ugh debugging stack corruption :{
freakazoid332 has joined #osdev
<kindofwonderful>
j`ey: sounds cool
<kindofwonderful>
i like the words stack and corruption
<heat>
do you like corruption?
xenos1984 has joined #osdev
<kindofwonderful>
no
<kindofwonderful>
i like stack corruption
<heat>
j`ey, hello heat consulting what can i do for you
<j`ey>
heat: tell me how to fix my stack!
<kindofwonderful>
lol
<heat>
step 1) don't fuck it up
<kindofwonderful>
j`ey: is the consiglieri in the family
<j`ey>
alright, let me get on that
<kindofwonderful>
give or take
<heat>
that's also not a gangster term
<heat>
j`ey, but srs how did you fuck it up such that the stack frame is getting overrun
<heat>
signal stack frame, that is
<kindofwonderful>
heat: there was a time i did some assembly believe it or not
<kindofwonderful>
lol
<kindofwonderful>
i know zid wouldn't but I DID
<j`ey>
heat: im not sure yet.. and I just started to make progress and then came home frm the office ..
<mrvn>
heat: well, null or 0.0.0.0 would be ANY
<mrvn>
heat: what would be another invalid address?
<kindofwonderful>
mrvn: i cancelled my university registration
<heat>
mrvn, null is not a valid address you can pass
<heat>
(in most implementations)
<heat>
j`ey, assuming this is a kernel problem i'd stick a canary in there or something and keep verifying it
<j`ey>
heat: it's the stack of the userspace
<heat>
i know
<kindofwonderful>
it's corrupt ?
<mrvn>
heat: maybe, if sockaddrlen is 0 wouldn't null be ok?
<heat>
it's embezzling funds
<j`ey>
I also want to see if I can turn off aslr or whatever, to get deterministic addrs
<mrvn>
heat: but I ment null address and not a null pointer
<heat>
mrvn, i dont believe so
<heat>
it /may/ depend on the protocol family though
<mrvn>
heat: probably UB but with the length being 0 nothing should dereference the pointer
<heat>
but in practice what happens is
<heat>
if (addrlen != sizeof(sockaddr_in)) return -EINVAL;
<mrvn>
true.
<mrvn>
but that is totally valid
<heat>
and this is in fact the behavior specified by posix
<heat>
BUT i don't see why your proposed behavior couldn't be valid
<mrvn>
but as said I was refering to the null address you mentioned, which would be 0.0.0.0 for IPv4 or INET_ANY
<mrvn>
so makes sense that connecting to INET_ANY does dissolves the connection
<heat>
maybe?
<heat>
the language seems very vague here
<mrvn>
sockets kind of lack a disconnect(). You can shutdown the FD in eigther direction but how would you get it back open?
<heat>
apparently, by connect(AF_UNSPEC)
<heat>
which seems to be supported by UDP and TCP in linux
<heat>
and is required to be supported in DGRAM by POSIX
<heat>
bsd sockets are kinda shit
<mrvn>
is AF_UNSPEC in POSIX?
<heat>
everything is vague enough that lots of systems have different behavior
<kindofwonderful>
heat: you are on my speed dial now
<heat>
no
<kindofwonderful>
yes
<heat>
no
<kindofwonderful>
yes !!
<heat>
i'll ignore you if you ping me randomly
<kindofwonderful>
no
<heat>
ban evader
<heat>
ddevault, btw you might find fuchsia's driver useful. i certainly did
<heat>
although they only support newish gens
<ddevault>
I was just thinking it might be better to skip these docs and start from the libgbm entry points I would use on Linux and work my way through the code
<heat>
i would not recommend it
<heat>
drm is huge
<ddevault>
I am not particularly uncomfortable with large codebases
<ddevault>
and have already spent some time in all of this shit
<heat>
if you're already going through it, just steal drm
<heat>
like most unixes do
<ddevault>
nah, maybe later
<heat>
i've found the i915 driver really fucking hard to read
<heat>
because of all the tiny indirections and gen-specific callbacks
<sham1>
It's interesting that a lot of the DRM code in Linux seems to be MIT or equivalent
<heat>
it's because of mesa, X11, etc afaik
<sham1>
Meh, makes it easier to potentially steal. At least from the point of view of the law
<heat>
most of this really is MIT-like licensed
<heat>
most drm drivers are dual licensed too
<heat>
also the OG dri was MIT iirc
<sham1>
Would explain it
<heat>
i've thought about porting DRM
<heat>
but it's also one of those things that like, really? do I really want that?
<heat>
if I have DRM I must bring in mesa
<heat>
two huugeeeee blobs of code
<heat>
i could just "have fun" writing a vulkan driver
<heat>
then if I really wanted opengl I would use mesa's zink
<heat>
but do I have time for that?
<heat>
lots of tough questions
<sham1>
And then there's stuff like "well how would you firmware"
<heat>
that's not quite an issue
<heat>
just linux-firmware
<sham1>
But wouldn't that require some linux compat for the drivers
<heat>
no
<heat>
linux-firmware is just a repo full of blobs
<sham1>
Like beyond just yoinking the DRM code. No?
<sham1>
Well how do the blobs do their thing
<heat>
they get loaded
<heat>
through sysfs iirc
<sham1>
And I would at least imagine that the blobs need some special interfaces
<heat>
no?
<heat>
these get loaded to the GPU
<sham1>
Oh
<mrvn>
sham1: the kernel detects the device and generated a udev event, udevd sees the event, loads the firmware and tells the firmware where to find it in ram.
<sham1>
Like over the PCI bridge
<sham1>
Hmm
<mrvn>
sham1: the driver then does upload that to the device
<heat>
the point is that fw runs on the GPU, not in your CPU
<heat>
and same for wifi, etc
<sham1>
Well that would explain it then
<sham1>
Of course I'd wonder why it's just not in the device in the first place, but oh well
<j`ey>
updates etc
<mrvn>
sham1: costs, updateability
<heat>
the i915 runs fine without firmware for instance
<heat>
i imagine it must have some already flashed
<sham1>
Hmm okay, cost is one thing yeah. But for updateability I'd see that it could easily be made so that you could update the device alongside other system firmware
<heat>
i think the devices usually have ROM
<mrvn>
sham1: then you would need expensive flash
<mrvn>
and some way to recover from a bad flash
<sham1>
Yeah, you would. But the devices are already expensive as they are
<mrvn>
sham1: irrelevant. every cent saved matters
<sham1>
I suppose
<heat>
wifi is cheap for instance
<sham1>
Alright, I see
<sham1>
Interesting
LostFrog has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
air has quit [Ping timeout: 260 seconds]
PapaFrog has joined #osdev
kindofwonderful has quit [Ping timeout: 268 seconds]
<mrvn>
heat: would be hard to upload the firmware if it doesn't show anything on the monitor by default.
eck has quit [Quit: PIRCH98:WIN 95/98/WIN NT:1.0 (build 1.0.1.1190)]
eck has joined #osdev
<mrvn>
heat: normally you get a rom with basic firmware and then updates are uploaded to ram
Ermine has quit [Quit: Cya!]
gamozo has joined #osdev
Ermine has joined #osdev
gamozo has quit [Client Quit]
<pitust>
apple doesnt do that, for at least some stuff afaik
<geist>
still got a lingering cough from this damn cold
<geist>
nearly a week and a half on
wootehfoot has quit [Read error: Connection reset by peer]
<mrvn>
sure it's not covid?
<geist>
i dont think so mosty because i have covid tested a few times and came back negative. but it's possible. tis why i'm mostly just quarantining myself
Shambles has joined #osdev
Shambles has left #osdev [#osdev]
<mjg>
on a positive note i somehow managed to do nothing this week
<mjg>
well i did quite a few things, but none i would consider real work as a programmer
air has joined #osdev
air has quit [Ping timeout: 260 seconds]
<heat>
mjg, are you sure you don't want a fancy new title?
<heat>
programmer sounds dumb
<heat>
Principal Software Architect?
<heat>
then you can get promoted to VP of FreeBSD
<mjg>
code base influencer
<heat>
president of performance
<heat>
chief flamegrapher
<zid>
Lock Spinner
<heat>
noooooo not a spinlock
<heat>
spinlocks bad
<heat>
or spinlocks good
<heat>
depends if you're in kernel mode or not
<mjg>
not this fucking debate
<sham1>
Spinlocks are neutral
<heat>
chaotic neutral
<mjg>
i made the mistake of buying monster energy drink yesterday
<mjg>
i remembered this crap tasting like bubble gum
<heat>
yeah it tastes funny
<heat>
i much prefer red bull
<mjg>
got myself a mango-flavored loacl brand
<mjg>
i was unable to take more than 2 sips of that monster thingy
<mjg>
red bull tastes like crap
<mjg>
i remember first and only time i overdosed on this crap
<mjg>
was studying for my first exam in college
<mjg>
around 5 am i was so tired i decided to take a nap, but could not fall asleep whatsoever
<heat>
nah i like red bull
<mjg>
you also like c++
<heat>
overall i prefer not to have heart problems
<heat>
but if energy drink -> red bull
<heat>
I don't like C++ lmao
<heat>
i hate every language
<heat>
they're all objectively bad
<mjg>
then may i recommend not drinking energy drinks?
<mjg>
:]
<mjg>
also a sensible sleep schedule is a lpus
<zid>
I'd drink nothing but red bull if I won the lottery
<mjg>
what's the lottery? early grave?
<zid>
the lottery
<zid>
THE lottery
<sham1>
What is this, New Vegas?
<heat>
fallout new vegas but instead of living in a nuclear wasteland you're just so highly addicted to sugary energy drinks that everything else feels sad and depressing
<heat>
i'm liking this writing prompt
<zid>
new writing prompt: write £50 into my paypal
<heat>
fallout new vegas but instead of living in a nuclear wasteland you're living in Liverpool in the 1980s
<mjg>
fallout new vegas but instead you are a game dev working on fallout new vegas
<heat>
lmao
<zid>
new vegas seems exactly like living in pheonix or austin or something rn
<mjg>
got bottle caps as currency?
<mjg>
btw i'm starting Onyx Flamegraph NFT
<mjg>
you can be first before it takes off
<heat>
they should do fallout eastern europe in the 90s
<mjg>
early 90s is lame
<mjg>
i can give you ussr life simulator though
<heat>
the trick is that you end up in 2022 and most of it still looks the same
<mjg>
you stand in line for 10h to buy basic goods
<mjg>
people would team up with their neighbours or family to hold position in line
<mjg>
some lines would literally take days
<sham1>
Well there's already "Eastern Bloc border simulator" in Papers, please
<heat>
eastern bloc is objectively a better experience than 90s post-soviet eastern europe
<CompanionCube>
isn't the 90s sucking hard how putin got elected?
<heat>
CompanionCube, no
<heat>
putin was yeltsin's pal
<heat>
he was /appointed/ by yeltsin
<CompanionCube>
indeed, but in putin's reign the economy was on the upswing and he got credit for that alongside the standard shenanigans
<heat>
yeah
<heat>
mjg, my flamegraphs are more attractive than monke
SGautam has quit [Quit: Connection closed for inactivity]
Burgundy has left #osdev [#osdev]
divine has quit [Remote host closed the connection]
epony has quit [Remote host closed the connection]
<bslsk05>
en.wikipedia.org: Devpts: Difference between revisions - Wikipedia
<heat>
my only edits in wikipedia are pretty much just editting stupid/truebutnotwikipediable shit out
<heat>
editing*
Vercas6 has quit [Ping timeout: 258 seconds]
<mjg>
:)
alpha2023 has quit [Read error: Connection reset by peer]
divine has joined #osdev
<heat>
i don't know what's worse - the tty or the vt100 stuff
alpha2023 has joined #osdev
Vercas6 has joined #osdev
SpikeHeron has quit [Quit: WeeChat 3.7]
<heat>
how do you implement cpu time timers?
<heat>
i imagine you could do something weird in the scheduler but erm, yuck?
<heat>
yeah i guess that's it
<heat>
arm the normal timer if the event falls within the next time slice, if you switch the thread without it expiring unarm it
<heat>
disarm
<heat>
but this becomes a lot harder for process-wide timers
dude12312414 has joined #osdev
air has joined #osdev
dutch has joined #osdev
<clever>
heat: LK maintains a sorted list of when every timer will expire, so it can get the next timer to expire, and scheduling timeslices are just normal timers
<heat>
yes
<clever>
but if your switching to a realtime thread or the idle thread, it will cancel the timeslice timer
<heat>
that is not related
<clever>
and just never force a context switch
<heat>
i'm talking about ITIMER_PERF and ITIMER_VIRT
<clever>
ah
<clever>
what do those count?
<heat>
sorry, PROF and VIRTUAL
<heat>
they measure cpu time
<clever>
ahh
<heat>
measuring is easy
<heat>
getting signals for those isn't
<clever>
if i was to add that to LK, i would probably have a per-thread or per-process list of sorted timers, and compare total time spent against the next timer in the list, when i context switch in
<clever>
and convert it into a normal timer when i context switch
<heat>
that works for thread cpu time
<heat>
not process
<clever>
oh, yeah...
<clever>
because other threads will be consuming cpu time in parallel
<clever>
just accept that it wont account for the current timeslice in other threads?
<heat>
but that doesn't work
<heat>
the current timeslice is the most important one
<heat>
it may also never end
<heat>
if tickless
IRChatter has quit [Ping timeout: 260 seconds]
srjek has joined #osdev
<clever>
check how many threads are scheduled, and count say 3x faster, and then double-check the total spent in the irq, and adjust?
<heat>
i thought of that but that doesn't sound great
<clever>
so if you have say 75ms left on the timer, and your running on 3 cores, set a timer for 25ms from now
<heat>
this is the part where i check freebsd and get horrified
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]