thinkpol has quit [Remote host closed the connection]
thinkpol has joined #osdev
MrBonkers has quit [Ping timeout: 268 seconds]
<kazinsal>
ooh, virtualbox 7 is out? neat
heat has quit [Ping timeout: 260 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
nlocalhost has joined #osdev
<klange>
The only notable thing I found in the release notes is that Oracle is going to patent troll Opus users.
<klange>
Sorry, I mean they're removing Opus support because they're joining a patent pool that intends to stiffle Opus.
<geist>
reminds me, i need to figure out if there's a solution with vbox + win 10 + WSL2. i noticed that since i reenabled WSL2 it killed vbox's hypervisor bits, for obvious reasons
<geist>
but apparentlyt here is a way to coexist, since vmware 15 has no problem with it
<klange>
Yeah, VirtualBox does not play well with anything using HyperV and they print a lovely little message to the machine log telling you to _google for instructions_ on how to disable all HyperV-related features in Windows ;)
<klange>
vmware does... very special things
<zid>
hyperv is weird, as best as I can tell it's windows itself inside a vm, and has an api to tell the hypervisor to start you along side it
<zid>
and normal nesting is disabled
<zid>
so everything needs hyperv support
<klange>
geist: For the ultimate in jenga towers, I enabled nested virtualization for WSL2 and just ran VirtualBox in Linux.
<klange>
The Wayland-over-RDP stuff is kinda slow for the graphical output, but you get your proper hardware virtualization, at least!
<clever>
klange: thats odd, virtualbox on linux has its own dedicated driver/api, that partially co-operates with the kvm driver/api
<clever>
both kvm and virtualbox can be loaded at once, and whichever starts a guest first grabs a lock, and causes the other to fail
<clever>
but once the guest shuts down, it releases the resources in a sane way, and either one can go next
<clever>
multiple guests can start, as long as they all use the same driver/api
<klange>
Yeah, they don't seem to be doing that on Windows with HyperV.
<clever>
how have they screwed windows up that badly, and why is it hiding the answer in the logs and google??
<geist>
that's probably because on the windows thing i think hyperV is just always running when it's enabled
zaquest has quit [Remote host closed the connection]
<klange>
But then I also don't have a "Pro" install of Windows on my Surface, so the availability of HyperV at all is Microsoft graciously letting me use it for WSL, so *shrug*
<clever>
qemu can also use hyper-v directly, so you dont need special drivers on windows
<geist>
right. i think it has a kvm like interface, but i guess vbox just doesn't want to use that
<clever>
geist: ah, that sounds more xen-like
<geist>
dunno if that's the vmware solution (use the hyperv interface)
<clever>
and now i'm wondering, how kvm and virtualbox co-operate...
<clever>
at least on aarch64, linux leaves a tiny stub hvc handler in EL2 initially, and drops to EL1, and i guess something then expands that stub later
xenos1984 has joined #osdev
<klange>
Virtualization stuff on x86 works completely differently from the hypervisor exception levels on ARM, and VirtualBox is x86-only, so best not get your head stuck in that.
<clever>
thats what i feared
<geist>
indeed, however with VHE on arm it looks much more like x86
<geist>
and FWIW, the risc-v virtualiztion stuff looks functionally like arm with VHE
<clever>
is VHE that extension where EL2 kinda looks like EL1?
<geist>
ie, if you're in root supervisor mode you can set up a set of banked virtual supervisor control registers and return to it
<geist>
yeah
<geist>
so i think the gist is while the EL2 thing on ARM looks nice, its very Type 1 hypervisor like, and really didn't end up being what everyone wants
<clever>
yeah
<clever>
and then you pay a pentalty to hvc into EL3 every time your master EL2 wants to do an action that needs hypervisor powers
<clever>
EL2 and EL1*
<clever>
i have used xen in the past, and that fits the EL2 model far better
zaquest has joined #osdev
<geist>
yeah i think where raw EL2 breaks down is the way the page tables i think only let you map the bottom half
<geist>
ie, it seems to not let you run a Real OS at EL2 with user space and whatnot
<clever>
yeah
<geist>
iirc. i might be wrong though, but iirc it only has TTBR0_EL2
<clever>
its meant to just have only the hypervisor, which has access to all system ram, and a single paging able, plus the nested table that applies to EL1?
<geist>
so real type 1s i can think of are ESXi, but it's really more like a lightweight posix OS, with user space and everything, that primarily tuned to be a guest host
<clever>
and no split TTBR0/TTBR1 to support a userland under EL2
<geist>
that's that it seems to me to be
<clever>
i believe xen is also a type-1, but its kinda dumb in some ways
<clever>
xen isnt capable of emulating devices or directly doing virtio style things
<geist>
yah so i'm thinking that's basically what arm was thining at the time: some sort of dumb type 1, kinda firmware ike, not ncessarilly a full OS
<clever>
a userland proc within a guest (not nesesarily the master guest) has to run a cpu-less qemu to handle that
<clever>
so dom1 (normal guest) traps when it hits a virtio doorbell, xen (EL2) then switches to dom0 (the master), and dom0 then unblocks the qemu thread
<clever>
and xen just manages the communication channels, context switching, and memory allocation/mapping
<geist>
now i dunno precisely what hyper-V looks like. i assume its some sort of NT kernel, perhaps running a few processes, so i guess it's really a full thing
<clever>
xen can be configured to run the qemu in another guest, i think they call it driver domains
<clever>
so when dom2 hits the doorbell trap, it passes that off to a qemu in dom1, which is also unprivedged
<clever>
so even if you somehow exploit a bug in qemu to gain execution privs, your still in another guest
<clever>
and now you need a priv escalation exploit, and attack dom0 somehow
m3a has quit [Quit: Lost terminal]
gog has joined #osdev
frkazoid333 has joined #osdev
frkazoid333 has quit [*.net *.split]
zxrom has quit [*.net *.split]
pg12_ has quit [*.net *.split]
smeso has quit [*.net *.split]
xvmt has quit [*.net *.split]
bauen1 has quit [*.net *.split]
fkrauthan has quit [*.net *.split]
sprock has quit [*.net *.split]
antranigv has quit [*.net *.split]
nanovad has quit [*.net *.split]
sham1 has quit [*.net *.split]
cross has quit [*.net *.split]
nanovad_ has joined #osdev
nanovad_ is now known as nanovad
smeso has joined #osdev
antranigv has joined #osdev
fkrauthan has joined #osdev
xvmt has joined #osdev
sham1 has joined #osdev
bauen1 has joined #osdev
[itchyjunk] has joined #osdev
cross has joined #osdev
sprock has joined #osdev
<kazinsal>
geist: it's kind of xen-like; when hyper-v is enabled the bootloader loads ntoskrnl or securekernel with a specific set of modules including hvloader.dll as its "primary" subsystem, which loads the actual CPU-specific hypervisor core and uses that to set up the "root partition", which is the local "bare metal" instance of Windows
rurtty has quit [Ping timeout: 246 seconds]
<clever>
kazinsal: sounds like like xen and dom0
MrPortmaster is now known as MrBonkers
h4zel has quit [Read error: Connection reset by peer]
smeso has quit [Quit: smeso]
<geist>
kazinsal: ah okay, so it's NT but maybe no actual user space?
<kazinsal>
yeah, it's like, a veeeeeery bare NT kernel that exists to run the hypervisor and that's it. all the actual goods are in the kernel or user space of the root partition's windows instance
<zid>
not enough copies of windows, they need to shoehorn a couple more in
<zid>
windows kernel uefi shell, windows running on the ME, etc
smeso has joined #osdev
<geist>
yah makes sense
<geist>
and it's clear the modern xbox has a copy of it too, etc
<clever>
its also similar to my pipe-dreams of making an EL2 hypervisor out of LK, and then also running LK in EL1 too
<clever>
ive got so many projects in my head that i may never start
<clever>
and go one step further, LK in EL3 too, because why not? :D
qubasa has joined #osdev
vdamewood has joined #osdev
<kof123>
"if everything is a file why isn't tracing a file descriptor and why can't you open it in the filesystem" not at that level but i was actually thinking about that in a crude way...
<clever>
kof123: one surprise a friend discovered in the ptrace api on linux, is that the attachment is specific to a PAIR of threads
[itchyjunk] has quit [Remote host closed the connection]
<clever>
so you cant roam your debugger beteen threads within the debugger app
<kof123>
since i am all about metaness, i decided on some "rangelist" structure, which is basically start/end address. and then "extra data" fields. so one can map any structure or database thing that way if they wanted. that is below a filesystem, used for carving up a disk, or ram, or swap, "start/end addresses" -- "its all the same to me" -- ace of spades. filenames/filesystem will live on top of that or then map to those.....leading to wa
<kof123>
nting to have "extra data" fields for a "FILE * stream" fs, file descriptors, etc. the reasoning is simply using similar data structure for carving up disk/ram/etc. lol and then "filenames" like /file_desc/<label> is there a reason to give labels/"names" to file descriptors besides just an integer? i dont know, im all about meta lol
<kof123>
sorry for length, its more in the dream of SSI type things :D
<kof123>
just saying it crossed my mind lol
<kof123>
similar idea for all the various "lock" types
<clever>
kof123: have you seen /proc/PID/fd/ and fdinfo? (on linux)
<kof123>
not in detail, i should look at existing stuff probably. its because i want to reuse that "pair of addresses" structure many places, so have lots of "extra data fields" that are optional, that one can enable for a particular "filesystem"
<clever>
[root@amd-nixos:~]# ls -l /proc/141246/fd/
<clever>
kof123: the fd folder, has a symlink for every open fd in the given pid, but those symlinks are also special, you can open them even if they seem to be a dead link
<clever>
it always clones the fd from the proc, rather then opening the file at the given name
<clever>
sockets show up like this, and if you open the link directly, it will clone the socket fd, and then you can use read/write to inject stuff into the stream
<clever>
kof123: fdinfo then shows the seek position and the open flags
<clever>
so you could monitor the progress of a file copy
<kof123>
yeah, if i ever get that far thats i will end up with, command line utilities that get/set the "Extra data fields" kind of like filesystem "attributes"
<kof123>
*lots of command line utilities
<clever>
one ugly trick ive seen people do before, is using gdb to attach to a process, and then forcibly call exit(0);
<clever>
to kill it, without the parent thinking it was killed
Oshawott has joined #osdev
archenoth has quit [Ping timeout: 264 seconds]
dude12312414 has joined #osdev
DanDan_ is now known as DanDan
<kof123>
my idea is a result of crudeness. <start address> <end address> [extra fields] <-- one "entry", ignoring how this might be sorted or queried for now. thus, a fixed-size for each "entry" (and ability to keep it -- and subfields -- aligned). a pseudofs would just have different optional [extra fields] that suit it -- i.e. more specialized version of same basic structure
<kof123>
anyways....for me its a result of doing the dumbest/simplest thing possible lol
<kof123>
and being "neutral" on e.g. ok that's an address range, are those on a disk? in ram? etc. is that actually file data stored there? so wanting to reuse that same basic thing over and over lol
<kof123>
and is this "list of entries" actually stored on a disk? in ram? all neutral lol
<kof123>
so the hope is i can re-use it many places lol
<clever>
kof123: i'm fairly certain the apollo flight computer used core memory for bloody everything, even cpu registers
<clever>
ive seen a YT vid, where somebody bought a used one on ebay, turned it on, and it resumed a simulated flight like the power had just blinked out for a second
<clever>
that shit dont need no automatic suspend :P
<kof123>
wait...core memory was non-volatile? interesting
invalidopcode has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<clever>
yeah, core memory is basically a hdd with a weird head
<clever>
writing memory to a core magnetizes the core
<clever>
s/memory/data/
<clever>
reading involves writing a known value, and checking if the polarity flipped via a sense wire
<clever>
if it did flip, then it wasnt what you just wrote
<clever>
and so, reads are destructive
<clever>
the other bit, is just a normal row/column matrix, put half the current into a row and column, the magnetic field on most cores isnt enough to re-magnetize it
<clever>
but the one core that is at the focal point, where the active row&column both pass thru the core, will get a double-dose of the magnetic field, and re-magnetize
<clever>
the sense wire, is just weaved thru every single core in the entire array
<zid>
are we doing core memory
<zid>
*reads backwards*, yep
<clever>
that double-dose of field, will initially be canceled out by the core, and when the core flips, it will cause a spike in the field, which induces a current into the sense wire
<zid>
Yea, just let it dump the stored charge to read it, so you need to put it back
<clever>
yep
<zid>
I'm surprised more types of storage don't need it tbh
<zid>
like dram
<zid>
they do refreshes still though
<zid>
just not instantaneously, I guess there's enough charge left that they can.. top it up?
<clever>
i did discover, the sram in the rp2040, has a special low-voltage mode for power saving
<clever>
while in that state, reads are destructive, and may not even return the right data
<zid>
neat
<clever>
but if untouched, it can maintain the data, while leaking less uA
<zid>
Now it's like normal DRAM then :P
<zid>
Rowhammer mode
<clever>
but the controller has no refresh logic, and its still a full web of transistors for every bit
<clever>
its mainly intended for sleep modes
<clever>
both cores will wfi/wfe, and then the ram voltage is ramped down
<clever>
upon wake-up, it ramps the voltage back up, then sets the arm loose
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
frkazoid333 has joined #osdev
<kof123>
"and so, reads are destructive" that makes sense. i have an old radio shack dictionary of electronics 1970s that has something like that...i dont think dram was around...that explains that :D
<kof123>
it needed "refreshed" somehow after a read, mystery solved lol
Vercas6 has joined #osdev
<zid>
I somehow have the 17th most upvoted post on r/osdev s
<zid>
I should make a post designed to get #1..
<moon-child>
too much gameboy, not enough anime girl
<moon-child>
tits get clicks
<zid>
"My new ANIME OS. Pls excuse englando, am 11"
<zid>
In rust
Gooberpatrol66 has joined #osdev
_xor has joined #osdev
smach has joined #osdev
smach has quit [Read error: Connection reset by peer]
eryjus has joined #osdev
eryjus has quit [Client Quit]
bgs has joined #osdev
SGautam has joined #osdev
Vercas6 has quit [Remote host closed the connection]
<bslsk05>
github.com: Onyx/vfs.h at master · heatd/Onyx · GitHub
<heat>
my files are pretty simple
<heat>
bare minimum really
<pbx>
why do you keep the dentry around?
<heat>
you need it to get the filename
srjek has joined #osdev
<mjg>
what do you mean by closed in this context
<pbx>
close(2) on it by a different thread
<heat>
that should just unref it yeah
<mjg>
that should not be a problem
<pbx>
well, jein. for a different process that'd be fine
<heat>
i imagine your system right now is trivially deadlockable in poll
<heat>
two threads, one passes [2, 3], the other passes [3, 2]
<heat>
you naturally lock in each file in poll, and oopsie
<mjg>
i don't know your internal naming, normally peole have a an array of struct file objs indexed into by fd numbers
<pbx>
but for other thread of same process, those share an fd
<pbx>
my internal naming is a bit weird
<heat>
wdym
<mjg>
the invariant here is that the underlying file obj remains refed for the duration of the syscall
<heat>
unix traditional names or death by fire
<mjg>
so in the simplest case you always ref it on fd -> file translation and unref when you are done
<pbx>
fd numbers index into "stream pointers", which are fds in unix lingo. "stream ptrs" refer to "streams" which are files
<mjg>
also meaning close() does not free it from under you
<heat>
oh wow change that ASAP
<heat>
that is so not unix i almost forgot you're talking about unix
<pbx>
meh, 2014-me design choices :shrug:
<mjg>
no matter how you call it or whatever tf, you need to provide an invariant that the obj is safely accessible thorough the syscall
<mjg>
and there you go
<mjg>
it's not hard
<heat>
i think pbx was just locking them
<pbx>
mjg, ok, so add a ref per call. that's a pretty good one
<pbx>
how did i not come up with that before
<heat>
pbx stupid mjg genius
<mjg>
i don't mind sarcastic comments
<mjg>
but then i really wonder how did you run into the problem to begin with
<heat>
mjg, you have gone into the negative IQ range after being forcefed so much unix
<heat>
i'm still in the 40s
<heat>
anyway I pinged you to ask ya if you know if POSIX specifies the behavior of concurrent read calls or lseeks or whatever
<mjg>
i have vague recollection it demands consistency on the file *descriptor*
<mjg>
but linux does not give a fuck
<pbx>
mjg: less experienced me decided to want to have a lock on any state that was being referenced, for fear of concurrent change
<heat>
if you don't exclusively lock a fd, you can get two reads just reading the same thing and if you're not careful, you could end up with a wrong offset
<heat>
(which may be an issue i have rn)
<heat>
normal fear leads you to the dark side
<heat>
fear of concurrent change leads you to openbsd
<mjg>
pretty weird
<mjg>
already does not work even without smp
<pbx>
a lot of stuff in here that needs to be fixed
<pbx>
needless to say, the scheduler and task switching code i wrote back then was a dumpster fire and has been rewritten ground up
<pbx>
heat: my poll implementation is somewhat funky and gets around that issue
<mjg>
so is this an unix-like kernel?
<mjg>
have you ever tried running a test suite from other systems?
<pbx>
i had looked for one a long time ago, didn't find a good one
<pbx>
got a recommendation?
<mjg>
yes and no. linux test project is decent, but a lot of it is linux-specific, so you would need to selectively patch it out
<mjg>
netbsd has a test suite, most of which concerning basic unix functionality
<mjg>
but it may come with crap deps not worth the effort
<mjg>
afair it needs something in c++
divine has quit [Ping timeout: 268 seconds]
tsandstr has joined #osdev
<pbx>
up to now my test strategy has been: try to port some app, see how badly it breaks
<mjg>
i would argue porting ltp is best back for the buck in that case
<mjg>
for one it will tell you instead of failing in a weird manner
<mjg>
s/back/bang
<mjg>
fucking analphabetism, too much php last week
<pbx>
yeah, especially signals have been hard to get right
<pbx>
and more importantly keep getting them right. they've regressed a lot over my process management rewrites
<mjg>
porting an allocator like jemalloc would be fun as well
<mjg>
again comes with a test suite
<pbx>
i was at a point where i had a unmodified bash with working job control
<mjg>
now that iw rote it, glibc has a test suite!
<mjg>
which is also easy to use
<pbx>
after having looked at glibc, i'm not gonna touch that shit with a ten foot pole
<mjg>
dude
<pbx>
something in me cannot stand GNU code
<mjg>
that's drepperism on steroids
<mjg>
if you can stomach finding out how to compile it, you will get rewarded :p
<mjg>
i don't think anyone thinks that code looks decent, any semantics concerns aside
divine has joined #osdev
<pbx>
idk, atm i'm using an (also horrible) modified newlib, with a focus on writing my own code for newly added parts of the API
<tsandstr>
I am playing around with osdev for the first time and am trying to launch a "Hello World" 64 bit kernel using GRUB and UEFI. I have been trying to follow the directions https://wiki.osdev.org/Bootable_Disk and https://wiki.osdev.org/GRUB#Building_a_GRUB_UEFI_binary_.28BOOTX64.EFI.29 but I am running into trouble. From what I understand, the BIOS should find the grub EFI file and launch GRUB, and then GRUB should con
<tsandstr>
tain a memdisk with a config file that tells it how to load the FAT file system and find the "real" config file which points it to the kernel. The problem I am facing is that I land in a GRUB prompt, and the memdisk seems correct, but I cannot access the FAT file system at all. When I run `ls (hd0)`, GRUB complains and says "Device hd0: No known filesystem detected - Sector size 512B - Total size 131072KiB". Any ide
<tsandstr>
as on how to get GRUB to load the file system?
<bslsk05>
wiki.osdev.org: Bootable Disk - OSDev Wiki
<bslsk05>
wiki.osdev.org: GRUB - OSDev Wiki
dude12312414 has joined #osdev
bguebert has quit [Quit: leaving]
dutch has joined #osdev
<mrvn>
If you want to test your posix compatibility then build perl and python.
<mrvn>
tsandstr: the BIOS has no idea what to do with EFI files. you need an EFI for that.
<tsandstr>
mrvn: I am running on QEMU using OVMF... I think that should be an EFI? In any case, GRUB is launching, so I assume EFI is functioning
<mrvn>
tsandstr: and (hd0) should have a partition block, not a filesystem, on it.
<mrvn>
did you mean (hd0,0)?
<tsandstr>
mrvn: How do I check what is actually on (hd0) in GRUB? When I run `ls`, I see (memdisk) (hd0) and (cd0). I don't know how to see any parititons
<mrvn>
If you are using qemu you can just load the kernel directly
<mrvn>
forget about boot media and that stuff for now
dutch has quit [Quit: WeeChat 3.6]
<tsandstr>
mrvn: Can you explain what you mean by that?
<mrvn>
qemu -m 64 --kernel your-kernel.elf iirc
<zid>
hd0 has the partitions
<zid>
hd0,0 etc
<tsandstr>
mrvn: most of what I have been trying to do so far is to implement the multiboot 2.0 spec and traverse the information that I get from the bootloader and from EFI boot services, so I don't really want to bypass GRUB
<tsandstr>
If evrything was working normally, what would `ls` output at the GRUB prompt? Would it show me the FAT partition?
blockhead has joined #osdev
xenos1984 has quit [Ping timeout: 260 seconds]
dutch has joined #osdev
xenos1984 has joined #osdev
theruran has joined #osdev
bguebert has joined #osdev
IRChatter has joined #osdev
tsandstr has quit [Ping timeout: 264 seconds]
xenos1984 has quit [Ping timeout: 268 seconds]
vdamewood has joined #osdev
xenos1984 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
vdamewood has quit [Read error: Connection reset by peer]
bguebert has quit [Quit: leaving]
vdamewood has joined #osdev
bguebert1 has joined #osdev
bguebert1 is now known as bguebert
nur has quit [Ping timeout: 268 seconds]
srjek has quit [Ping timeout: 268 seconds]
bguebert has left #osdev [#osdev]
heat_ has joined #osdev
heat has quit [Ping timeout: 246 seconds]
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
vdamewood has quit [Quit: Life beckons]
<heat_>
mjg, you wrote a test suite for glibc?
<heat_>
i guess they stole bsd's?
<mjg>
you may want to take a one week detox from lsd
<mjg>
kthx
Matt|home has joined #osdev
gog has joined #osdev
heat_ has quit [Read error: Connection reset by peer]
<heat_>
mjg, "now that iw rote it, glibc has a test suite!"
bauen1 has quit [Ping timeout: 252 seconds]
<vin>
What should a scheduler be called that is aware of how many threads it should spawn for an operation and if those threads must be overlapped or not.
mahk has quit [Ping timeout: 255 seconds]
<heat_>
what's "an operation"
heat_ is now known as heat
<vin>
read or write
<vin>
to a device
<heat>
schedulers don't spawn threads for io
<heat>
in fact, schedulers don't spawn threads
<heat>
ever
<vin>
Right, but I have a common system that controls the thread pool size for an operation and if those threads can overlap with each other.
<heat>
ok, that's not a scheduler IMO
<heat>
maybe some sort of IO scheduler
<heat>
but not a thread scheduler, which is usually the meaning for "scheduler"
<vin>
Hmm this gave me some ideas, thanks.
<heat>
you're welcome
<heat>
make sure to assign copyright to me
<heat>
or patents
<heat>
thanks
<vin>
Haha sure :)
wolfshappen has quit [Quit: later]
<zid>
wondered what you said for a moment there, had a window covering irc so it was just make sure you ass
<heat>
make sure you ass though
<heat>
give me all that trunk
<heat>
your lovely lady lumps
<heat>
your hump, your hump, your hump, your hump
nikitalocalhost has joined #osdev
mahk has joined #osdev
Burgundy has joined #osdev
h4zel has joined #osdev
bgs has quit [Remote host closed the connection]
<gog>
hi
netbsduser has quit [Remote host closed the connection]
<heat>
henlo
<heat>
goggers
<sham1>
Evening all
<klys>
happy birthday, heat
<heat>
you're a day late but i still appreciate it <3
<heat>
did you become an expert in old english by becoming part-time nordic
<gog>
no i actually took a couple classes on old and middle english in college
<heat>
aw
<heat>
i prefer my theory
<gog>
it did help me understand some icelandic out of the gate tho
<heat>
hehe he icelandic funny old language
<heat>
i'd love to learn how to read medieval manuscript though
<gog>
pmuch
<heat>
i can kinda do it sometimes but it's hardddd
<heat>
funnily enough i don't only like computers but also humanities stuff
<gog>
same
<heat>
history would be gr8
<gog>
before i landed the computering job was considering going back to school to get a degree in literature or history or smth
<heat>
philosophy too but that sounds more effective if you're tripping ballz
<gog>
i almost gave up on programming as a hobby and desired profession entirely tbh
SpikeHeron has joined #osdev
<heat>
yeah
<gog>
i still migh tidk
<heat>
i mean, i like this too much to not do this as a job
<heat>
but
<gog>
but for now it's a more realistic career and i'm enjoying it
<heat>
i would like to explore what out there
<heat>
sometimes i feel like i'm rushing myself too much
<heat>
working on what you love is great but then I think you become a bit tied up
<heat>
"i could get a bsc in history or travel through europe but i'm too busy typing lines of code for $BIGCORP" seems idunno, maybe not great
<gog>
yeh
<heat>
iDunno new apple product btw
<heat>
ah sorry, ba
<heat>
bsc is for science stuff only
<heat>
what if I say fuck it and go become a doctor
<heat>
just for the laughs
<gog>
idk i think i'm just a pathological malcontent sometimes. my life has improved dramatically in the past few years and i find myself yet again unhappy about a fundamental basis of my life
<heat>
i get dumb just by looking at organs but "haha medic lmao"
<heat>
gog, i feel you
<gog>
and then i wonder if i should go back to therapy
<heat>
i would like to have all the things, at once
<heat>
i went to a psychologist and she told me life is about compromises
<heat>
which yeah, sure
<mjg>
mofo
Vercas61 has joined #osdev
<mjg>
where is the supposed offset locking
<mjg>
i still don't see it for shit
<mjg>
for example
<mjg>
ssize_t ksys_read(unsigned int fd, char __user *buf, size_t count)
<heat>
FMODE_ATOMIC_POS is set for seekable files and dirs
<mjg>
if (file_count(file) > 1) {
<mjg>
v |= FDPUT_POS_UNLOCK;
<mjg>
mutex_lock(&file->f_pos_lock);
<mjg>
wow, i stand corrected
<mjg>
let's check where that showed up
<heat>
manpage says 3.14
<heat>
read(2)
<mjg>
ok that makes sense, i gtfo'd around 3.10
<gog>
heat have you been drinking
Vercas6 has quit [Ping timeout: 258 seconds]
Vercas61 is now known as Vercas6
<heat>
gog, no
<gog>
o
<gog>
you seem uncharacteristic rn to me idk
<gog>
maybe i just don't talk to you enough
<heat>
maybe
<gog>
¯\_(ツ)_/¯
<heat>
i dont usually let out tough issues that trouble me in irc
<gog>
i do because i'm afraid to talk to my real friends
<heat>
aw
<heat>
wait wdym im were not real friends
<heat>
;_;
<gog>
i mean meatspace friends
<heat>
good, good
<heat>
that's understandable but like, erm, just do it
<heat>
thats how you filter fake friendos from the realz
<heat>
i've also just noticed 80% of my life advice is just do it
<heat>
hire me nike
h4zel has joined #osdev
<gog>
it's not entirely bad advice. i'm in a better place i've ever been in ever because i just did things
<gog>
hence my annoyance about still having problems
<gog>
i'm sick of problems
<gog>
how can i be happy and discontent at the same time why is life full of contradictions
<gog>
etc
<heat>
totes
<heat>
i don't think we'll(as humans) ever be free from problems
<mjg>
not enough lsd
<heat>
......
<heat>
yeah maybe lsd helps
<heat>
no problems if you're high as a kite writing sick codez
<heat>
and shaping a whole operating system for decades to come
IRChatter has quit [Ping timeout: 268 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<pbx>
is it just me or does MSG_PEEK seem like an absolutely terrible idea for stream sockets?
<pbx>
especially blocking MSG_PEEK|MSG_WAITALL
<heat>
why?
<pbx>
nothing like walking down the message buffer queue, deciding not everything you need is there, backing out, waiting for more packets to come in
<pbx>
what happens if someone else reads while you're waiting, for example?
<heat>
if you need to go down a buffer queue that's *your* problem
<heat>
right
<heat>
again, that's *your* problem
<heat>
MSG_PEEK is useful if you want to know how much data you have queued up
<heat>
once you start getting threads into the mix, you stop being able to rely on that
<pbx>
i mean, that's the sensible approach to socket input, right? have a queue for the app level packet buffers, and consume those as needed in read
<heat>
erm, sorry
<pbx>
saves a copy to a per-socket byte oriented read buffer
<heat>
MSG_PEEK is useful if you wanna take a quick peek
<heat>
thinked about MSG_TRUNC for a bit
<pbx>
MSG_TRUNC isn't posix, is it?
<heat>
idk
<heat>
I implemented Linux for sockets
<heat>
... which is often the best "standard" ;)
<pbx>
i do cross ref manpages when POSIX is vague, but try to not go overboard with linuxisms
<heat>
>i mean, that's the sensible approach to socket input, right? have a queue for the app level packet buffers, and consume those as needed in read
<heat>
yes
<heat>
but if you need to walk the list if you wanna know how much data you have on your hands, that's your issue
<pbx>
nah, thats fine
<heat>
i don't see why a size_t buflen would work
<heat>
wouldn't*
<pbx>
size_t rq_bytes;
<heat>
ok
<heat>
so where's the issue?
<pbx>
i worry about a PEEK over multiple inbound packets
<heat>
why?
<pbx>
so say i want to PEEK WAITALL 6kB, split over 5 TCP packets. Only 3 are in the queue. I walk down the queue, conclude that 3 packets in the queue ends, release queue lock, wait on "new data" event\
<heat>
yes
<pbx>
new data event comes, but meanwhile another process with an fd to the socket has read some data
<heat>
yes
<heat>
where's the issue?
<heat>
1) I don't see how PEEK comes into play
<pbx>
what do i do: treat the first oppurtunity to grab the full 6k as the "truth" for that call?
<pbx>
give up?
<pbx>
reading is simpler, it just consumes buffers, no guarantee between concurrent calls
<pbx>
also, what happens if i want to peek more bytes than my queue may be large?
<heat>
I don't see how consuming is simpler than peeking here
<heat>
the only difference is that you skip a list_remove
<heat>
if WAITALL you wait for 6KB, simple
<heat>
once you have them, read them
<heat>
>also, what happens if i want to peek more bytes than my queue may be large?
<pbx>
hmm, think i'll go for a read lock on the socket. only one concurrent read/recv/recvfrom/recvmsg at any time