<heat>
kof13, geist, was talking about my local linux test kernel
<heat>
it's about 10MB compressed
<kof13>
:/ i think that is normal nowadays, same with bsd
<kof13>
i don't really think it matters per se, but if you are on 64M ram you will notice :D
<heat>
it's around 34MiB uncompressed
<heat>
this isn't a tinyconfig but it has a few bells and whistles disabled
<geist>
gorgonical: it's coherent
<geist>
what the inner vs outer sharable lets you do is specify how far out it needs to worry about sharing
<geist>
so if you marked it inner sharable, and then something in the outer domain maps it it may not be coherent
<gog>
hi
<geist>
basically allows for mutiple levels of coherency
<geist>
however, in practice i think nothing at all uses outer sharable, so it's kinda moot
Vercas has joined #osdev
<geist>
i think their idea was you could have coprocessors or whatnot that are outer sharable, in which case all of your inner pages arent coherent, unless you mark them outer too
<geist>
but then that presumably has a cost, since it causes it to need to deal with more caches farther away
<heat>
hi gog we're talking about horrible arm64 mmu caching details
<geist>
note that somewhere in the manual it states that for a single OS instance all of the cpus and whatnot must be inner. so the assumption is that all symmetric cpus in a symmetric system are inner by definition
<heat>
everything has so much configurability you end up configuring it exactly the same as everyone else
<geist>
i *thought* remember reading somewhere that outer was deprecated and may be removed in some later version?
<geist>
the other page bit that i think is effectively unused is the sharable bit, iirc. it basically says from what i remember 'make this page coherent'
<geist>
as if if you didn't set it the cpu is free to be incoherent with that page. nothing of course uses that so it's always set
<geist>
also an old optimization that probably mattered in the armv6 days or something
<geist>
you also see this inner/outer thing when it comes to stuff ike the dsb/dmb instructions, or the cache flush instructions
<geist>
letting you specify how far out you want it to insert the barrier
<geist>
it's commong, for example, to see something like `dmb ish`, vs `dmb sy` (or just `dmb`)
<geist>
since the ish version only has to insert a memory barrier as much as it matters to everything in the inner domain, ie local cpus
<geist>
but doesn't need to barrier relative to other shit like devices or whatnot
<heat>
and the p a g e t a b l e w a l k e r
<geist>
which is inner, iirc
<heat>
didn't you need a dmb sy for that?
<heat>
or am i misremembering?
<geist>
i think page table walkers are inner, so no you only need inner
heat_ has joined #osdev
<heat_>
oh ok i believe you then
<heat_>
in riscv you have none of this
<heat_>
caching bits in PTEs? what's that?
<geist>
also i think you can configure that in the TTBR and/or TCR?
<heat_>
haha PMP go brrrrrrrrr
heat has quit [Read error: Connection reset by peer]
<geist>
the cache coherency of the page table walker, etc
heat_ is now known as heat
<heat>
maybe
<geist>
also one of those details you never not set
<heat>
TIL google has a funny easter egg where if you search vi it suggests emacs and vice-versa
<heat>
it's kinda cute but both should suggest to GNU NANOOOOOOOOOOOOO
<bl4ckb0ne>
it should suggest ed
<zid>
nano > vi > emacs > nano, duh
<heat>
as much as i appreciate ed as the standard unix text editor one cannot deny the superiority of GNU nano
<heat>
other nanos? those suck
<heat>
GNU nano? fuckin mint
<zid>
You're just trying to save face when you have to tell me later that you have a micro
<heat>
a microwhat
<zid>
Yes
<heat>
a microwave? yeah i have one
<heat>
it's pretty standard around here
<heat>
we're too busy having siestas to heat our own food
<heat>
today i had an endoscopy
<heat>
hopefully i get better from here on out
<bl4ckb0ne>
hows the plumbing
<heat>
it looks okay-ish but they took some samples from my stomach to take a closer look
<heat>
i had a bit of esophagitis apparently too, probably from my recent stomach problems
<heat>
geist, think we'll ever see a new MMU format that's not a radix tree?
<heat>
i struggle to see it happen, the radix tree is a pretty good data structure, O(1) and everything
<zid>
logn for write isn't it
<zid>
in base.. 4096
<zid>
basically 1 but not technically 1
<zid>
base 512
<heat>
considering the tree has a fixed depth it is O(1) isn't it?
<zid>
I guess
<zid>
feels like a scam though
<heat>
MMUs are a ponzi scheme
<zid>
MMUs are a scam by big ram to sell you more bits
<bl4ckb0ne>
is it why downloading it is so expensive
<zid>
they try to cover-up being able to download more ram
<zid>
like the oil lobby burying climate change info
<gorgonical>
geist: okay so I'm not crazy for thinking that marking my buffer as inner on both cores and cacheable in the memory attributes/MAIR would be enough?
<gorgonical>
As in, it should be enough and maybe I'm doing something wrong?
<zid>
so they have to hide it on the dark web and pay a lot for security etc, makes it hard to find and expensive
<heat>
virtual memory is nonsense
<heat>
the vm people are taking us for absolute fools
grumbler has quit [Quit: It's time]
heat has quit [Ping timeout: 252 seconds]
dh2` is now known as dh`
orccoin has joined #osdev
Arthuria has joined #osdev
<geist>
gorgonical: sounds correct to me
stolen has joined #osdev
<gorgonical>
hmm. then I'll have to check my t's and i's and see what I've done wrong. I have just now, 5 minutes ago, gotten the protocol working on hardware by setting the memory regions non-cacheable and rewriting the spinlock code and adding no-cache mmap support to my kernel
<gorgonical>
But that will obviously be slow and I don't know why it didn't work in the first place
<gorgonical>
But at least it works now
<geist>
no cache against some sort of device that's doing dma?
<geist>
like, you were dealing with a dma device and had to swtich to no cache to make it work?
<netbsduser>
for a lark i decided to implement a PE loader and shim Windows' storport.sys port driver
<netbsduser>
i tested it with the virtio storage driver for windows, which happily executed its first scsi request block
<geist>
oh neat!
<netbsduser>
there is much more to do if it's to be a useful shim, most urgently getting its interrupts and dpc infrastructure running (i just waited a moment and then checked the buffer to see if it was transfered to)
<zid>
when iastor so you can do intel bios raid!?
Vercas has quit [Ping timeout: 246 seconds]
Hammdist has joined #osdev
gog has quit [Ping timeout: 240 seconds]
Vercas has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
Arthuria has quit [Ping timeout: 246 seconds]
zxrom has quit [Ping timeout: 252 seconds]
netbsduser has quit [Ping timeout: 245 seconds]
zxrom has joined #osdev
<kazinsal>
iirc iastor is a miniport driver so it gets called by storport
Burgundy has joined #osdev
frkazoid333 has joined #osdev
<gorgonical>
geist: no, it's just regular RAM I'm using as a communication buffer
wereii has quit [Server closed connection]
wereii has joined #osdev
tutu_wind has joined #osdev
<geist>
which device is this?
<gorgonical>
the board? a rockpro64 that has a rk3399
<geist>
kk
<geist>
not some super early arm
<gorgonical>
nah
<geist>
i the cortex-a9 days or so you nad o actually turn that shit on
<geist>
so no, no reason. of course you need whatever memory barriers you need
<geist>
or something that has an implicit barrier for you, since the memory model is weak
<gorgonical>
I guess I misread the manual then? Because to me it suggests that if you have hardware coherency then setting cacheability to wb and shareable it should "just work"
<gorgonical>
Is that not true?
geist has quit [Server closed connection]
geist has joined #osdev
<geist>
well. so you have a shared memory buffer, how are you signalling to each other core that something is there?
<gorgonical>
ipi
<geist>
and you're inserting a dsb there to make sure the data is flushed before you ipi?
<gorgonical>
I did try some dsbs here an there, but I suppose its possible I wasn't being perfectly consistent about it
<gorgonical>
Sometimes these late night debug sessions can get disorganized
<geist>
ah yeah if you put in a dsb you should be okay
<gorgonical>
in theory dsb(sy) should cover all cases right?
<geist>
like as a general rule, write out the data, dsb, ipi, and the first core should have synchronized it's stuff before it sends the ipi
<geist>
yep
<gorgonical>
does the reader need to dsb sy before reading?
<geist>
no
<gorgonical>
I wouldn't think so if I have hw coherency
<gorgonical>
If it were sw coherency maybe a dc would be necessary?
kazinsal has quit [Server closed connection]
kazinsal has joined #osdev
<geist>
shouldnt need to between two cores no
<gorgonical>
anyway, if I always always dsb sy before ipi on the core where the data is modified, its inner with wb caching, then the data should be coherent,m right?
<geist>
yes
<geist>
given what you have described to me yes
<gorgonical>
because some instructions like linux's spin_trylock don't even work if you don't mark it as wb, ldaxr only works on very specific memory configuration
<gorgonical>
okay I will have to really methodically test that tomorrow then to make sure I'm not losing my mind
<gorgonical>
an extra caveat, the coherency works on the underlying pa, right?
<geist>
yes and yes you're right, atomics only work explicitly on regular memory
<geist>
i'd suggest validating your MAIR settings
<gorgonical>
yep
<gorgonical>
I'll have to do that
<geist>
there's really only a handful of ways to set it up and 'regular memory' is pretty much what you want
<gorgonical>
Ofc this all worked in QEMU because of memory model fakery and whatnot
<geist>
yes it doesn't do anytig at all with that
<gorgonical>
iirc we borrowed linux's MT_XXX settings so it should be exactly identical
<bslsk05>
github.com: lk/arch/arm64/include/arch/arm64/mmu.h at master · littlekernel/lk · GitHub
<gorgonical>
MT_NORMAL should be exactly the same as Linux's notion of it
<geist>
kk
<geist>
yeah it's hust 0xff
<gorgonical>
just got to make sure that when I'm mmaping it in I don't change the attributes or something
<gorgonical>
The point is to create a sockets-like interface for shuttling data across the trustzone boundary between so all the data movement is originated in userspace
<geist>
oh if it's across a trustzone boundary that might change things
<gorgonical>
ha ha
<geist>
i think cache coherency across that gets funny
<gorgonical>
ofc
<geist>
you muight have to clean the cache and whatnot
<gorgonical>
well the memory will never be marked as secure
<gorgonical>
the two buffers will always be non-secure
* geist
nods
<gorgonical>
so hopefully that won't create a "Secure dirty" situation
<geist>
this is where i run ot of ideas.i know very practical knowledge of dealing with trustzone shit
<geist>
yeah exactly, was thinking of a secure dirty thing
<gorgonical>
I should check up on that to be sure
<geist>
you can try to flush the cache and see if it makes it go away
<geist>
ie, write some data, clean the cache lines, see if the other side starts to magically see it
<gorgonical>
aggresively flush whole dcache before ipi?
<geist>
no no just the cache lines
<geist>
like write the data, then clean the cache line
<gorgonical>
ah
<geist>
worth a shot, see what happens
<gorgonical>
the upshot is at least it works with noncache so if this doesn't pan out I can still continue on with work and argue future work
stolen has quit [Quit: Connection closed for inactivity]
agent314 has joined #osdev
orccoin has quit [Ping timeout: 246 seconds]
PapaFrog has quit [Ping timeout: 255 seconds]
PapaFrog has joined #osdev
valshaped74248 has quit [Ping timeout: 240 seconds]
gabi-250 has quit [Ping timeout: 246 seconds]
thinkpol has quit [Server closed connection]
thinkpol has joined #osdev
gabi-250 has joined #osdev
warlock has joined #osdev
Burgundy has quit [Ping timeout: 255 seconds]
valshaped74248 has joined #osdev
orccoin has joined #osdev
nyah has joined #osdev
orccoin has quit [Ping timeout: 255 seconds]
Vercas has quit [Ping timeout: 246 seconds]
Vercas has joined #osdev
GeDaMo has joined #osdev
Hammdist has quit [Quit: Client closed]
agent314 has quit [Ping timeout: 252 seconds]
valshaped74248 has quit [Ping timeout: 255 seconds]
valshaped74248 has joined #osdev
valshaped742488 has joined #osdev
valshaped74248 has quit [Ping timeout: 240 seconds]
valshaped742488 is now known as valshaped74248
Matt|home has joined #osdev
furt_box has joined #osdev
furt_box has quit [Remote host closed the connection]
<sortie>
<heat> #osdev would be more fun if we had challenges but sadly no one but me does osdev here
<sortie>
What are you talking about
<sortie>
I osdev circles around you mannn
<sortie>
In the good ol' days we would race each other to implement stuff, like mention mesa and all three of us had OpenGL by dawn
valshaped74248 has quit [Ping timeout: 252 seconds]
tutu_wind has quit [Quit: Client closed]
valshaped74248 has joined #osdev
<kof13>
i interpreted it as somewhat tongue in cheek. also, os devs you </conway's law>
<Mutabah>
I have grown tired of this simple "OS Development" thing, and have moved on to... COMPILER DEVELOPMENT!
<Mutabah>
(... semi-jest - I do return to osdev every couple of months, but I also have a compiler that takes most of my hobby time)
<kof13>
:D if i am here i am coding something related...just i tend to have giant sidequests, code in states of non-building. it doesn't really help to post anything
mogery has joined #osdev
xenos1984 has quit [Ping timeout: 246 seconds]
xenos1984 has joined #osdev
<kof13>
here are 100 skeleton functions, compiles great. what if you try to use them? <man steps into elevator, falls into chasm>
valshaped74248 has quit [Ping timeout: 255 seconds]
MaxLeiter has quit [Server closed connection]
MaxLeiter has joined #osdev
sturmmann has joined #osdev
Burgundy has joined #osdev
valshaped74248 has joined #osdev
sturmmann has quit [Quit: sturmmann]
zxrom has quit [Quit: Leaving]
gog has joined #osdev
xenos1984 has quit [Ping timeout: 246 seconds]
stolen has joined #osdev
xenos1984 has joined #osdev
grumbler has joined #osdev
asarandi2 is now known as asarandi
netbsduser has joined #osdev
<sham1>
I do OS development since I keep working on my Emacs setup, making it better for work
dude12312414 has joined #osdev
<gog>
i don't do development
tutu_wind has joined #osdev
awita has joined #osdev
dude12312414 has quit [Client Quit]
mogery has quit [Read error: Connection reset by peer]
Burgundy has quit [Ping timeout: 246 seconds]
frkazoid333 has quit [Ping timeout: 246 seconds]
goliath has joined #osdev
Beato has quit [Quit: I have been discovered!]
onering has joined #osdev
blop_ has quit [Ping timeout: 246 seconds]
blop_ has joined #osdev
Vercas has quit [Quit: Ping timeout (120 seconds)]
Vercas has joined #osdev
<ChavGPT>
lol
<ChavGPT>
void
<ChavGPT>
vnode_lock(vnode_t vp)
<ChavGPT>
}
<ChavGPT>
{ lck_mtx_lock(&vp->v_lock);
<ChavGPT>
void
<ChavGPT>
vnode_lock_spin(vnode_t vp)
<ChavGPT>
{ lck_mtx_lock_spin(&vp->v_lock);
<ChavGPT>
}
<ChavGPT>
void
<ChavGPT>
vnode_unlock(vnode_t vp)
<ChavGPT>
{ lck_mtx_unlock(&vp->v_lock);
<ChavGPT>
}
<ChavGPT>
darwin-xnu
<ChavGPT>
this is what happens when webdevelopers decide to do some kernel hacking
<gog>
:(
<gog>
what if you're a kernel hacker that became a webdeveloper
<gog>
even though i'm not really either
<gog>
i'm actually a fraud
<ChavGPT>
i can't think of a legitimate cae o that happening
<ChavGPT>
modulo brain damage-inducing accidents etc.
<bslsk05>
lore.kernel.org: [GIT PULL] Remove Itanium support
<ChavGPT>
what are you going to run now heat and geist
<heat>
the pain is sharp
<heat>
i've always been a netbsd fan
<heat>
more than netbsduser even
<heat>
did you know netbsd can run everywhere
<ChavGPT>
except itanium
<ChavGPT>
this is an impetus for me to port SOLARIS to itanium
<netbsduser>
heat: yes and not very: you have to provide it data in the format it expects (pci information, scatter/gather lists, that sort of thing), it uses two giant variadic functions called StorPortNotification and StorPortExtendedFunction to do things like acquire/release a spinlock, enqueue a DPC, or complete a request
<bslsk05>
github.com: Windows-driver-samples/storage/miniports/storahci at main · microsoft/Windows-driver-samples · GitHub
<netbsduser>
heat: not yet, i expect to need to do more work before this would work as at a glance it needs some more stuff implemented in my storport shim
<heat>
i would be surprised if this isn't exactly the driver microsoft uses
<mcrod>
heat: hi
<heat>
hi
<netbsduser>
i suspect it is, the "fastfat" driver in the same repo is the actual bundled fat driver of windows
<heat>
Copyright (c) 1989-2000 Microsoft Corporation
<heat>
haha yes
<heat>
oh gosh they really do use exception handling in the kernel
<heat>
i guess it's fun that they made it a compiler-level construct while linux does it with assembly hacks and asm goto
Left_Turn has joined #osdev
dude12312414 has joined #osdev
valshaped74248 has quit [Quit: Gone]
valshaped742488 has joined #osdev
mogery has joined #osdev
<mcrod>
someone at my company suggested C++ for the next product
Turn_Left has joined #osdev
<mcrod>
then the examples promptly failed to compile
<mcrod>
god i'm hungry
Left_Turn has quit [Ping timeout: 240 seconds]
netbsduser` has joined #osdev
Benjojo has quit [Ping timeout: 245 seconds]
geist has quit [Read error: Connection reset by peer]
stolen has quit [Ping timeout: 255 seconds]
kazinsal has quit [Read error: Connection reset by peer]
kkd has quit [Ping timeout: 255 seconds]
relipse has quit [Ping timeout: 252 seconds]
kwilczynski has quit [Read error: Connection reset by peer]
ggherdov has quit [Read error: Connection reset by peer]
SanchayanMaity has quit [Read error: Connection reset by peer]
nohit has quit [Read error: Connection reset by peer]
theruran has quit [Ping timeout: 246 seconds]
kazinsal has joined #osdev
stolen has joined #osdev
netbsduser has quit [Ping timeout: 246 seconds]
Benjojo has joined #osdev
relipse has joined #osdev
frkzoid has joined #osdev
geist has joined #osdev
Vercas has quit [Ping timeout: 246 seconds]
Vercas has joined #osdev
tutu_wind has quit [Quit: Client closed]
mcrod has quit [Quit: leaving]
mcrod has joined #osdev
<immibis>
c++ is a good choice if you don't like the environment adding 10x speed penalty to your code just for existing
<immibis>
(but you don't mind a 10x longer compile time :P )
<geist>
also usual rule: its good if you know what you're doing, and everyone on your team does. but as you add more folks on the team that dont fully grok the language (which hardly anyone does) you'll have a lot of acquired language debt to constantly deal with
<immibis>
oh, social factors... just make the entire product by yourself without ever talking to anyone, and they won't bother you
<immibis>
don't even talk to anybody outside of work
<geist>
totes
<geist>
ie, a hobby project
<immibis>
don't even say hello to the cashier at the supermarket
xenos1984 has quit [Ping timeout: 252 seconds]
xenos1984 has joined #osdev
xenos1984 has quit [Ping timeout: 246 seconds]
Ellenor is now known as MelanieMalik
grumbler has quit [Quit: It's time]
netbsduser` has quit [Ping timeout: 255 seconds]
netbsduser` has joined #osdev
<heat>
rust
<mcrod>
rust
<heat>
have you considered writing it in
<heat>
rust
theruran has joined #osdev
xenos1984 has joined #osdev
<mcrod>
my boss's predecessor was fascinated with rust
<mcrod>
thanks, I'll just stick to C
grumbler has joined #osdev
orccoin has joined #osdev
orccoin has quit [Ping timeout: 258 seconds]
qubasa has joined #osdev
Left_Turn has joined #osdev
<nikolar>
C for the win
Turn_Left has quit [Ping timeout: 255 seconds]
<mcrod>
the problem is, C is playing catch up with some C++ features these days
<netbsduser`>
gcc should really try to innovate some improvements to C, like they used to do
<zid>
nobody gives a shit, is the problem, they're too busy trying to catch up to the C++ spec spam
<mcrod>
case ranges would be a nice to have
<mcrod>
i can definitely say though with absolute confidence ANSI C is still ruling the world
<ChavGPT>
they should make C like javascript
<netbsduser`>
i don't think anyone really writes ANSI C
<mcrod>
sure they do
<mcrod>
they hate it, but they do
<mcrod>
read: embedded
<netbsduser`>
those ones definitely don't
<mcrod>
the mega corporate embedded compiler doesn't even really support C11
<mcrod>
i know what you'll say: they write C99
<mcrod>
if they're lucky enough, they will
<sham1>
C89 KUR^W
<mcrod>
fortunately we use C99
<netbsduser`>
there's nothing in ANSI C that says that volatile int *someregister =0xwhatever; *someregister = 42; will actually write 42 to the address 0xwhatever
<mcrod>
i'm not sure I believe you
<sham1>
It's implementation-specific
<netbsduser`>
how could it make that guarantee? the standard was designed to allow for weird "C" on a LISP machine where the compiler uses arrays to represent the storage for different types, and then there are other weird "C"'s they had to accomodate like AS/400 C
<zid>
Good news, C doesn't have to say it.
<zid>
Your compiler says it, it being the thing that defines the implementation.
<zid>
Infact, int *somereg = blah; is IDB to begin with.
<netbsduser`>
that's the wonderful thing about the C that we actually write
<mcrod>
sham1 looks right: An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 2.1.2.3 Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by
<mcrod>
the
<mcrod>
unknown factors mentioned previously. *What constitutes an access to an object that has volatile-qualified type is implementation-defined.*
<zid>
It's not, via just the spec, possible to write OS code in C
<zid>
Mainly because it doesn't mandate things be.. fast? Like, a += 30; could take 800 seconds to execute and be compliant. Live with it.
<zid>
It's not a problem, just a fact
<sham1>
Writing malloc is technically undefined behaviour
<netbsduser`>
it could not be specified because its strength is precisely that it doesn't specify too much
<netbsduser`>
so true enlightenment is realising that undefined behaviour is good actually
<moon-child>
-fno-strict-aliasing c is the only real c
gog has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
stolen has quit [Quit: Connection closed for inactivity]
gareppa has joined #osdev
phoooo has joined #osdev
zxrom has joined #osdev
phoooo has quit [Client Quit]
<gog>
hi
* kazinsal
pets gog
* gog
prr
<zid>
hyper? agreed.
<ChavGPT>
hyprrrr
<ChavGPT>
you know what sucks mon
<ChavGPT>
memory reclamation in low mem conditions
awita has quit [Remote host closed the connection]
<netbsduser`>
ChavGPT: yes, i like to page things out before it gets too severe
<netbsduser`>
i keep a hierarchy of memory priority, so that e.g. paging i/o will not block when it tries to allocate its request blocks
flom84 has joined #osdev
<mcrod>
hi gog
<gog>
hi mcrod
* mcrod
hug gog
<zid>
gog: you made some kind of tree shenanigan at some point right? I need to add mmap(0,
<zid>
so that I can STEAL DLMALLOC
<gog>
i don't exactly have a mmap
<zid>
I do, it just doesn't have mmap(0,
<zid>
you have to pick the virtual address yourself
flom84 has quit [Quit: Leaving]
<moon-child>
that's mean
<moon-child>
why would you make me do that
<zid>
Hostility.
<gog>
ohh
<gog>
i sort of have that in some branch somewhere
<gog>
i have a redblacktree with keys (base, length) of used space
<gog>
so i just walk that until i find a gap with the right length
<zid>
ye that's what I remembered
<gog>
and the tree also stores a pointer to the vm struct
<zid>
Maybe I should revive my BITMAP
<gog>
if i don't still have the code it'd be fairly trivial to reproduce
<zid>
and just use that
flom84 has joined #osdev
<zid>
bitmaps are nice and easy to use/write/understand
<zid>
and only 'pretty' slow rather than 'painfully'
<gog>
bitmaps are a lot of vm space but i guess trees are too when they start getting full
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
flom84 has quit [Ping timeout: 246 seconds]
gareppa has quit [Quit: WeeChat 3.8]
vdamewood has joined #osdev
rwb is now known as rb
grumbler has quit [Quit: It's time]
<dzwdz>
what should i check if i'm unable to receive IRQs when in ring 3?
<zid>
interrupts being enabled
<dzwdz>
i run sti right before sysret
<zid>
sysret loads flags reg
<zid>
from stack
<dzwdz>
...right
<zid>
you were supposed to push 0x7202 or whatever
<zid>
if you wanted to iret to userspace with irqs enabled
<zid>
then every time after that you can just save/restore as normal
<dzwdz>
oh - eflags is part of rflags, right?
<dzwdz>
i wrongly assumed it was a separate register
<dzwdz>
and i didn't see the docs mention that sysret writes to eflags so i assumed it preserves the current value
<dzwdz>
thanks
<zid>
flags -> eflags -> rflags
<zid>
same as ax -> eax -> rax
<dzwdz>
yeah
<dzwdz>
obvious in retrospect
nortti has quit [Server closed connection]
nortti has joined #osdev
Matt|home has quit [Quit: Leaving]
<gorgonical>
I have managed the buffers themselves with caching
<gorgonical>
But still the lock isn't synchronizing correctly and I get a deadlock
<gorgonical>
But geist it did turn out to be a problem with secure dirty
<heat>
zid, you don't need mmap for dlmalloc, just brk
<zid>
yea but then you can't really free for shit
heat has quit [Remote host closed the connection]
<netbsduser`>
just experimented with loading storahci.sys
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
heat has joined #osdev
<netbsduser`>
it does require much more than viostor.sys unfortunately
<netbsduser`>
i'll eventually try and get enough shimmed for storahci.sys
<heat>
zid, not in the kernel unless you play funny tricks with virtual memory there
<heat>
but the TRADITIONAL! userspace hack is to discard ranges of unused pages that effectively reduces your memory consumption
<gog>
hi
<heat>
hi grog
<gog>
hi hete
<heat>
hete just woke up
<heat>
from a noice nap
<gog>
cool
<heat>
poggers
<mcrod>
i'm holding my cat
<gorgonical>
i just adopted a cat, mcrod
<gorgonical>
she's still in the hiding in the bathroom in her box phase
<zid>
same
mogery has quit [Quit: mogery]
<gorgonical>
that you got a cat or that you're in your bathroom hiding phase
<zid>
in a box hiding
<gorgonical>
yep
<gorgonical>
metaphorically all of us osdevers do that
<gorgonical>
in the greater box of our homes
<heat>
>all of us osdevers
<heat>
woah woah hold the phone
<heat>
other people do osdev too?
<gorgonical>
I just do shitty phd research and pretend i have chops
sturmmann has joined #osdev
<zid>
heat: Why would the kernel not want to free things, and how would I implement that 'userspace hack' without a way to track said allocations?
<heat>
sure you do, you have the mmu
<heat>
but it's not a question of "why would the kernel not want to free things", it's "give me an allocator that's trivial to implement and is Good Enough(tm)"
<heat>
all things considered, dlmalloc isn't a great choice for a kernel allocator
<heat>
but it works
<zid>
you're not really answering my question
<zid>
I'm having that question because I don't understand what you're trying to say
<zid>
"you have the mmu" isn't really an answer to "the kernel doesn't free"
ripsquid has quit [Ping timeout: 240 seconds]
<heat>
i think I misspoke
<heat>
what I meant to say is "brk isn't an impediment to freeing things, unless you're in the kernel, in which case you can take the choice of still playing the vm tricks (but may potentially fault on any memory access))"
<zid>
what vm tricks
<heat>
<heat> but the TRADITIONAL! userspace hack is to discard ranges of unused pages that effectively reduces your memory consumption
<zid>
that's a userspace hack
flx-- has joined #osdev
<zid>
and doesn't answer the question either, because of what I asked, how are you tracking that?
<heat>
it works in the kernel if you take the page faults
<zid>
The point of brk is that you're *not* doing tracking
<heat>
in the page tables
<zid>
what page faults?
flx- has quit [Read error: Connection reset by peer]
<zid>
this is like 1) brk 2) ??? 3) ??? 4) ??? 5) ??? 6) handle page fault 7) ??? 8) ???
<heat>
lets say you have a large-ish range of memory inside your brk region that is completely free
<zid>
free conceptually, we don't actually have to way to signal that it's free
<heat>
the linux system call for this (which you could implement kernel-side too) is madvise(MADV_DONTNEED)
<zid>
but then we need a way to track whether each page/range is free
<zid>
and that's.. the bitmap I suggested in the first place
<heat>
hold on
<heat>
so madvise(MADV_DONTNEED) basically takes the pages mapped on the range, unmaps them and frees them. the next page fault will give you brand new, zeroed ones
<heat>
that's the tracking. it's just the page tables
<zid>
so munmap, then
<heat>
it's not munmap, because munmap would mean next access => fault
<heat>
erm
<heat>
s/fault/SIGSEGV or whatever/
<zid>
okay but we free'd it
<zid>
why wouldn't it fault
<heat>
because it's not free in a virtual addressing sense and touching it will work as usual
<zid>
what
<heat>
that's the vm trick
<zid>
what'a a "virtual addressing sense"
<zid>
I know of mapped memory, and faults, those are my two options
<heat>
you can't mmap elsewhere and get that same range
<zid>
my cpu doesn't have a virtual addressing sense
<Cindy>
do you think virtual addressing shoudln't be on CPU?
sturmmann has quit [Ping timeout: 255 seconds]
[itchyjunk] has joined #osdev
diamondbond has joined #osdev
diamondbond has quit [Remote host closed the connection]
diamondbond has joined #osdev
diamondbond has quit [Remote host closed the connection]
<gog>
mmap me
<ChavGPT>
MAP_FAILED
<gog>
also wasn't there a 68000 something that had an external MMU
<gog>
or could use one
<gog>
but didn't need one
<zid>
yes
<zid>
nothing needs one
<zid>
It's just useful if you wanna run multiple programs
<gog>
yes
<netbsduser`>
zid: i need one
<netbsduser`>
there was a 68851 mmu for the 68020
<zid>
well, I haven't got one
<netbsduser`>
unlucky
<netbsduser`>
you can get an MMU-bearing 68030 accelerator quite cheaply, the TF536
<zid>
I want a load bearing 6502
<gog>
hi
heat has quit [Remote host closed the connection]
heat has joined #osdev
elastic_dog has quit [Ping timeout: 258 seconds]
stolen has joined #osdev
elastic_dog has joined #osdev
Left_Turn has quit [Ping timeout: 255 seconds]
Left_Turn has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]
<netbsduser`>
i've made a little progress towards running the storahci driver
<netbsduser`>
need to shim StorPortInvokeAcpiFunction (!) to get any further
<zid>
how much towards iastor.sys?
<netbsduser`>
i tested the XP version of that but it was out of the question
<netbsduser`>
used dozens upon dozens of functions from the NT kernel itself rather than nicely sticking to the storport interface
<zid>
:D
<zid>
it's STORAGE TECHNOLOGY
<zid>
not just a driver, smh
<heat>
wait, you're shimming storport and not the nt kernel stuff?
<zid>
ndiswrapper yo
<zid>
nstorwrapper
<netbsduser`>
i am not masochistic enough to deal with the entire hundreds of NT kernel symbols that general drivers use
<heat>
the enviable windows storage stack
<heat>
well i'd expect the storage drivers to still use those?
doppler2 has joined #osdev
<netbsduser`>
believe it or not, they don't
<netbsduser`>
most of them use under 25 symbols almost all (or even entirely) from storport
<zid>
I'd expect the odd call here and there for sure
<zid>
given nothing is actually stopping them
<heat>
that's bizarre
<heat>
is the rest inlined or??
<netbsduser`>
virtio-scsi for example uses a few things from the NT kernel proper and HAL, but the official MS drivers don't
<heat>
like no way there are no locks in a storage driver?
<heat>
or does storport take care of serialization for ya or?
<CompanionCube>
is the broader goal here to support some proprietary RAID driver or what?
<netbsduser`>
well, the storport interface is quite abstract, and it helps a lot with serialisation by e.g. allowing you to have MSI vectors associate with a spinlock and the ISR is locked by such
<heat>
fun and fuckery i think
<zid>
That's why I wanna see iastor CompanionCube, so I can run ICH10R raid
<netbsduser`>
and the StorPortNotification function is a massive variadic function which includes functionality like "lock MSI no. 3's associated spinlock"
<netbsduser`>
heat is right
<zid>
sweet
<CompanionCube>
ah
<netbsduser`>
i was looking at the virtio-scsi driver for windows and struck by how it looked simple enough to shim