<zid>
krastorio makes uranium processing spit out iron and stone, always fun to have to deal with trash
<moon-child>
krastorio? Is that a mod?
<zid>
yea
<klange>
I think I'll release a ToaruOS 2.1.
<zid>
Does it run factorio?
<klange>
no, and the next person to mention factorio is getting a totally unfair kicking
<heat>
facts
<heat>
:100:
<zid>
heat did you hear about the round american stuffed cookie with trivia on them?
<heat>
no
<zid>
hmm, I tried one, and I really like em, they're called fact oreos
<Griwes>
Now a kick for that would be, actually, a 100% fair kicking
<zid>
Agreed
<klange>
SO IT SHALL BE
zid was kicked from #osdev by klange [zid]
SpikeHeron has joined #osdev
<klange>
(and zid was never seen in #osdev ever again)
nyah has quit [Remote host closed the connection]
gog has quit [Ping timeout: 268 seconds]
<klange>
let's see, what do we have in 2.1... Non-lazy window resize, glyph caches improving text rendering speed in a bunch of stuff, Kuroko 1.3 with bigints and all that jazz, aarch64 support is technically new but I did a preview release of that ages ago...
<klange>
new signal implementation, that's pretty big I guess... ability to unmap pages, that was really important for the non-lazy window resize to not just massively leak everything...
<heat>
you couldn't unmap pages before?
<klange>
Yep.
<klange>
The most amusing instance of this is that for the longest time the wallpaper app would kill itself when you changed wallpapers, as the allocator couldn't reliably reuse freed blocks from textures and it would take up multiple megabytes it couldn't return to the system.
corecode has quit [Ping timeout: 248 seconds]
<heat>
LOL
<klange>
So I just made it restart.
<geist>
noice
<geist>
well to be fair unmapping is where it gets hard!
corecode has joined #osdev
<geist>
in general creating things is easy, tearing it all down so that it goes back to zero safely is hard
<heat>
crap
<heat>
how do I erm, filter out arguments from GCC's target spec?
<geist>
much harder to mess up accessing the wrong disk when you have the full path to it
lg has joined #osdev
<mxshift>
Is that a systemd thing? I thought that came with udev before systemd existed
<geist>
oh maybe
<mxshift>
But yes, it's a great improvement. There was one generation of machines I worked with that had non-deterministic enumeration order
<zid>
I turn the determinism off
<mxshift>
Manually finding out which disk was which was tedious
<zid>
eth0 for life, ensp0p1 or whatever can die
<mxshift>
It's a different matter when sdb will change what port it maps to on every boot
<zid>
so.. insane bios?
klys has joined #osdev
bauen1 has joined #osdev
<mxshift>
And hardware. It was a machine of compromises
wand has quit [Ping timeout: 258 seconds]
wand has joined #osdev
<geist>
been booting the kernel on this old p4 which is finding all sorts of fun edge cases i hadn't tried before
<geist>
yay old hardware stress test
the_lanetly_052 has joined #osdev
wand has quit [Ping timeout: 258 seconds]
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 252 seconds]
poyking16 has joined #osdev
wand has joined #osdev
<zid>
p4, otherwise known as p6
<zid>
thanks intel
<zid>
p6++++
<kindofwonderful>
are you guys using vim ?
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 246 seconds]
Burgundy has joined #osdev
<moon-child>
Sometimes, you use vim. But sometimes--well, sometimes vim uses you.
<moon-child>
Vim is like 'that girl'. You know the one. You never really went steady, but you'd run into her from time to time while knocking around in disreputable emacsen...
<zid>
are you okay
<klange>
I have been using my own editor for four years now.
<bslsk05>
web.archive.org: [FoRK] And then there's Haskell... (was: Bone / Greenspun, etc.)
<zid>
sorry I wasn't born in 2007
<zid>
I was born in the 80s infact.
bauen1 has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
Burgundy has quit [Ping timeout: 246 seconds]
<mjg_>
geist: slightly related, i hear booting os/2 is *the* test for a hypervisor
GeDaMo has joined #osdev
<kindofwonderful>
mjg_: don't get smug
netbsduser has joined #osdev
kindofwonderful has quit [Ping timeout: 246 seconds]
Ellenor is now known as AmyMalik
kindofwonderful has joined #osdev
<netbsduser>
i've thought a bit more about efficient approaches to a single-level store
<netbsduser>
one way: try to eliminate as much cyclic referencing as possible, rely primarily on refcounting. since a generational/moving GC is now no longer needed, more viable to do physical (i.e. simply persist pages of the heap, don't need an object-based approach) approach to persisting
<netbsduser>
since i don't think i can *eliminate* reference cycles from smalltalk, need cycle detection - can use a low-priority process and have it perform a cycle detection run on a checkpointed state
<netbsduser>
GeDaMo: cheers for that link, this looks marvellously detailed. system/38 (along with IBM i, but there appears to be no thorough technical documentation of its internals available outside of big blue itself) are very interesting platforms
potash has quit [Read error: Connection reset by peer]
<GeDaMo>
Page 5, top of the middle column appears to be referring to single level store
potash has joined #osdev
<GeDaMo>
The references are all in that same PDF
<pbx>
klange: thats odd. never had any issues with the console
<pbx>
why large? static link, plus its basically a full sysroot
<pbx>
so all hdrs libs etc
<pbx>
could do an iso but atm i dont have a cdrom driver nor iso9660 fs
<moon-child>
netbsduser: there was an 'international workshop on persistent object systems'. It has not been held in over 20 years, but you will likely find useful threads: https://dblp.org/db/conf/pos/index.html
<bslsk05>
dblp.org: dblp: Workshop on Persistent Objects (POS)
<pbx>
so that'd be a ramdisk boot, which is slow for few hundred meg images
<klange>
I tried a few different configurations of QEMU, but the keyboard just doesn't seem to do anything - curious what version you're running, might give me a hint on hardware config differences
<moon-child>
netbsduser: for my money, tracing gc is fine; and outlawing cycles is not very nice
<pbx>
hmm. i've moved my dev env across qemus from 2013 to now, never had that issue
<pbx>
only had it show up on real pentium ii hw
<pbx>
what version are you using
<klange>
6.2
<pbx>
i'm on 5.2.0
<moon-child>
netbsduser: (in particular, refcount-chasing is slow, and a gc pass on persistent old-space is unlikely to be slower than a cycle detection pass on persistent oldspace)
<klange>
Hm, not a lot different between the two releases...
DarkL0rd has joined #osdev
<netbsduser>
moon-child: interest in this field really dwindled from the point of having symposiums and workshops to being almost untouched nowadays as far as i've seen (a few projects like CapROS aside, does it still exist?). i had thought of taking a tracing gc approach but i saw a lot of difficulties - it would be trickier to square it with the simpler model of persisting the object heap at page granularity without regard to what's within pages
<moon-child>
how's that?
<moon-child>
I mean, aside from a page being associated with a particular generation/region/what-have-you in the gc
the_lanetly_052_ has joined #osdev
<netbsduser>
because if i used a generational copying approach, for example, that would generate much larger deltas between checkpoints, which would result in a lot more writing to disk than i'd prefer. alternatively i could change the on-disk format from a simple representation of the object heap as it's physically laid out in RAM into something more abstract - i thought about one big table of objects containing members universal to all objects, with pointers
<netbsduser>
to space where class-specific data is stored - that could allow for more efficient disk use, but i expect it would be very challenging to implement
the_lanetly_052 has quit [Ping timeout: 246 seconds]
<moon-child>
you need to have the ability to compact your oldspace anyway, to deal with worst-case pathological fragmentation
<moon-child>
probably that could be an offline thing though in any event. Beyond that, you don't necessarily need to copy oldspace
<moon-child>
probably more compelling is an incremental approach (tricolour or so, perhaps) to avoid latency spikes
<moon-child>
for interactive use
<moon-child>
anyway going to bed now; chat more tomorrow
smach has joined #osdev
sav_ has joined #osdev
smach has quit [Ping timeout: 260 seconds]
dzwdz has quit [Ping timeout: 264 seconds]
dzwdz has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 252 seconds]
Burgundy has joined #osdev
<klange>
pbx: i extracted your kernel and used some of your old sources as a reference to poke around in gdb and it looks like you aren't specifically enabling the keyboard ps2 port. I threw a `call i8042_write_command(0xae)` at it and now I can type.
<bslsk05>
lwn.net: The search for the correct amount of split-lock misery [LWN.net]
gog has joined #osdev
<gog>
afternoon, nerds
<heat>
TIL there's a way to detect split locks
<heat>
gog, hi, i was just in the middle of nerding, how are you?
<gog>
hi
<gog>
i'm well
<gog>
took off early from work because my boss isn't around and i need to ask his permission before doing a thing i want to do
<gog>
and tomorrow i'm off because it's birthday
<sham1>
Good evening lads and lasses
<heat>
happy bday if i forget
<heat>
but i'll try to remember
gareppa has joined #osdev
gareppa has quit [Remote host closed the connection]
<mrvn>
heat: obvious comments on that LWN article: 1) why is there no option to kill processes that exceed the rate limit? 2) why wasn't that a runtime adjustable parameter from the start? 3) why isn't that a per process limit?
<heat>
what's the point of having a rate limit if it doesn't limit but rather kill?
<mrvn>
heat: so that code that does a split lock once a second keeps running but the DOS attack doing it 1 billion times in a row dies.
<mrvn>
you could have a warn limit and kill limit too
<heat>
but the 5.19 patch just delays you
<mrvn>
But killing a process just because it does one split lock is rather harsh.
<heat>
just so it's not noticeable
<mrvn>
I think that's the worst solution. It makes actual use cases unbearably slow while DOS attackers don't care. They simply don't succeed.
<mrvn>
Which brings me to the 3rd point: You want to mark "God of War" as being allowed to split lock without enabling it for everyone.
<heat>
DOS attackers care
<heat>
they failed
<mrvn>
they aren't going to "fix" their code to not split lock.
<heat>
ok? they're attackers, and they failed
<mrvn>
slowing them down isn't better than killing them. There really is no point in lettimg them run even slow.
<heat>
there is
<heat>
this rate limiting is only for the dmesg warning
<heat>
the split lock fault itself does not have rate limiting
xenos1984 has quit [Ping timeout: 264 seconds]
<mrvn>
heat: that was about the 10ms delay option.
<mrvn>
The original warn solution really does nothing at all against DOS except make it worse because now you also get syslog messages.
awita has quit [Ping timeout: 246 seconds]
<heat>
if I get your process to generate a bunch of split locks, you get rate-limiting-SIGKILLED and die?
<heat>
"anything else creates an easily exploitable denial-of-service vulnerability."
<kindofwonderful>
mrvn: hi
<kindofwonderful>
welcome back
<mrvn>
heat: true. that is a DOS on the faulty service while preventing a DOS on the whole system.
<heat>
but you don't want a DOS at all
<heat>
10ms delay is the least shitty of the shitty worlds
<heat>
services notice they're running very slow, and no one gets DOS'd
<heat>
well, you do get DOS'd a bit
<mrvn>
heat: possibly. except that pretty much was a DOS for the game.
<mrvn>
heat: why wasn't the 10ms delay coupled with a rate limit? A malicious program will flood the system with split locks. So rate limit them and if the limit is exceeded add the 10ms delay.
<heat>
idk
<Griwes>
> He also suggested filing a bug with the publishers of God of War to get its misbehavior fixed.
<Griwes>
Bless his heart
<Griwes>
What a sweet summer child
<mrvn>
hehe. How many years past release if God of War?
<gog>
13?
<gog>
oh shit
<GeDaMo>
Closer to 20, I'd think
<gog>
18
<mrvn>
anyway, split lock sounds like something that realy doesn't scale with the number of cores.
<GeDaMo>
I have it on the PS2
<mrvn>
Do modern CPUs still halt the whole bus for all cores or do they have something smarter now?
<heat>
it's the new god of war
<heat>
not the old one
<GeDaMo>
Ah
<Griwes>
Still
<Griwes>
Asking gamedevs to fix a "bug" of this kind?
<mrvn>
Griwes: it's reasonable for a game that's still getting updates.
xenos1984 has joined #osdev
<Griwes>
They can usually barely fix actual bugs
<heat>
it's not a native linux game
<mrvn>
Griwes: they just have to find the library that causes the split lock and report it there
<heat>
it's under wine lol
<Griwes>
Also that yeah
<heat>
"hey, this weird behavior of a system you don't support is breaking your game running under like 2 compat layers. pls fix ty"
<Griwes>
Like, if you send me a bug report saying I'm doing funny atomics that break a system I don't support, I'll laugh lol
<mrvn>
Problem with wine games is that they are usualy some other firm buying the right to publish the wine version and the original firm doesn't care about linux bugs at all
<heat>
hm?
<heat>
what's a "wine version"?
<mrvn>
(or just private people playing it in wine)
<heat>
steam distributes proton (wine + a bunch of shit)
<mrvn>
heat: a linux version of the game that just comes with wine
<heat>
if you decide to play video games with it, it's your fault
<zid>
wine version is a real thing, kinda weirdly
<heat>
i'm not aware of such shenanigans
<zid>
a linux version that's easier to emulate in wine than normal :P
<heat>
that's also like, a poor idea
<heat>
blob'd, non-updatable wine, yay!
<mrvn>
heat: that exists too
<mrvn>
wine patched to work around bugs in the game
awita has joined #osdev
elastic_dog has joined #osdev
gildasio has quit [Ping timeout: 258 seconds]
Matt|home has quit [Ping timeout: 246 seconds]
awita has quit [Quit: Leaving]
<zid>
Finally found out what to do with bulging lithium pillows
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<truepassion>
geist: yeah my inital guess was may be RTL version? but not sure
Lumia has joined #osdev
bauen1 has joined #osdev
Lumia has quit [Ping timeout: 272 seconds]
carbonfiber has quit [Quit: Connection closed for inactivity]
Lumia has joined #osdev
<heat>
some linux sockets can be mmaped
gildasio has quit [Ping timeout: 258 seconds]
wand has quit [Ping timeout: 258 seconds]
<sham1>
That sounds horrible
gildasio has joined #osdev
<heat>
why
<heat>
it's like files, but sockets
<heat>
and sockets being literally files with a special syscall, I don't see what's wrong
<mjg_>
sockets are not seekable so there is that
wand has joined #osdev
<mrvn>
heat: how is that going to work? How do you seek on a socket?
<heat>
idk
<heat>
but seeking is not required for mmap
<heat>
plenty of character devices implement mmap but don't seek, nor do they have a read/write
<mrvn>
they do? which ones?
<mrvn>
Do they map some MMIO regs?
<heat>
/dev/fb0 is an easy one
<heat>
yeah
<heat>
or whatever
<mrvn>
That's not really a char device.
<heat>
mmap does not require seek whatsoever, at least in standardish kernels
<mrvn>
It does require random access though
<heat>
no
<heat>
why would it?
<heat>
if your thing wants to map a thing, it maps it
<mrvn>
because if someone reads from base+1GB you don't want to wait and map 1GB of data before the page fault returns.
<heat>
of course these sockets that implement mmap must not be mapping a TCP stream, because that's impossible/very hard+useless
<heat>
AF_PACKET is one
<mrvn>
I guess you could have something like RDMA pretend to be a socket and internaly it then read/writes the respective pages over the network.
<mrvn>
AF_PACKET is just a placeholder for implement-the-protocol-yourself :)
<heat>
no
<mrvn>
heat: does linux have a socket type that allows mmap?
<heat>
that's very much not AF_PACKET
<heat>
you're thinking about AF_RAW there
<mrvn>
"Packet sockets are used to receive or send raw packets at the device driver (OSI Layer 2) level. They allow the user to implement protocol modules in user space on top of the physical layer." They kind of are :)
<heat>
AF_PACKET is what tcpdump/wireshark uses to capture packets
<heat>
it's pretty much it's usage
<mrvn>
heat: SOCK_RAW is the socket type. That goes along with AF_PACKET. The other type is SOCK_DGRAM which is slightly higher level.
<heat>
and it implements mmap so you don't even need to travel
<heat>
(to the kernel)
<heat>
yes, you're right, my bad
<mrvn>
heat: I think wireshark uses pcap, which uses a subset of AF_PACKET.
<heat>
yes
<heat>
but AIUI you usually use mmap there
<heat>
so, see, mmappable sockets :)
<mrvn>
heat: is that a ringbuffer then? An early implementation of kernel uring?
<heat>
yeah i believe it's a ringbuffer
<heat>
there's a whole doc on it in Documentation/
<mrvn>
So basically the same as the /dev/fb0 case. Missusing the FD to connect a bunch of kernel memory to the user space.
<heat>
it's not misusing the fd
<heat>
devices don't need to be read/write-able
<heat>
what would you do with a read() on /dev/fb0?
<heat>
or a write()?
<heat>
if you want to send commands, you usually opt for an ioctl
<mrvn>
it's not mapping the socket data, just a ring buffer that gets constantly overwritten. So it's a (good) hack to get fast access to the data as it passes by.
<heat>
it's simpler and faster
kindofwonderful has quit [Quit: WeeChat 3.6]
<heat>
again, what would you do on the /dev/fb0 case?
<mrvn>
heat: you can read/write on fb0 just fine.
<heat>
read what?
<heat>
the framebuffer itself?
<mrvn>
the graphics memory.
<heat>
eh
<mrvn>
yep. the /dev/fb0 is really just a fixed sized memory buffer.
<heat>
and then constantly rewind, etc
<heat>
for no gain really
<mrvn>
Oh no. you can read up to the FB size.
<heat>
DRM nodes are even worse
<heat>
what would you read on /dev/dri/card0?
<mrvn>
You would do pread() on the FB, read + seek is kind of stupid.
Lumia has quit [Ping timeout: 260 seconds]
<heat>
pread is relatively new, UNIX-speaking
<mrvn>
No idea about /dev/dri/card0. I think that's rather driver specific.
<heat>
ok, an intel GPU for instance
<heat>
would it read INTELINTELINTEL in a loop? ;)
<mrvn>
no idea
<heat>
most devices map well to ioctls and mmap, NOT read/write
<heat>
taking a trip to the kernel and back to read /dev/fb0 is just a poor idea
<mrvn>
I just worked with /dev/fb0 on m68k. The generic framebuffer is just a memory based file with some ioctls.
<mrvn>
heat: the FB implements the lowlevel read/write functions in the kernel and then the generic mmap code just works on it. You aren't really supposed to constantly read/write it.
<mrvn>
but you can
<heat>
oh wow you can actually read/write to it
<mrvn>
Want to make a screenshot? open /dev/fb0, read
<heat>
TIL
<heat>
anyway, the DRI node is a better example
<heat>
there's no good answer for "What should be read/written" except "idk, a packeted command structure?"
<mrvn>
heat: I believe the reason for that is that linux has a file_ops struct with callbacks for read/write but nothing for just mmap. So they overload read/write and everything just works then.
<heat>
and if you're moving packeted commands back and forth through read/write, you lost and that's horrible
<heat>
there's absolutely an mmap callback
<heat>
mmap does not work in terms of read/write
<mrvn>
maybe now. It's like 30 years ago when I worked on the FB
<heat>
in 1992? hi linus :v
<mrvn>
close, 95
<heat>
oh yeah /dev/zero is a great example
<heat>
it's "seekable"
<heat>
but you don't actually seek anywhere because everything is a lie and it just memsets your buffer
<mrvn>
you can also read from it
<heat>
sure
<heat>
but mmap will never work on an infinite buffer
<mrvn>
but what happens whem you map it SHARED :)
<heat>
as in, there's no infinite buffer to represent the whole device, so it fucks around with .mmap
<heat>
it's just a normal shared mapping AFAIK
<heat>
of anon-backed memory
<mrvn>
why does it even need to fuck around with .mmap? .read simply does a bzero() and you are done.
<heat>
yes
<heat>
but if you're mmaping it
<mrvn>
then mmap calls .read() and gets bzero of the page.
<heat>
it's a size 0 file
<mrvn>
yeah, that bit you have for fudge around with
<heat>
unix is built on lies
<mrvn>
but it's a char device. so file size is kind of out there
<mrvn>
good example for an mmap-able char device.
<mrvn>
heat: YOU CAN'T HANDLE THE TRUTH!
<mrvn>
can you seek to the end on /dev/zero?
<heat>
i highly doubt it
<heat>
everything is a file, except not really. everything is read/write-able, except directories, symlinks, and most block/char devs. mmaping maps the "contents of the file", except on directories, symlinks and pipes where it doesn't exist, and block, char when it's not implemented
<heat>
also block and character devices can map things when not read/writeable, and so can sockets!
<heat>
unix is the crème de la crème of design
<heat>
the best part of Great UNIX Design(tm) is when you read from /proc, but you don't read everything so you get stale data
epony has joined #osdev
<mrvn>
you don't get stale data I believe, you always get the data from offset 0
<heat>
i believe you get stale data, it's buffered
orthoplex64 has joined #osdev
<heat>
a call to a procfile's .read buffers a whole bunch of data, and you read it bit by bit
<mrvn>
that would actually be usefull then
<mrvn>
and consistent
<mrvn>
also would be just like readdir
<mrvn>
sort of
<mrvn>
reading a dir while files are created or deleted has strange effects
<heat>
yes, there's no consistency in readdir
netbsduser has quit [Remote host closed the connection]
<mrvn>
there is some but it's strange.
<heat>
where?
<mrvn>
I don't see it in the manpage anymore but afaik there are some conditions on what successive calls to readdir may return
<mrvn>
new and deleted files may or may not appear but existing files can not be skipped because the FS resized the hashtable or something.
<mrvn>
what it comes down to is that the libc may do readdir_plus and buffer entries so you get stale data. Or not and you get latest data. or any mix. But the stream doesn't skip.
<heat>
or link + unlink + link + unlink + link + ... ;)
<AmyMalik>
snerf.
<klange>
pbx: correction to my previous debugging report, it seems all I need to do is inject a `i8042_read_ram(0)` and this gets the keyboard working
poyking16 has quit [Quit: WeeChat 3.5]
<pbx>
hmm. any reason for that? i8042 weirdness?
<pbx>
forgetting to init it seemed logical, but does read_ram also do that?
<kazinsal>
hoo boy. one of my coworkers brought a bottle of plum brandy back from his trip visiting family in Romania and we had a tasting in the office and I did not realize it was 60% ABV
<AmyMalik>
unix is not atomic
<zid>
-which is weird, because when unix was designed, everything was atomic
<zid>
it was super fashionable
<zid>
atomic toaster, atomic trains, etc
<gog>
hi
<zid>
the words atomic toaster apparently summon gog
<gog>
it was actually "trains"
<AmyMalik>
where's magog when you need them
<zid>
ah, that sort
<gog>
yes
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat_ is now known as heat
smach has joined #osdev
<kazinsal>
WITH THE GUARDS OF MAGOG SWARMING AROUND / THE PIED PIPER TAKES HIS CHILDREN UNDERGROOUUUUND
eroux_ has quit [Ping timeout: 260 seconds]
<geist>
had to look that one up!
<klys>
molecular sequence, cellular energy, printed protein