<geist>
When you do the memory backed file thing using the syntax you have there where does it get mapped?
<geist>
I assume that’s different from ‘back all of memory with a file?’
<zid`>
It adds a new thing to the bus, it seems
<zid`>
,id=fred
<clever>
part of the question, is how much dirty memory the mmap system will allow?
<zid`>
and then info mtree
<zid`>
will show it like it does for vga ram, system ram,e tc
<geist>
An interesting, maybe shows up as nvram using whatever the current nvram e820/acpi/etc thing is
<geist>
clever: i think it tends to drive it towards zero, if it’s file backed
<zid`>
yea I'm not sure how the client is supposed to detect it
<geist>
Idea being that mapped files should fairly quickly get their data written out
<geist>
Like, say 30 seconds or so
<geist>
It might be tuned differently, but for the most part mapping a file is basically the same mechanism as mapping the underlying file cache that you’d just be filling in in the kernel with write(), so in the backend of that there’s something draining all the modified pages and converting them to non mod
<clever>
so, would the mmap be read-only to trap writes, flip to rw, and then back to ro once it initiates the flush?
<geist>
Yeah i dunno how/if it applies back pressure. It could
<geist>
In the same way that after a burst of write() activity it can start blocking until the threshold is met
<geist>
Orit’s possible it behaves less good with mmap and then a burst of activity
<geist>
These are sort of fun things we’re starting to deal with with zircon as we tech up the mmap/write back mechanism
<geist>
Looooots of tuning that serious OSes have to deal with in the long run there
<geist>
Anyway, gonna go walk. Been hanging out at a park, need to jet
knusbaum has quit [Ping timeout: 240 seconds]
knusbaum has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
pretty_dumm_guy has joined #osdev
<heat>
geist, btw you're supposed to use LLVM_PARALLEL_LINK_JOBS with llvm
<heat>
so like cmake ... -DLLVM_PARALLEL_LINK_JOBS=1 to have a single parallel link
<heat>
from my experience it's not worth limiting if you're not using LTO
heat has quit [Ping timeout: 240 seconds]
papertigers has joined #osdev
knusbaum has quit [Ping timeout: 276 seconds]
knusbaum has joined #osdev
heat has joined #osdev
jack_rabbit has joined #osdev
knusbaum has quit [Ping timeout: 240 seconds]
heat has quit [Ping timeout: 244 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
<geist>
yah, makes sense. i thought i had queued a Debug job but that was probably mistaken
Likorn has quit [Quit: WeeChat 3.4.1]
gaze___ has quit [Ping timeout: 248 seconds]
ggherdov has quit [Ping timeout: 248 seconds]
seds has quit [Ping timeout: 255 seconds]
<geist>
yah that works fine
mxshift has quit [Ping timeout: 240 seconds]
dude12312414 has joined #osdev
seds has joined #osdev
mxshift has joined #osdev
ggherdov has joined #osdev
gaze___ has joined #osdev
ggherdov has quit [Ping timeout: 258 seconds]
gaze___ has quit [Ping timeout: 276 seconds]
ggherdov has joined #osdev
rustyy has left #osdev [#osdev]
ggherdov has quit [Max SendQ exceeded]
sonny has joined #osdev
seds has quit [Ping timeout: 258 seconds]
gaze___ has joined #osdev
<sbalmos>
geist was turning into that shady guy texting away furiously in the park. heh.
seds has joined #osdev
ggherdov has joined #osdev
<sonny>
Did fushia make a mistake in using a memory unsafe language for development?
<sbalmos>
as opposed to... ?
<sonny>
A language that has guarantees of some sort
<sonny>
I'm just curious what the rationale is
<dh`>
are you part of the RESF, or are you asking sincerely?
<sonny>
resf?
<dh`>
rust evangelism strike force
<sonny>
all my questions are sincere
<dh`>
ah in that case
<sonny>
It doesn't matter to me what they picked
<dh`>
there are no memory-safe languages suitable for writing kernel code, except maybe rust but that's a matter of some contention
<sonny>
As for rust, I've only recently gotten interested in it
<sonny>
dh` that simple?
<dh`>
(well, "no" is a pretty strong word. nothing even halfway mainstream even by boutique language standards though)
<sonny>
iirc there used to be some osdev in modula-2
<dh`>
pretty much - choices for memory safety are basically garbage collection, statically allocating everything, linear types, affine types, and really crazy stuff
<sonny>
I haven't checked myself beyond that tbh. I just started thinking that once it's done, there's gonning to be a flood of vulnerabilities
<dh`>
garbage collection is probably possible in a kernel but not without hating yourself, statically allocating everything is its own special kind of hell, linear types are too limited to be useful, affine types are rust
<dh`>
I can't remember what the ground rules in modula-2 were
<dh`>
modula-3 is garbage collected, pascal is unsafe, it's presumably somewhere in the middle but I can't remember and/or never knew
<sonny>
Is bounds checking still too slow?
<dh`>
bounds checking doesn't get you guarantees, only mitigations
<sonny>
I thought Pascal was education only
<dh`>
*snort*
<dh`>
lots of real software was written in pascal in the 80s and 90s
<dh`>
not Standard Pascal, which isn't suitable even for teaching noobs
<sonny>
oh
<dh`>
but e.g. turbo pascal for dos, think pascal for macos
<sonny>
object pascal? I've heard that name
<dh`>
yeah
<geist>
yah also note we explicitly have been very careful about how memory management is done in the kernel and use C++ to pull it off IMO fairly well
<geist>
use after frees and leaks have not been an issue in general
<geist>
i think we managed to pull that off fairly well
<dh`>
also, memory safety vs. C/C++ code is made out to be a much bigger deal than it really is
<geist>
primary reason rust wasn't on the table for zircon is simply we started on this 7 years ago and rust had a long way to go
<dh`>
still does, afaict
<geist>
nowadays it might have gotten more attention, but even then i think it has a way to go for kernel work, indeed
<geist>
though i am in no way a rust expert
<sonny>
was making a new language going to take too long as well?
<geist>
oh gosh yes
<sonny>
hmm
<geist>
and that's 100% not what we were interested in
<dh`>
neither am I, but what I've heard from people I know who've dug into it is that there's a very strong tendency to end up using unsafe code for anything nontrivial
<geist>
much more interested in having a functional system in a fairly short amount of time, which is why we were able to start with a fairly simple and unopinionated LK and get to hello world in a month or two
<sonny>
I see
<geist>
dh`: yeah i think you have to have achieved some sort of zen with the language to even know when/where to do that sort of thing, IMO
<geist>
so it's sort of like tier 2 or 3 rust to really know how to abuse it
<zid`>
make a new language lol is not anything anybody would seriously consider for a project that needs to get done, and be fast at the end
<sonny>
unix did
<sbalmos>
Rust as a low-level no-stdlib core systems language is still evolving quite a bit
<zid`>
unix did not
<sbalmos>
still a /lot/ of "use nightly" and "enable this/that flag" etc
<geist>
yah
<sbalmos>
and I'm still unraveling its black art of linker control
<sonny>
zid` iirc at least sysv1 is in C
<sonny>
it's not like vms
<zid`>
most of unit was hand written assembly
<sbalmos>
geist: speaking of which, took me a while here (FSVO "a while") to find the IRQ handler in lk, buried down in exception handling
<sonny>
oh
<zid`>
and C didn't exist until C existed, so you couldn't use it
<zid`>
and compilers didn't optimize back then
<geist>
what we have done in the kernel is fairly strong use of ASAN, typesafe pointers, delayed deallocation, etc and all in all memory issues haven't been a problem
<zid`>
so the comparison is flawed even if it were true
<sbalmos>
C was just a better-symbolic Assembly
<sonny>
zid` that might be a benefit?
<dh`>
a while back I ran into a blog post where someone was trying to make their rust byte-code interpreter run as fast as a C one, and they had to pull out all the stops and write unsafe code to get it sorta near
<dh`>
reminded me of that depressing haskell paper where a bunch of 5-star haskell wizards tried to make a haskell http server keep up with apache
<sbalmos>
uh, Rust's "bytecode" is LLVM
<geist>
sbalmos: yeah for the most part low level stuff will originate arch/* and then flow upwards into the kernel
<dh`>
sbalmos: ?
<geist>
nothing unique, but if you are looking for low level details that are arch specific they should live in arch/*
<zid`>
rust is always going to be slower unless you write the entire project in one file
<zid`>
they have no name mangling or anything
<sbalmos>
geist: ya, just tracing everything at the PIT init for threading, I saw where the handler was created, etc, but I was like O_O WhereTF is the LIDT tying into the IVT?
<zid`>
it can't propagate the constraints outwards in order to elide those mandatory bounds checks etc
<zid`>
if you do if(x > 0 && x < 10) g(x); and g is in a differnt 'crate' it has no way to know that x is safe to index into g's internal array
<geist>
sbalmos: yeah there's a bunch of arch and platform abstraction there, though generally symbolically. ie, 'something must implement arch_* or platform_*'
<geist>
vs more dynamic plug this into that
<geist>
so it's kinda halfway between a single slammed together thing and a highly generic thing. mostly trying to be small and simple
<geist>
x86 targets on LK are not as fleshed out, fair warning. LK is primarily an arm/riscv/etc OS
<geist>
x86 is not as high a priority, and there's a huge pile of PC nonsense that it has mostly not tackled, so you might be a bit dissapoint there
<geist>
but frankly i'm just not that interested in PC shit as much. seen it, done it, usually not as interesting to me
<geist>
hell i dont think i've even enabled SMP on x86 yet. it's a TODO, but just meh. did it on the zircon 'fork' and never felt the desire to roll it back
<sbalmos>
¯\_(ツ)_/¯
<geist>
mostly because x86 SMP is a ton of shenanigans i haven't felt the desire to do all over again
<sbalmos>
x86 anything is a ton of WTFery
<geist>
also things like the 4 different ways to save FPU state, etc
<sbalmos>
geist: probably better, for my purposes, that x86 wasn't fully fleshed out. makes it a bit more straightforward to follow the paths for me and tie the mental strings together.
bauen1_ has joined #osdev
<sonny>
well, I'm stumped on memory safety apart from an embedded interpreter
<sbalmos>
embedded where?
<sonny>
At a low value of memory somewhere
<sbalmos>
ultimately anything at the lowest level is going to have to allow unsafety, because there has to be a building block that determines what is the definition of "safe"
<sonny>
this could be that building block
bauen1 has quit [Ping timeout: 276 seconds]
<sonny>
either way, the bigger problem is that with c and c++ you don't get to define it, which would be the point of making a language. There just was not enough time or priority
<sbalmos>
... or back when C / C++ were originally invented, they didn't know what they didn't know
<sonny>
what I like is that you get this great abstraction in C, that memory is an array. That's such a great philosphy
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
liz has joined #osdev
smeso has quit [Quit: smeso]
smeso has joined #osdev
Andrew is now known as \Andrew
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
\Andrew is now known as GNU\Andrew
bauen1 has joined #osdev
bauen1_ has quit [Ping timeout: 260 seconds]
<mrvn>
sonny: and yet you can't even implement malloc in C or new in C++ fully standard conform without going into idb.
GreaseMonkey has quit [Ping timeout: 255 seconds]
the_lanetly_052 has joined #osdev
<sonny>
mrvn idb?
<klange>
implementation-defined behavior
<klange>
but, that's the point of half the standard library - it implements "high level" functionality you can not otherwise implement without relying on implementation-defined behavior
<klange>
see: the entire file i/o interface
Jari-- has joined #osdev
<mrvn>
klange: The i/o iterface isn't build on IDB.
<sonny>
mrvn I get malloc, but why new?
<mrvn>
sonny: same reason. object lifetimes and casting char array to other types.
sonny has quit [Quit: Ping timeout (120 seconds)]
liz has quit [Quit: Lost terminal]
sonny has joined #osdev
archenoth has quit [Read error: Connection reset by peer]
archenoth has joined #osdev
<sonny>
Since the kernel is just a process, can you have two kernels running at the same time?
<zid`>
You have one per cpu running at all times
<mrvn>
what do you think SMP is?
<zid`>
and you switch which copy of the kernel is running when you switch tasks
<zid`>
a user program and a kernel are an inseperable pair
<zid`>
separable*
<mrvn>
zid`: not necessary
<moon-child>
sonny: well, I have one kernel running on my laptop, and another running on my phone
<sonny>
ok, so is it possible to say load an updated kernel and kill the old ones?
<moon-child>
at the same time
<zid`>
In theory yes, in practice it has issues
<sonny>
moon-child on the same hardware
<mrvn>
sonny: if you can somehow transfere all the data structures
<zid`>
it will need to play nicely with all the old data structures that are still in memory
<sonny>
ok good
<moon-child>
virtual machines are a thing
<zid`>
there is a linux tool that patches the kernel at runtime
<zid`>
to update it
<moon-child>
anyway there is 'livepath'
<sonny>
zid` have two heaps per process, swap the other one out
<moon-child>
in ubuntu and rhel, I think
<mrvn>
sonny: if you want to design your kernel to run as multiple kernels then you need to implement some resource sharing code.
<zid`>
good luck
<moon-child>
fun fact: it's because of livepatch that every linux function starts with 5 bytes of nop
<zid`>
Not sure why you're TELLING me what the solution is, when 2 lines previous you didn't even know it was possible
<sonny>
it's an idea
<sonny>
I don't know if it works
<zid`>
So what's your plan for 'switching heap'?
<zid`>
and what does it achieve
<sonny>
that was in response to maintaing the data structures, I can correct from the stored heap
<zid`>
if I add a member to struct complex_memory_map_tracking_struct {} in the middle somewhere in the new kernel, how does your 'second heap' help this?
<mrvn>
Think of running multiple kernels on your SMP as taking the idea of per-core data structures to the extreme.
<mrvn>
You need migrate functions for everything.
<sonny>
mrvn I see
<zid`>
There are now two entirely different sets of semantics in operation for how the kernel cooperates to share physical memory
<sonny>
zid` so I put the new updates in the stored heap and try to synchronize
<mrvn>
If you have zero global data structures and only per-core structures and migration functions then upadting to a new kernel should become easy too.
<zid`>
you probably can't, and that isn't just a swap is it
<zid`>
that's basically shutting the machine down
<zid`>
and trying to port its internal state to the new format
<mrvn>
zid`: you can do that one core at a time.
<zid`>
that's a LOT of code
<sonny>
oh :/
<sonny>
and yeah, I wanted to simulate shutting the machine down
<sonny>
I imagine this will make for a resilient system
<moon-child>
depending on what exactly you are after, you might consider serialising userspace process state, destructively updating kernel, and then restoring userspace
<zid`>
even just building the code would be nearly impossible because you'd need to be able introspect what was otherwise private state
<mrvn>
sonny: normaly you only have suspend and resume with the same kernel version because nobody writes code to update kernel structures to a new version on resume.
<zid`>
you'd need to write a serializing function for every single kernel data structure
<moon-child>
some work has been done on serialising userspace linux apps and even sending them over the network
<zid`>
even if it's completely local to a translation unit
<sonny>
zid` I can rethink what a process looks like
<mrvn>
moon-child: the user-space interface is a stable ABI. It doesn't change much if at all.
<zid`>
moon-child: Yea, much more doable, and still basically impossible if any semantics change, like how big a struct sigaction_t is or whatever
<moon-child>
well ...
<zid`>
so for easy cases it's merely "boat loads of code" rather than "impossible code" :D
<moon-child>
linux doesn't break compat usually (at least the kernel)
<mrvn>
zid`: if the size of sigaction_t changes then you have to recompile all your apps.
<zid`>
This is where windows HANDLE is an inferior option at least, so we've got that going for us
xenos1984 has quit [Read error: Connection reset by peer]
<zid`>
(where it's just a uintptr_t pointer that may end up not packing properly afterwards)
<sonny>
I think this is what CRDTs are for
<zid`>
nope
<zid`>
that's about being, and you may not have guessed this from the name, conflict-free and replicated
<zid`>
we specifically are not replicating and do have conflicts
srjek has quit [Ping timeout: 255 seconds]
<sonny>
I thought the kernel (or any target process) was being replicated
<mrvn>
except for the shared bits
<moon-child>
zid`: well, I'm _trying_ to replicate but ...
<moon-child>
(sorry)
<sonny>
does any filesystem have the name of the process that created the file in the 'birth metadata'?
<sonny>
my other idea is to let the filesystem also look like ram. I guess a theme for me is persistence
<mrvn>
the problem with persistace is that disks are so slow. Try making your 10G NIC persistant.
<mrvn>
if you have a system with some NV-ram you might have a go at it.
<sonny>
klys: what ever the user creates belongs to them, memory included
<klys>
sounds like it needs some quotas too
<sonny>
I don't find files as a tree very useful idea
<sonny>
mrvn networks worry about peristence themselves in the protocol?
<mrvn>
sonny: you get a tcp packet, you send the ACK back and then you crash. When you reboot how will you recover that tcp packet? The other side isn't going to resend it, it was ACKed.
<sonny>
ah
<sonny>
so the server just times out then
<sonny>
bugs and stuff hurt less if you can restart I think
<mrvn>
no, you just have a blob of missing data unless you save it to disk before sending to ACK. So every ACK takes forever and consider what that does to your network speed.
<sonny>
rip
<mrvn>
with NV-ram it's not a problem.
Jari-- has quit [Remote host closed the connection]
vai has joined #osdev
sonny has quit [Ping timeout: 252 seconds]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
greaser|q has joined #osdev
greaser|q is now known as GreaseMonkey
jack_rabbit has quit [Ping timeout: 240 seconds]
FatAlbert has joined #osdev
puck has quit [Excess Flood]
puck has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
psykose has quit [Ping timeout: 260 seconds]
gog has joined #osdev
<mrvn>
Here is an idea about language design: Say you have: Big fn1(Big x); Big fn2(int); where fn1 does return x. When you call: Big b = fn1(fn2(23)); wouldn't it be nice to call fn2 with the address of b as the structure return register?
<Mutabah>
That's what inlining is for
<mrvn>
The language should have a syntax to say that the argument of fn1 is returned so to RVO on it.
<moon-child>
that's implementation, not design
<moon-child>
implementation should take care of it. Don't push it into the language. If the user needs such control, they can say void fn2(int,Big*restrict) anyway
<Mutabah>
Probably more `Big b = fn2(23); fn1(&b)`
<mrvn>
moon-child: The they can't say "Big b = fn2(...)" but have to first create a Big and pass it's address. That's an initialization and copy assignment then.
<mrvn>
Then *
<Mutabah>
Maybe with syntax for method calls that allows chaining? (to borrow rust, allow a `&mut self` method to be used like a `self` method)
<moon-child>
mrvn: only if you're c++-ish
<moon-child>
I mean, I should hope it's pretty obvious c++ is not a design to emulate...
<mrvn>
I like the idea of not having uninitialized values and have constructors.
<Mutabah>
`impl Big { fn fn1(i32)->Big; fn fn2(&mut self); } let b = Big::fn1(23).move fn2();`
<mrvn>
.move?
<Mutabah>
A syntax I just made up for `{let mut v = Big::fn1(23); v.fn2(); v}`
<Mutabah>
I.e. so you can all a method that mutates as part of a method call chain
the_lanetly_052_ has joined #osdev
<mrvn>
so like .apply or .invoke
<Mutabah>
yeah
<FatAlbert>
good morning OSDeV
<mrvn>
That works. The point of "Big fn1(Big x)" is to return the value so it can be chained.
<Mutabah>
Yeah. That's what I inferred. And the more sensible option there is to have a mutating method/function instead of a transforming method/function, and some sugar to stick it in a call chain
<mrvn>
Odd that it would be a method of the object though. Does evey object have that method implicitly? Can you override it? Why can't you override it? Gets a bit iffy.
<Mutabah>
Oh, `move` is a rust keyword
<mrvn>
looks lkike a method call though
the_lanetly_052 has quit [Ping timeout: 276 seconds]
<Mutabah>
Could also use `->` in place of `.` (that's a valid rust symbol, and not used in that position) - but that would have confused you more :)
<Mutabah>
The idea was just "some syntax that calls a mutating unit/void-returning function, and returns the receiver"
<mrvn>
In C you have fn1(23) | fn2, or in ocaml fn1 23 |> fn2 for chaining.
FatAlbert has quit [Quit: WeeChat 3.5]
<mrvn>
You would need some other infix operator for a self mutating chaining
<mrvn>
or some keyword or function
vai is now known as Jari--
<mrvn>
fn1(23) |> mutate fn2 |> some more |> ...
<mrvn>
How would you extend that when you have multiple return values? void multi_mutate(A &a, B &b, C &c) can't really chain that.
<zid`>
greater than dot? pfft
<mrvn>
moon-child: I'm tempted to have a language design where all functions have the form: Error name([in, out, inout] Arg1 arg1, ...)
<mrvn>
or name([in, out, inout] Arg1 arg1, ...) (nofail), since returning an error is implicit
vdamewood has joined #osdev
hgoel[m] has quit [Quit: You have been kicked for being idle]
vinleod has joined #osdev
vdamewood is now known as Guest9613
vinleod is now known as vdamewood
Guest9613 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
<vdamewood>
So, I think if I use /etc/passwd like so many other OS's use, I'm going to make the place-holder password 'CorrectHorseBatteryStaple' instead of 'x'.
<zid`>
make sure it includes a random salt which is "6"
<zid`>
sorry, 4
<zid`>
had to check #221
<vdamewood>
Yeah, the IEEE-vetted random number.
pretty_dumm_guy has joined #osdev
<kingoffrance>
eh, use a ddr pad and have to hit right sequence within margin of error/timing. anyone who can barbarian dance deserves root
<kingoffrance>
its a challenge/response type deal
<vdamewood>
The password shal be that they have to get Perfect, in Hard, for the song Butterfly
<vdamewood>
shall*
GeDaMo has joined #osdev
<kingoffrance>
seriously though, what else could use timing? (other than expiring tokens/expiring passwords/one-time etc.)
<marshmallow>
I'm wondering, say that kernel code lives in page tables marked as r-x, are the protection bits (somehow) hardware-enforced?
<j`ey>
yes you will fault if you try write to that
<mrvn>
having memory W^X (writable exclusive or executable) is a big security feature.
<kingoffrance>
^ will fault. some things may allow similar protections independent of paging too, e.g. amd elan sc 520 (486-ish SOC) :D
<mrvn>
never allow executing anything that can be written to and vice versa.
<marshmallow>
sure, but the protection bits are actually set by the kernel, and not by the hardware, no?
<mrvn>
set by the kernel, used by the hardware
<marshmallow>
in which sense "used by the hardware"?
<mrvn>
Hardware might also have separate user read/write and kernel read/write bits
<j`ey>
the hardware checks the bits when its tryingto write or read or execute
<mrvn>
marshmallow: enforced
gxt has quit [Ping timeout: 268 seconds]
gxt has joined #osdev
<zid`>
hmm, did the ppro have 1G pages or were they added later?
<bslsk05>
en.wikipedia.org: Page Size Extension - Wikipedia
<zid`>
I think that's only 2M
<mrvn>
For anything but a phys mapping of all memory a 1G page seems kind of insane. Unless you do high performance computing where processes easily allocate 100GB memory.
<mrvn>
zid`: Do you have some mechanism to defragment physical pages so you get contiguous and aligned ranges of 1GB memory?
<zid`>
aha it was pentium 2
<zid`>
no, p2 added PSE36 which was an alternative to PAE, wtf
<mrvn>
You should ignore everything below long mode.
<zid`>
westmere is the answer it seems
heat has joined #osdev
uzix has joined #osdev
uzix has quit [Client Quit]
uzix has joined #osdev
_xor has quit [Quit: WeeChat 3.4.1]
uzix has quit [Changing host]
uzix has joined #osdev
uzix has quit [Quit: WeeChat 3.0]
sympt9 has joined #osdev
sympt has quit [Ping timeout: 256 seconds]
sympt9 is now known as sympt
dennis95 has joined #osdev
gildasio has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
XgF has quit [Remote host closed the connection]
XgF has joined #osdev
uzix has joined #osdev
gog has quit [Ping timeout: 276 seconds]
gildasio has quit [Remote host closed the connection]
tomaw has quit [Quit: Quitting]
tomaw has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
wand has quit [Remote host closed the connection]
cross has joined #osdev
<marshmallow>
other doubt, in ARM64, say that the kernel is compromised, is the attacker still not meant to access the secure world?
<mrvn>
urgs, I'm lloking at memcpy_s, which does bounds checking and zeroes out `dest` if the bounds don't fit. But also on overlap. So on overlap it destroyes `src` and returns an error. How is that sensible?
<mrvn>
marshmallow: is the kernel running in secure mode?
Likorn has joined #osdev
<mrvn>
So in 700E teil oder 1700E?
<mrvn>
ups
<marshmallow>
mrvn: well yes, the kernel runs on EL1 context, whereas the secure world should run in EL3
<marshmallow>
uhmm no OK sorry, I think I'm mixing up secure monitor w/ trustzone, which are two actually different things
Likorn has quit [Quit: WeeChat 3.4.1]
gildasio has joined #osdev
<kingoffrance>
re: memcpy, IIRC thats fine for c89 memcpy at least. memmove i think must handle overlap, memcpy it is undefined
<kingoffrance>
i mean, seems kind of odd "why doesnt it just call memmove() then?" but seems permitted IMO
<kingoffrance>
err, linux says "The memory areas must not overlap" so that is more strong
<kingoffrance>
maybe that is proper :D
<kingoffrance>
quote: "(POSIX and the C standards are explicit that employing memcpy() with overlapping areas produces undefined behavior.)"
<kingoffrance>
so, can go either way :D
<Griwes>
he's talking about memcpy_s, not memcpy
<kingoffrance>
sure, but why should it not be "orthogonal" ?
<mrvn>
c++reference says it will zero out dst on overlap and return an error
<mrvn>
If it reports overlap as error it should not also corrupt memory.
psykose has joined #osdev
elastic_dog has quit [Ping timeout: 258 seconds]
elastic_dog has joined #osdev
<kingoffrance>
yeah, but im sure that's "safe" to some ppl
CYKS has quit [Quit: Ping timeout (120 seconds)]
jafarlihi has joined #osdev
CYKS has joined #osdev
jafarlihi has quit [Ping timeout: 264 seconds]
jafarlihi has joined #osdev
divine has joined #osdev
bauen1 has quit [Ping timeout: 276 seconds]
dude12312414 has joined #osdev
liz_ has quit [Ping timeout: 276 seconds]
jafarlihi has quit [Quit: WeeChat 3.5]
GNU\Andrew is now known as Andrew
sonny has joined #osdev
<sonny>
Is it still true that system calls have to be implemented in assembly?
<j`ey>
do you mean from the userspace side or the kernel side?
<j`ey>
(as in.. the implementation of the sys call, or the actual sys call 'instruction')
jstoker has quit [Read error: Connection reset by peer]
k8yun has joined #osdev
<sonny>
the implementation
X-Scale` has joined #osdev
<j`ey>
i dont think they ever had to be asm
X-Scale has quit [Ping timeout: 246 seconds]
<sonny>
oh, nevermind then
<sbalmos>
the transition from userspace to kernelspace, "yes"
X-Scale` is now known as X-Scale
<j`ey>
the interrupt/exception handler will probably be some asm before jumping into a higher level language
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
jstoker has joined #osdev
<mrvn>
On the lower ARMs foolow the C calling convention for IRQs and syscalls
<mrvn>
s/foolow/follow/
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
dennis95 has quit [Quit: Leaving]
Likorn has joined #osdev
<dh`>
none of the _s stuff was coherently designed
<dh`>
best to not waste time thinking about it
sonny has quit [Quit: Client closed]
bliminse has quit [Quit: leaving]
srjek has joined #osdev
bliminse has joined #osdev
elastic_dog has quit [Ping timeout: 264 seconds]
elastic_dog has joined #osdev
liz_ has joined #osdev
liz_ is now known as liz
gareppa has joined #osdev
elastic_dog has quit [Ping timeout: 248 seconds]
gareppa has quit [Client Quit]
gildasio has quit [Quit: WeeChat 3.5]
elastic_dog has joined #osdev
mahmutov has joined #osdev
sonny has joined #osdev
<geist>
re: backing up disk, reminds me i keep meaning to take apart an old HP logic analyzer i've had forever and back up its disk. almost certainly some 100 MB SCSI drive or whatnot
sonny has quit [Quit: Ping timeout (120 seconds)]
sonny has joined #osdev
the_lanetly_052_ has quit [Remote host closed the connection]
Likorn has quit [Quit: WeeChat 3.4.1]
<sbalmos>
oh now you're really hitting below the belt. Probably SCSI-1 at that, with maybe a pre-GPIB interface on the back for other bench instrument chaining
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
sonny has quit [Quit: Client closed]
<sbalmos>
geist: for the first time in 18 years, a book from college is actually useful (for once). broke out the old OS design book and started rifling back through the chapters on IPC and synchronization.
gorgonical has joined #osdev
pretty_dumm_guy has joined #osdev
<geist>
yah sometimes going back and reading them is useful
<geist>
even once you're experienced
<geist>
it dusts off old neural pathways
<sbalmos>
back in the lk codebase, is the shell app set to be a start-on-boot app? wasn't sure I could find the final link there.
<geist>
yeah
<geist>
i think more completely, iirc all apps start by default unless you mark them as no-start-on-boot
<geist>
ther eis a way to manually start them with a command line, which is the idea for the no-start-on-boot apps
mahmutov has quit [Ping timeout: 268 seconds]
<sbalmos>
right. I found the pseudo-command line and was working backwards
<geist>
apps are discovered by a special section they are put in
<sbalmos>
I saw the start-on-boot app array that's iterated at the end of the bootstrap2 process
<geist>
right
<geist>
it's like the LK commands, they're put in an array that the linker script coalesces
<sbalmos>
but it was that final "okay, is the command shell part of that auto boot array?"
<sbalmos>
yeah, that was the last thing was I saw the modules defs in the linker scripts
<geist>
yah, it's not a special array for auto boot, it's all apps, but there's a flag that tells it to start or skip
<geist>
it's a pretty dumb but functional mechanism. i've been stewing the idea of having an autoexec style mechanism that lets the system run a series of shell commands on boot, but haven't decided precisely where that goes
<geist>
if it's in the shell app, or some new autoexec app that lets you pass in stuff from the build system or whatnot
<geist>
but really should do something so i can finally write on-server unit tests instead of requiring they be run manually
<geist>
i could also inject commands into the command line i suppose, but figured i'd do it a little cleaner than that
<geist>
the real intent and main use of the app thing in LK is for a usual embedded system it's the place where you functionally insert your 'main' for the embedded thing you're building
<sbalmos>
right
<geist>
it's sort of like the loop() in arduino style of where you put your bits
<geist>
so usually they have a single app
<sbalmos>
yup, no biggie. no need for userspace or such.
<geist>
right, though i have a lkuser project in another repo that inserts its own 'app' that basically kicks off the main process
<geist>
though actually it doesn't do that yet, it does it via an explicit command line right now. eventually it'll probably run a 'userspace' app
Likorn has joined #osdev
k8yun has quit [Read error: Connection reset by peer]
bauen1 has joined #osdev
<clever>
geist: but unlike arduino, it has threads, and you can register multiple apps!
<clever>
the way ive been using it, is both what you said, and animations that run on the gui
<geist>
yep at some point i actually ported some arduino code to it and it worked pretty well
<geist>
just ran the arduino sketch in a thread and it was totally fine
<geist>
and you can easily. have background servers doing stuff
<clever>
yeah, just need some bindings to translate gpio over
<geist>
and worker threads for stuff like net stacks or bluetooth or whatnot