sprock has quit [Read error: Connection reset by peer]
sprock has joined #osdev
tacco has quit []
skipwich has joined #osdev
LostFrog has quit [Read error: Connection reset by peer]
PapaFrog has joined #osdev
gog has quit [Ping timeout: 240 seconds]
gog has joined #osdev
isaacwoods has quit [Quit: WeeChat 3.2]
dbana has quit [Quit: Lost terminal]
dbana has joined #osdev
dbana has quit [Quit: leaving]
nanovad has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
nanovad has joined #osdev
gog has quit [Quit: byee]
dude12312414 has joined #osdev
Izem has joined #osdev
sts-q has quit [Ping timeout: 248 seconds]
sts-q has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.2]
flx- has joined #osdev
flx has quit [Ping timeout: 258 seconds]
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #osdev
smeso has quit [Quit: smeso]
smeso has joined #osdev
networker has joined #osdev
<networker>
does threading or multiprocessing make the processing process any faster ? i mean eventually they are still just context switching tho
<Izem>
sure, if the process makes use of it
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<networker>
Izem: yea but still if i create more processes or more threads, it just do context switch anything so why the speed doesn't remain the same
<Izem>
if more than one thread is running and you have distributed the work will it not be done faster?
<Izem>
there is not just one thread running and being switched I imagine
<networker>
oh yea i forgot, most CPU have more than one core now :P
<networker>
yea probably faster
shlomif has joined #osdev
ElectronApps has joined #osdev
Izem has quit [Quit: Lost terminal]
AssKoala has quit [Ping timeout: 258 seconds]
theruran has quit [Quit: Connection closed for inactivity]
Burgundy has joined #osdev
networker has left #osdev [Leaving]
anon16__ has quit [Ping timeout: 245 seconds]
LostFrog has joined #osdev
PapaFrog has quit [Ping timeout: 240 seconds]
rubion has joined #osdev
<Affliction>
If threads often block on I/O, more software threads than hardware threads can make an improvement there
<geist>
right, it allows for a different type of programming than if you hadn't multithreaded apis
<geist>
which may or may not actually be more efficient/lower latency/etc even on a single cpu machine
<moon-child>
that's what async i/o is for
<moon-child>
ctx switches kill
<geist>
sure, but say you have background processing, it's lots of times more efficient than if you had to stop every so many iterations and check for other stuff, etc
<geist>
and i wouldn't say ctx switches kill
<geist>
it's not so black and white
<moon-child>
geist: yeah, fair enough. I was being a bit flip, but
<moon-child>
no but
<geist>
sure
dennis95 has joined #osdev
<Affliction>
Now I'm reminded of old java apps that run 2 threads for every socket they use.
<kazinsal>
one day once $gameIWorkedOn finally goes under I will write some stories about the absolutely atrocious threading-related hacks I was involved in on that project
<kazinsal>
such as multi-threading the client-side portion of an anticheat drier to make it more difficult for people to find which thread the actual work was being done in
<kazinsal>
driver*
<kazinsal>
or manually doing NT syscalls to hide threads from debuggers
<bslsk05>
hackaday.com: MULTICS Gets A New Release… 52 Years After Launch | Hackaday
<GeDaMo>
Isn't OS/360 now z/OS ?
<GeDaMo>
"z/OS is a 64-bit operating system for IBM z/Architecture mainframes, introduced by IBM in October 2000.[2] It derives from and is the successor to OS/390, which in turn followed a string of MVS versions." https://en.wikipedia.org/wiki/Z/OS
<bslsk05>
en.wikipedia.org: z/OS - Wikipedia
<Santurysim>
GeDaMo: looks like z/OS is for another mainframe series. It wouldn't run on System/360
<GeDaMo>
Windows 10 wouldn't run on the original IBM PC either :P
<zid>
because it's a pile of junk
kulernil has quit [Ping timeout: 244 seconds]
<zid>
I won't say to which thing that "it" refers though
<Santurysim>
I think it's obvious
sortie has joined #osdev
<Santurysim>
Btw, which is the language multics written in? In the beginning, it was PL/1
<sortie>
I'm quite curious about that too
transistor has quit [Ping timeout: 268 seconds]
transistor has joined #osdev
woky has quit [Ping timeout: 272 seconds]
woky has joined #osdev
tacco has joined #osdev
shlomif has quit [Ping timeout: 240 seconds]
mahmutov has joined #osdev
flx- has quit [Ping timeout: 245 seconds]
scaleww has quit [Quit: Leaving]
<geist>
apparently thele source is availab
<geist>
the original source was released, and this appears to be based on it
gog has quit [Quit: bye]
koolazer has joined #osdev
dennis95 has quit [Read error: Connection reset by peer]
<bslsk05>
rhaleblian/pirix - Emulation of SGI's IRIX Interactive Desktop on Raspberry Pi 3/4 (and any other platform having MWM). (0 forks/11 stargazers/MIT)
dennis95_ has quit [Remote host closed the connection]
dennis95_ has joined #osdev
GeDaMo has quit [Quit: Leaving.]
mctpyt has quit [Ping timeout: 258 seconds]
mctpyt has joined #osdev
dormito has quit [Ping timeout: 245 seconds]
Arthuria has quit [Ping timeout: 245 seconds]
craigo has quit [Quit: Leaving]
dormito has joined #osdev
<Nuclear>
4DWM was basically a slightly improved version of MWM, there are many MWM-like (and improved) window managers, the one I'm using is fvwm
<Nuclear>
it's extremely lightweight, and fully configurable
<klange>
fvwm, lightweight, ha, even it is a 1MiB binary - dynamically linked to all the X bits!
<klange>
my compositor is 50KiB!
<klange>
now _that's_ lightweight!
<zid>
mine is like 20 bytes, but granted it is just rep movsb
<Nuclear>
heh
<Nuclear>
rep movsd is faster :)
<zid>
not really
<klange>
mine's *spews some vector instruction vomit*
<Nuclear>
well... it used to be, but these things change over time :)
<Nuclear>
probably doesn't make a difference on a modern PC
<zid>
pre ivy it's slow
<zid>
post ivy it's basically as good as avx
<klange>
I think Intel currently recommends rep movsd for memcpy, but that don't make no compositor on its own.
<klange>
You'll take my alpha channels from my cold, dead, transparent hands.
<zid>
my alpha is lul
<zid>
I rmw the framebuffer
<zid>
it's a fake framebuffer for fake people though cus qemu
<klange>
My compositor runs quite nicely on an actual framebuffer ;)
<zid>
I don't have an actual fb to test on :(
<klange>
Sad. Back in my day, we just rebooted into our own OSes and hoped we didn't do anything to mess up our main setup!
<zid>
my desktop has an nvidia card, fuck knows how to do it
<zid>
maybe if i booted my 82810 machine
<Nuclear>
the nvidia card is perfectly capable of using VGA and VESA modes
<Nuclear>
supports VBE 3.0 for sure
<zid>
I don't :P
<klange>
Just boot with grub and ask it for a framebuffer.
<zid>
could do, but that sounds like cheating if I ever heard it
<Nuclear>
klange: I make it a rule to always test on a couple of different real computer at least once every non-trivial commit, to avoid surprises :)
<klange>
I've got the dedicated laptop these days. Even has a "real" display driver that kicks it into its native panel resolution after VESA configures it for crap.
ahalaney has quit [Quit: Leaving]
<Nuclear>
I use an asus eeepc a lot for testing these days. it's small doesn't take too much space, and boots easily from a USB stick
<j`ey>
I'm having to test on the M1, there's no qemu for it D:
AssKoala has quit [Ping timeout: 240 seconds]
<Nuclear>
back when I was testing every single edit on real machines, I had a laptop set up for netbooting, and my "make install" rule dropped the kernel image into the tftp directory, but nowadays I'm just doing most of my development with qemu and test a few times a day with a usb stick
<Nuclear>
M1 should be interesting
<Nuclear>
I've seen some reverse engineering efforts to make linux run on it
dennis95_ has quit [Quit: Leaving]
<j`ey>
I've been refactoring the gpio driver that someone wrote for it
<clever>
ive also setup netboot for my rpi's, to make testing far simpler
<clever>
so i can just whack a big red reset button after the compile is done
<clever>
or even wiggle a gpio pin from the CLI, so i can just `make && force-remote-reset`
<Nuclear>
yeah for the rpi qemu sucks, bud I didn't have a version that can netboot, so I did a custom thing to boot over serial
<zid>
should hook the reset button to a serial port too
<klange>
Nuclear: The primary effort, Asahi Linux... is managed by a friend of mine ;)
<clever>
Nuclear: rpi qemu is even worse for my needs, because i'm testing a cpu core that qemu just lacks
<zid>
echo "f2" > /dev/serial0
<klange>
And "toaruos on m1 when?" is already a meme???
<clever>
zid: in my case, i wired the DTR pin of the ftdi chip, to the soc reset pin
<clever>
zid: then with ioctl's, i can pull DTR high or low
* clever
grabs link
<Nuclear>
klange: nice, I'm looking forward to considering apple again for my next laptop when it runs linux, though I'll probably end up with a thinkpad or a dell xps tbh
<bslsk05>
github.com: rpi-open-firmware/uart-manager.cpp at master · librerpi/rpi-open-firmware · GitHub
<j`ey>
clever: I switched from screen to picocom, pico supports toggling DTR
<klange>
I did start poking at trying to set up an aarch64 toolchain, and I think I've got something working, but even if Misaka's "more portable" than toaru32 was, it's still going to be a lot of work to even get the bare minimum running.
<clever>
zid: this is a custom serial terminal program, on startup it pulls DTR high, allowing the rpi to boot, if i ctrl+c, it yanks DTR low, and then cleanly exits, causing the rpi to come to a grinding halt
<klange>
And that project definitely needs a stable USB stack ready to go or it's going to be kinda pointless...
<clever>
zid: so i can essentially treat uart-manager like an emulator, code runs when i start it, code halts when i ctrl+c it
<clever>
j`ey: uart-manager also supports xmodem transfers, and hitting X when the remote system says to
<Nuclear>
clever: seems convenient, I need to hit reset manually on mine, but then my boot loader starts up and sucks the kernel over the serial port and jumps to it automatically, so it's not that bad
<klange>
The other thing that really needs me to get off my ass on USB is my Surface. I've got that booted to a GUI but there's definitely no legacy PS/2 emulation happening there.
<clever>
Nuclear: thats exactly why my custom uart program has xmodem support
<clever>
i dont have usb drivers working yet, so i cheat with xmodem
<klange>
My ThinkPad dualboots Toaru and Ubuntu, and the usual iteration process is "boot into Ubuntu, git pull, make, sync, reboot, select Toaru from grub menu"
<klange>
And that ThinkPad is old enough it has real PS/2 keyboard and mouse.
<klange>
It's also the last generation to have a traditional BIOS.
<Nuclear>
oh yeah those are a must :)
<Nuclear>
I don't want to have to write PCI->USB->HID just to get keyboard input give me a break :)
<zid>
I'm tempted to do that for keyboard
<zid>
I don't currently support mice or keyboards
<zid>
and I have pci-e anyway
<zid>
and I know how HID works for keyboards already
<clever>
Nuclear: thats why all of my stuff is still serial based
<klange>
The other thing that ThinkPad just barely predates is USB3, but I picked up an ExpressCard USB 3 card so I've got a dedicated xHCI controller I can poke.
<clever>
Nuclear: i havent gotten usb host working yet
<Nuclear>
clever: haven't even tried myself. It's on my todo list for some day...
<clever>
klange: oh yeah, xhci has some great design choices for virtualization
<clever>
Nuclear: ive done usb-device, but not host yet
<klange>
The device spec seems a bit more straightforward. The host specs are, uh, fun.
<klange>
But we'll get there... after all, I did get SMP 'working' during a lunch break >_>
<clever>
the next thing i want to get done, is v3d
<clever>
then i'll have baremetal opengl
<klange>
I could say "the next thing I want is..." for weeks on end, but I what I end up working on is incapable of being predicted
<clever>
same, lol
<clever>
where is that meme...
<klange>
There is so much stuff on my TODO list, and I've already performed two miracles this year by getting x86-64 and SMP...
<clever>
i also need to fix linux booting on LK
<clever>
and fix armv6 issues
<klange>
I think my current priority should be AHCI drivers and bringing back the ext2 implementation. _Then_ it should be xHCI + HID devices.
<clever>
that reminds me, LK has working ext2
<clever>
i want to add ext3 and ext4
<klange>
At some point I need to revisit the network stack. I wrote a new one for the new kernel but it's about the same level of shit as the old one and it needs so much more...
gog has quit [Ping timeout: 248 seconds]
<klange>
I need to bring back my EFI loader, write the bootstrap for a BIOS hard disk loader since my current one only works as an El Torito payload, I have two old network device drivers to port from toaru32...
<klange>
SMP is stable but I need better userspace locks 'cause the compositor runs like shit with multiple cores and I know exactly why, and... I wanted to write an installer.
<klange>
I think that about sums up the current "short term" roadmap for ToaruOS.
<bslsk05>
ext4.wiki.kernel.org: Ext4 Disk Layout - Ext4
<klange>
Maybe instead of trying to fix the write support in my ext2 implementation, I should abandon it and just build my own FS and do read-only ext2,3,4...
<kazinsal>
*yessssssss*
<kazinsal>
joiiiiiiin usssssss
scaleww has joined #osdev
<kazinsal>
the league of bad bespoke filesystem implementers
<clever>
kazinsal: a few years back, i made a custom fuse fs ontop of sqlite, to fix some inode exaustion bugs
<clever>
but the biggest limitation in that design, was the entire file body is held as a single row in the table
<clever>
so block based random access and partial writes where very expensive
<kazinsal>
ack
<clever>
ive also found a custom FS on the pi4(00)
<clever>
the first layer is just 32bit magic, 32bit size, $size bytes, and some padding so the next magic is aligned
<clever>
for certain magics, the payload has a char[16] name prepended, and may have a compressed body with a hash appended
<clever>
writes are expensive, because it doesnt support fragmentation
<clever>
it also has some special magic#'s for "padding files", to make things your likely to edit, land on an erase block boundary
Arthuria has joined #osdev
sortie has quit [Quit: Leaving]
gog has joined #osdev
Burgundy has quit [Ping timeout: 245 seconds]
ZombieChicken has joined #osdev
rubion has quit [Ping timeout: 248 seconds]
scaleww has quit [Quit: Leaving]
warlock has joined #osdev
Arthuria has quit [Ping timeout: 245 seconds]
isaacwoods has quit [Quit: WeeChat 3.2]
ZombieChicken has quit [Ping timeout: 244 seconds]
YuutaW has quit [Quit: WeeChat 3.2]
tacco has quit []
YuutaW has joined #osdev
<clever>
s_feature_ro_compat not compatible, 0x46b
<clever>
klange: this is what a freshly formatted ext4 volume has, that is upsetting LK
<clever>
RO_COMPAT_HUGE_FILE has been added in the first nibble, RO_COMPAT_DIR_NLINK|RO_COMPAT_EXTRA_ISIZE in the 2nd nibble, RO_COMPAT_METADATA_CSUM in the 3rd nibble