<osdever>
sham1: everything is an object controlled by the object manager which is also the underlying "file system", the io is done by request packets, devices are treated like files, there is dpcs to realize deferred processing of work
<Ermine>
I also heard of XT architecture which claims to be derived from NT
<kingoffrance>
i will basically end (or rather, start, then build atop) up like that: "Burroughs Large Systems", wikipedia: No Assembly language or assembler; all system software written in an extended variety of ALGOL 60 named ESPOL. However, ESPOL had statements for each of the syllables in the architecture.
<kingoffrance>
however, there will be "instructions" to point to functions that implement new instructions, meta all the way down
<kingoffrance>
1960s hardware, in software, today!
xenos1984 has quit [Ping timeout: 246 seconds]
xenos1984 has joined #osdev
<osdever>
heat: yes
<osdever>
i think it is smart
<heat>
the joke is that you butchered the name
<heat>
also no you cant haha its patented!
* gog
patents heat
<osdever>
has the patent really not runout yet
<heat>
there are dozens
<heat>
capitalist gog
<gog>
5442758 is still valid
<sham1>
kingoffrance: but that's just assembler but Algol
<gog>
or maybe not idk
<Ermine>
socialist heat?
<gog>
anyhow it's 5 im gonna go home comrades
<gog>
arise ye workers from your slumbers
<gog>
and go home to tak ea lil nap
<GeDaMo>
There are processors where the assembly language is just Forth
<heat>
arise ye works from your office chairs
<osdever>
hopefully most of the patents are outdated
<sham1>
Choppers
gog has quit [Quit: Konversation terminated!]
<osdever>
then they will be useful to study to learn about rcu
<heat>
no
<Ermine>
google claims 5442758 is outdated
<heat>
studying from patents is death by 1000 cuts
<bslsk05>
github.com: lk-overlay/app/inter-arch/inter-arch.c at master · librerpi/lk-overlay · GitHub
<clever>
heat: when i wrote some custom FDT parsing code, i used fdt_next_node() to walk the tree, and as i encounter interesting nodes, i copy the values off to global vars
<clever>
once this loop has finished, the dtb in ram no longer serves any purpose, and nothing points to it
<clever>
so i can just treat it as free ram
phoooo has joined #osdev
<phoooo>
clever: is that guaranteed to always work?
<clever>
phoooo: when the dtb is in regular ram, yeah
<clever>
its just binary data, nothing makes it magical
gorgonical has joined #osdev
<phoooo>
okay okay
<gorgonical>
Turns out trying to use Linux's spinlock interface for a cross-kernel shared lock is a bad idea
<phoooo>
but that's in case I don't use libfdt
<phoooo>
that is, if I just get the desired data and don't care about the binary representation anymore
<phoooo>
anyway, thanks for the info
<heat>
gorgonical, lol what
<gorgonical>
heat: who knew that the kernel implementation of spinlocks has extra semantic information? lol
<gorgonical>
not me, apparently
<heat>
ticket locks should be pretty safe apart from preempt_disable/enable
<heat>
i know their qspinlocks are a bit fucked
<gorgonical>
anyway, I am using a spinlock to coordinate between my kernel and linux and if you acquire a spinlock linux forbids you from sleeping
<heat>
really need percpu
<heat>
yep
<gorgonical>
But in my case I still think it'
<clever>
gorgonical: ive made the mistake of using a mutex (will sleep when a conflict is found) from within an irq handler
<clever>
but that wasnt setup as a fatal error
<clever>
so instead, it only blew up when a thread tried to grab a mutex its already owning
<gorgonical>
hmm
<heat>
you just need to use one of the many options that help you debug that
<clever>
the irq handler temporarily borrows whatever thread it happens to interrupt
<heat>
including lockdep
<heat>
and classic may_sleep(); calls around the kernle
<gorgonical>
heat: I know what the problem is and exactly where it happens, just I need to change how the driver works
<gorgonical>
But this didn't happen with my QEMU kernel so I must have changed some config
benlyn has quit [Ping timeout: 248 seconds]
<gorgonical>
What's the "correct" lock to use here then, from Linux's perspective?
<gorgonical>
Or you mean that I need to reimplement a lock thing here
<heat>
spinlocks sometimes require shared percpu areas
<heat>
and dont allow sleeping if you *really* need to sleep
<heat>
semaphores work like mutexes, rw sems work like mutexes
<heat>
you should really state your problem
<heat>
not the crash :)
<gorgonical>
Okay yes. I have an inter-kernel channel that is just implemented as two one-way buffers between the two kernels
<gorgonical>
I have a state machine in my driver that coordinates the protocol between them, but I need a single bit of information to indicate state, which in this case is who has the write lock
<heat>
have you tried seqlocks?
<heat>
seqlocks sound perfect here, maybe
<gorgonical>
I haven't heard of them but I also have little experience in careful smp grounds
netbsduser has quit [Ping timeout: 256 seconds]
<heat>
but like, a manual seqlock
<heat>
so the idea is that you have a shared u32 or something
phoooo has quit [Quit: Client closed]
<heat>
when reading, you check if the sequence counter is even (if not, someone's writing, and you wait for that), then you do your read, and then you check if no one wrote in the meanwhile
<gorgonical>
I guess a seqlock does encode part of what I've got in my protocol
<heat>
writers take a lock (need to serialize against any other writers, skippable here), bump the sequence, do the write, end the write
<heat>
ending the write means bumping the seq again
<heat>
i've seen seqlocks (as an idea) be used across user <-> kernel or KVM <-> kernel barriers
<gorgonical>
So the value is that by reading the sequence number before and after data read you can tell if someone changed the data
<gorgonical>
Because otherwise I don't see any more information in this than a write lock
<heat>
yes, and if someone is changing it you just actively wait
<gorgonical>
Because what i have now is A takes lock, sends notification to B, B reads, sends ack to A, A releases lock
<gorgonical>
The general probl
<gorgonical>
This protocol is really dumb and lockstep, but it's easy
netbsduser has joined #osdev
<gorgonical>
Because with this lockstep I don't need a queue. You can be either idle, reading, or writing, and you cannot transition between reading and writing
bauen1 has joined #osdev
Left_Turn has joined #osdev
vdamewood has joined #osdev
Turn_Left has quit [Ping timeout: 245 seconds]
dude12312414 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
SGautam has joined #osdev
<dzwdz>
gcc reads $SYSROOT/usr/include/ during the build, right?
[itchyjunk] has quit [Ping timeout: 256 seconds]
goliath has quit [Quit: SIGSEGV]
[itchyjunk] has joined #osdev
<mcrod>
hi
troseman has joined #osdev
bgs has quit [Remote host closed the connection]
heat_ has joined #osdev
heat has quit [Ping timeout: 246 seconds]
stolen has quit [Quit: Connection closed for inactivity]
<heat_>
dzwdz, yes
<heat_>
pass -v and you'll see include search paths, including those gcc sees don't exist
heat_ is now known as heat
<dzwdz>
whoops, i phrased that badly
<dzwdz>
i meant when building gcc itself, after ./configure --sysroot=/whatever/
<dzwdz>
i'm wondering what happens if said sysroot is empty
<heat>
nothing
Left_Turn has quit [Read error: Connection reset by peer]
<heat>
it just can't build against those headers it's expecting, so IIRC (but im really not sure) it'll fail the build
<heat>
when build libgcc, or libstdc++, or libsanitizer, whatever