<Clockface>
in NASM, is equ like a macro for a single value?
<moon-child>
yes
kazinsal has joined #osdev
<Clockface>
thanks
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
gog has quit [Ping timeout: 240 seconds]
gog has joined #osdev
CryptoDavid has joined #osdev
biblio has quit [Quit: Leaving]
kingoffrance has joined #osdev
gorgonical has quit [Ping timeout: 240 seconds]
gorgonical has joined #osdev
newpy has quit [Quit: Leaving]
bauen1 has quit [Ping timeout: 240 seconds]
elderK has joined #osdev
orthoplex64 has joined #osdev
crm has quit [Ping timeout: 256 seconds]
crm has joined #osdev
orthoplex64 has quit [Ping timeout: 256 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
FreeFull has quit []
CryptoDavid has quit [Quit: Connection closed for inactivity]
sonny has joined #osdev
sonny has left #osdev [Closing Window]
srjek has quit [Ping timeout: 240 seconds]
ns12 has quit [Ping timeout: 256 seconds]
Jari--_ has joined #osdev
<Jari--_>
hi all
<Jari--_>
pancreat values appear so good I can drink liqour
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<kingoffrance>
s/*/haiku hi all! pancreat / values appear so good that / i can drink liquor
duckworld has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
<Jari--_>
hi
<Jari--_>
hmm
sdfgsdfg has joined #osdev
ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
ElectronApps has joined #osdev
gog has quit [Ping timeout: 256 seconds]
gog has joined #osdev
* gog
mews sleepily
<sham1>
mov :3
<gog>
mov $gog, bed
<zid>
movb $gog, garbage
<geist>
yay someone using at&T
<zid>
mov [luxury], zid
<sham1>
AT&T is confusing
<gog>
good morning to you too zid
<zid>
AT&T is actually un-confusing.. until it suddenly is confusing because they tried to be TOO orthogonal
<zid>
and now something doesn't look natural
<zid>
indirect calls, out instruction, etc
<geist>
yah agreed. there's a sense to it, but there are some places where it's a big head scratching
<geist>
but then those cases it's because x86 itself is not that orthogonal
<sham1>
It makes referencing the AMD documentation weird because, well, the arguments are shuffled
<zid>
AT&T is a foreign language I absolutely have to translate to/from
<zid>
idk how that could be natural
<moon-child>
I mean, obviously it could be natural if you spent time getting familiar with it
<moon-child>
but yeah. I don't trust myself to write at&t and not screw it up
<zid>
if you only, maybe
<moon-child>
it's hard enough writing assembly without screwing up, period
<geist>
yah, like i said before it's simply just vax assembly as applied to x86
<zid>
After seeing intel syntax any reasonable human should surely be like "oh, this is way simpler"
<geist>
there's also a very similar variant for m68k
<geist>
so it's really following DECs style from the 70s. same general left to right, $ %, etc
<gog>
i actually like that tbh
<gog>
a thing to show you what value in text is what
<gog>
register or immediate or etc.
<geist>
agreed. what i *dont* like is how a plain number is a dereference
<gog>
yes
<gog>
that has caused me many headache
<geist>
it makes sense when you think of label, but i'd have preferred something like (0x1234) or (label)
<gog>
yes so it's clear that it's a deref
<geist>
especially since as soon as you have an offset it's N(register)
<gog>
can you do 0(whatever) or is that a syntax error
<geist>
but a lot of that is because x86 isn't regular in that regard: you can't have a plain label + a complex addressing mode
<geist>
whereas i think you can on vax
<zid>
the fact you guys are going "let's come up with ways to make it make sense" sorta proves my point ngl
<geist>
no no i mean, it makes sense why it is the way it is
<zid>
oh absolutelyu
<geist>
i just dont like some of the mistakes they made
<zid>
the same way it makes sense that english has words that are their own opposites
<gog>
it was a different time and we should forgive their shortsightedness
<zid>
it makes sense because sarcasm + time
<moon-child>
I mean
<zid>
it doesn't make it sensible
<moon-child>
it makes sense
<moon-child>
but you know what else makes a lot of sense?
<geist>
to me it's like saying 'i can see why chinese makes sense' but i still can't read it at all
<moon-child>
just using intel :P
<geist>
no, what makes sense is to stick with what the tools use and just deal with it
<gog>
you know what makes even more sense? giving me pets and snacks
<geist>
since it's Just Another ISA and each isa has their own thing
<zid>
all the tools use intel, so np :p
<sham1>
Honestly I'd like a hybrid approach the most when doing x86 or AMD64. Basically use Intel notation but also have the prefixes like $, % and so on
<geist>
not really. gcc, etc likes to default to at&t, objdump, etc
<zid>
sham1: isn't that what NOT giving 'noprefix' to gas does?
<moon-child>
sham1: you can do that with gas
<geist>
you can apply switches but they frequently break, etc
<moon-child>
.intel_syntax
<sham1>
Yes
<zid>
gas has att, intel noprefix and intel
<geist>
inlien asm, etc
<zid>
the latter should be precisely that
<sham1>
I'm gonna have to adopt GAS again
<geist>
clang i think has issues with it too
<moon-child>
geist: -masm=intel
<sham1>
NASM is slow anyhow
<moon-child>
yeah only works w/gcc
<zid>
-mintel too
<moon-child>
but inline assembly needs to die anyway soo
<geist>
right. that's my point. stick with the defaults since that's the path that's well trodden
<dh`>
the problem is the architecture, not the assembly language
<zid>
geist only compiles -O0 with no warnings confirmed
<geist>
since in my book it's just another isa. there are plenty
<gog>
moon-child: inline assembly considered harmful?
<moon-child>
sham1: how much assembly are you writing, that the amount of time it takes to assemble matters?
<moon-child>
gog: yes
<zid>
ehhh inline assembly *does* have positives though
<sham1>
Admittedly not much
<gog>
i will continue to write inline assembly
<gog>
idc
<geist>
sure. use it when you gotta use it
<sham1>
I still like my assembly swift
<zid>
I'll avoid it where possible, but it's definitely useful to do it inline
<moon-child>
gog: ._.
<zid>
and 'where possible' means 'when it doesn't cause code differences', which is actually not that often
<moon-child>
zid: ._.
<geist>
yep. i try to use intrinsics if i can, which over the years more and more things have been instrinsics
<zid>
moon-child: constraints are too powerful man
<geist>
vs, say 10-15-20 years ago where you had to write a lot more inline asm
<dh`>
any of these intrinsics documented yet?
<gog>
i still have my ugly gdt reloading code inline :p
<geist>
i am always going back to old projects of mine and converting things to intrinsics that have subsequently showed up
<geist>
dh`: sure, like the atomics that gcc/clang use
<zid>
stops you having to do mov rsi, arg1; mov rdi, arg2; mov rax, rsi; mov rdx, rdi; rtdsc.. or whatever, you can just do the rdtsc with the D:A constraint
<geist>
used to be if yuo wanted atomics you always did it yourself. but nowadays most arches have most of them implemented
<sham1>
Although one thing I like about using GAS is that I wouldn't need to dispatch between having a special thing for compiling for a .asm file vs. .c, just pass .S and .c into ${CC} and you're golden
<geist>
or things like __builtin_ffs or whatnot
<sham1>
stdatomic.h
<geist>
or the endian swap intrinsics
<geist>
sure but if you're *implementing* stdatomic.h
<geist>
ie, osdev
<sham1>
That's freestanding
<sham1>
You don't need to implement it
<geist>
i disagree
<dh`>
where's it going to come from?
<zid>
You might need to
<zid>
you don't have to
<moon-child>
for freestanding code I would definitely prefer the __atomic* stuff
<zid>
(same for everything in libgcc)
<moon-child>
you probably depend on gcc stuff anyway
<moon-child>
so why take the buildchain complications?
<geist>
right, and you can implement your own stdatomic, or your own atomics, etc. but in general prefer to use the intrinsics if the arch supports it
<geist>
for LK for example i think maybe 6 or the 9 arches implement the full suite, so only a few do i have to resort to inline asm
<gog>
just be sure your libgcc is -mno-red-zone :p
<moon-child>
FRED go brr
<sham1>
Hm, wait. It's not actually freestanding
<sham1>
My mistake
<geist>
but then also have to consider the first version of gcc they showed up in, etc
<sham1>
Yeah, use intrinsics in that case
<geist>
sham1: yah not a lot in freestanding
<moon-child>
geist: the __sync* stuff is pretty old
<sham1>
I really thought that atomics would be a part of the freestanding in the standard. After all, as said, you'd just use intrinsics for them anyhow
<geist>
yah i think __atomic is the replacement
<moon-child>
but, god help you if you're still using gcc 4.2
<moon-child>
sham1: atomics are permitted to be implemented in terms of locks
<dh`>
even when stuff is in freestanding, you still have to provide it; as an OS, you're the implementation
<sham1>
I see
<moon-child>
will have to be, for sufficiently large stuff
<dh`>
maybe the compiler ships with float.h or whatnot that you'd actually want to use, more likely not
<zid>
on alpha you have to implement them by buying an x86 machine
<zid>
badum tish
<moon-child>
I think on arm the rmw stuff is lockfree but still goes through a runtime library
<geist>
yah and for example VAX doesn't impelment any of them, so you need to provide your own. or riscv doesn't implement the double word atomics, so it calls through to something you have to implement (IIRC)
<sham1>
Oh I'd certainly use float.h or stdint.h because those are specifically stuff that is extremely tied to the processor arch
<sham1>
Same for stdbool.h and whatever. iso646.h
<geist>
also stdarg.h whcih is mostly just a wrapper around some builtins to implement it, but it's still tied to the compiler
<dh`>
do you want to paste gcc's stdint.h (assuming they ship one) into your OS?
<sham1>
That too
<sham1>
Well I'd just use whatever stdint.h is provided by the compiler I'd port. If I was to write my own C compiler I'd use that thing's stdint.h
<sham1>
And so on
<geist>
yah can do a #include_next of it
<dh`>
e.g. the stddef.h that gcc ships is full of horrifying hacks and not suitable for use anywhere sane
<dh`>
(or at least it used to be)
<geist>
yah part of it is how much you want your OS/freestanding binary to deal with multiple variants of gcc/clang
<dh`>
because it was supposed to provide a semi-compliant stddef.h on top of completely broken vendor unixes of the 90s
<geist>
it gets much harder if you expect others to bring their compiler
<geist>
vs mandating a particular prebuilt or version or whatnot
<sham1>
BYOC
<geist>
moon-child: iirc gcc on arm64 has switched to a sceheme where they detect new (v8.1) vs old (v8.0) atomics dynamically
<moon-child>
right
<geist>
we're discussing what to do about that for fuchsia right now
<geist>
since i think clang hasn't adopted that strategy
<dh`>
does the difference actually matter? runtime hotpatching is the best way
<geist>
that's the question
<moon-child>
dh`: nah, recompilation is the best way
<geist>
a) hjow much of a diff does the new atomics make (evidence is a lot) and b) is runtime detection worse/better than runtime hotpatching
<geist>
or c) is recompilation suitable
<dh`>
recompilation for different machine variants isn't practical
<geist>
my guess is C is good for kernel, and for user space one of the b vvariants is worth it
<dh`>
for userspace you can do it entirely with dynamic linker gimmicks
<moon-child>
dh`: why not?
<geist>
yah
<moon-child>
see synthesis os
<geist>
but that's all based on the idea that the atomic is already a function call, vs being inline
<geist>
whereas *usually* atomic instructions can be simply inline where they're used
<dh`>
synthesis was a research project :-)
<geist>
but *thats* hard to patch since the new atomics are fundamentally different on arm,
<moon-child>
yeah. Point is if you recompile you can do it all inline
<geist>
so a) you have to be able to tolerate a function call
<geist>
and then b) how do you dynamically switch the function call (patch or let the function figure it out or dynamic linker tweaks)
<moon-child>
dh`: well, os research has been dead for 20 years. Soo I don't think it's that significant that nothing ever came of synthesis :P
<dh`>
perhaps
<sham1>
POSIX
<geist>
so if a) is tolerable then there are a lot of options for b)
<geist>
for a kernel it may be tolerable to just have multipl kernels for different major codegen options like this
<moon-child>
IIRC apple makes you submit llvm bitcode with every app
<geist>
say v8.0, v8.1 (new atomics), v9.0 (whatever may come there)
<moon-child>
and the mill recompiles everything for each cpu model (or, at least, purports to)
<moon-child>
hell, gpus compile shaders to a uarch-specific format
<moon-child>
it's not like there's no precedent for runtime recompilation
<dh`>
it's just expensive
<dh`>
not so much from a runtime perspective as from the "stuffing a compiler into your kernel" perspective
<moon-child>
how frequently do you install(/upgrade) new apps?
<dh`>
anyway I know you know about tendra and TDF so I won't belabor the point
<dh`>
I recompile my kernel periodically, I'm not the target audience
<moon-child>
sure
<geist>
yah i think for fuchsia we can tolerate a few different kernels, since it's a microkernel and there are literally only one or two variants of a binary
<geist>
can even boot time select them if we didn't mind the space
<moon-child>
also: package repos can ship packages for different feature levels. (Something like that would be nice to have for x86 too, sse/avx2/avx512 at least. But no distros have done that yet)
<geist>
tat'st he more interesting thing yeah
<moon-child>
but I still think the system should be capable of recompiling by itself. (What happens if you swap out your hardware? Iirc windows will choke on that.)
<geist>
tis true though i;m not sure that's so practical on things on batteries or constrained memory
<geist>
especially if the optimal compliation is a very complex language or LTO style codegen that is generally assumed to be the case nowadays
<zid>
C++ being involved makes that untenable, takes hundreds of gigs of ram to use a C++ compiler to produce binaries that don't suck :p
<moon-child>
hmm phones are kinda different though, it's an soc that's not really expected to be upgradable or swappable
<geist>
i was going to pick on rust for it too since it's kinda similar
<Belxjander>
moon-child: windows chokes when the "core drivers" have to deal with changed hardware... because it assumes the currently set graphics driver matches the card in use and doesn't detect for changes until AFTER core drivers are already in-use due to the loader order of launch IIRC
<moon-child>
that said you should at least be able to do a crappy compilation, just enough to get up and running and then download an optimized version from repos
<moon-child>
Belxjander: right
<zid>
yea it has like.. 'platform' drivers
sdfgsdfg has joined #osdev
<zid>
so changing your ahci controller etc is just a no-go
<zid>
aka a mobo swap
<Belxjander>
moon-child: if you reset a "core driver" back to a generic default driver... you can then change the hardware after that... and update the driver again to fixup acceleration features
<moon-child>
Belxjander: makes sense. (Also kinda dumb that the core gfx driver isn't always generic but ¯\_(ツ)_/¯)
<Belxjander>
zid: yeah... motherboard chipset, CPU feature accelerations and graphics are all in the "core driver" listing as well... Windows can't setup GDI/Video handling without a Display Driver which breaks the kernel graphical and UI handling... which is something optional on practically every other OS I am aware of
<dh`>
realistically for most users and most situations, if you get new hardware you reinstall the OS
<zid>
nah you phone microsoft
<zid>
and they give you a new activation on your licence and tell you what to do
<dh`>
once you move out of that territory it gets a lot less clear though
<Belxjander>
moon-child: all graphics drivers in windows have to provide a basic "DisplayDriver" model API presence and then add on top of that... if you have 2 display drivers... then they have to be setup with one as default (primary) as kernel binding at launch
<zid>
(this is the actual advice microsoft used to give, idk if it's still true)
<Belxjander>
zid: they don't do the phone thing anymore... its re-run setup and have it go through troubleshooting...
<Belxjander>
zid: it then "fixes" the machine setup locally for drivers and stuff... with LOTS of restarts
<dh`>
e.g. in an ideal world you'd hotswap a new cpu board in and the system would detect it, recompile whatever it needed to, and chug along
<dh`>
even if the new cpu board contained hw that didn't exist when the original machine was installed
<Belxjander>
dh`: in an ideal world... the essential core would work as a generic model and everything specific would be optional addons to that core...
<dh`>
nah because you want to be able to unplug and throw away the old cpu board eventually
<Belxjander>
dh`: which would allow for the system to start up... and then detect the addons specific to the hardware in actual use
<dh`>
and you shouldn't have to shut down ever, either :-)
<zid>
Ideal world for me is I just boot the old OS, build a new kernel targetting the new cpu, then swap my grub config to the new kernel, reboot with the new hw
<zid>
and I keep a GENERIC_AF_KERNEL in reserve that can boot anything
* Belxjander
actually did work up a generic as hell "Launch Anything..." kernelling setup based on selecting "x86 32bit" or "x86 64bit"... basically architecture selections at boot and little else... everything after that was modularized where possible with a minimal essential to boot subset of drivers in-kernel-image
<Belxjander>
basically enough to load drivers from disk and little else for the kernel essentials driver wise
<zid>
It only works for somewhat generic setups though
<zid>
glhf if you have encrypted disks in a raid or whatever
<zid>
kernel needs to know a lot about your setup for that to work
<Belxjander>
managed to get it capable of booting about 15-16 machines all from the same installation actually with unique hostnames and setups on all of them too...
<Belxjander>
zid: yeah... I didn't have that for bootable requirements but did have support for post-launch scripted binding of such storage media
<zid>
net.ifnames kernel option is required for my OS to boot right :P
ElectronApps has quit [Remote host closed the connection]
elderK has quit [Quit: Connection closed for inactivity]
GeDaMo has joined #osdev
gog` has joined #osdev
gog` has quit [Client Quit]
ns12 has joined #osdev
sdfgsdfg has quit [Ping timeout: 256 seconds]
sdfgsdfgsdfgsfsd has joined #osdev
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
sdfgsdfgsdfgsfsd is now known as dikhed
dikhed is now known as dfghfgdh
dormito has joined #osdev
dennis95 has joined #osdev
Jari--_ has quit [Ping timeout: 256 seconds]
myon98 has quit [Ping timeout: 250 seconds]
LittleFox has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
LittleFox has joined #osdev
LittleFox has quit [Remote host closed the connection]
LittleFox has joined #osdev
LittleFox has quit [Remote host closed the connection]
LittleFox has joined #osdev
Arthuria has joined #osdev
ravan has joined #osdev
dormito10 has joined #osdev
dormito has quit [Ping timeout: 256 seconds]
ElectronApps has joined #osdev
bauen1 has joined #osdev
pretty_dumm_guy has joined #osdev
dfghfgdh has quit [Ping timeout: 256 seconds]
srjek has joined #osdev
Arthuria has quit [Ping timeout: 240 seconds]
<klys>
is anyone here familiar with qemu -display qubes-gui,domid=0,log-level=0; ?
Terlisimo has joined #osdev
gog has quit [Ping timeout: 256 seconds]
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
<Bitweasil>
Playing with the gui domain?
<Bitweasil>
(no, sorry, still learning Qubes and deciding if it's worth the hassle)
gog has joined #osdev
<zid>
what even is qubes
<Bitweasil>
Annoying? It's Invisible Things Labs "containers of isolation" OS, in which all the windows from various isolated VMs are brought together into a single combined display.
<Bitweasil>
So you can have an untrusted VM for random browsing, a personal VM for email/etc, and other isolated domains running, all separated by Xen.
crm is now known as orthoplex64
ElectronApps has quit [Remote host closed the connection]
<Bitweasil>
The concept is solid, but I don't know how much it gains you if you use multiple different machines and some are all combined system image stuff.
FreeFull has joined #osdev
* Bitweasil
waits for his office to warm.
<klys>
so I can start my vm with `virsh -c xen:/// start vm-name' and then it appears to be running (hey, I retrieved the ivt from qemu); now, there is no display visible.
<Bitweasil>
Wouldn't #qubes be a better place for gui domain discussion?
<klys>
ok I get
<Bitweasil>
Mostly because I don't think many people here actually usei t...
<klys>
yeah well most of us know qemu and can read source
friedy10- has joined #osdev
<Bitweasil>
*shrug*
gioyik has joined #osdev
<gog>
i can't read at all
<zid>
None of those signs ever stop gog afterall
<gog>
exactly
dormito10 has quit [Quit: WeeChat 3.3]
* kingoffrance
throws gog a no-reading-required fish o<
* gog
eats fishy
<gog>
i feel like a fish rn
<blockhead>
cold and wet?
<gog>
yes
<zid>
I was thinking poor long term memory and craving aniseed pop-up boilies
<gog>
that too
<zid>
is there any fishing in iceland, other than in the sea
Oli has joined #osdev
<sham1>
Where else would you fish on a volcanic island
<Bitweasil>
I would assume there are lakes and freshwater sources somewhere on it.
<zid>
I don't know enough about iceland to know
<zid>
some places.. don't have lakes, and if they do, fish are optional
<Bitweasil>
People live there, so I'd assume that it has some freshwater, somewhere.
<zid>
birds spread fish around, but there have to be freshwater fish /somewhere/ for them to do that with
<zid>
I know they have geothermal vents, and probably a brook or two
<gog>
oh yeah fly fishing for trout is a big tourist draw here
<gog>
there are many well-populated lakes and streams
<zid>
fair enough
<zid>
There's about 400 carp lakes per square mile where I live
<gog>
and it rains 300 days a year so fresh water is plentiful. also the glaciers
<zid>
we're below sea level so the water doesn't drain out
<gog>
whoops
<zid>
and the 'soil' is actually clay anyway
<zid>
so you can just dig a hole, fill it with water, and add fish
<Bitweasil>
Heh.
<gog>
nice
<Bitweasil>
Done that here... without the fish.
<Bitweasil>
"Hrm. That hole hasn't drained in three days. No, I'm not going to put a tree there."
<zid>
no liners or plants or need to fix the soil etc
<zid>
literally just dig
<zid>
you can have shear cliffs if you like
dennis95 has quit [Quit: Leaving]
<zid>
there's an open face clay mine in my town
<zid>
(they make bricks)
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
<gog>
nice
<gog>
masonry is based
<zid>
I assume icelandic houses are made of fish and moss
<gog>
mostly
<gog>
the tallest building in iceland is actually just an upturned boat
<zid>
I just got done playing a fun game, "This list removal hangs if you select more than so many elements, what clever search terms will return fewer items so you can slowly delete them all?"
<zid>
I thought the tallest building in iceland was when someone dropped an ice-cream cone
<gog>
i actually did that to an NTFS partition once
<gog>
totally by mistake
<gog>
i must've ovewrote the MFT index because i couldn't recover anything
<Bitweasil>
Yeah, I'm pretty careful with dd, lsblk beforehand, etc.
<gog>
a hard-learned lesson for me
mahmutov has joined #osdev
<sham1>
There's a reason why it's often known as "Disk Destroyer"
<Bitweasil>
That's most of what I use it for.
<Bitweasil>
Wiping drives that blkdiscard doesn't work properly on.
<kingoffrance>
eh, its useful if one is imaging. zero first, then install OS/whatever. then make image -- if this was a priorly-used disk, much smaller images
<Bitweasil>
You can do that after the install a lot more safely, though.
<bslsk05>
www.audioasylum.com: RE: A revolution in audio rendering - SBGK - Computer Audio Asylum
<kingoffrance>
maybe i should ask: does uefi store stuff on disks? maybe it is more of a danger to modern people ?
<kingoffrance>
then i would agree
<kingoffrance>
or "recovery partitions" or whatever
<Bitweasil>
What's the context? There's an EFI boot partition, but most of the stuff EFI stores gets stuck in some nvram somewhere.
<kingoffrance>
i just dont see how zeroing a disk that you are totally replacing is dangerous
<Bitweasil>
It's not. The problem is when you type the wrong partition and then zero something important.
<Bitweasil>
I'm not saying that zeroing before an OS install is bad.
<kingoffrance>
ok fair :)
<Bitweasil>
I'm saying, if you're imaging it, you should zero the free space in the partition *after* the install.
<Bitweasil>
Because if the install has downloaded and deleted temp files, those may be on the partition, as non-zeroed data, but not actively used.
<Bitweasil>
A "big zero file" after install will overwrite those with the zeros that are properly handled in imaging.
<zid>
just image the fs itself, make an iso
<zid>
rather than the drive
<zid>
note: you may want to use tar, to preserve permission bits :P
<Bitweasil>
Depends on what you're blowing it out to.
<Bitweasil>
An image you can slap on SD is pretty nice.
<gog>
what about rock ridge
* Bitweasil
mutters something about that sounds like ISO stuff and handwave mumble...
<kingoffrance>
these are not the dvds you are looking for
<Bitweasil>
I used a DVD to install an OS recently on something that was UEFI only, but didn't support exFAT USB sticks in EFI.
<Bitweasil>
It... worked.
<gog>
i don't even have an optical drive lol
<Bitweasil>
I have a couple BluRay burners that are USB3 and I use for random stuff, but this was an old laptop with a built in and still working optical drive!
<zid>
I don't even have an picture of an optical drive
Matt|home has quit [Quit: Leaving]
<gog>
wow an artifact
<gog>
belongs in a museum
<Bitweasil>
Hey, 100GB on an optical disc doesn't suck for backup. :p
<gog>
true
<zid>
it sucks because of the speed still though
<sham1>
It's like tape in that regard
<sham1>
And that's why it's backup
<zid>
100GB / 1MB/s = pain :p
<gog>
wow LTO9 can carry 18TB
<Bitweasil>
It's a whole lot faster than 1MB/s. And, backup. :p
<Bitweasil>
A stack of those backs up a lot of hard to find media.
<gog>
:|
<Bitweasil>
*shrug* Or buy an external 5TB USB drive, either way.
<Bitweasil>
I don't mind having optical media burners around.
<Bitweasil>
I did discover I lack blank CDs, though. :/
<zid>
I need a cd burner and a fat stack of CDs
<Bitweasil>
My daughter has a CD player and I was thinking of getting her some stuff burned to audio CD.
<gog>
i never did finish the last spool of CD's i bought
<zid>
so I can debug code on a playstation
<zid>
I came up with a dumb trick though so maybe I'd only need 1 disk
<zid>
but all the assets to the disk, launch the exe by copying it into memory with the cheat cartridge
<gog>
and some dodgy DVD+RW's where every other one failed
<zid>
DVD+RWs are dodgey just cus barely anything could read em
<gog>
true
<Oli>
For measurement, I have read about floppy disk write speed to be around 100kbps and 250kbps.
<gog>
i used to make backups with a floppy. and i had an onion tied to my belt, which was the style back in those days
<Bitweasil>
It was the bees knees!
<sham1>
I could probably buy a Blu-Ray drive for about 100 euros. I'd just have to find one that can also record
<Bitweasil>
SHouldn't run you more than $60 or $70
<Bitweasil>
I've got...
<Bitweasil>
*looks*
<zid>
I never made backups on floppies they were too small for anything I'd want to back up, like my goat porn
<Bitweasil>
I have a Pioneer BDR-XD05S
<zid>
slip of the tongue, GREATEST OF ALL TIME porn
<sham1>
zid: Zip disks
<zid>
phew
<Bitweasil>
USB3, has an extra USB plug for moar power, and does everything I ask.
gioyik has quit [Ping timeout: 276 seconds]
<zid>
yea I've seen those weird double plugs
<zid>
they're like.. semi fused together
<sham1>
Siamese USB3
<gog>
yeah makes it fun to use on a laptop with only one port on either side
<Bitweasil>
If you have a USB3 port, usually it doesn't matter.
<Bitweasil>
They supply enough power.
<gog>
i'm not clicking that after what you said zid
<zid>
it's the greatest of all time cable
<zid>
not porn
<zid>
...unless you REALLY like cables
* gog
sweats profusely
<Bitweasil>
I hate those things. :/
<sham1>
Does it also involve goats
<Bitweasil>
micro-USB3.
<Bitweasil>
A goat might eat it.
<Oli>
Talking about PlayStation, one could debug code in, by using a exploit named as FreePSXBoot, and a computer communicating via serial port to the PlayStation port, using a software named as NOTPSXSerial: It features debugging and PS-EXE uploading options. One may build a PSX Serial cable end from a AV Multi Out cable, using the steps featured in the web page that the next hyperlink goes to:
<bslsk05>
github.com: Adding documentation about making a half serial I/O port with a component AV Multi Out cable, to serial_psx_cable.md by Sharwil-Summoner · Pull Request #10 · unirom/unirom.github.io · GitHub
<zid>
you don't need to use an exploit
<zid>
the port on the back is on the bus
<zid>
you can just fuck with the system in realtime, hence gamesharks
<zid>
patch it to an infinite loop somewhere, rewrite memory with your payload, done
<Oli>
That is using the parallel port!
<gog>
for earlier systems with that port
<zid>
the newer models sucked anyway (and the first model but hey)
<zid>
imagine using a scph-75xx unironically
<gog>
i know so little about playstation hacking
<zid>
you're better off
<zid>
it's a mess of a thing
<zid>
gameboy is what you want, lovely lovely gameboy
<Oli>
Its graphic coprocessor features a practical functions for drawing 3D graphics: It is very approachable.
<zid>
It does not and isn't
<zid>
It has no floating point, no perspective, etc. It's vastly inferior to the n64 in terms of accessibility, and those pale in comparison to 'literally anything else that can do 3d'
<zid>
It's probably the hardest way to do 3D you can manage
<gog>
i watched a vid about the guys that made crash bandicoot and all the stuff they had to do to eke out the most from the machine
<gog>
like monkeypatching the dev libs
<zid>
yea the sdk and kernel are both absolutely insane
<zid>
the kernel code is all total shit, and the sony provided sdk even patches the shit out of it at boot
<gog>
lol nice
<Oli>
Granted, if without a custom, albeit costly approach to calculate floating point in software, it differs from serving as smooth 3D movement than the Nintendo 64 provides, however, its graphic processor unit serves an approachable set of commands to draw on the screen to me; one may read at a list and description of, in the web page that the next hyperlink goes to:
<zid>
Then note they're about a page long and have 0 details :P
<Oli>
Perhaps I am just content with it. The geometry transformation engine documentation in continues after it.
<zid>
It's not horrific after you spend 40 hours writing the 1/3/12 fixed point code, and the dynamic tesselation engine etc
<zid>
meanwhile on n64 you just submit 3D verts
<Oli>
The Nocash psx-spx document as served me the best usage description of the platform graphic processing unit and geometry transformation engine of: I am feeling curious about if there is one describing them better.
<Oli>
Sounds nice: I am unfamiliar yet with development on Nintendo 64 platforms: Thank you for sharing about, zid!
<zid>
no, korth's docs are pretty much all there is
<zid>
other docs are just spread around various emulators and stuff
air has quit [Ping timeout: 268 seconds]
air has joined #osdev
dormito has joined #osdev
gioyik has joined #osdev
Terlisimo has quit [Quit: Connection reset by beer]
[itchyjunk] has joined #osdev
nomagno has joined #osdev
Terlisimo has joined #osdev
<gorgonical>
A good start to the week -- last night I hacked together an arduino with a temperature sensor to interact with my web power switch to upgrade my dumb on-off heater into a thermostat-controlled one.
<gorgonical>
Not osdev-related, but good motivation to get some hypervisor work done today :)
<gog>
:D
biblio has joined #osdev
<Bitweasil>
Nice!
<gog>
i haven't really gotten anything done today code wise
<gog>
i'm exhausted and would like a day off where i have no obligations or expectations to fulfill pls
sortie is now known as sortiecat
<Oli>
I have for long been debugging a feature of a sound engine; may today be the day I get it down. One step at a time!
<Oli>
Sounds as a nice place to every now and then day off you describe, gog!
* geist
yawns
<geist>
good morning folks!
<jimbzy>
Sup?
<Bitweasil>
allo!
dormito has quit [Ping timeout: 240 seconds]
dormito has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
heat has joined #osdev
<heat>
helloooo
<heat>
belated happy new year
* gog
passes bagels out all around
<heat>
yo gog did you get the address allocation working?
<gog>
almost there
<heat>
i remember reading a question of yours about the rb tree
<gog>
yeah i figured out the rbtree
<heat>
the key is the key (address), the datum is a void * that's supposed to represent what's keyed
<heat>
I didn't write that code and I honestly find it garbage
<gog>
i actually did something slightly different
<gog>
the key is the tuple (address, size) and i wrote a comparison function for it
<heat>
yes
<gog>
and i had a flash of inspiration that checking for overlaps is pointless because there are only two possible non-overlapping conditions
<bslsk05>
github.com: edk2-platforms/Extents.c at master · tianocore/edk2-platforms · GitHub
<heat>
it's such a well thought interface
<heat>
the only issue with this one is that rb tree nodes aren't inline in the structure, which they should
<heat>
for efficiency's sake
<heat>
gog: np :)
<gog>
so yeah now i have to actually finish writing some kind of heap so i can start really testing out vm allocation
<gog>
and actually write the gap-finding algo
<gog>
i have a bunch of diagrams i drew on paper of it tho
<heat>
my heap doesn't use vm allocation
<heat>
it's just a brk with a randomised base
<gog>
mine doesn't directly, i need it to allocate the tree nodes :p
<heat>
(correction: it's not a brk, but it uses one)
<gog>
i did start writing an object pool type thing but it started looking like i just needed to actually write a heap instead of doing extra work to avoid it for the moment
<heat>
also, warning: kernel unmaps are not fun
<heat>
you should avoid them
<gog>
yes
<heat>
unmapping kernel memory means broadcasting a tlb shootdown over all the cpus
<heat>
which isn't the case with user memory
<gog>
yes\
<heat>
do your vm regions have backing objects already?
<gog>
anonymous vm regions do
<gog>
and the only thing it contains is a pointer to the anonymous_fault_handler
<geist>
would need them anyway to have something to stick into the tree
<geist>
sounds like a good start
<gog>
:)
<gog>
yeah laying some good groundwork here
<gog>
much further along than any of my prior experiments
<geist>
yah the next phase after that is having the vm region point to a backing object
<geist>
then having the backing object sharable by multiple vm regions
<gog>
yes
<gog>
then you have the basis for files
<geist>
and voilá you have sharable memory
<gog>
also that
<geist>
or files, or basis for COW
<gog>
shareable memory is going to be a necessary thing. in my mind it's a message-passing kernel
<geist>
also you reduce the need to store the page mappings in the page tables
<geist>
ie, the page tables aren't load bearing anymore and you can free memory by freeing the object (and unmapping of course)
<gog>
yeah my end goal with that is to do what other kernels do and treat the page tables like a cache
<geist>
but you know this of course, mostly exposition for folks following along
<gog>
:)
<gog>
i know all the theory
<gog>
its putting it to code where i struggle :p
<geist>
that's the critical part. once you understand the pieces that's a sizable chunk of modern VM design
<geist>
or not so modern, same thing
<gog>
what's old is new again
<heat>
modern 1990s VM design
<geist>
pretty much
<zid>
disregard all that, just map things and forget about it, it'll get torn down eventually anyway. Life is fleeting, everything is meaningless.
<heat>
didn't really change did it lol
<zid>
Shared memory is a security issue, files are a pain
<geist>
the only real shift i can think of is an idea i've had that i've been talking about at work with other VM folks is to completely shift everything to runs of pages, and then COW at the run level
<geist>
ie, take something like how BTRFS handles vnodes -> file runs
<gog>
existentialOS
<geist>
and then treat it as vm objects -> runs of pages
<geist>
and COW at the page level, instead of the object level like most systems do
<heat>
isn't that kind of what the page folios patches do on Linux?
<heat>
not sure if you've been following along
<geist>
ie, COW a vm obect? do a straight clone of the object, no parent child relationship, and let the page level COW work
<geist>
nope. i have not been following along on linux. mostly on purpose, to be honest
<heat>
yeh I figure
<heat>
GPL and all that
<geist>
well and also you can't unsee things
<geist>
not from a GPL point of view
<geist>
mostly from a 'clouds your thinking' sort of view
<gog>
yes
<gog>
linux has many examples of how not to engineer software in my not-remotely-humble opinion
<heat>
they're trying out a change where all the struct page * everywhere become a page_folio structure which holds N pages, and is part of their efforts into putting huge pages in the page cache and all that
<geist>
oh that doesn't sound like what i'm thinking
<geist>
i'm thinking far more fundamental. like all the page runs in the system are a bTRFS style btree with active copy on write
<heat>
well, it doesn't hold, it just points to stuff like struct folio{ struct page *head, *tail; size_t nr_pages;};
<heat>
oh
<geist>
and if you clone a vm object it fundamentally makes a copy, but the underlying mechanism lets it lazyly COW pages individually
<geist>
instead of doing the traditional shadow copy stuff
<geist>
the fuchsia API design is in this direction so it sets up for it, sicne COWing a VMO is expressed simply as a 'clone this vmo'
<gog>
rewinding slightly, that is one thing i was thinking about before wrt page tables is that relying on them for storing information about vm state feels fundamentally shaky
<geist>
gog: agreed. for x86 you can basically get away with it if you're okay with burning lots of memory to keep page tables in ram
<geist>
but there are arches where that's not the case
<heat>
the most important bit is that if you know that mapping X's vm_region is marked VM_WRITE and mapping X has write disabled, mapping X is for some reason write protected
<geist>
do they matter? probably not. linux chose the strategy of using the page tables to hold stuff. i call those 'durable' page tables
<geist>
heat: yeah but that's precisely the kinda thing you can store in the vm region object itself
<geist>
the permissions of the mapping
<heat>
when I say mapping I mean mapping of a single page
<heat>
you can't have single page granularity like that unless you allocate a separate data structure with all of that info
<geist>
right
<geist>
*generally* speaking the answer is you allocate a separate data structure with that granularity
<geist>
since it's pretty rare to need to do single page permissions like that
<heat>
Hm? It's pretty common
<geist>
well, yeah, but not hyper aggressively
<heat>
see COW, software dirty bit
<geist>
ah yes but that can be stored inside the vm region/object heirarchy itself
<geist>
hard to explain, but that's a function of how you set up the shadow objects and whatnot
<geist>
or can be at least
<geist>
what's the harder one is if you map say a 1MB RW anonymous object
<geist>
and then go back and mark half of it as RO. do you split the mapping into two? (that's what zircon does currently)
<geist>
then what if you mark every other page as RO? do you keep splitting the mapping? (yep currently)
<geist>
most code doesnt' do that, except when it does
<heat>
depends, if it's mprotect-like, that sure
<heat>
if its kernel internal you may not need to
<Bitweasil>
GeDaMo, yeah... saw that. lulz.
<geist>
exactly. sadly there's some code that we deal with that hyper aggressively mprotects
<Bitweasil>
My Dishy is up out of cat reach.
<geist>
presumably because on other platforms it's no biggie
<geist>
some security thing where its internal heap is mprotected constantly as objects are freed or whatnot
<heat>
which platforms?
<geist>
presumably linux/windows
<heat>
afaik linux also splits regions
<heat>
you can see it on pmap <pid>
<geist>
that's what i thought too, but i guess they have an optimization there that makes it not too bad
<geist>
as it currently stands zircon will just keep splitting regions, and coalescing them later
<geist>
but it gets bad since you might end up with 10k regions
<geist>
or whatnot, depending on how aggressively they mprotect their internal stuff
<geist>
the obvious solution is to have some sort of sub-region mprotect overlay tree
<zid>
sounds like a job for a mmap flag
<geist>
where it doesn't have to split the region object, but the regio object itself has some way to mark runs of itself as having lesser permissions than the mapping in the first place
<heat>
so log2(10K) = ~14 lookups in the worst case
<geist>
since we already have those permissions: if you map a RO region you can't mprotect it to RW later
<heat>
not horrible
<geist>
but you can take a RW region and mprotect it to RO
<geist>
heat: no but enough to show up
<heat>
is that scudo paranoia?
<gog>
yeah my thinking on that is that a vm region should only be created or deleted, never split or resized. put the policy in the backing object
<geist>
heat: i dunno. i think its in chromium
<geist>
they have their own heap, etc
<heat>
>they have their own heap
<geist>
or whatever the chrome engine is
<heat>
fuck
<geist>
oh yeah that whole blob of code is already a huge pile of internal stuff
<geist>
heat: but you're right, it does beg the question: *why* does it matter? we store the region list in a WAVL tree. it should be log2
<geist>
oh oh now i remember. it's nto the tree, it's reverse lookups that are slow
<geist>
object -> regions is now a 1:N mapping
<geist>
which is inefficient currently
<heat>
but they're always 1:N no?
<heat>
at least in the design
<geist>
since the code is not currently written to assume there is an excessive number of overlapping mappings of objects
<heat>
ah yes
<geist>
rght and there are a bunch of O(N) operations from object back to all its mappings
<geist>
specificaly page mapping shootdowns when doing COW, etc
<heat>
why RO instead of unmapping the pages? that would halve the N
<geist>
ie, i map an object 1000 times, then if i deallocate a page in the middle of it i have to O(N) through all the mappings and make sure the page isnt mapped
<geist>
what do you mean RO?
<heat>
why does the chromium heap (supposedly) mprotect address space as read-only instead of unmapping it
<geist>
i have no idea.
<heat>
why does it even do anything like this
<dh`>
garbage collector
<geist>
yah possible it's in the javascript heap, indeed
<geist>
it does heavy shenanigans with pages
<geist>
also likes to manually deallocate pages, etc
* heat
wonders how portable chromium and firefox are
<geist>
both of those are bad in the zircon VM right now: creating lots of mappings of a single anonymous object + lots of page deallocates (creates a O(N) walk through all the mappings)
<dh`>
not much you can do to avoid that
<geist>
yah i dunno precisely how linux/windows avoid such a complex thing, but maybe they understand that there are a ton of mappings that dont overlap
<geist>
and thus it's not a O(N) walk anymore
<geist>
but a log2 walk from object -> mapping to find which one intersects
<geist>
our code assumes that all mappings are equally overlapping so it has to walk through every one. it's simply a linked list of all mappings attached to an object
<geist>
anyway, fun things to solve. just VM stuff you get into when you start running bigass code on it
<heat>
I know linux has a bunch of reverse mapping code
<heat>
it's not just a simple linked list of mappings
<geist>
yah probably some sort of more clever algorithm to avoid this
<geist>
also i guess if you had a per page -> mapping reverse lookup you could drill into the object, iterate per page and then walk back to all the mappings
<geist>
i know the BSDs have traditionally stored that
<gog>
yeah struct pmap
<gog>
or something
<geist>
yah
heat has quit [Remote host closed the connection]
heat has joined #osdev
<heat>
I see
<heat>
I found out how linux does it
<heat>
dunno if you wanna hear it, since GPL2 and whatnot
<geist>
it's not GPL2 that i'm worried about
<geist>
what do they do in this case?
<heat>
for anonymous mappings, they essentially maintain a red-black tree of (start_mapping, end_mapping) for each anon backing object
<heat>
it's all object-based reverse mapping, not per-page
<geist>
ah and they can be sure they dont overlap because tey have a different notion of shared vs anoymous mappings
<heat>
I was reading a lwn article from 2003 where it said they found per-page reverse mapping really slow and with large overhead
<geist>
IIRC. a shared mapping uses different plumbing
<heat>
I think shared mappings use internal tmpfs? not sure
<geist>
ah so that's a fundamental difference: zircon has no concept of shared vs unshared mappings. mappings are simply mappings
<heat>
non shared mappings can also be shared
<heat>
with COW
<geist>
it's very flexibe, but.... in this case it reduces the chance of optimization because you can't tell if N mappings of an object are overlapping or not since there's no distinction between mapping the same object N times
<geist>
hmm, so then how does their red/black tree handle that?
<geist>
does it point back to an intermediate mapping which then broadcasts out to multiple ones?
<sham1>
Could be a special bit in the actual backing object
<sham1>
Not sure though
<heat>
it iterates through the tree
<heat>
they have some code where it can look at the subtree [lower_bound, upper_bound]
<geist>
or coudl be their red/black tree allows multiple overlapping mappings
<geist>
yah okay
<heat>
I don't see them calling a generic rb_tree_insert() so I imagine this is all hacky
<zid>
wow, did you see ingo's new patchset?
<j`ey>
2,000 commits later...
<zid>
ingo's new patchset is 22000
<zid>
:D
<gog>
jesus
<zid>
sorry, 25000
<zid>
178,024 insertions(+), 74,720 deletions(-)
<j`ey>
25,000 changed files
<geist>
what was it? major refactor?
<j`ey>
header file cleanup
<zid>
loots of header cleanup
<zid>
which meant basically every file needed its include list fixing up too
<j`ey>
revamping headers a ton to stop having huge headers
<j`ey>
one example was that a preprocessed pid.c went from 90k lines to 30k lines
<bslsk05>
lwn.net: [PATCH 0000/2297] [ANNOUNCE, RFC] "Fast Kernel Headers" Tree -v1: Eliminate the Linux kernel's "Dependency Hell" [LWN.net]
<geist>
cool
<zid>
mainly centered around the task struct stuff, by the looks of it
<zid>
lots of things were including task.h to access some random task detail
<j`ey>
yeah, that stuff is kinda nasty, using untyped bytes and stuff
<zid>
which then recursively included EVERY task related header
<j`ey>
(the new stuff is nasty, but it makes sense)
<zid>
yea it's a shame he couldn't come up with a better workaround for that
<j`ey>
the new way is to just attach a giant pile of bytes at the end of the task_struct, and then have accessors with unique offsets into that
<zid>
I'd love to see a testcase for exactly why it ends up being necessary
<zid>
I assume it's just that
<zid>
struct task { struct bob a; struct bar b; struct foo c; .. } ends up being the task def
<zid>
which means you need to know sizes, and thus recursively include headers
<geist>
yah have had some recursive header problems in zircon basically concerning the same header (kernel/thread.h)
<geist>
since ltos of stuff has anchors in the thread struct you get a recursive problem where thing can't be easily declared in header foo.h and also have foo.h include thread.h
<zid>
I wonder if you could somehow mechanically generate 'naked' versions of all the structs and have ghost headers
<geist>
subsystem foo has a struct it wants to put inline to the thread struct, basically
<zid>
so turn that into struct task { struct { int, int, char, char, int; } anon; struct ... };
<zid>
you might be able to generate it once ahead of time in the build scripts if you carefully include guarded each header, idk
wand has quit [Remote host closed the connection]
wand has joined #osdev
GeDaMo has quit [Remote host closed the connection]
mahmutov has quit [Ping timeout: 240 seconds]
<catern>
I vaguely recall some operating system where environment variables are thread-local, anyone know what I'm thinking of?
<geist>
not that i know of, possibly VMS
<geist>
but it's environment variables are a bit more complex than unixy ones
<sham1>
It technically breaks POSIX semantics, but it'd still be an interesting exercise
<zid>
free yourself from the yoke of posix
<dh`>
geist: hmm I figured you meant O(n) of the n reverse mappings of the same page, not all mappings
<geist>
to do the former yo need per page mapping tracking
<geist>
which of course may be the answer
<catern>
(what I even more would like to do is support full-fledged function-level dynamic scope for environment variables - so I can bind an environment variable within a single function call and have it unset when I return from that call - and also have this work with setjmp/longjmp too. but I'm not sure how to do that...)
<catern>
(so thread-locals are a first step)
<dh`>
per-page mapping tracking seems necessary if you ever invalidate pages for eviction
<dh`>
or even for "let's mark this inactive now so we can evict it later"
sdfgsdfg has joined #osdev
<geist>
not necessary, just potentially more optimal