<Mutabah>
and hearing about them brings back memories
<geist>
yeah exatly, i was just saying i loved those early breakthroughs
<zid>
There's potentially a fuck load of work behind that
<zid>
depending on how those processes came to exist
<PapaFrog>
That is MBR -> Protected mode -> Long mode -> Elf loader -> multitasking with syscall/sysret.
<geist>
every time i hear any song off Kid A I think back of early osdev hackery
lentement has quit [Ping timeout: 252 seconds]
<Mutabah>
I see those and I want to get back to that level of OSDev, but then I remember that my projects are well past that and into the API design stage
<PapaFrog>
I guess I will make a filesystem next.
<zid>
how did you load your processes then, out of interest?
<zid>
I did effectively that ^ but in a really dumb way by passing them in as grub modules :D
<geist>
maybe build a little shell so yuo can interact with it a bit
<PapaFrog>
They are just functions loaded run with user-mode CS and SS.
<zid>
ahh
<zid>
The hacks to bypass "I don't have a thing I will have yet" are always fun to hear
<geist>
might be fun to build a little loader without even using a FS
<geist>
just have some ELF binaries or whatnot loaded as .data payloads into the kernel
<PapaFrog>
Yeah.. i could do that.. I had to do that with fonts when I was fooling with EFI.
<heat>
are you sleeping for like, rand() % 1000 ms?
linearcannon has quit [Ping timeout: 268 seconds]
<PapaFrog>
heat: Yes.. with a LCG.
<heat>
ah, cool stuff :)
<geist>
heat: hmm, you said before it was virtio-gpu-vga?
<heat>
now make them block
<geist>
playing with some of the new graphics devices you mentioned the other day (new to me at least)
<heat>
i mentioned it a couple of hours ago :p
<heat>
wdym "you said before it was virtio-gpu-vga?"? -ENOPARSE
<geist>
i only say that because on my qemu it dpesn't say that's a valid device
[_] has quit [Remote host closed the connection]
<geist>
so really i'm asking for clarification. is it virtio-gpu-vga?
linear_cannon has joined #osdev
<heat>
oh its virtio-vga apparently
<geist>
ah yes. okay
<geist>
was just plahing with ramfb, butinteresting that linux doesn't detect that
lentement has joined #osdev
<heat>
yeah because it sees it as efifb or vesafb or whatever
ppmathis has quit [Quit: Ping timeout (120 seconds)]
<geist>
so must not be generically described, and/or linux has no driver for it
ppmathis has joined #osdev
<heat>
OVMF supports it with a GOP driver and everything, seabios probably does too
<geist>
yeah
<geist>
hmm, virtio-vga is not a valid name... i wonder if it's x86 specific...
<geist>
ah yes. eh, not that useful to me then
<heat>
it doesn't work for aarch64 because of the aforementioned problems, if thats what you mean
<geist>
well, doesn't work as in it doesn't even accept it as an option
<heat>
yep
<heat>
you'd experience corruption
<geist>
riscv does, so that's nice
<geist>
heh wow, the framebuffer is mapped waaaaaaay high on this qemu machine
<geist>
Memory at 380800004000
<heat>
i can't wait for the next qemu gpu device that makes me wonder why it was even added in the first place
<heat>
cirrus, that ati thing, bga, qxl, virtio and ramfb
<geist>
i haven't looked for docs for it but i assume it's basically a standard virtio-gpu with an extra feature bit for a fixed framebuffer or something?
lentement has quit [Ping timeout: 260 seconds]
<heat>
maybe
skipwich has quit [Quit: DISCONNECT]
<heat>
virtio is really confusing and quite honestly poorly documented in the spec
<heat>
virtio-gpu i mean
<geist>
would certainly be nice.i have a driver for virtio-gpu, but it forces you to manually implement a scanout every time you want to update
<geist>
seems like all it'd need is some way to say 'take this buffer and turn it into a forever scanout'
skipwich has joined #osdev
<geist>
also reminds me i need to finally add pci support to my virtio layer
<geist>
it only does virtio-mmio since that's where i needed it first (arm, no pci)
<heat>
i'm lacking the exact opposite :)
<geist>
yah it's not a big deal but requires some refactoring
<heat>
i have some dt PCI code in some git stash somewhere that i should really push into a branch, including bus configuration and proper enumeration
<heat>
i don't trust it to not fuck up on more commodity PC hardware though
<geist>
yah i added just enough to pick it out enough to bootstrap things
<geist>
but then there's no DT on PC hardware so everyone wins
<geist>
dangit everytime Everlong comes on I have to stop and rock out
<geist>
what a song
<heat>
linux through dark magic and nerd tears can fully reconfigure your whole PCIe hierarchy if it thinks it's wrong
<heat>
say your BARs fall outside of the pcie memory space
<immibis>
wouldn't having to tell the device every time you want to update the frame make a lot of sense for a virtual device?
<immibis>
you don't want it to deploy one of the awful systems that console emulators use to detect when you changed important memory, like marking it read-only and emulating every write instruction
<geist>
sure, it makes some sense. it's still annoying though
<geist>
you have to put together a whole virtio transaction every time
<geist>
'here, blit this object to the scanout'
<geist>
but you're right, it's probably more efficient in the end. espeically if you just have some static framebuffer console that does nothing like 99.9% of the time
<geist>
assuming the guest os is of course wired up to know when to flush or not
<zid>
I wish a single of the devices gave vblank messages
<zid>
even if it wasn't *meant* for general usage
<zid>
It'd be nice to have like, a passthrough device for opengl with vsync
gog has quit [Ping timeout: 268 seconds]
netbsduser has quit [Ping timeout: 260 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 240 seconds]
netbsduser has joined #osdev
raphaelsc has quit [Remote host closed the connection]
Neo has joined #osdev
lentement has joined #osdev
xenos1984 has joined #osdev
netbsduser has quit [Ping timeout: 264 seconds]
lentement has quit [Ping timeout: 260 seconds]
<PapaFrog>
If a PIE executable has no relocations, I can just load it at a arbitrary address and call the _start?
<Mutabah>
should be able to
jjuran has quit [Quit: jjuran]
Fingel has quit [Ping timeout: 252 seconds]
netbsduser has joined #osdev
jjuran has joined #osdev
netbsduser has quit [Ping timeout: 260 seconds]
smeso has quit [Quit: smeso]
smeso has joined #osdev
gbowne1_ has joined #osdev
gbowne1_ has quit [Read error: Connection reset by peer]
<geist>
so re: the virtio-gpu, found it in the spec, it's just a little blurb
<geist>
basically says BAR 1 will have a VGA framebuffer and the first time you create a virtio-gpu scanout it blows it away
<geist>
pretty straightforward
<zid>
I looked at virtio-gpu but it seemed overly complicated compared to just.. not using it
<zid>
but I assume it makes it work in vmware as well as qemu, rather than using one of qemus' much simpler ones
<geist>
yah and also its present on !x86 machines
<zid>
qemu-bochs or whatever that one is is very nice, it's just 'write magic numbers to tell it the size of the display and then we'll give you back an address' or whatever the simplest system you can think of is
<zid>
the pci-e stuff is just an abstraction over that, that you can do away with
<zid>
I think virtio-gpu makes you deal with the device caps thing too? The one you need co-routines to deal with nicely, bleh
<geist>
yah in general
<geist>
it requires you send messages to and fromt it to create new surfaces and query the capability
<geist>
it does have the ability to create multiple windows which is kinda neat
<zid>
does any of the software implementing virto-gpu actually.. support that?
<zid>
I can't imagine qemu doing so
gbowne1 has quit [Remote host closed the connection]
<zid>
its output always seemed very rigid and formal
<geist>
good question
<zid>
I assume it was for if you wanted to like, do a wine via virt
<zid>
and have emulated 'windows'
<zid>
like an X setup but with qemu acting as the server
<zid>
wsl works like it even
netbsduser has joined #osdev
carbonfiber has quit [Quit: Connection closed for inactivity]
lentement has joined #osdev
netbsduser has quit [Ping timeout: 252 seconds]
lentement has quit [Ping timeout: 255 seconds]
antranigv_ has joined #osdev
vdamewood has joined #osdev
antranigv has quit [Ping timeout: 260 seconds]
netbsduser has joined #osdev
netbsduser has quit [Ping timeout: 272 seconds]
masoudd has joined #osdev
antranigv_ is now known as antranigv
antranigv is now known as antranigv_
antranigv_ is now known as antranigv
antranigv is now known as antranigv_
parecos has joined #osdev
netbsduser has joined #osdev
antranigv_ has quit [Ping timeout: 272 seconds]
goliath has joined #osdev
netbsduser has quit [Ping timeout: 260 seconds]
antranigv has joined #osdev
parecos has quit [Read error: Connection reset by peer]
<zid>
what a coincidence, /win 17 is the combination to my luggage
<FireFly>
:p
netbsduser has quit [Ping timeout: 260 seconds]
vai has joined #osdev
<vai>
re
<FireFly>
tervetuloa
spareproject has joined #osdev
gog has joined #osdev
<zid>
gloggy-moggy
<gog>
ziddles
<kazinsal>
gogchamp
<gog>
kazzy
<kazinsal>
nya~
* kazinsal
pets gog
<zid>
Great googgily moogily I'm late for my nap
<kazinsal>
I've got a standup at 9:30 and a union briefing at 10, and it's 2:22, so I'm two bottles of soju deep
<gog>
one of our providers glitched out yesterday and we had so many unhidden products today that the app crashes when i try to see the summary
<gog>
that's fun
GeDaMo has joined #osdev
<kazinsal>
I'm real glad I just work on mostly on prem vmware crud now
<kazinsal>
with a few doses of AWS
<gog>
i overdose on aws daily and i feel like dying
<kazinsal>
we're just starting to dive into it
<kazinsal>
starting with VCP
<kazinsal>
moved some test SQL crap up in yesterday, with the goal of putting some prod beancounter stuff in this weekend
<kazinsal>
which is a nice easy six hours of double OT for doing nothing
<gog>
nice
<kazinsal>
guess it's new guitar time in the near future
bauen1 has quit [Ping timeout: 256 seconds]
netbsduser has joined #osdev
masoudd has quit [Ping timeout: 252 seconds]
spareproject has quit [Ping timeout: 256 seconds]
<gog>
it's new gog time
<gog>
better get a gog to keep and headpat
<zid>
is it gog time or full on gog o'clock?
<gog>
yes
<zid>
oh no
<zid>
I haven't battened down any of my hatches
<kazinsal>
incoming gogpocalypse
<kazinsal>
prepare for gogmageddon
<gog>
armagogddon
<gog>
agogcalypse
zetef has joined #osdev
zetef_ has joined #osdev
zetef has quit [Ping timeout: 264 seconds]
zetef_ has quit [Read error: Connection reset by peer]
zetef has joined #osdev
zxrom has joined #osdev
theyneversleep has joined #osdev
bauen1 has joined #osdev
<sskras>
Hi, I am new here.
<sskras>
PapaFrog, you wrote: "That is MBR -> Protected mode -> Long mode"
<sskras>
Does the Real mode => Protected mode switch happen in MBR?
<zid>
It happens wherever you do it
<zid>
are you asking him where he put it?
<sskras>
Yes, I'm asking how namely PapaFrog did that.
<zid>
It'd be very atypical to do it inside the MBR (and tbh it's pretty rare to bother doing the real mode part yourself these days)
<sskras>
zid: I guess you mean that most of OSdev relies on the bootloaders to do that switch, right?
<zid>
yea, maintaining that code yourself has a bunch of drawbacks and no benefits
<zid>
It's fun to mess around with once or twice though
<sskras>
.... unless you are writing a Type-1 hypervisor:)
<zid>
make a little bootable floppy disk you wrote all by hand or whatever.. not that floppy disks still exist
<zid>
hypervisor startup environment doesn't look like an MBR though does it
<zid>
MBR code has to like, carefully code around FAT12 structures and stuff that a doubt a hypervisor will be doing
<zid>
or the dos partition format
<sskras>
Umm, I am not sure we are on the same page. To me the MBR bootstrap code is just a 446 bytes of x86 insns structured any way you like.
<sskras>
And for a quite a long time I wondered if it's possible to implement the AHCI driver inside the bootstrap area (these 446 bytes minus the RM=>PM switch code)
<sskras>
Not really an AHCI driver, but the minimal AHCI reader...
<gog>
probably not
<zid>
446? what happened to the other 64!?
<gog>
partitionsss
xenos1984 has quit [Read error: Connection reset by peer]
<zid>
oh right the dos partition thing, the thing I literally said, uses the other 64
<zid>
I found an picture
<sskras>
zid: I assumed the disk is partitioned. But yes, in case I am architecting my own hypervisor, it may use it's own disk-blocks slicing scheme. So +64 bytes... is very handful in case I am going PM ASAP.
navi has joined #osdev
<zid>
I still don't understand why your hypervisor would give a shit about partitions at all
<zid>
you run the hypervisor in long mode, and just squirt some startup code for the guests via memcpy as far as I know
<zid>
(Unless you're windows 10 hyper-v, apparently, piece of junk)
<sskras>
Maybe because I plan to have it installed and run in parallel to the preinstalled OS (or several of them) on that PC.
<zid>
That is how hypervisors always work?
<zid>
I don't see the reason for your complicated gnostic boot scheme
<sskras>
Not necessary in general case. But in case want the hypervisor to be user-friendly, it kind of make sense.
<zid>
Normally you'd just boot your own little long mode program, and it'd launch the guest OSs transparently/agnostically
<gog>
UEFI
<sskras>
God please no! :D
<zid>
You might need to write a real mode stub if they expect to be launched by grub or whatever to copy the first sector of grub
<zid>
but that stub is entirely fake and gets its data from the aether, not a real partition scheme
<gog>
don't write programs
<zid>
^
<gog>
computers do malicious compliance
<zid>
we've already got far too many and they're all crap, we should just say "no more new things" and start deleting/pruning/repairing/etc what we've already got imo
<gog>
yes
<GeDaMo>
Sounds good to me :P
<sskras>
zid: At this point it doesn't matter if it's a hypervisor or not. We are not talking about guests yet. One of my reqs is to avoid doing RM as soon as possible. That's it.
<gog>
you can avoid real mode and protected mode entirely if you use UEFI
<GeDaMo>
Can grub jump to 64 bit mode?
<sskras>
gog: Thanks for the insight, but no – UEFI is the crap I avoid the most :). The Legacy BIOS is the only acceptable way to me. I guess that means that such project would not run on a part of new PCs.
<gog>
it can if the firmware has CSM
xenos1984 has joined #osdev
<gog>
anyhow if you're writing a type 1 hypervisor targeting only systems with legacy bios gives you a narrow range of computers on which the hypervisor can run transparently
<gog>
unless you have a more recent board that can use coreboot/libreboot
<gog>
GeDaMo: it can load 64 bit kernels but i don't think it can go directly to long mode before the kernel is loaded
<GeDaMo>
Ah
<gog>
in my humble and poorly-educated deicision the hypervisor itself should be agnostic of how it's loaded. the part that does the dirty work of getting the environment prepared for the hypervisor and the hypervisor itself should be separate concerns
<gog>
s/decision/opinion/
<sskras>
gog: true regarding transparency. But then hypervisor might take its' measures on UEFI system (after the first cold boot) to short-circuit booting the UEFI Firmware on the following reboots. Maybe by loading a ROM image of coreboot instead. I see several possibilities.
<sskras>
And I agree about being agnostic, unless I have concerns about UEFI eg. being infected / acting as a malware / spying on my devices.
<sskras>
Anyways, going the CSM way looks still OK during the initial steps to me. I just wonder about the percentage of new PCs that has no CSM support... already.
<gog>
UEFI isn't the only vector through which that can happen. and in any case you can, for the most part, hide the fact that you're EFI from the guest systems
jjuran_ has joined #osdev
<sskras>
gog: OK (even if hiding is not my objective). But you got me intrigued with the other vectors :). What are they?
<gog>
SMBios, ACPI
<gog>
those have been around for longer than EFI
<zid>
gog when are you going to verify my dmi pool data
<gog>
i already did, it's wrong
<gog>
there might be spying malware hiding in a wifi adapter
Stary has joined #osdev
jjuran has quit [Ping timeout: 260 seconds]
jjuran_ is now known as jjuran
<gog>
unless you can verify the code and silicon of everything you're running on then believing that one thing is unqiuely dangerous vs. another is naiive
<gog>
you can observe something's behavior in a vacuum and get an idea of if it's spying and calling back to its host
<gog>
but just saying "oh that's UEFI it's vulnerable" is facile because everything is vulnerable and you're trusting that in the chain of custody of the device from design to manufacture to distribution that it wasn't somehow compromised
<gog>
and it's true that UEFI provides an attack surface for applications, but a hypervisor can hide that and prevent the guest from even being able to write to the ESP or variables
CompanionCube has joined #osdev
<sskras>
I mostly agree. I just can't stand UEFI in general. It's one of the most horribly architected pieces of software I ever saw...
<gog>
UEFI as an API or its implementationS?
<sskras>
I want a hypervisor that is as much tiny as possible. Something like BitVisor and Ramooflax.
<gog>
bitvisor has a uefi loader
<sskras>
I haven't used its' API much enough to criticize it. It's the architecture that looks like a total failure to me. And not to me only.
<gog>
a total failure that exists as a reality that software developers must deal with
zetef has quit [Read error: Connection reset by peer]
<sskras>
Well, yes. And I tend to search for compromissions/alternative solutions. Though not in the potential hypervisor project which I started my asking for :)
<sskras>
But by mentioning ACPI you got me to the point where I have another q.
<bslsk05>
uefi.org: 16.1. Sleeping States — ACPI Specification 6.4 documentation
<sskras>
Is that known to be done by some open source project?
<sskras>
I mean I would like to be able to respond to network via a minimal TCP stack.
<sskras>
And be able to go full power after receiving a specific signal.
<sskras>
That's like Wake-on-LAN, just with one CPU core active...
<gog>
i don't know much about that
<sskras>
I guess it would need to turn off all the CPU cores except for one. Then to leave only interrupt from NIC bound to the TCP stack. Then probably to do HLT in a loop...
<sskras>
That's OK. You gave me quite a bunch of insights re my first question anyway :)
<gog>
the guest system would have to support the sleep states
<gog>
and you'd have to supply tables that show the emulated host supports them too
<sskras>
Ummm. Let's put the context that way: I have a PC remotely. It runs Linux. My friend does development on it. And accidentally it shuts the OS down. Traveling remote takes time. And the remote LAN setup is quite complicated. So routing Wake-on-LAN (doing a Wake-on-Internet) would be costly / needs a research.
<sskras>
My idea was that it could be possible to emulate powering the machine off [the G2 (S5) state] by the means of hypervisor. And to boot the guest OS on demand. The guest would think it was turned off and on. No real sleep state involved into the scenario.
<sskras>
A kind of poor man's Lights Out Management module emulation in software :)
<sskras>
(and that's completely unrelated to my 1st topic about avoiding RM)
<gog>
i mean yeah you can probably do that
netbsduser has quit [Ping timeout: 256 seconds]
heat has joined #osdev
<heat>
sskras, UEFI has no architecture besides "uefi driver" and "uefi application"
netbsduser has joined #osdev
<heat>
the rest is all API - and it works quite well
<heat>
the fun bit is that they're all bazel clones
<heat>
which itself is a blaze clone
<pounce>
yeah
<heat>
>If you're familiar with Blaze / Bazel, Buck or Pants you will probably find Please very familiar
<pounce>
:|
<pounce>
i used buck when i worked at fb
<pounce>
it kind of sucks
<heat>
buck or buck2?
<heat>
there's a "new" buck2 written in RUST
<pounce>
buck1
<pounce>
ik
<pounce>
buck2 is a bit better
<gog>
please ~~clap~~ build
<pounce>
at least bc it works better on non servers where the java environment is unpredictable
<heat>
having to use java build tools must be one of those things
<heat>
hey alexa, play sad music
<pounce>
well i was specifically trying to build weird apple specific things with it
<pounce>
which is horrible
<pounce>
Bundles for example, are just directories
<pounce>
and buck isn't built to "build" a directory
<pounce>
don't even get me started on preserving xattrs
<zid>
gog: Do american developers clap when the build finishes
<gog>
yes
<gog>
we always clap
<gog>
i'm building rn and it's about to finish
<gog>
clapclapclap oh fuck it failed
<heat>
are you edging the build OwO
<pounce>
bruh
<heat>
build denial
<pounce>
uwu
gildasio has quit [Ping timeout: 260 seconds]
<gog>
the build is gooning
<gog>
it won't finish
gildasio has joined #osdev
<sham1>
What a horrible day to have eyes and have to read this stuff
<heat>
gog what build system do you think jeb bush uses
<Ermine>
heat: random question: is onyx scheduler adapted for alder lake or newer
<heat>
no
<sham1>
Is onyx scheduler Jeb Bush compatible
<heat>
the onyx scheduler is not great, its a RR with priorities per-cpu with some really amateur way of balancing between cpus
<heat>
yes, the onyx scheduler voted for jeb bush in the republican primaries
<gog>
jeb bush uses ninja
Matt|home has joined #osdev
<heat>
Ermine, i've been meaning to replace it with a CFS-like algorithm
<heat>
i forgot what the name in literature is
<heat>
weighted fair queueing maybe?
<heat>
in any case that would take a large overhaul that would also make it understand core asymmetry and let it migrate threads between cores, which it currently doesn't do
<heat>
then there's the thread director thing which i... genuinely have nof ucking clue as to how that works
<Ermine>
oh, that's a lot of work
<heat>
yep. scheduling is hard
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
lentement has joined #osdev
lentement has quit [Remote host closed the connection]
bauen1 has quit [Ping timeout: 256 seconds]
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
theyneversleep has quit [Remote host closed the connection]
bauen1 has joined #osdev
<gog>
gooning and ongoing are anagrams
<gog>
you're welcome for this unnecessary information
goliath has quit [Quit: SIGSEGV]
<nikolapdp>
thank you gog
Matt|home has quit [Quit: Leaving]
<Ermine>
thank you gog
* Ermine
gives gog a piece of cheese
* gog
is fascinated
<kof673>
> incoming gogpocalypse it was "spring" yes you get your magic red stone lol
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
<sham1>
Ongoing gooning
bauen1 has quit [Ping timeout: 255 seconds]
bauen1 has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
bauen1 has quit [Ping timeout: 272 seconds]
bauen1 has joined #osdev
Fingel has joined #osdev
Fingel has quit [Quit: Fingel]
Fingel has joined #osdev
bauen1 has quit [Ping timeout: 260 seconds]
Left_Turn has joined #osdev
bauen1 has joined #osdev
Left_Turn has quit [Remote host closed the connection]
xenos1984 has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
xenos1984 has joined #osdev
Left_Turn has quit [Max SendQ exceeded]
Left_Turn has joined #osdev
<immibis>
thank you gog
bauen1 has quit [Ping timeout: 268 seconds]
bauen1 has joined #osdev
<gog>
happy to be of unnecessary service
masoudd has joined #osdev
<vai>
yo
heat has quit [Remote host closed the connection]
heat has joined #osdev
Matt|home has joined #osdev
<kof673>
> the dragon who seeks to destroy the tree of life at its roots, but is for ever foiled by the god who represents the nocturnal sun in the shape of a great cat, as seer in the dark
<kof673>
just to back up my statement lol
Turn_Left has joined #osdev
<gog>
dang
<gog>
i'm a great cat
spare has joined #osdev
lentement has joined #osdev
<heat>
yes but you're not the best cat
<heat>
the best cat is my cat
Left_Turn has quit [Ping timeout: 260 seconds]
dutch has joined #osdev
lentement has quit [Ping timeout: 268 seconds]
<immibis>
the best cat is netcat (gnu)
<gog>
my cat is better than your cat
<gog>
can your cat be a violent little bastard for no apparent reason or purpose???
<gog>
mine can
<kazinsal>
I think that's all cats
<gog>
oh
<heat>
no my cat is nice
<heat>
the green one i showed you
<heat>
i have a black and white cat and she's a meanie
<gog>
hmm
<gog>
well my cat is black and white too but he's not mean, he's just unpredictable
<Mondenkind>
well, it 'works', but you're still not allowed to do atomic operations on the members individually then
<Mondenkind>
also, it's kinda nice to do mixed-size accesses even off the trylock path. do a single 32-bit faa, and you don't need a separate load to see if you're already at the front of the line
<Ermine>
on code styling: so method names are capitalized or not?
<heat>
what code styling?
<Mondenkind>
(have to lay it out so what you add 1<<16, not 1; otherwise overflow is not handled properly)
<Mondenkind>
Ermine: whatever you want
<Ermine>
heat: in onyx
<heat>
snake case
<Mondenkind>
oh
<Ermine>
like spinlock.h Spinlock class vs pipe.cpp pipe class
<heat>
oh, thats really old and not what you should be looking at
dutch has quit [Quit: WeeChat 4.1.1]
<heat>
oh its unused too, i should remove it
<heat>
"error: address argument to atomic operation must be a pointer to integer or pointer ('struct spinlock *' invalid)"
<heat>
the fuck
<Mondenkind>
oh apparently not
<heat>
oh, pointer to integer or pointer to pointer
<Mondenkind>
i thought that was supposed to work
<Mondenkind>
and there was like some fuckery about whether padding was incorporated into the compare or not, but if you just made sure there was no padding it was fine
<heat>
yeah i had the impression it's supposed to work too
<heat>
the union looks slightly more optimal than the full struct cmpxchg
<Mondenkind>
looks like llvm gets both right--just gcc
<Mondenkind>
also i'm not sure you actually want an infinite loop there? if the cas fails, then the lock was still locked at some point concurrently with the trylock, so it is correct to return. and then trylock is waitfree
<heat>
probably, i wasn't too sure if we could observe transient failures there
<Mondenkind>
strong vs weak cas?
<heat>
no, that's already handled by the intrinsic