freakazoid12345 has quit [Ping timeout: 250 seconds]
c2a1 has joined #osdev
<c2a1>
quick question, are far jumps only performed in kernel mode? where are they most common?
[_] is now known as [itchyjunk]
<Mutabah>
In modern systems, they're just something done during early bring-up
<Mutabah>
Far jumps are part of the x86's segmentation "feature", which was very commonly used in 16-bit "real mode", but nearly never used in 32-bit and larger modes
sts-q has quit [Ping timeout: 252 seconds]
<zid>
Yea you must first provide context like "Are we in 1970"
nyah has quit [Ping timeout: 252 seconds]
<vdamewood>
For real!
<c2a1>
trying to wrap my head around how context switching works
<heat>
in x86 you essentially capture each thread's context in the stack and then basically pop + iret it all
<heat>
when switching to a thread
<heat>
iret does a sort of far return to whatever segment you have on the stack
<c2a1>
what is a context typically composed of
<c2a1>
just registers and memory locations?
<heat>
basic registers, fpu state, segment registers (for user vs kernel mode), cr3 (for paging), stack
<Mutabah>
register states
<zid>
anything you don't want to have overwritten or leaked to a differnet processs
<c2a1>
like, the entire stack is copied every task switch?
<zid>
like, you'd be mad if your eax and top of stack suddenly changed every time your process got a timeslice
<kazinsal>
the stack pointer is just saved and restored
<zid>
they each use their own stack, usually
<zid>
so just yea, rsp gets saved/restored
<zid>
rsp is the trickest part of a context switch
<c2a1>
ah
elderK has joined #osdev
<c2a1>
so the kernel reads the stack stored in user memory if i'm correct
<zid>
Like, you enter an IRQ or such, and you can't touch any of the registers OR the stack without destroying them, good luck :P
<zid>
kernel never reads user stack to my knowledge
<zid>
unless you do a syscall and pass it a pointer to a struct allocated there I guess
<Mutabah>
A simple task switch method is the following:
<Mutabah>
Push all callee-save registers to the stack
<Mutabah>
Load a new CR3 (paging root register) and ESP
<Mutabah>
Pop callee-save registers
<Mutabah>
return (which returns to the saved state)
<zid>
(Then reality appears and writing to arbitrary stack pointers like that is a massive vuln and also may fail and cause an exception). Osdev is hard.
srjek|home has quit [Ping timeout: 260 seconds]
<Mutabah>
(The above assumes that you have a kernel stack for each thread, which means that user state was saved by the entry to kernel-space)
terrorjack has joined #osdev
c2a1 has quit [Read error: Connection reset by peer]
<zid>
broke his face
YuutaW has quit [Quit: WeeChat 3.2]
[itchyjunk] has quit [Quit: Leaving]
^-^hi has joined #osdev
dormito has quit [Ping timeout: 252 seconds]
dormito has joined #osdev
ElectronApps has quit [Remote host closed the connection]
elastic_dog has quit [Ping timeout: 260 seconds]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
elastic_dog has joined #osdev
X-Scale has joined #osdev
gorgonic- has joined #osdev
nanovad_ has joined #osdev
m5zs7k_ has joined #osdev
Bitweasil- has joined #osdev
particleflux_ has joined #osdev
Retr0id5 has joined #osdev
NieDzejkob_ has joined #osdev
bradd_ has joined #osdev
j`ey_ has joined #osdev
puckipedia has joined #osdev
Mutabah_ has joined #osdev
vin1 has joined #osdev
Oli_ has joined #osdev
koon_ has joined #osdev
Oli_ has quit [Client Quit]
Ameisen_ has joined #osdev
scoobydoob has joined #osdev
Celelibi_ has joined #osdev
wille2 has joined #osdev
junon has quit [*.net *.split]
X-Scale` has quit [*.net *.split]
Oli has quit [*.net *.split]
ephemer0l has quit [*.net *.split]
puck has quit [*.net *.split]
bradd has quit [*.net *.split]
vai has quit [*.net *.split]
stux|away has quit [*.net *.split]
j`ey has quit [*.net *.split]
koon has quit [*.net *.split]
scoobydoo has quit [*.net *.split]
clever has quit [*.net *.split]
Retr0id has quit [*.net *.split]
Celelibi has quit [*.net *.split]
air has quit [*.net *.split]
Mutabah has quit [*.net *.split]
Ameisen has quit [*.net *.split]
Geertiebear has quit [*.net *.split]
gorgonical has quit [*.net *.split]
vin has quit [*.net *.split]
ZetItUp has quit [*.net *.split]
NieDzejkob has quit [*.net *.split]
nanovad has quit [*.net *.split]
DanDan has quit [*.net *.split]
opios2 has quit [*.net *.split]
particleflux has quit [*.net *.split]
Bitweasil has quit [*.net *.split]
m5zs7k has quit [*.net *.split]
tux3 has quit [*.net *.split]
Retr0id5 is now known as Retr0id
nanovad_ is now known as nanovad
scoobydoob is now known as scoobydoo
Mutabah_ is now known as Mutabah
ravish0007_ has joined #osdev
wille2 is now known as wille
wille has quit [Read error: Connection reset by peer]
sts-q has quit [Ping timeout: 252 seconds]
ravish0007 has quit [Ping timeout: 252 seconds]
ornitorrincos has quit [Ping timeout: 252 seconds]
NieDzejkob_ has quit [Read error: Connection reset by peer]
ornitorrincos has joined #osdev
NieDzejkob has joined #osdev
m5zs7k_ is now known as m5zs7k
mjg has quit [Ping timeout: 252 seconds]
Marsh has joined #osdev
Santurysim has joined #osdev
andreas303 has joined #osdev
sts-q has joined #osdev
air has joined #osdev
devcpu_ has joined #osdev
elastic_dog has quit [Ping timeout: 252 seconds]
andreas3- has quit [Ping timeout: 252 seconds]
Ermine has quit [Ping timeout: 252 seconds]
night has quit [Ping timeout: 252 seconds]
Mikaku has quit [Read error: Connection reset by peer]
MiningMarsh has quit [Ping timeout: 252 seconds]
Marsh is now known as MiningMarsh
devcpu has quit [Ping timeout: 252 seconds]
kanzure has quit [Ping timeout: 252 seconds]
jbg has quit [Ping timeout: 252 seconds]
terrorjack1 has joined #osdev
wereii has quit [Read error: Connection reset by peer]
buffet1 has joined #osdev
kanzure has joined #osdev
night has joined #osdev
nanovad has quit [Ping timeout: 252 seconds]
brenns106 has quit [Ping timeout: 252 seconds]
terrorjack1 is now known as terrorjack
terrorjack has quit [Ping timeout: 252 seconds]
brenns10 has joined #osdev
wereii_ has joined #osdev
buffet has quit [Ping timeout: 252 seconds]
buffet1 is now known as buffet
Celelibi_ is now known as Celelibi
jbg has joined #osdev
nanovad has joined #osdev
dormito has quit [Ping timeout: 265 seconds]
DutchIngraham has joined #osdev
fkrauthan_ has joined #osdev
elastic_dog has joined #osdev
dutch has quit [Ping timeout: 252 seconds]
gorgonic- has quit [Ping timeout: 252 seconds]
fkrauthan has quit [Ping timeout: 252 seconds]
fkrauthan_ is now known as fkrauthan
dormito has joined #osdev
acidx has quit [Ping timeout: 252 seconds]
acidx has joined #osdev
gorgonical has joined #osdev
amine7 has joined #osdev
elderK_ has joined #osdev
elderK has quit [Ping timeout: 252 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
decartes_ has quit [Ping timeout: 252 seconds]
elderK_ is now known as elderK
xenos1984 has joined #osdev
amine has quit [Ping timeout: 252 seconds]
dh` has quit [Ping timeout: 252 seconds]
amine7 is now known as amine
vancz has quit [Ping timeout: 252 seconds]
darkstardevx has quit [Remote host closed the connection]
darkstardevx has joined #osdev
terrorjack has joined #osdev
darkstarx has joined #osdev
vancz has joined #osdev
k4m1 has quit [Ping timeout: 252 seconds]
k4m1_ has joined #osdev
sprock has quit [Ping timeout: 252 seconds]
sprock has joined #osdev
aejsmith has quit [Ping timeout: 252 seconds]
darkstardevx has quit [Ping timeout: 252 seconds]
eau has quit [Ping timeout: 252 seconds]
eau has joined #osdev
ElectronApps has joined #osdev
elderK has quit [Quit: Connection closed for inactivity]
dormito has quit [Ping timeout: 246 seconds]
jimbzy has quit [Ping timeout: 252 seconds]
dormito has joined #osdev
MiningMarsh has quit [Ping timeout: 252 seconds]
MiningMarsh has joined #osdev
heat has quit [Ping timeout: 260 seconds]
dormito has quit [Ping timeout: 250 seconds]
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
dormito has joined #osdev
dormito has quit [Ping timeout: 250 seconds]
dormito has joined #osdev
Electron has joined #osdev
ElectronApps has quit [Ping timeout: 250 seconds]
stux|away has joined #osdev
h4zel has quit [Ping timeout: 250 seconds]
dormito has quit [Ping timeout: 260 seconds]
dormito has joined #osdev
mahmutov has joined #osdev
GeDaMo has joined #osdev
vin1 is now known as vin
dormito has quit [Ping timeout: 252 seconds]
dormito has joined #osdev
dormito has quit [Ping timeout: 252 seconds]
dormito has joined #osdev
dormito has quit [Ping timeout: 252 seconds]
aejsmith has joined #osdev
h4zel has joined #osdev
dormito has joined #osdev
dormito has quit [Ping timeout: 252 seconds]
dormito has joined #osdev
Electron has quit [Quit: Leaving]
ElectronApps has joined #osdev
dormito has quit [Ping timeout: 250 seconds]
dormito has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
ElectronApps has quit [Remote host closed the connection]
<Oli>
The RPI boot process begins with ARM 32 bit mode; you can change the configuration in the boot device's first partition FAT32 filesystem
<nur>
in the "Writing a kernel in C" example there is a comment for raspi4
<Oli>
to switch to 64 bit mode*
<nur>
ah
<klange>
As I said, there is no aarch64 raspberry pi bare bones on the wiki, that is still aarch32 code, and mmio addresses on a raspberry pi are "mmio addresses on a raspberry pi", not anything to do with aarch64 even if the particular raspberry pi is one of the newfangled aarch64 ones.
xenos1984 has joined #osdev
<klange>
And that in itself is also an answer for you: The RPi 4 still supports 32-bit code, and much like any other backwards-compatible platform that supports 32-bit code, mmio is often mapped within the 32-bit range so that 32-bit code can still reach it
<nur>
so the board can't access the mmio peripherals in 64 bit mode?
<klange>
?
<nur>
you seemed to imply "mmio addresses on a raspberry pi" can only be done in 32 bit mode
<klange>
Uh, no, I did not.
<nur>
sorry I read it wrong then
<klange>
Quite wrong.
<nur>
so what you're saying is, the example code is 32 bit, and the newer aarch64 cpu also supports this mode
<klange>
Yes.
<nur>
and it boots into 32 bit mode by default
<klange>
That's irrelevant.
<Oli>
RPI boots into 32 bit mode by default
<nur>
unless we change its config otherwise
<Oli>
Exactly!
<nur>
in which case, would we be using an mmio function that accepts a 64 bit pointer
<klange>
It's MMIO. It's just an address.
<nur>
so... it doesn't matter?
<nur>
because the MMIO addresses are all in the 32 bit range anyway?
dormito10 has joined #osdev
dormito has quit [Ping timeout: 252 seconds]
<klange>
Sorry if I'm being curt, it's late here and I just spent the last hour dealing with the fallout from a bot getting access to my SMTP server and sending a million spam messages from a user's account before the mail log filled the entire disk.
<nur>
that's all right
<klange>
> the examples I've seen still use 32 bits to refer to the address space
<klange>
> why is this
<klange>
RPi 4 supports 32-bit code for backwards compatibility, so they need to map hardware to addresses that 32-bit code can reach.
<clever>
klange: the pi4 has both a low-peripherals and a high-peripherals mode
<clever>
klange: so it can put the MMIO either at the top of the 32bit addr space, or way up in 64bit space
<klange>
please stop pinging me
<klange>
just, like, in general
<clever>
ok
<nur>
thanks everyone
<nur>
clever, you can ping me anytime! :D
<clever>
nur: for the entire vc4 series (pi0 to pi3), there is a dedicated MMU, that maps the "arm physical" space to the bus addr space, 64 pages of 16mb each, covering exactly 1gig of the arm physical space
<clever>
nur: anything beyond that 1gig is a bus fault
<clever>
for the pi4, i think that mmu still exists, but i need to research the hw more
<clever>
the closed firmware allows moving the MMIO as i said above
<nur>
ah
<nur>
and I suppose it's different on different ARM boards
<clever>
yeah
<nur>
how does it work for say, if you launch an aarch64 VM with just virt IO
<clever>
you would use an api like KVM to map guest physical to host physical, and setup the MMIO to just trap into the host
<clever>
then any attempt to access MMIO triggers a fault into the host, where you can emulate it
<clever>
nur: this is a guide on how to use the raw /dev/kvm api, to create your own vm
<nur>
holy crap that's amazing
<nur>
thanks!
<clever>
KVM_SET_USER_MEMORY_REGION is used to map a range of the physical space in the guest, to a range of virtual space in the process managing it
<nur>
is that your blog
<clever>
nope, i just stumbled upon it one day
<j`ey_>
nur: i skimmed it a few years ago, it looks good
<clever>
nur: the blog example is for x86, but the only real difference is the fields in `struct kvm_regs` and what ISA you copy into the guest ram and point PC at
<nur>
if my host is x86 though
<clever>
kvm can only run a vm that is compatible with the host cpu
<clever>
if you want to run arm on x86, then you need more of an emulator, like qemu's TCG
<klange>
The far more interesting thing imo is how to actually set up the virtualization, not Linux's API around it...
dormito10 has quit [Ping timeout: 252 seconds]
dormito10 has joined #osdev
puckipedia is now known as puck
<nur>
well, if I used QEMU's full emulation mode there is no question of trapping to the host
<clever>
qemu would be setting up the traps, and handling them
<nur>
how do I find out what the addresses I need to write to are for virt IO. Some kind of PCI discovery? Is there a devicetree to be read somewhere? Is there... UEFI?
<j`ey_>
depends!
<clever>
nur: depends on what the vm is emulating
<clever>
arm stuff typically uses device-tree
<clever>
x86 typically uses acpi via bios
<clever>
uefi can be enabled on both
<nur>
aha
<nur>
"can"?
<j`ey_>
arm64 can use uefi+acpi too
<clever>
just pass it a bios blob with -bios
<clever>
the qemu console can also let you cheat, and just print the entire mmio tree
<nur>
so as a kernel writer, do we need to anticipate _everything_?
<j`ey_>
yep
<j`ey_>
if you want it to work everywhere
<clever>
or you can cheat, peek at the qemu console, and write a driver that will only work in that exact vm
<nur>
but of course we want to dynamically configure these things
<clever>
a lot of rpi baremetal is that form of cheating
<clever>
just read the docs, write to the mmio, and ignore the device-tree
<nur>
aha
<clever>
then your code will break every time a new model comes out
dormito10 has quit [Ping timeout: 252 seconds]
mahmutov has quit [Ping timeout: 252 seconds]
dormito10 has joined #osdev
gog has joined #osdev
MiningMarsh has quit [Ping timeout: 252 seconds]
dude12312414 has joined #osdev
MiningMarsh has joined #osdev
dormito10 has quit [Ping timeout: 252 seconds]
dennis95 has joined #osdev
dormito10 has joined #osdev
freakazoid12345 has joined #osdev
jimbzy has joined #osdev
mahmutov has joined #osdev
freakazoid12345 has quit [Ping timeout: 268 seconds]
freakazoid333 has joined #osdev
gxt_ is now known as gxt
ElectronApps has quit [Remote host closed the connection]
freakazoid343 has joined #osdev
dormito10 has quit [Ping timeout: 260 seconds]
DanDan_ has joined #osdev
freakazoid333 has quit [Ping timeout: 252 seconds]
mahmutov has quit [Quit: WeeChat 3.1]
gareppa has joined #osdev
DanDan_ is now known as DanDan
dormito10 has joined #osdev
gareppa has quit [Remote host closed the connection]
mahmutov has joined #osdev
vai has joined #osdev
h4zel has joined #osdev
mahmutov has quit [Ping timeout: 252 seconds]
h4zel has quit [Ping timeout: 260 seconds]
dennis95 has quit [Quit: Leaving]
mahmutov has joined #osdev
Stary_ is now known as Stary
devcpu_ has quit [Quit: leaving]
devcpu has joined #osdev
freakazoid12345 has joined #osdev
freakazoid343 has quit [Ping timeout: 252 seconds]
h4zel has joined #osdev
freakazoid343 has joined #osdev
freakazoid12345 has quit [Ping timeout: 268 seconds]
koon_ is now known as koon
freakazoid343 has quit [Ping timeout: 268 seconds]
freakazoid12345 has joined #osdev
freakazoid12345 has quit [Ping timeout: 268 seconds]
heat has joined #osdev
nickster has joined #osdev
corecode has joined #osdev
<corecode>
hi
<gog>
hi
<Oli>
Hello, corecode and gog!
<dzwdz>
what do y'all think about plan9-style exit messages?
<dzwdz>
basically when a process exits it can pass a string to the parent
<corecode>
ah like an inverse argument?
<corecode>
simplifies a lot of non-streaming IPC
<dzwdz>
i don't think i get what you mean?
<dzwdz>
like on unixes when a process exits it returns a byte
<corecode>
you invoke a process with environment and arguments
<dzwdz>
on plan9 it returns a string
<corecode>
what i'm saying is returning an (array of) strings is sort of the inverse
<corecode>
it's cute
<gog>
returning an arbitrary object could be useful
<dzwdz>
yeah, i really liked that idea first time i saw it
<corecode>
of course you need to store that somewhere until the process is reaped
<dzwdz>
but now i'm having second thoughts
<clever>
corecode: a fragment of the argv is stored in a a fixed-size array in the linux task structure
<gog>
yeah that object and its lifetime would have to be managed by the process handling portion of the code
<dzwdz>
that's very easy to implement
<dzwdz>
i feel like returning a string instead of a number complicates stuff for not much in return
<dzwdz>
you don't really gain anything by making processes return a string
<dzwdz>
if there was an error, why not just print it to stderr
<clever>
corecode: that is the difference between the truncated `Name:` in `/proc/PID/status` and the full args in some other entry
<clever>
the truncated name is in a fixed-size field, that cant be swapped out
<GeDaMo>
Return a string in which language?
<clever>
while the full argv, is peeking into the actual userland stack of the proc, and can hit swap
<corecode>
clever: yea
<dzwdz>
i think it's either always english or localised
<Oli>
If it was an error string it hands to a parent process, I am pondering about an implementation of supporting a multi-language system approach.
<corecode>
clever: that's why returning stuff means either very small storage or having to hold on to a memory object that belongs to a dead process
<corecode>
dzwdz: i think that many processes could then return their result (sort of like a function) instead of printing on stdout (procedure with side effects)
<heat>
you can already return data like that using pipes
<corecode>
no
<corecode>
that's not returning
<heat>
yes it is
<heat>
write(...); return 0;
<corecode>
so why are there process arguments
<heat>
dunno
<dzwdz>
it's just another way to pass stuff to a program
<heat>
pipes also do that
<corecode>
you could pass arguments in via a pipe
<heat>
exactly
<heat>
and that's what you do in the standard unix model
<gog>
everything is a pipe
<corecode>
because it is impractical, that's why
<heat>
read from stdin, write to stdout
<Oli>
Thank you for hinting about a process handing structured data to a parent upon it's exit; so sounds practical for me.
<dzwdz>
how about a parent passing structured data to the child?
<corecode>
yea
<corecode>
you mean a sequence of 0-terminated strings?
<corecode>
:)
<dzwdz>
or a struct or something
<heat>
stdin
<heat>
you can write anything to a pipe
<corecode>
i like the argument passing
<corecode>
and returning of data
<heat>
argument passing in the argv[] way is there because it's relatively common and useful
<heat>
returning strings isn't common nor useful
<corecode>
[citation needed]
<heat>
where would you use it?
<heat>
and how is it not replaced by stdout?
<corecode>
i would find it more useful to get data returned from a process than setting up pipes, capturing stdout, parsing it
<corecode>
because that's what a lot of spawning processes does
<heat>
no need to parse stdout
<dzwdz>
i actually think that i'm going to remove support for returning strings from my kernel
<corecode>
how do you use the output then?
<corecode>
heat: i think you're too negative
<heat>
you can pass binary through stdout
<corecode>
not engaging with the merits
<dzwdz>
you need to parse the data no matter how you get it
<corecode>
oh
h4zel has quit [Ping timeout: 252 seconds]
<corecode>
maybe the parent could pass a buffer (page) during spawn()
<heat>
how does that solve the issue?
<corecode>
what issue?
<heat>
parsing the data
<corecode>
i'm not talking about parsing
<heat>
also what's spawn()?
<corecode>
syscall that creates a process with arguments etc
<Oli>
If it isn't in a known structure for, a key=value syntax is a way to go for
<corecode>
Oli: i'd go for opaque blob with a convention
<corecode>
kernel doesn't have to care
<corecode>
dzwdz: so why did you decide to remove returning of strings?
<dzwdz>
it doesn't add anything useful
<corecode>
i think it does, but okay
<dzwdz>
and if i remove it i could simplify some of the code
<corecode>
fair
<Oli>
I would go for so, too: I feel better by it's data size compactness in contrast to.
<corecode>
it's a simple way for IPC
<dzwdz>
for heavily limited ipc
<corecode>
yea
<dzwdz>
you'd need proper ipc anyways
<dzwdz>
so why overcomplicate stuff with another shittier one
<heat>
piping works so well because you can chain everything together very easily and stdout is always open (even if its not a pipe)
<corecode>
there are advantages of having a simple solution that covers 80% of uses
<heat>
assuming reading returned data would be something akin to waitpid(), it's just not a great fit in any model
friedy has joined #osdev
<dzwdz>
heat: it does
<corecode>
i don't get the negativity
<corecode>
not everything must be unix
<dzwdz>
^
<dzwdz>
unix is overrated
<dzwdz>
but that's not a discussion that i want to have rn
<heat>
you can talk about plan9 without talking about unix i'd say
<corecode>
i mean, by all means, have processes expose RPCs
<dzwdz>
are any of y'all making oses that aren't unixy?
<corecode>
everything is a server, and you have to do an RPC
<corecode>
i do mostly embedded, so no unix there
<corecode>
hm that makes it sound like android tho
<heat>
no embedded is definitely not android
<heat>
unless you work on the kernel that is
<corecode>
no i mean everything is a server and you have to do RPC
<heat>
no that sounds like a microkernel
<corecode>
that's how android processes interact
<corecode>
service and intents they are called, i think
<clever>
you put a structure into memory, that is a series of length-prefixed objects, each with a tag on it
<heat>
the i915 also has mailboxes
<clever>
and then you put the physical address of that structure into the mailbox
<clever>
the mailbox itself, is simply a fifo, with an irq to wake the far end
<corecode>
and i guess based on use you either share ownership or transfer it?
<clever>
corecode: yeah, you flush the packet to ram, then post its addr to the mailbox, transfering ownership temporarily
<corecode>
i think modern x86 does the same for inter processor communication
<clever>
the firmware on the far end will read the packet, do something, modify the packet to hold a result, and then return the same addr, on a 2nd fifo
<corecode>
yea, message queue with shared data
<clever>
from what ive seen of arm inter-core stuff, its purely mutex primitives and a way to raise a special irq (ipi) on the far core
<corecode>
plenty of opportunity to get race conditions or memory model issues
<clever>
but there is no fifo, you have to build that yourself, using the mutex primitives
<clever>
the rpi avoids most of the race conditions, by not having an array of messages, and using the mailbox to clearly define who writes when
<clever>
so you just need to deal with the non-coherent caches
<clever>
xhci has doorbells instead of mailbox, all messages are in a ring, with a special bool saying a given msg is valid
<clever>
the doorbell is purely a mechanism to make the hw poll the array again
<corecode>
well i came in here to talk about bloom filters
<clever>
and to save writes, when the ring wraps around, it inverts the expected value if the "is valid" field
<clever>
so all stale data, becomes invalid
<corecode>
so you have another flag that you xor with to get validity?
<clever>
yeah
<corecode>
ok
<corecode>
i guess that's an extra MSB on the pointer register
<clever>
so the xhci buffer will basically look like AAAAABBBBB
<clever>
and the A is the last valid msg
<clever>
and it just keeps checking that first B, to see when it turns valid
<clever>
and its not entirely a ring-buffer, the final msg in the list, is just a "goto X, B is now valid"
<clever>
so then the array looks like AAAAAA, and the read pointer is at the front
<corecode>
ok
<clever>
and only when it becomes BAAAA, does it consider that valid, and move on
<clever>
bloom filters, is that the thing where you have say a 9x9 matrix of multiplication factors? and for each pixel of input, you multiply that pixel by every cell in the matrix, and then add it to the output, centered on the input coord?
c2a1 has joined #osdev
<c2a1>
Hey why does the multiboot header on osdev lack a tags field? is it an older specification?
<corecode>
clever: no, that's some convolution filter
<heat>
c2a1, that's multiboot1
<heat>
multiboot2 is the one that has tags
<c2a1>
ok thanks
<corecode>
clever: a bloom filter is a probabilistic data structure
<sortie>
Yeah bare bones uses a Multiboot 1 header
<c2a1>
do newer versions of grub support mb1
<heat>
yes
<clever>
corecode: ah
<c2a1>
and does mb2 allow raw binaries?
<heat>
yes? I think, not sure
* c2a1
reads
<heat>
not sure why you'd use binary blobs with multiboot
<clever>
c2a1: i think grub just looks for the multiboot magic# at an aligned addr, within the first X bytes of the binary
<clever>
it doesnt care what other structures exist in the file
<heat>
yes it does, it needs to load it
<sortie>
c2a1, if at all feasible, I always recommend using ELF as a container format. It's easy to load and avoids sooo many pit falls with flat binaries
<heat>
you can also use PE if you want to do something like linux and have a UEFI stub
<c2a1>
side question, have any of you tried using any of the bsd boot loaders with your os?
<c2a1>
trying to avoid the gpl as much as possible
<heat>
using grub doesn't bind you to the GPL
<heat>
same with gcc
<c2a1>
sortie, what are some pitfalls out of curiosity?
<heat>
c2a1, flat binaries need to be contiguous in memory or have huge blobs of 0s in between
<c2a1>
heat, even then it's somewhat relevant as they seem to be very cross platform
<c2a1>
openbsd and netbsd's to be specific. not sure if they use the same header formats abd whatnot though.
<sortie>
c2a1, the files don't say where they are supposed to be loaded. That create some ambiguity. They are difficult to inspect with debugging tools. Regions of zeros needs to be stored in them, so they can't be sparse. It's easy to screw up their loading address when making them.
<heat>
they also don't have symbol information, relocation information, no dynamic linking(although that's not kernel relevant most of the time)
<clever>
heat: i believe objcopy will deal with making them contiguous and filling in any holes between DT_LOAD's
<clever>
but yeah, elf does make things so much simpler
<heat>
if objcopy changed my load addresses I would be very angry
[itchyjunk] has quit [Remote host closed the connection]
<sortie>
c2a1, it turns out that ELF is actually super simple for loading a kernel. You read a struct header at the start. From that, you locate the segment headers. They are a list of memory locations with source offsets in the file and destination location in memory, and a trailing region to memset to 0.
<sortie>
So basically you just iterate the program headers and do the memcpy/memset operations it tells you to do
<sortie>
Dynamically loaded ELF is a lot more complex, but a statically linked ELF kernel is literally that simple.
<sortie>
c2a1, my point here is that ELF might actually be simpler than flat binaries + issues getting them working correctly + drawbacks of being unable to inspect them with debugging tools.
<heat>
that reminds me
<heat>
i have huge issues returning errors from the elf loader to the exec caller
<clever>
a mem_alloc_hook() can be used to force some relocation (but not patching) upon what elf.c does
<heat>
note that you can always flatten your elf files into binary if you need to
<c2a1>
sortie: thanks
friedy has quit [Quit: WeeChat 3.2]
dormito10 has quit [Ping timeout: 252 seconds]
dormito10 has joined #osdev
dormito10 has quit [Ping timeout: 252 seconds]
dormito10 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<geist>
clever: oh hah, i'm not sure i'd use that ELF code as an example
<geist>
it was kinda a weekend hack and written in a wonky way, kinda as an experiment (the whole callback thing)
<clever>
well, it works.... lol
<clever>
i feel like if you leave me alone too long, i might wind up adding a userland to my bootloader, with that elf code as the loader....
<clever>
all the feature creep!
<clever>
do i need a userland in my bootloader? lol
<heat>
woah I found a new errno
<heat>
ELIBBAD
<Oli>
My ideal bootloader has a beepy tune playing out of the PC speaker and a sinouidal-moving text scroller; userland in bootloader sounds like UEFI at some level to me: It may serve good!
<clever>
not counting shared logic, like libc and the 2d framework
heat has quit [Remote host closed the connection]
<kingoffrance>
"what do y'all think about plan9-style exit messages?" i have lots of ideas for strings...but have not gotten to that point yet. just fyi i am not opposed.
<kingoffrance>
i will not say good or bad, just an experiment
<kingoffrance>
and i wont know for a while how it turns out
<kingoffrance>
gimme some months/years :)
<kingoffrance>
to become "operational" lol
<kingoffrance>
i am not opposed, anyway...
<Oli>
Reading the repository linked on the description of the video you have shared with me here, I am feeling desire to express to you my gratitude for being involved in the creation of a libre firmware for RPI systems!
h4zel has joined #osdev
<clever>
Oli: some of the major tasks that remain but are relatively simple: hdmi out, proper arm SMP, pi3-aarch64 support, page flipping for linux, config files
<clever>
each of those should be simple, the answers are known, it just has to be converted into source code
<clever>
the more unknown things, are h264/mpeg2 accel, isp, camera, dsi
<Oli>
*I gaze at you, smile, and inhale deeply*
<clever>
SMP for example, the current problem is that LK claims all 4 arm cores for itself, with a fully working SMP scheduler
<clever>
Oli: arch_chain_load() is then used to execute linux on core 0
<clever>
but the problem, is that no code exists, to hand off the other 3 cores
<clever>
so the other 3, are still technically paused in LK's idle function, waiting for the LK scheduler to wake them
<clever>
even after linux overwrites the LK kernel.....
<clever>
ive formulated several plans of attack for that, but havent tested any yet
sm2n has joined #osdev
dormito10 has quit [Ping timeout: 252 seconds]
dormito10 has joined #osdev
<c2a1>
could one solve the problem of context switching overhead by isolating the kernel to one core and userspaxe to the others?
<clever>
c2a1: its less about the switching overhead, and more about getting the core out of the scheduler, and passing it to another os
<clever>
and yeah, one solution is to just hook the entry-point, and never let the LK scheduler get the core to begin with
<clever>
pre-park it
<clever>
but then i cant do anything fancy like multi-core gunzip
<clever>
c2a1: also, aarch64 dropped support for linux to uncompress itself, so the bootloader is now responsible for the gunzip
<clever>
or just dont compress
<corecode>
hm, how do i map values uniformly to a smaller range? i guess i'll need some divisions
c2a1 has quit [Ping timeout: 245 seconds]
junon has joined #osdev
<junon>
Perhaps the wrong channel but I'm going through a game right now and was instructed to write gates to negate a two-complement signed 8-bit byte. I just did a bitwise NOT and then added 1, but is there a way to do that without a full adder?
<corecode>
probably more ##electronics
<corecode>
no, i don't think you can do it without a full adder
<corecode>
well, no
<corecode>
maybe half adder?
<junon>
The half adder just omits the carry gate right?
<corecode>
well i'm thinking you only add carry
<corecode>
you still need a carry chain
<junon>
well you have to add carry chain all the bits up anyway, right?
xenos1984 has quit [Read error: Connection reset by peer]
bradd_ has quit [Quit: No Ping reply in 180 seconds.]
bradd has joined #osdev
[itchyjunk] has joined #osdev
xenos1984 has joined #osdev
<corecode>
yes
<corecode>
but all other data you just add 0
h4zel has quit [Ping timeout: 252 seconds]
EtherNet has quit [Remote host closed the connection]
EtherNet has joined #osdev
<geist>
clever: actually over in the lkuser repo i do have some code that uses lib/elf to load user space
<clever>
ah, hadnt noticed that repo
<clever>
guessing i can just add it as an overlay?
<sortie>
I booted my Sortix 0.9 operating system released December 30, 2014. This was the first technically self-hosting release, although it wasn't installable and old and buggy and lacks lots of ports and got older ports.
<sortie>
Anyways I put the source code of Sortix 1.0, released March 2016, onto it via the ext2 filesystem support. With a few hacks, 0.9 was actually able to compile 1.0. I never tested that before and it was never intended to work.
<clever>
sortie: nice!
<sortie>
I just booted the Sortix 1.0 built under Sortix 0.9 and it actually works
<clever>
was going to ask if it could build the new one, but then you went and answered that
<sortie>
I previously confirmed that Sortix 1.0 is able to build the upcoming Sortix 1.1dev (2021 source code on the master branch), and actually get far bootstrapping the modern ports
u0_a259 has joined #osdev
u0_a259 is now known as c2a1
<sortie>
Note this 0.9 -> 1.0 jump stays with 0.9 ports, rather than 1.0 ports. 1.1dev is able to natively build all the ports, a state I think I can get to using only 1.0 ports, but bootstrapping that via 0.9 ports is going to be *difficult*.
<clever>
ports?
<klange>
Ported third-party software.
<clever>
ah
<sortie>
If I can find a solution for that though, then I can establish a 0.9 -> 1.0 (kinda, with 0.9 ports) -> 1.1dev (kinda, with 0.9 ports) -> ??? -> 1.1dev (with 1.1dev ports)
<sortie>
That would vindicate my 2014 claim that I was self-hosting
<j`ey_>
lol
<klange>
I don't think I'm really any closer to building gcc natively than I was five years ago...
<clever>
until i fix my cross-compiler setup to work in arm->vc4 mode, i cant possibly self-host
<klange>
I haven't attempted a native build of much more than individual apps in a while, there's at least two Python scripts that need to be ported to Kuroko first. My aim at the moment should be to get my build down to _just_ gcc and binutils...
<klange>
Which really means I need a DEFLATE compressor if I want to do it correctly...
mahmutov has quit [Ping timeout: 245 seconds]
<c2a1>
are gzip and compress the same thing
<c2a1>
looks like they use the same encoding
<klange>
gzip is a wrapper around a DEFLATE payload
<clever>
i was mildly surprised to see zfs gzip-9 compression using zlib functions
<clever>
and yeah, deflate was a function within zlib
<clever>
always fun when you call something by 3 different names!
<klange>
It's not three different names.
<clever>
lib/zlib_deflate/deflate.c:static block_state deflate_slow (deflate_state *s, int flush);
<clever>
ah, its zlib_deflate, not just zlib
<klange>
zlib is an implementation - the defacto one. gzip is a wrapper with a bit more information about the payload. DEFLATE is the name for the actually compression format inside of it.
<clever>
ah
<klange>
Other stuff also uses DEFLATE but not gzip, and of course there are other implementations especialy of the decompression side of things.
<clever>
i feel like zfs doesnt need the gzip extras, since the fs layer gives that, but they are probably using the gzip name, because what you just said isnt as well known
<klange>
I have my own decompressor, I use it for PNGs and compressed tarballs, and there's even a version of it in my kernel that unpacks comrpessed ramdisks on boot.
<clever>
yeah, linux has a special build of it, that runs with the mmu off, and uses a dumber heap
<clever>
that special one, is for the zImage, to unpack itself
<clever>
seperate from the initrd one
<sortie>
Hmm. make from Sortix 0.9 doesn't quite run on Sortix 1.0. There was an ABI change in how to read directories. I might need to patch the 1.0 kernel with some 0.9 compat.
<clever>
the zImage one, also has to have relocation patching done with asm, because gcc cant generate 100% PIC objects
nyah has quit [Ping timeout: 252 seconds]
<sortie>
At least 0.9 quake runs on 1.0
<clever>
sortie: one idea, is if you build the kernel first, then reboot to run an 0.9 userland on a 1.0 kernel
<clever>
then any tools built during the 1.0 userland build, can be ran immediately
<clever>
ive thought of the same thing, when upgrading from 32bit linux to 64bit
<sortie>
clever, basically I was able to cross-compile a whole pristine 1.0 system cleanly from 0.9, so I could build a kernel & userland with a matching ABI
<clever>
ah, if you can do it in more of a cross fasion, you dont need the 1.0 kernel
<sortie>
The trouble here is that the 1.0 kernel is actually not able to run 0.9 binaries perfectly (nor the other way around) because struct dirent changed
<clever>
i was thinking more in a native fashion
<clever>
yeah, thats an issue
<sortie>
I might be able to build towards 1.1dev on a 0.9 kernel but honestly that kernel is damn old and lacks features
<sortie>
A full 1.1dev bootstrap, I imagine, is best done with a 1.1dev kernel running a 1.1dev userland (bootstrapped from a 1.0 userland), with a patch to support 0.9 binaries
<sortie>
Basically one big temporary hybrid
<sortie>
Then hopefully 0.9 has enough ports -- I doubt it -- to actually bootstrap the core ports