LittleFox has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
LittleFox has joined #osdev
goliath has quit [Quit: SIGSEGV]
adder has quit [Remote host closed the connection]
thesock has joined #osdev
wgrant has joined #osdev
thesock has quit [Quit: Konversation terminated!]
vinleod has joined #osdev
wgrant has quit [Quit: WeeChat 3.5]
thesock has joined #osdev
thesock has quit [Client Quit]
vdamewood has quit [Ping timeout: 268 seconds]
gog has quit [Ping timeout: 268 seconds]
vinleod is now known as vdamewood
X-Scale83 has quit [Quit: Client closed]
levitating has quit [Quit: Leaving]
levitating has joined #osdev
thesock has joined #osdev
Matt|home has joined #osdev
wgrant has joined #osdev
levitating has quit [Remote host closed the connection]
housemate has joined #osdev
thesock has quit [Quit: Konversation terminated!]
housemate has quit [Remote host closed the connection]
housemate has joined #osdev
housemate has quit [Remote host closed the connection]
<zid>
For the americans, remember, if a finger lands on your property, you get to keep it
Brnocrist has quit [Ping timeout: 268 seconds]
Brnocrist has joined #osdev
<kazinsal>
so say we all
<kazinsal>
though note to residents of blaine, wa: if your finger lands on my side of the border, I will not keep it. I just got my trusted traveler card renewed and I do not want to have it taken from me over a lost fingat
heat has joined #osdev
<vdamewood>
kazinsal: So, if it happens, you'll give us the finger?
<Mondenkind>
i want kazinsal's finger🥺
<kazinsal>
vdamewood: whichever agency dealt with the feet washing up on shore twenty years ago can handle the finger
wgrant has quit [Quit: WeeChat 3.5]
wgrant has joined #osdev
<vdamewood>
As long as it's not the people who deided it was a good idea to blow up a whale on the beach.
<vdamewood>
decided*
Gnana has joined #osdev
netbsduser has joined #osdev
<geist>
blaine the train is a pain
<vdamewood>
Blaine has a train?
<kazinsal>
there's probably an amtrak stop there, sure
<geist>
it's a deep reference that i dont expect anyone to get
<vdamewood>
Probably, the Cascades line goes vrom Eugene to Vancouver
<vdamewood>
from*
<kazinsal>
ah, no, there isn't! goes straight from pacific central to bellingham
<kazinsal>
the blaine crossing is my preferred one by car because it has the fun extra lane that lets me skip the hour of waiting
<kazinsal>
thanks to my Certified Not A Terrorist card
<kazinsal>
the Lynden crossing is closer but doesn't have such a lane
<geist>
but yeah teh cascades does go through there AFAIK
<geist>
i always meant to take it
<jeaye>
But how else would you get harrassed about why you're crossing the border on a Thursday afternoon?
<geist>
i was thinking abut point roberts anyway when you first mentioned it
<kazinsal>
actually these days I think I am closer to blaine anyways
<geist>
oh man there are fireworks everywhere outside, and i'd love to continue sitting on the porch listening to it
<geist>
but the mosquitoes are eating me alive
<jeaye>
You'll still hear 'em inside.
<kazinsal>
heh, yeah. nasty lil buggers
<kazinsal>
reminds me, I gotta get down that way this summer for a weekend
<zid>
I hope not
<kazinsal>
my NEXUS renewal came through yesterday so I'm just waiting on my new card
<zid>
If you can hear the mosquitoes through walls they must be HUGE
<jeaye>
Deathsquitos.
<jeaye>
(found in the plains)
<zid>
My mother likes to breed them, for whatever reason
<zid>
I should see how hard it is to breed dragonflies
<heat>
wow i'm up so early the PNWers are still here
<heat>
hi
<geist>
whatever version of mosquitoes are up here in PNW are nothing like the ones we had in texas where i grew up
<geist>
but these will still eventually bite you
<geist>
they love to get all up in your grill
<kazinsal>
they wait for you to let your guard down
<heat>
tech snob mosquitoes vs yeehaw mosquitoes
<Mondenkind>
mosquitoes already in wa? eesh
netbsduser has quit [Ping timeout: 264 seconds]
<Mondenkind>
none up here yet really
<jeaye>
I haven't seen any in Seattle yet, but I also wansn't out on the porch listening to fireworks.
<kazinsal>
there's a good few up near the fraser
<kazinsal>
and runoffs thereof
<vdamewood>
No squitoes yet here in Portland
<geist>
i'm out in the woods, and i think there's some water nearby
<geist>
especially around dusk they really come out
<kazinsal>
yeah, stagnant freshwater is 4loko for the lil bastids
<vdamewood>
Yay! Splody day is over!
<geist>
still a few stray splodies
Matt|home has quit [Read error: Connection reset by peer]
wgrant has quit [Quit: WeeChat 3.5]
vdamewood has quit [Quit: Life beckons]
wgrant has joined #osdev
bliminse has quit [Quit: leaving]
GeDaMo has joined #osdev
MrCryo has joined #osdev
zetef has joined #osdev
zetef has quit [Client Quit]
Matt|home has joined #osdev
bliminse has joined #osdev
op has joined #osdev
Jari-- has joined #osdev
<Jari-->
rock'n'roll
mubluekoor has quit [Quit: mubluekoor]
mubluekoor has joined #osdev
goliath has joined #osdev
Jari-- has quit [Ping timeout: 256 seconds]
X-Scale has joined #osdev
navi has joined #osdev
X-Scale13 has joined #osdev
X-Scale has quit [Ping timeout: 250 seconds]
navi has quit [Ping timeout: 240 seconds]
m3a has quit [Ping timeout: 240 seconds]
Gnana has quit [Quit: ..]
m3a has joined #osdev
goliath has quit [Quit: SIGSEGV]
MrCryo has quit [Quit: MrCryo]
X-Scale13 has quit [Ping timeout: 250 seconds]
mubluekoor has quit [Quit: mubluekoor]
edr has joined #osdev
Left_Turn has joined #osdev
levitating has joined #osdev
m3a has quit [Remote host closed the connection]
Jari-- has joined #osdev
Starfoxxes has joined #osdev
q3lont has joined #osdev
lanodan has quit [Ping timeout: 264 seconds]
op has quit [Ping timeout: 260 seconds]
op has joined #osdev
navi has joined #osdev
Jari-- has quit [Ping timeout: 272 seconds]
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
levitating has quit [Quit: Leaving]
levitating has joined #osdev
op has quit [Remote host closed the connection]
Turn_Left has joined #osdev
Turn_Left has quit [Max SendQ exceeded]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 256 seconds]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 256 seconds]
Gooberpatrol_66 has joined #osdev
Gooberpatrol66 has quit [Ping timeout: 264 seconds]
vai has joined #osdev
mubluekoor has joined #osdev
op has joined #osdev
xenos1984 has quit [Ping timeout: 268 seconds]
xenos1984 has joined #osdev
eau has quit [Quit: bleh!]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 268 seconds]
MrCryo has joined #osdev
MrCryo has quit [Ping timeout: 268 seconds]
xenos1984 has quit [Ping timeout: 264 seconds]
MrCryo has joined #osdev
q3lont has quit [Quit: Leaving]
MrCryo has quit [Ping timeout: 256 seconds]
gog has joined #osdev
xenos1984 has joined #osdev
vai is now known as Jari--
MrCryo has joined #osdev
gog has quit [Quit: byee]
<mjg>
> Problems worthy of attack prove their worth by fighting back.
<kof673>
(with oblig. internet quote beware) “A WORD TO THE WISE Let the world pass in its time-ridden race; never get caught in its snare. Remember, the only acceptable case for being in any particular place is having no business there.”
<kof673>
sounds like vonnegut "we are here to fart around, and don't let anyone tell you otherwise"
<heat>
mjg, are you working on the rcu stat
<heat>
cuz that'll definitely bite back :v
<mjg>
i may over teh weekend
<mjg>
the way the l man is proposing this is too error prone tho
<nikolapdp>
what's going on
<mjg>
i got full smr operation on freebsd few years back, could nto be fucked to get it to a committable state
<mjg>
but it very much relied heavily on maintaining as much sane state as possible
<mjg>
so in particular vnodes not suddenly becoming something else
<mjg>
in the entire ordeal i'm confusing how tf was xfs allowed to not wait for rcu grace periods
<mjg>
confused even
<heat>
that whole convo made me realize i have some weird race condition bugen in my dentry code wrt inodes popping in and out of view
<nikolar>
BUGEN
<nikolapdp>
BUGGEN
<heat>
i *probably* need rcu free deferral there anyway
<mjg>
you don't do the one-time read?
<mjg>
anyway the only real difficulty with this shit is handling the crappers
<mjg>
like LSM
<mjg>
what bites is regrettable hooks which are racy by design
<mjg>
and the vfs folk not interested in changing that
<nikolapdp>
how does the one time read work anyway
<heat>
maybe with a seq count. like: d_inode(dentry) {rcu_read_lock(); do {seq = dentry->d_seq; ino = dentry->d_inode; inode_get_if_not_zero(ino); } while(seq != dentry->d_seq);}
<heat>
that's my idea anyway
<heat>
(with proper error handling along the way)
<heat>
fwiw i don't understand what you mean with one-time read
<heat>
if you mean "taking d_inode out of the dentry to struct file", yeah, i do that, but i need to be careful around that particular bit of code
<mjg>
no
<mjg>
i mean the race l man mentioned
<mjg>
i presume you transition dentries to hold NULL on unlink
<heat>
yes
<mjg>
say you are racing against someone who continuously creates and unlinks on the same name
<mjg>
you may spot inode1, NULL, inode2, NULL, etc.
<mjg>
if you read the inode pointer more than once... ooops
<mjg>
you might have done some shit based on the one pointer, and some shit based on the other
<mjg>
so you make sure to READ_ONCE and stick with it
<nikolapdp>
mjg what does READ_ONCE do exactly
<mjg>
in this context prevents the compiler from fucking with that load
<mjg>
issuing it multiple times 'n shit
<nikolapdp>
so something like a read and a compiler barrier or something
<heat>
i'm worried with just the basic race i mentioned
<heat>
unlink/open, with unlink doing d_inode = NULL and open grabbing a dying inode
<heat>
or dead inode
<heat>
i'm not sure if i actually need a sequence counter there, but i definitely need get_if_not_zero with some rcu protection around that
<mjg>
you need seq at the end to validate the association
<mjg>
i presume you change it when modifying d_inode
<mjg>
fwiw ONYX can probably implement fully-scale rcu usage very easily
<mjg>
because you don't have to deal with this shit
<mjg>
LSM et al
<heat>
i dont have a d_seq yet
<heat>
but yes, that's the plan
<mjg>
q:S
<mjg>
that's bad mon
<mjg>
correctness first
<mjg>
unless you are read-write locking around right now
<heat>
why correctness? i don't have rcu walking yet
<mjg>
ye ok
<mjg>
PESSIM^Wmakes sense
<heat>
OH this is actually not a race here, i lock the last parent dir's inode shared
<heat>
so i can't just unlink it while open is looking at it
<heat>
this might be a problem for other syscalls though, but not open
netbsduser has joined #osdev
<mjg>
so are you faster than illumos at path lookup?
<mjg>
you very plausibly already are
<mjg>
since they take mutexen all the way
<mjg>
tell you what mofo give me an up to date snap
goliath has joined #osdev
<heat>
what for
* geist
yawns
<heat>
hello geist
<heat>
you're safe, the fireworks are gone
<geist>
the explosions continued far into the night
<heat>
ohno
<geist>
like 3am
<zid>
win any fingers?
lanodan has joined #osdev
<geist>
still have all of em!
sham1_ has joined #osdev
sham1 has quit [Killed (NickServ (GHOST command used by sham1_!~sham1@65.20.114.35))]
sham1 has joined #osdev
sham1 has quit [Client Quit]
sham1_ is now known as sham1
<heat>
there's a particularly awful trick i need to pull off here with procfs
<heat>
pid entries and associated subentries need to have lazy inode numbers
<heat>
basically schordinger's inode :)
op has quit [Remote host closed the connection]
Starfoxxes has quit [Remote host closed the connection]
<geist>
i ended up spending like 2 hours yesterday walking through btrfs data structures
<geist>
the btrfs inspect-filesystem command is really really useful
<geist>
i encourage anyone designing their own FS to do something similar
<heat>
what is it?
<geist>
i think i'll brush off my old btree project and finish it off
<heat>
is it debugfs for weirdos
<geist>
it's a command line, the btrfs tool does everything command line wise, but it also has a 'dump all of the data structures' usage
Jari-- has quit [Ping timeout: 256 seconds]
<geist>
with tons of switches to let you control what to see
<heat>
ah yeah okay debugfs for weirdos nice
<geist>
so you can basically dump any of the internal trees
<heat>
yeah xfs also has one, debugfs is ext2/3/4's version
<heat>
it is really really handy
<nikolapdp>
geist you have a btree fs?
<geist>
ah didn't know about debugfs
<geist>
nikolapdp: no but... if you have a btree what best to do with it!
<heat>
yeah ermine was using it the other day to save his corrupted fs
<nikolapdp>
geist, well an fs or a database :)
<geist>
but also would be interesting to take a mature btree and apply it to things like VM data structures, since what works best with btrees than a single block size (pages)
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
npc has joined #osdev
<heat>
yeah that's basically the maple tree
<heat>
fully RCU-able btree
<nikolapdp>
yeah tree structures are nice
<geist>
yah trouble i've generally found is there aren't a lot of good non GPL generic btree libraries around AFAICT
<geist>
plus it's fun to build something like that
<heat>
become GPL-pilled geist
<geist>
noooo!
<heat>
GNU/LittleKernel
* geist
bats it away
<heat>
what spelling of littlekernel do you prefer?
<heat>
LittleKernel? littlekernel? lk?
<geist>
good question, i wasn't thinking much about it
<nikolapdp>
most often you refer to it as lk
<heat>
lk is a little hard to explain to random people
<gog>
hi
<nikolapdp>
oi
<geist>
yah that's the problem. i mean i'm terrible at naming things so i tend to name it the first thing i think of
<geist>
heck i have a previous kernel i never released called `muffle`
<gog>
i'm very good at naming things you should have asked me
<geist>
because, i dunno wasn't thinking
<geist>
everything thinks lk == linux kernel
<nikolapdp>
geist are you referring to a c++ btree library?
<geist>
or C
<gog>
NewOS
<nikolapdp>
lel
<gog>
oh wait that one was already taken
<gog>
by you
<nikolapdp>
geist well if you find a c one, i'd be curious to take a look
<geist>
but yeah, i have it in C++ now, so you ca templatize it
<heat>
haha muffle sounds like a fun name for a... javascript framework?
<geist>
it was a little µkernel i was fiddling with for a few weekends, more L4 like with very minimal interface
<gog>
i'm gonna write a kernel in java called toebeans
<gog>
i was not just looking at breki's paws
<geist>
got it kinda working but then abandoned it and started on a new line of little kernels, uos, and uos2
<nikolapdp>
uh java
<geist>
and then went a little bigger, hence 'little kernel' vs 'µos'
<gog>
yes jav a do you have a problem with that
<gog>
it's no more stupid than my c# idea
<geist>
at the time (about 2005) i was thinking about the L4 style of microkernel a lot
<nikolapdp>
i mean c# is just ms java so :P
<geist>
LK was started out of the guts of uos2
<gog>
well, maybe more stupid because i _do_ have a compiler for native c#
<gog>
it just doesn't have a feature i need and i don't have the nenn to try to figure out how to write it myself
<geist>
actually i may have done muffle after uos. may have bee uos, uos2, muffle, littlekernel
<geist>
but those were like weekend projects, just a basic hello world with some basic context switching
<geist>
on qemu on arm, so it was very fast to get them going
<geist>
that's when i started really following the gospel of booting with `-kernel ` and not fucking around with bootloaders and whatnot
<geist>
just load your shit and go, dont worry about booting on real things, get to the meat of it, play with ideas, discard them, start over, repeat until you find what you like
<geist>
people get so fixated on sequentially implementing everything perfectly, but the key is to move fast and try out ideas and retry, you learn a hell of a lot more that way
npc has quit [Remote host closed the connection]
scaleww has joined #osdev
<kof673>
well, on top of that too...sequential means can get stalled on something. insert pipeline metaphor :D
<kof673>
or dsp :D
<geist>
right
<geist>
it's a problem i've seen here over and over again
<geist>
*especially* getting stuck on the x86 bootloader problem. not as much lately since grub is more mature
<geist>
but in the earlier days it was the classic trap
<zid>
noo my bootloader should be BETTER than grub
<zid>
and I'm not allowed to write any real OS code until it is
<zid>
how dare you geist :(
<geist>
exactly
<geist>
bcos i think was really stuck in that trap
<geist>
spent like 5 years trying to build the perfect bootloader
<geist>
no idea if they ever finished it, but i seriously doubt it
<zid>
I spent 5 days getting ayame onscreen and then gave up once I'd achieved it
<geist>
they had like antialiased truetype fond rendering in their bootloader
<kof673>
i'm not saying i am anywhere near...reliable...got 99 problems but lack of something to work on is not one :D
<geist>
i'm pretty bad at starting something, doing all the fun parts, but not really doing the polish and commiting at the end
<geist>
i think having to do that a work where the process is so slow sours the taste a bit
<zid>
I am doing it *for* fun
<zid>
so that's inevitable
<geist>
plus i think i like the act of programming more so than getting things done
goliath has quit [Quit: SIGSEGV]
<nikolapdp>
understandable geist
<geist>
like it's pleasing to get in the zone and do something, that feels nice
<kof673>
does anyone use smallerc? i am just screwing around adding targets to "test" little programs...it does not matter, just it does not like my compiler invocation -dos_foo -mac -win, generates elf always...so i call the linker manually object(s) -> executable, to get proper executable (for dos, mac)
<kof673>
i think it is just picky about argument order :/
<kof673>
-v shows, it does not even invoke the linker :/ it seems fixed but...why is it doing this? who knows
<kof673>
dos/dosemu of course is totally robust, it looks at the contents, not file extension j/k it segfautls lol
<kof673>
*segfaults
Left_Turn has joined #osdev
Left_Turn has quit [Max SendQ exceeded]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 268 seconds]
MrCryo has quit [Remote host closed the connection]
scaleww has quit [Quit: Leaving]
netbsduser has quit [Ping timeout: 272 seconds]
goliath has joined #osdev
<geist>
hmm, no
<heat>
hah here's a fun fact: you can proactively reclaim memory in linux using e.g echo "1G" > /sys/fs/cgroup/memory.reclaim
<nikolapdp>
what does that do exactly
<geist>
oh cute. i have used the other switch to dump the file cache and whatnot
<heat>
nikolapdp, it reclaims memory
<heat>
i have no other way of describing this
<heat>
like, it takes the amount of memory you asked for and literally frees it. it stays in the page allocator
<heat>
vs the normal mode of allocation where linux does not proactively reclaim memory, but rather acts on memory pressure (which is when you get the horrible deadlocking, etc)
<nikolapdp>
interesting
<geist>
is it a one time actuion, or is setting that 1G there actually trying to set a cap on that cgroup?
<heat>
one time
<geist>
makessense, so it's running the normal reclaimation to that threshold
<heat>
i'm 99% sure you can set caps on memcgs but that's another mechanism
<geist>
on cgroups too it must be tracking what pages belong to what
<geist>
though since on linux most of them are anonymous, it's easy to do so
<heat>
yep
<heat>
memory cgs keep their own LRU lists of pages
<geist>
that would makes sense
<geist>
on the topic of reclaimation, now that i have my proxmox box loaded up the integrated memory ballooning is really nice
<geist>
works exactly as expected, and to a linux client if you're watching it with top you basically see total memory move around
<geist>
you can even set relative priority between the VMs
<nikolapdp>
oh that's fancy
<geist>
not a thing you'd probably want to do in production, but it's nice for overcommiting a box with lots of test OSes and whatnot
<geist>
and there's even client balloon drivers for windows
<heat>
overcommit is so based
<heat>
it's like being heavily in credit card debt and paying off cc debt with more cc debt
<geist>
i basically have one main VM that used to be the thing i ran on the box that i set to high priority
<geist>
so when i'm using it its more or less the same as before
<nikolapdp>
heat how's that analogy based
<geist>
but then i can switch over and futz with the other ones which will slowly drain memory out of the others
<heat>
nikolapdp, because when banks do it it's economy 101, when people do it it's financially irresponsible, when kernels do it it's MEGA BASED LETS GO
<geist>
like i said it'd be irresponsible on production
<kof673>
^^^ just saying depends on who/where you ask :D semi-related, i notice old osen/etc. just malloc() in a ghetto attempt to see how much RAM there is...guess what linux does? overflows size_t :D i am guessing if you don't actually write to the areas, it is just "bookkeeping" but :D
<geist>
since your production systems are presumably sized for the task, and having the size change owuldn't be a good idea
<heat>
overcommit is not irresponsible
<kof673>
*if you just repeatedly malloc()
<heat>
i'm joking around but overcommit is key and pretty fine
<heat>
it just depends on how hard you're overcommitting the thing
<geist>
yah and i can overcommit the cpu like crazy, because the nature of it i'm not really doing more than one thing at a time in any given OS
<kof673>
*count overflows, it perhaps just goes forever
<nikolapdp>
yeah but overcommitting memory will hurt eventually
thesock has joined #osdev
lanodan has quit [Quit: WeeChat 4.2.1]
lanodan has joined #osdev
thesock has quit [Remote host closed the connection]
Left_Turn has quit [Read error: Connection reset by peer]