<klange>
While I still don't have the music, classic Doom is so much better with the sound at least. Even if I am cheating slightly by using an AC97 on an ARM VM.
<dmh>
lol nice
myon98 has joined #osdev
<geist>
ah did you punch that through PCI?
<geist>
guess so, unless there's a virtio-audio or something (which i hvaen't seen references to somewhere)
<bslsk05>
www.kraxel.org: Virtual I/O Device (VIRTIO) Version 1.1
<klange>
I don't see support for it in qemu yet; I think the most platform-appropriate option is usb-audio.
<klange>
And frankly none of this is reflective of the audio on either of the two actual hardware setups I am targetting, so *shrug*
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
<Griwes>
aaaaand I have working syscalls
<Griwes>
well, just one now, but all's fitting together correctly
<Griwes>
last thing remaining for this commit to be ready is to fix some weird build system behavior
<heat>
congrats
<heat>
i'm feeling lazy so I've just looked into riscv traps and context switching
nyah has quit [Quit: leaving]
<geist>
heat: not a lot there huh?
<geist>
only thig i find particularly annoyig with the riscv solution is there's no separate vector for 'from user space' vs 'from supervisor mode'
<geist>
so it gets a little tricky to restore the cpu state
<heat>
yeah i kinda got lazy once I realised how not-x86 the context switching is
<heat>
geist, I think there are vectors for that if you use the vectored mode
<heat>
actually no huh
<heat>
what's that for then
<geist>
the separate vectors are i think only for external irqs
<geist>
er wait maybe not even that. i didn't find it to be particularly compelling
<heat>
yeah I didn't really get them
<geist>
lemme re-read it
<geist>
but since it's optional and there's not a huge win and additional complexity tos upport both modes i didn't think it worth implementing
<heat>
it's for IRQs
<heat>
says asynchronous interrupts
<geist>
ah yeah. so only the irqs that have the top bit set
<geist>
software interrupts, timers, external
<geist>
the non interrupts (where a syscall would be vectored from) still all go through the base + 0 vector
<geist>
if you note what about 'user software interrupt', whcih is also 0, how would you tell if it's vectored or not? and i think the answer is 'that can't happen because user software interrupt can't be triggered that way' or something
<geist>
but this part of the priviledged spec is a great example of what i dont like how the riscv docs
<geist>
basically the docs are written to describe the registers
<geist>
and then when they get to the part where they describe the mtvec register (where you put in the interrupt/exception base address) it then goes ahead and describes how interrupts/exceptions work
<heat>
oh it's described in the machine stuff?
<geist>
'here's a register that holds the vector table, and oh i guess you should know what that's for, here's how interrupts work'
<geist>
and yes. it's described in the machine section. when you get to the supervisor section it assumes youv'e read the machine section
<geist>
i was bitten by that a few times to. for things that are implemented basically the same in supervisor mode it's assumed (or maybe pointed out) that the real descriptions are in the machine mode section
<geist>
and sueprvisor mode section is jsut describing basically how it applies there
<geist>
basically there seems to be no real high level 'here's how the arch works' and then a later section describing registers that let you configure the arch
<geist>
you have to jsut read the whole thig and then infer how the arch works
<heat>
yea I agree, it's weird
<heat>
especially coming from intel
<geist>
yah or even ARM. both of them treat control registers as a thing in service of the thing they're describing (the feature)
<geist>
but all of this is mitigated by the fact that the whole thing is so darn simple you can simply jsut read it end to end and basically remember it
<geist>
or at least remember the basic concepts
<geist>
as the arch inevitably gets more complicated the docs will definitely need to get restructured a bit
<heat>
something I've been meaning to ask you: is the only difference between riscv32 and 64 that registers are larger and you have more instructions (the dword variants)?
<heat>
i just had the horrible idea of copying arch/riscv to arch/arm64 and go for that for now
<klange>
at least with arm there's, like, actual hardware that's easy to get and use virtualization on
<dmh>
so true
<dmh>
how many years in
<dmh>
kinda crazy considering you can run softcore in fpga and traceout that way
<kazinsal>
someone talk me out of buying a vax
[itchyjunk] has quit [Ping timeout: 240 seconds]
sonny has joined #osdev
<dmh>
well how much
<kazinsal>
$280 USD + $105 USD for shipping to canada
<moon-child>
wow that's pretty good
<kazinsal>
microvax 3100, 32 MB
<moon-child>
get it
[itchyjunk] has joined #osdev
<kazinsal>
hrm, okay, that's a problem, no hard drive
<kazinsal>
wonder if I can just shove any ol' SCSI drive in there
<kazinsal>
ooh, multiple reports of SCSI2SD working in it
<geist>
caveat: you'll need a AUI to ethernet box (easy to find on ebay) and little DEC serial port to real serial port cable
<geist>
they used this little almost rj45 but with a key offset thing
<geist>
also easy to get on ebay
<geist>
i had managed to get it kinda working with a straight rj11 crammed into it with the pins lined up but the dec plug is better
<klange>
Something I want of the same vintage is a VT340.
<geist>
yah those also take the same plug
<geist>
id' probably get a 220 or a 420. seem to be fairly available
<geist>
340s i think were an odd duck
<klange>
They are _the_ color DEC!
<geist>
those still seem to be fairly expensive on ebay. i'm looking for a cheapo one but it hasn't happened yet
sonny has quit [Quit: Client closed]
<geist>
kazinsal: re: any old scsi drive. i found it to be pretty tolerable too. same with scsi cdroms. i also installed VMS from 'cdrom' by writing a iso image directly to a scsi drive and booting off it
<geist>
same with netbsd
<geist>
though a scsi2cd supports multiple LUNs so that makes it easy
<geist>
power wise it's not too bad either. iirc it pulls like 95W
<geist>
(not doing a good job talking you out of this am i?)
<kazinsal>
not in the slightest haha
<geist>
well, when you do it i can hook you up with the magic i had to cobble together to net boot one
<geist>
you had to speak some proprietary protocol and wrap the image it loads with some header that i figured out
<kazinsal>
ah, neat
<geist>
but once you do you can just take yuor bits and slam it in ram and start outputting chars almsot from the get go
<geist>
one neat thing: the firmware on the vax *always* respect a BRK on the serial port
<geist>
it will absolutely drop you out of whatever you're doing, even if you've completely hosed the state of the system
<geist>
so yuo can pretty much jsut hook it up in a closet somewhere and connect a serial cable to a linux box or whatnot
<kingoffrance>
^ im not certain, but i wonder if alpha also had this
<geist>
i've seen soem sparc boxes that mostly honor it. dunno precisely how it works there
<kazinsal>
yeah, that's a handy feature to have
<geist>
in the original VAX 11/780 the serial/console stuff was a separate cpu that could obviously watch the traffic go by, but i think the later ones kept the same model, even if it was built into the cpu itself
<kazinsal>
cisco boxes do too, or at least used to. if something was all messed up you could send three BRKs in a row and it'd immediately halt the machine and go into rommon
<geist>
i had remembered reading a 11/750 or 730 had an 8085 based console, etc
<geist>
also for that reason at least on the bigger VAXen you could read/write the console via writing to a pair of dedicated control registers in the cpu itself
<geist>
whcih was nice. you could basically single instruction output a char
<geist>
but iirc by the time these later microvaxes came around that was nerfed and you talk tot he serial port like a regular peripheral
<geist>
anyway. yay join the vax club!
<geist>
honestly it might be from the same seller. iirc there's someone taht's jsut perpetually selling that exact model with that exact config
<geist>
like they have some motherload they're slowly dishing out
<mxshift>
Aspeed BMC SoCs have a magic string you send on a UART that drops it into a ROM monitor with direct access to AHB
<geist>
+++ATH
<kazinsal>
NO CARRIER
* moon-child
decides to just write //todo not horrible and move on
<mxshift>
Oxide used the same string as the office wifi password for a while
<klange>
/* TODO make this less shit */
ElectronApps has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<Griwes>
ha, randomizing the order of my two (with one functioning) syscalls has already allowed me to diagnose a stupid bug in my build system
<Griwes>
neat
k8yun has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
zaquest has quit [Remote host closed the connection]
k8yun has quit [Quit: Leaving]
zaquest has joined #osdev
<kazinsal>
geist: what do you use for a console for your vax? looks like it uses some DEC 6P6C cable for RS-232
<geist>
yah that's what i was talking about, you need to at least get that
<geist>
i bought one on ebay for $10 or so
<geist>
then i can just plug it into a PC or whatnot
<kazinsal>
neat
<geist>
like i said in a pinch you can jam in a rj11 and make the pins line up, but nothing holds that in place
<geist>
AFAICT the DEC plug is the same size and pinout as a RJ11 but it has the tab offset
<geist>
presumably just to be DEC
<kazinsal>
oho, looks like someone makes a DEC MMJ to RJ45 rollover cable
<geist>
yah i remember that not being a big deal
<kazinsal>
so I can slap it in the aux port on one of the routers I keep around and dial "through" that over SSH to the VAX
<geist>
and like i also said it has an AUI on the back, so you'll want one of those too
<kazinsal>
yeah
<geist>
or a thinnet i think, but i didn't have coax cables floating around
<geist>
and i only have one old 10base T hub that takes coax anyway
<kazinsal>
haha yeah, I'd rather AUI into an actual switchport
<geist>
yah i was surprised to also find an aui to ethernet box for cheap on ebay too. one of those grey ones with the colors next to the lights
<geist>
forget the brand but i instantly recognized it
<kazinsal>
I used to have one of those around here somewhere
<geist>
must have been pretty ubiquitous
<kazinsal>
came with some old sparc box my uncle gave me when I was a youngin
<kazinsal>
which I unfortunately cannot find anymore
<geist>
Allied Telesis it appears
<geist>
AT-210TS
<kazinsal>
yep, that looks familiar
<geist>
yah looks like you can get em for $15-$20 on ebay
<bradd_>
hi. in uefi, GOP, can I somehow get the default monitors native resolution?
<moon-child>
I would just pick the biggest resolution
<bradd_>
ok
sprock has quit [Ping timeout: 256 seconds]
elastic_dog has quit [Ping timeout: 250 seconds]
<kazinsal>
you could get the EDID info for the active display from GOP
elastic_dog has joined #osdev
<kazinsal>
if you do a LocateProtocol on... I think it's EFI_EDID_DISCOVERED_PROTOCOL and it succeeds it should spit out a typedef struct {uint32_t sizeOfEdid; const uint8_t* edid}
<kazinsal>
may want to double check the UEFI docs on tha tthough
<bradd_>
yeah, I'm looking through it now. seems doable. thanks
vancz_ is now known as vancz
<geist>
hah was trying to get virtio working on the 68k virt machine
<geist>
was puzzling why it couldn't detect the devices
<geist>
someone forgot to endian swap the registers!
<zid`>
was that someone you
<geist>
maaaaaaaybe
<geist>
is kinda intersting though that the virtio mmio interface isn't host native
<geist>
though i guess in a cross endian situation like this you gotta pick one or the other, the host machine or the emulated machine
MrBonkers has quit [Remote host closed the connection]
MrBonkers has joined #osdev
the_lanetly_052 has joined #osdev
bauen1_ has quit [Ping timeout: 256 seconds]
bauen1 has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
GeDaMo has joined #osdev
masoudd has joined #osdev
gog has joined #osdev
dormito has joined #osdev
gog has quit [Read error: Connection reset by peer]
<zid`>
also makes function protos shorter so I have to split fewer of them
nyah has joined #osdev
<zid`>
Me and the VGA BOIS going on the vengabios. boom boom boom boom, I want you in my room. we'll spend the night together, together playing doom.
<gog>
when you're alone and you need a friend, someone to help you kill the demons
<gog>
just come along baby take my gun, we'll shoot some demons tonight
dennis95 has joined #osdev
catern has joined #osdev
ElectronApps has quit [Remote host closed the connection]
<zid`>
gog watch out there's a spider on your keyboard
<zid`>
wait nevermind, he's under control
<gog>
he's my friend it's ok
<zid`>
under control, gog
<zid`>
like a keyboard
<gog>
yes
<gog>
yes i get it
<gog>
:p
<zid`>
UNDER CONTROL GOG
<gog>
THANK YOU ZID
<sham1>
If you have to explain the joke, it's not funny
<zid`>
Explaining a joke is like dissecting a frog
<zid`>
nobody laughs and the frog dies
<gog>
my wife and i have an ongoing gag where we explain obvious jokes to one another
<gog>
it's funny every time imo
<zid`>
I find it funny too
<gog>
we dissected lungfish in hs bio
<zid`>
I'm dicking with page tables, did we ever discover if you need NX set all the way down, or just on the pml4e containing it
<zid`>
we discussed it before but I don't remember the actual answer
<gog>
so like for example, if you set NX in a PDE that whole 2MB is NX
<gog>
in a PDPE the whole GB
<sham1>
We had to dissect a frog or something. I didn't make jt
<gog>
permissions enforce down the tree
<zid`>
but that seems like it'd not be very cacheable
<gog>
idk if that's how it works in actual hardware is the thing
<zid`>
you'd have to keep rechecking the pdml4e even if you have the pte cached
<gog>
but in qemu i set NX on a PDPE and my kernel #PF'd on entry
<gog>
even though the PTE was not NX
<zid`>
I think maybe it only applies if it's a short entry
<zid`>
so it only marks that 2MB entry as NX if it's a huge page
<zid`>
it only marks the 1G range as NX if it's a giant page
<gog>
no, it was a regular page directory
<gog>
or PDPE rather
<gog>
PDPT*
<zid`>
I guess it does have to do a full walk the /first/ time though
<zid`>
and maybe it bails early
<zid`>
so all bits matter
<gog>
i think so
<gog>
but i'd have to dig into the docs again to make sure i understood them correctly
<zid`>
confusing notes like `With PAE paging, the PDPTEs do not determine access rights.`
<zid`>
don't help
<gog>
hm
<gog>
maybe i misremembered, i'll have to do an experiment later
[itchyjunk] has joined #osdev
<zid`>
I guess the question is
<zid`>
"What happens if I set NX in a PTE, but not in a PD"
<zid`>
The access rights from the paging-structure entries used to translate linear addresses with the page number: The logical-OR of the XD flags (necessary only if IA32_EFER.NXE = 1).
<zid`>
from the TLB section
<gog>
so qemu's behavior is right then
<zid`>
and what's qemu's b ehavior?
<gog>
logical or with the bits of its containing table
<zid`>
(I mean, it's a hypervisor right so it just does.. what your cpu does anyway?)
epony has quit [Read error: Connection reset by peer]
pretty_dumm_guy has joined #osdev
blockhead has quit []
epony has joined #osdev
<GeDaMo>
It's just occurred to me I'm the same age as Christopher Walken was when he made the Weapon of Choice video :|
<gog>
fatboy slim > moby
<gog>
he was 57 when he did that wow
<gog>
wait
<gog>
47?
<gog>
no 57
<GeDaMo>
0x39
<gog>
lol
<gog>
yes
k8yun has joined #osdev
<zid`>
GeDaMo: Can I have half your stuff when you die in the next couple of years?
<GeDaMo>
Which half? :P
<zid`>
down the middle vertically
<GeDaMo>
You could have half my stuff now, it's mostly crap :P
<zid`>
a keyboard with QWERT
<zid`>
a monitor with the start button but not the systray
epony has quit [Ping timeout: 240 seconds]
<sham1>
QWERTZ
k8yun has quit [Quit: Leaving]
epony has joined #osdev
epony has quit [Ping timeout: 240 seconds]
epony has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
gwizon has joined #osdev
vdamewood has quit [Remote host closed the connection]
vdamewood has joined #osdev
gwizon has quit [Quit: Lost terminal]
k8yun has joined #osdev
heat has joined #osdev
dennis95 has quit [Quit: Leaving]
k8yun has quit [Ping timeout: 240 seconds]
k8yun has joined #osdev
k8yun_ has joined #osdev
k8yun has quit [Ping timeout: 250 seconds]
k8yun_ has quit [Quit: Leaving]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat_ is now known as heat
epony has quit [Ping timeout: 240 seconds]
the_lanetly_052 has joined #osdev
epony has joined #osdev
k8yun has joined #osdev
tiotags has joined #osdev
epony has quit [Ping timeout: 240 seconds]
<heat>
screw it i'm going for arm64
<heat>
riscv has bored me
<geist>
hah too easy?
<geist>
come on at least get it fully working (if you hvaen't already)
<heat>
yeah i know but it's boring me
<heat>
i want a good manual again ;_;
<j`ey>
heat: and you can test on your new rpi!
<heat>
i'll stick to kvm for now xd
<j`ey>
well even that is cooler than tcg :P
[itchyjunk] has quit [Read error: Connection reset by peer]
<heat>
hmm yeah idk
<heat>
arm64 seems fun but actually completing something would be fun
<heat>
something really funny I found out: because fedora can't cross compile packages they had to compile the whole of fedora inside qemu-system-riscv tcg
<bslsk05>
lwn.net: x86 User Interrupts support [LWN.net]
<catern>
seeing the string "IPI" makes me think "slow"
<catern>
but realizing this is basically support for explicit inter-core message passing makes me think "fast"
<catern>
(i guess IPIs are not necessarily bad? they're basically message passing anyway)
<zid`>
did anyone read the code?
<zid`>
How does it erm, work
<zid`>
presumably this is hardware accelerated, so now the cpu needs to know how threads work inside your OS!?
<catern>
check the "application interface" section
<catern>
surprisingly excellent
<catern>
(by that I mean the fact that they have an actual fd interface which nicely allocates indices and all that. very cool!)
epony has quit [Ping timeout: 240 seconds]
<zid`>
so it just sets a flag associated with a file descriptor, and the kernel can check it when it wakes the task up to wake it up into effectively a signal handler instead?
<zid`>
or userspace can poll the fd, either way
<catern>
If the receiver is running (CPL=3), then the user interrupt is delivered directly without a kernel transition. If the receiver isn't running the interrupt is delivered when the receiver gets context switched back. If the receiver is blocked in the kernel, the user interrupt is delivered to the kernel which then unblocks the intended receiver to deliver the interrupt.
<catern>
seems pretty clear
<zid`>
except it's all abstract?
<catern>
doesn't seem that abstract, the implementation is pretty obvious - set some "pending_ipi" bit on the struct task and deliver when you switch into that task
<catern>
that's for if the receiver isn't running, I mean
<catern>
if the receiver is running... it sends an IPI, seems pretty clear
<catern>
it receives the IPI*
<zid`>
clearly we have different interpretations of clear
<zid`>
I understand the semantics of it fine
<zid`>
I wanted to know the mechanics, which you just on the spot made up as a guess, sort of proving my point
mrvn has joined #osdev
<catern>
fair enough
<mrvn>
moin
tiotags has quit [Quit: Leaving]
<mrvn>
Anyone know if gcc/clang can produce code coverage information for const expressions?
<mrvn>
constexpr/consteval/constinit
<heat>
i don't think so
<heat>
sancov/gcov is fully runtime
<mrvn>
and misses all constevals
<heat>
wow looks like user interrupts are crap
<mrvn>
user interrupts?
<heat>
the 10x performance gain is only when you spin in user-space
<heat>
when you (reasonably) block in the kernel, it's only 10% faster than eventfd and 40% faster than signals(which aren't really meant to be used for ipc anyway)
<mrvn>
What's the hardware part in this? Reads more like a different interface to sending signals.
<heat>
new instructions
<mrvn>
"The interrupt state of each task is referenced via MSRs which are saved and
<mrvn>
restored by the kernel during context switch.
<mrvn>
" Sounds like a lot of overhead on task switch for little gain
<heat>
do not fear, the micro benchmark is here
<catern>
heat: that's not crap
<heat>
it's 10x faster than eventfd!!!!!!!!!!!!
<heat>
(on a 1M ping-pong IPC with 1 byte messages and where you spin the whole time in user-space)
<catern>
if you have a cpu-intensive thing that's always running on a core
<catern>
you can easily reach the 10x gain
<catern>
i mean, it's just a better alternative to a spinlock
<catern>
(well, plus it has actual interrupts)
<heat>
you should never ever use a spinlock in user-space ever
<catern>
spoken like a true person-who-does-not-write-high-performance-userspace-code
<mrvn>
"If the receiver is running (CPL=3), then the user interrupt is delivered
<heat>
if you need "high performance userspace code" don't run on a conventional OS
<mrvn>
directly without a kernel transition." Is that only if the receiver task is running?
<mrvn>
I think for me this feature will be 100% pointless. Violates the "race to sleep" principle I'm going for.
<heat>
someone should tell intel futexes exist
<mrvn>
heat: futexes don't interrupt
dormito has quit [Quit: WeeChat 3.3]
<heat>
interrupting is just a cute word for "worker thread that waits for an event"
GeDaMo has quit [Remote host closed the connection]
<mrvn>
heat: no. interrupt means it doesn't have to wait
<mrvn>
interruptiong vs. polling
<heat>
you don't have to wait if you use a futex and sleep on an address
<heat>
there's no polling here
<mrvn>
sleep is a wait
<heat>
it's like waiting for an interrupt but less asynchronous
* kingoffrance
watches catern have nightmare flashbacks as this was more or less discussed in another channel
<kingoffrance>
its happening again...
<mrvn>
user interrupts compare to signals, uintr_fd compares to event_fd and futexes.
<catern>
kingoffrance: lol you're right haha
<mrvn>
Urgs, looks like user interrupts don't save state. The app has to do that manually.
<mrvn>
How will that work with lazy fpu saving in the kernel?
<heat>
x86 doesn't do lazy fpu saving anymore
<mrvn>
heat: kernels do
<heat>
no, linux doesn't
<heat>
it's actually slower
<mrvn>
linux is not all kernels
<heat>
doesn't do so since like 2016 or so
<heat>
i don't understand why you choose this option
<heat>
instead of doing something sensible like a worker thread waiting for futexes in shared memory
<mrvn>
anyway, how is the app going to save FPU/SSE state?
<mrvn>
heat: because waiting has a big kernel overhead
<heat>
spinning also has a big kernel overhead
<mrvn>
heat: hence the whish to have interrupts instead
<heat>
the 10x speedup is only when you spin in user-space lol
<heat>
it's marginally faster than eventfd when it's not spinning but blocking as usual
<mrvn>
heat: what do you mean by "spin" anyway? I don't see any spinning in the proposed API
<bslsk05>
lwn.net: Re: [RFC PATCH 00/13] x86 User Interrupts support [LWN.net]
<heat>
"The 10x gain is only seen when the receiver is spinning in User space - waiting for interrupts."
<mrvn>
heat: that seems to be very bad wording unless he means the task is doing "while(true) if (testui()) { ... }"
<mrvn>
heat: The description of the hardware feature reads more like that the receiving task just has to be running. E.g. doing some calculations or whatever.
<heat>
they also fail to give out any examples of latency, it's all relative
<mrvn>
heat: note: "If the receiver isn't running the interrupt is delivered when the receiver gets context switched back." Latency can be days.
<mrvn>
On the hardware side this seems like a nightmare to implement race free. Descriptor tables that need to be read and modified from mutliple cores, premission checked, MSR registeres changed, stack manipulated and all of it atomic.
moon-child is now known as bowl-of-petunias
bowl-of-petunias is now known as moon-child
<mrvn>
22:37 < mrvn> anyway, how is the app going to save FPU/SSE state?
<mrvn>
Does gcc/clang "interrupt" attribute handle that magically?
<heat>
xsave
<mrvn>
heat: syntax error
<heat>
?
<mrvn>
heat: it's user code and supposed to call C code from the description. If you have to mess around with asm for the handler then it failed.
<heat>
it has intrinsics I guess
<heat>
I would go with the "if you need to use __attribute__((interrupt)) in user-space, your feature failed" but that works too ;)
<mrvn>
heat: The article only mentions 'interrupt' attribute
<mrvn>
My question was if that makes gcc save FPU/SSE state as needed too
<heat>
no
<heat>
although there is going to be a new flag, muintr for the interrupt attribute
<heat>
though they explicitly mention "Applications can choose to save floating point registers as part of the interrupt handler as well."
<heat>
because x86_64 user space obviously never uses the FPU
* mrvn
thinks this feature will cause tons and tons of hidden bugs where UIPI will corrupt fpu/sse state when it happens at a bad time.
<heat>
i agree
<heat>
but i bet no one is really going to use this
<mrvn>
That makes it even worse. Because everyone will have to pay for it.
<mrvn>
(in linux)
<zid`>
KCONFIG_UIPI=N
<zid`>
ftfy
<heat>
hopefully they only save and restore in processes where the feature is actually enabled
<mrvn>
heat: unless that would leak information then
<heat>
wrmsr when switching to the thread and wrmsr when switching out
<mrvn>
And who came up with the idea of having a "senduipi <index>" instruction instead of "senduipi <index>, data"? One should be able to at least send one word of data and not just interrupt.
<zid`>
make a new index, there's your one bit of data
<mrvn>
yeah, indexes 0-64. Only needs 8 UIPIs per word then.
<mrvn>
s/64/63/
<heat>
this was really poorly thought out IMO
<mrvn>
or at least it has a verry narrow target
<heat>
for the context switching latency, the fans of this feature clearly don't like other threads all that much
<heat>
so that was never an issue ;)
masoudd has joined #osdev
<heat>
maybe they were waiting for fsgsbase to be merged so they could add another wrmsr to replace it :v
<zid`>
I think it's basically just there to implement WaitForObjectEx(thread2);
<mrvn>
it could be usefull to replace signals, at least user defined ones.
<mrvn>
zid`: no. if you wait the feature fails to deliver.
masoudd has quit [Max SendQ exceeded]
masoudd has joined #osdev
<mrvn>
"No feedback on whether the interrupt was sent or received." Oh that sounds like fun.
<mrvn>
So I do "senduipi 23" and cross my fingers.
<heat>
there are no privilege checks on senduipis too
<geist>
oh wow a mrvn appears
<heat>
they assume everything is trusted
<mrvn>
heat: The descriptors the index points to aren't checked?
<mrvn>
geist: hi geist. I'm back. Had to make some tee, took me a while.
<geist>
hah hadn't seen you since the bounce to the new server, thought maybe you got lost in the shuffle
<heat>
"The current implementation expects only trusted and cooperating processes to communicate using user interrupts."
<mrvn>
geist: yeah, missed that move.
<heat>
this literally can't replace signals
<geist>
i wonder how something like riscv's user interrupts were supposed to help with this
<geist>
or if it was for a separate thing. i dunno if it was ever actually implemented
<mrvn>
heat: In the API you need the unitr_fd to create the needed descriptor tables.
<mrvn>
.oO(Everything is a file, even permissions)
mahmutov has joined #osdev
<mrvn>
What happens when 2 cores use senduipi? Does it block one core till the receiver does uiret? Does it wake up the kernel to queue them? Does it drop it on the floor?
<mrvn>
(I assume the last)
<heat>
i think it queues them
<heat>
that would be the most interrupty behaviour
<mrvn>
heat: queues them where?
<mrvn>
interrupts just drop when it fires twice.
joe9 has quit [Ping timeout: 256 seconds]
<heat>
it's the upid I think
<mrvn>
heat: assume both cores send the same index.
<mrvn>
one probably shouldn't share indexes between senders.
<heat>
honestly idk
<heat>
another wart in x86 i guess
<mrvn>
yeah, lots of details left haning in the air in the article.
<mrvn>
geist: do you know of something to get code coverage for constexpr/consteval/constinit in c++?
dormito has joined #osdev
<mrvn>
I saw this nice talk about using constexpr for unit tests but I really don't see how to check if all code is covered then.
epony has joined #osdev
AeroNotix has joined #osdev
ShahNaim has joined #osdev
masoudd has quit [Read error: Connection reset by peer]
masoudd has joined #osdev
heat has quit [Remote host closed the connection]
<moon-child>
anyone know of good resources on implementing very robust persistent storage systems?
<dmh>
can ya quantify how robust
<kazinsal>
maybe read some whitepapers from netapp?
masoudd has quit [Remote host closed the connection]
dude12312414 has quit [Remote host closed the connection]
<mrvn>
It also really depends on what access you want to grant. It this an archive that you basically never read? Tape formats work very well for that and any error just corrupts single files or mean you have to scan a bit for the next header.
<mrvn>
read/write/modify access is a totally different beast
* moon-child
nods
<moon-child>
I want to tolerate write-heavy workloads
<geist>
probably the right strategy is to read up and learn the basics first and then work up to it
<geist>
ie, as mrvn was saying read up and understand basic RAID and techniques first
<geist>
which i think are still fairly ubiquitous
<geist>
and work up to more integrated solutions like zfs or btrfs
<geist>
but really the answer is this stuff is *incredibly* complicated
<mrvn>
or really simple.
<geist>
though like many things generally built with layers of more simpler things
<geist>
but the whole package ends up being a highly complex layer cake
<mrvn>
A raid with a tar file on it or a common FS is really trivial stuff. But if your FS is buggy then bye bye data.
<geist>
indeed. though if you also want checksumming of data you need a less trivial fs, etc
<geist>
it starts to build up
<dh`>
how robust do you mean by "very robust"?
<mrvn>
If you value your data you don't want any single point of failure. So redundancy in the disk drives (raid, zfs). But also redundancy in the software: raid+ext4 on one set, btrfs on another, zfs on a third?
<moon-child>
haha
<mrvn>
And to protect against creeping error keep backups.
<geist>
or physical redundancy, not having data in the same physical location
<kazinsal>
or metaphysical redundancy (having an expensive 24X7 support contract)
<geist>
noice
<dh`>
there's one set of techniques for not losing filesystem volumes on crashes, there's another set for protecting against disk failures, and a third set for things like forest fires burning down your machine room
<geist>
and if you combine them you get a Voltron of Storage
<mrvn>
The most important thing I feel is protecting your data while you recover from a bad drive.
<dh`>
these techniques don't really intersect that much because of the different operational constraints at the different levels of concern
<mrvn>
A lot of people fail to recover from a recoverable failure. And I mean a lot.
<kazinsal>
I've definitely seen people lose data because they thought RAID-5 was enough, and their drives were all from the same few lots
<kazinsal>
one failed, then another failed mid-rebuild
<kazinsal>
RIP your data, gone to the great bit bucket in the sky
<mrvn>
You should also buy different drive models and drives from different charges. Rotate out some good drives after a while so drives in the array all have different used time.
<mrvn>
kazinsal: that happens a lot. A raid rebuild is usually a MAJOR load on the array. Way past the usual work load. And then the old flaky drives just go down like flies.
<kazinsal>
yerp
<mrvn>
kazinsal: most people don't scrub their raids.
<dh`>
anyway, not losing filesystem volumes on crash is well understood and, theoretically, textbook material, but given the ... shortcomings of readily available implementations that might be an optimistic perspective
<kazinsal>
I do datacenter stuff for a living so I tend to see a lot of storage nightmares
<mrvn>
dh`: hardware screws that up.
<mrvn>
dh`: don't trust your drives to adhere to standards and actualy write your data when they say they do.
<kazinsal>
unreliable power is one of the most deadly things to storage systems
<dh`>
theoretically, your hardware robustness layer should take care of that (to the extent possible)
<kazinsal>
all the code in the world will not save you if your drives keep losing power during workloads once a week
<mrvn>
If you want robustness you want a write-once design.
<dh`>
there is nothing you can do with SSDs that revert to an inconsistent mix of prior states on power failure
<dh`>
other than use those disks only for /var/obj