channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present

http://bespin.org/~qz/search/?view=1&c=osdev2&y=22&m=6&d=21

Tuesday, 21 June 2022

00:05:00 <geist> When you do the memory backed file thing using the syntax you have there where does it get mapped?
00:05:00 <geist> I assume that’s different from ‘back all of memory with a file?’
00:06:00 <zid`> It adds a new thing to the bus, it seems
00:06:00 <zid`> ,id=fred
00:06:00 <clever> part of the question, is how much dirty memory the mmap system will allow?
00:06:00 <zid`> and then info mtree
00:06:00 <zid`> will show it like it does for vga ram, system ram,e tc
00:06:00 <geist> An interesting, maybe shows up as nvram using whatever the current nvram e820/acpi/etc thing is
00:06:00 <geist> clever: i think it tends to drive it towards zero, if it’s file backed
00:07:00 <zid`> yea I'm not sure how the client is supposed to detect it
00:07:00 <geist> Idea being that mapped files should fairly quickly get their data written out
00:07:00 <geist> Like, say 30 seconds or so
00:08:00 <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
00:08:00 <clever> so, would the mmap be read-only to trap writes, flip to rw, and then back to ro once it initiates the flush?
00:09:00 <geist> Yeah i dunno how/if it applies back pressure. It could
00:09:00 <geist> In the same way that after a burst of write() activity it can start blocking until the threshold is met
00:09:00 <geist> Orit’s possible it behaves less good with mmap and then a burst of activity
00:10:00 <geist> These are sort of fun things we’re starting to deal with with zircon as we tech up the mmap/write back mechanism
00:10:00 <geist> Looooots of tuning that serious OSes have to deal with in the long run there
00:13:00 <geist> Anyway, gonna go walk. Been hanging out at a park, need to jet
00:48:00 <heat> geist, btw you're supposed to use LLVM_PARALLEL_LINK_JOBS with llvm
00:48:00 <heat> so like cmake ... -DLLVM_PARALLEL_LINK_JOBS=1 to have a single parallel link
00:51:00 <heat> from my experience it's not worth limiting if you're not using LTO
01:24:00 <geist> yah, makes sense. i thought i had queued a Debug job but that was probably mistaken
01:46:00 <geist> yah that works fine
02:17:00 <sbalmos> geist was turning into that shady guy texting away furiously in the park. heh.
02:23:00 <sonny> Did fushia make a mistake in using a memory unsafe language for development?
02:27:00 <sbalmos> as opposed to... ?
02:27:00 <sonny> A language that has guarantees of some sort
02:28:00 <sonny> I'm just curious what the rationale is
02:29:00 <dh`> are you part of the RESF, or are you asking sincerely?
02:29:00 <sonny> resf?
02:29:00 <dh`> rust evangelism strike force
02:30:00 <sonny> all my questions are sincere
02:30:00 <dh`> ah in that case
02:30:00 <sonny> It doesn't matter to me what they picked
02:30:00 <dh`> there are no memory-safe languages suitable for writing kernel code, except maybe rust but that's a matter of some contention
02:30:00 <sonny> As for rust, I've only recently gotten interested in it
02:31:00 <sonny> dh` that simple?
02:31:00 <dh`> (well, "no" is a pretty strong word. nothing even halfway mainstream even by boutique language standards though)
02:32:00 <sonny> iirc there used to be some osdev in modula-2
02:32:00 <dh`> pretty much - choices for memory safety are basically garbage collection, statically allocating everything, linear types, affine types, and really crazy stuff
02:33:00 <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
02:33:00 <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
02:34:00 <dh`> I can't remember what the ground rules in modula-2 were
02:34:00 <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
02:34:00 <sonny> Is bounds checking still too slow?
02:34:00 <dh`> bounds checking doesn't get you guarantees, only mitigations
02:34:00 <sonny> I thought Pascal was education only
02:35:00 <dh`> *snort*
02:35:00 <dh`> lots of real software was written in pascal in the 80s and 90s
02:35:00 <dh`> not Standard Pascal, which isn't suitable even for teaching noobs
02:35:00 <sonny> oh
02:35:00 <dh`> but e.g. turbo pascal for dos, think pascal for macos
02:35:00 <sonny> object pascal? I've heard that name
02:35:00 <dh`> yeah
02:36:00 <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
02:36:00 <geist> use after frees and leaks have not been an issue in general
02:37:00 <geist> i think we managed to pull that off fairly well
02:37:00 <dh`> also, memory safety vs. C/C++ code is made out to be a much bigger deal than it really is
02:37:00 <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
02:37:00 <dh`> still does, afaict
02:37:00 <geist> nowadays it might have gotten more attention, but even then i think it has a way to go for kernel work, indeed
02:37:00 <geist> though i am in no way a rust expert
02:38:00 <sonny> was making a new language going to take too long as well?
02:38:00 <geist> oh gosh yes
02:38:00 <sonny> hmm
02:38:00 <geist> and that's 100% not what we were interested in
02:38:00 <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
02:38:00 <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
02:39:00 <sonny> I see
02:39:00 <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
02:39:00 <geist> so it's sort of like tier 2 or 3 rust to really know how to abuse it
02:39:00 <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
02:39:00 <sonny> unix did
02:39:00 <sbalmos> Rust as a low-level no-stdlib core systems language is still evolving quite a bit
02:39:00 <zid`> unix did not
02:39:00 <sbalmos> still a /lot/ of "use nightly" and "enable this/that flag" etc
02:40:00 <geist> yah
02:40:00 <sbalmos> and I'm still unraveling its black art of linker control
02:40:00 <sonny> zid` iirc at least sysv1 is in C
02:40:00 <sonny> it's not like vms
02:40:00 <zid`> most of unit was hand written assembly
02:40:00 <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
02:41:00 <sonny> oh
02:41:00 <zid`> and C didn't exist until C existed, so you couldn't use it
02:41:00 <zid`> and compilers didn't optimize back then
02:41:00 <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
02:41:00 <zid`> so the comparison is flawed even if it were true
02:41:00 <sbalmos> C was just a better-symbolic Assembly
02:41:00 <sonny> zid` that might be a benefit?
02:41:00 <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
02:41:00 <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
02:41:00 <sbalmos> uh, Rust's "bytecode" is LLVM
02:41:00 <geist> sbalmos: yeah for the most part low level stuff will originate arch/* and then flow upwards into the kernel
02:42:00 <dh`> sbalmos: ?
02:42:00 <geist> nothing unique, but if you are looking for low level details that are arch specific they should live in arch/*
02:42:00 <zid`> rust is always going to be slower unless you write the entire project in one file
02:42:00 <zid`> they have no name mangling or anything
02:42:00 <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?
02:42:00 <zid`> it can't propagate the constraints outwards in order to elide those mandatory bounds checks etc
02:43:00 <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
02:43:00 <geist> sbalmos: yeah there's a bunch of arch and platform abstraction there, though generally symbolically. ie, 'something must implement arch_* or platform_*'
02:43:00 <geist> vs more dynamic plug this into that
02:43:00 <geist> so it's kinda halfway between a single slammed together thing and a highly generic thing. mostly trying to be small and simple
02:44:00 <geist> x86 targets on LK are not as fleshed out, fair warning. LK is primarily an arm/riscv/etc OS
02:44:00 <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
02:45:00 <geist> but frankly i'm just not that interested in PC shit as much. seen it, done it, usually not as interesting to me
02:45:00 <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
02:45:00 <sbalmos> ¯\_(ツ)_/¯
02:46:00 <geist> mostly because x86 SMP is a ton of shenanigans i haven't felt the desire to do all over again
02:46:00 <sbalmos> x86 anything is a ton of WTFery
02:46:00 <geist> also things like the 4 different ways to save FPU state, etc
02:50:00 <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.
02:51:00 <sonny> well, I'm stumped on memory safety apart from an embedded interpreter
02:51:00 <sbalmos> embedded where?
02:52:00 <sonny> At a low value of memory somewhere
02:52:00 <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"
02:53:00 <sonny> this could be that building block
02:55:00 <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
02:55:00 <sbalmos> ... or back when C / C++ were originally invented, they didn't know what they didn't know
02:56:00 <sonny> what I like is that you get this great abstraction in C, that memory is an array. That's such a great philosphy
04:31:00 <mrvn> sonny: and yet you can't even implement malloc in C or new in C++ fully standard conform without going into idb.
04:36:00 <sonny> mrvn idb?
04:36:00 <klange> implementation-defined behavior
04:37:00 <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
04:37:00 <klange> see: the entire file i/o interface
04:38:00 <mrvn> klange: The i/o iterface isn't build on IDB.
04:38:00 <sonny> mrvn I get malloc, but why new?
04:39:00 <mrvn> sonny: same reason. object lifetimes and casting char array to other types.
05:19:00 <sonny> Since the kernel is just a process, can you have two kernels running at the same time?
05:19:00 <zid`> You have one per cpu running at all times
05:19:00 <mrvn> what do you think SMP is?
05:19:00 <zid`> and you switch which copy of the kernel is running when you switch tasks
05:19:00 <zid`> a user program and a kernel are an inseperable pair
05:20:00 <zid`> separable*
05:20:00 <mrvn> zid`: not necessary
05:20:00 <moon-child> sonny: well, I have one kernel running on my laptop, and another running on my phone
05:20:00 <sonny> ok, so is it possible to say load an updated kernel and kill the old ones?
05:20:00 <moon-child> at the same time
05:20:00 <zid`> In theory yes, in practice it has issues
05:20:00 <sonny> moon-child on the same hardware
05:20:00 <mrvn> sonny: if you can somehow transfere all the data structures
05:21:00 <zid`> it will need to play nicely with all the old data structures that are still in memory
05:21:00 <sonny> ok good
05:21:00 <moon-child> virtual machines are a thing
05:21:00 <zid`> there is a linux tool that patches the kernel at runtime
05:21:00 <zid`> to update it
05:21:00 <moon-child> anyway there is 'livepath'
05:21:00 <sonny> zid` have two heaps per process, swap the other one out
05:21:00 <moon-child> in ubuntu and rhel, I think
05:21:00 <mrvn> sonny: if you want to design your kernel to run as multiple kernels then you need to implement some resource sharing code.
05:21:00 <zid`> good luck
05:21:00 <moon-child> fun fact: it's because of livepatch that every linux function starts with 5 bytes of nop
05:21:00 <zid`> Not sure why you're TELLING me what the solution is, when 2 lines previous you didn't even know it was possible
05:22:00 <sonny> it's an idea
05:22:00 <sonny> I don't know if it works
05:22:00 <zid`> So what's your plan for 'switching heap'?
05:22:00 <zid`> and what does it achieve
05:23:00 <sonny> that was in response to maintaing the data structures, I can correct from the stored heap
05:23:00 <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?
05:23:00 <mrvn> Think of running multiple kernels on your SMP as taking the idea of per-core data structures to the extreme.
05:24:00 <mrvn> You need migrate functions for everything.
05:24:00 <sonny> mrvn I see
05:24:00 <zid`> There are now two entirely different sets of semantics in operation for how the kernel cooperates to share physical memory
05:25:00 <sonny> zid` so I put the new updates in the stored heap and try to synchronize
05:25:00 <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.
05:25:00 <zid`> you probably can't, and that isn't just a swap is it
05:25:00 <zid`> that's basically shutting the machine down
05:25:00 <zid`> and trying to port its internal state to the new format
05:26:00 <mrvn> zid`: you can do that one core at a time.
05:26:00 <zid`> that's a LOT of code
05:26:00 <sonny> oh :/
05:26:00 <sonny> and yeah, I wanted to simulate shutting the machine down
05:26:00 <sonny> I imagine this will make for a resilient system
05:26:00 <moon-child> depending on what exactly you are after, you might consider serialising userspace process state, destructively updating kernel, and then restoring userspace
05:27:00 <zid`> even just building the code would be nearly impossible because you'd need to be able introspect what was otherwise private state
05:27:00 <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.
05:27:00 <zid`> you'd need to write a serializing function for every single kernel data structure
05:27:00 <moon-child> some work has been done on serialising userspace linux apps and even sending them over the network
05:27:00 <zid`> even if it's completely local to a translation unit
05:27:00 <sonny> zid` I can rethink what a process looks like
05:27:00 <mrvn> moon-child: the user-space interface is a stable ABI. It doesn't change much if at all.
05:28:00 <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
05:28:00 <moon-child> well ...
05:28:00 <zid`> so for easy cases it's merely "boat loads of code" rather than "impossible code" :D
05:28:00 <moon-child> linux doesn't break compat usually (at least the kernel)
05:28:00 <mrvn> zid`: if the size of sigaction_t changes then you have to recompile all your apps.
05:29:00 <zid`> This is where windows HANDLE is an inferior option at least, so we've got that going for us
05:29:00 <zid`> (where it's just a uintptr_t pointer that may end up not packing properly afterwards)
05:33:00 <sonny> I think this is what CRDTs are for
05:33:00 <zid`> nope
05:34:00 <zid`> that's about being, and you may not have guessed this from the name, conflict-free and replicated
05:34:00 <zid`> we specifically are not replicating and do have conflicts
05:36:00 <sonny> I thought the kernel (or any target process) was being replicated
05:36:00 <mrvn> except for the shared bits
05:37:00 <moon-child> zid`: well, I'm _trying_ to replicate but ...
05:37:00 <moon-child> (sorry)
05:44:00 <sonny> does any filesystem have the name of the process that created the file in the 'birth metadata'?
05:45:00 <sonny> my other idea is to let the filesystem also look like ram. I guess a theme for me is persistence
05:46:00 <moon-child> https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s07-tsalapatis.pdf ?
05:47:00 <sonny> yeah that, but my idea is more weird
05:48:00 <klys> to let ram look like the filesystem?
05:49:00 <mrvn> the problem with persistace is that disks are so slow. Try making your 10G NIC persistant.
05:49:00 <mrvn> if you have a system with some NV-ram you might have a go at it.
05:49:00 <sonny> klys: what ever the user creates belongs to them, memory included
05:50:00 <klys> sounds like it needs some quotas too
05:50:00 <sonny> I don't find files as a tree very useful idea
05:51:00 <sonny> mrvn networks worry about peristence themselves in the protocol?
05:52:00 <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.
05:55:00 <sonny> ah
05:56:00 <sonny> so the server just times out then
05:57:00 <sonny> bugs and stuff hurt less if you can restart I think
05:57:00 <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.
05:59:00 <sonny> rip
06:01:00 <mrvn> with NV-ram it's not a problem.
08:19:00 <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?
08:19:00 <Mutabah> That's what inlining is for
08:20:00 <mrvn> The language should have a syntax to say that the argument of fn1 is returned so to RVO on it.
08:20:00 <moon-child> that's implementation, not design
08:20:00 <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
08:21:00 <Mutabah> Probably more `Big b = fn2(23); fn1(&b)`
08:21:00 <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.
08:21:00 <mrvn> Then *
08:21:00 <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)
08:22:00 <moon-child> mrvn: only if you're c++-ish
08:22:00 <moon-child> I mean, I should hope it's pretty obvious c++ is not a design to emulate...
08:23:00 <mrvn> I like the idea of not having uninitialized values and have constructors.
08:23:00 <Mutabah> `impl Big { fn fn1(i32)->Big; fn fn2(&mut self); } let b = Big::fn1(23).move fn2();`
08:24:00 <mrvn> .move?
08:24:00 <Mutabah> A syntax I just made up for `{let mut v = Big::fn1(23); v.fn2(); v}`
08:25:00 <Mutabah> I.e. so you can all a method that mutates as part of a method call chain
08:25:00 <mrvn> so like .apply or .invoke
08:25:00 <Mutabah> yeah
08:25:00 <FatAlbert> good morning OSDeV
08:26:00 <mrvn> That works. The point of "Big fn1(Big x)" is to return the value so it can be chained.
08:27:00 <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
08:27:00 <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.
08:27:00 <Mutabah> Oh, `move` is a rust keyword
08:28:00 <mrvn> looks lkike a method call though
08:28:00 <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 :)
08:29:00 <Mutabah> The idea was just "some syntax that calls a mutating unit/void-returning function, and returns the receiver"
08:29:00 <mrvn> In C you have fn1(23) | fn2, or in ocaml fn1 23 |> fn2 for chaining.
08:29:00 <mrvn> You would need some other infix operator for a self mutating chaining
08:30:00 <mrvn> or some keyword or function
08:30:00 <mrvn> fn1(23) |> mutate fn2 |> some more |> ...
08:33:00 <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.
08:34:00 <zid`> greater than dot? pfft
08:42:00 <mrvn> moon-child: I'm tempted to have a language design where all functions have the form: Error name([in, out, inout] Arg1 arg1, ...)
08:44:00 <mrvn> or name([in, out, inout] Arg1 arg1, ...) (nofail), since returning an error is implicit
09:08:00 <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'.
09:09:00 <zid`> make sure it includes a random salt which is "6"
09:09:00 <zid`> sorry, 4
09:09:00 <zid`> had to check #221
09:10:00 <vdamewood> Yeah, the IEEE-vetted random number.
09:24:00 <kingoffrance> eh, use a ddr pad and have to hit right sequence within margin of error/timing. anyone who can barbarian dance deserves root
09:25:00 <kingoffrance> its a challenge/response type deal
09:26:00 <vdamewood> The password shal be that they have to get Perfect, in Hard, for the song Butterfly
09:26:00 <vdamewood> shall*
09:31:00 <kingoffrance> seriously though, what else could use timing? (other than expiring tokens/expiring passwords/one-time etc.)
10:12:00 <marshmallow> I'm wondering, say that kernel code lives in page tables marked as r-x, are the protection bits (somehow) hardware-enforced?
10:13:00 <j`ey> yes you will fault if you try write to that
10:15:00 <mrvn> having memory W^X (writable exclusive or executable) is a big security feature.
10:15:00 <kingoffrance> ^ will fault. some things may allow similar protections independent of paging too, e.g. amd elan sc 520 (486-ish SOC) :D
10:15:00 <mrvn> never allow executing anything that can be written to and vice versa.
10:16:00 <marshmallow> sure, but the protection bits are actually set by the kernel, and not by the hardware, no?
10:16:00 <mrvn> set by the kernel, used by the hardware
10:16:00 <marshmallow> in which sense "used by the hardware"?
10:17:00 <mrvn> Hardware might also have separate user read/write and kernel read/write bits
10:17:00 <j`ey> the hardware checks the bits when its tryingto write or read or execute
10:17:00 <mrvn> marshmallow: enforced
10:23:00 <zid`> hmm, did the ppro have 1G pages or were they added later?
10:23:00 <zid`> (ppro introduced pae)
10:24:00 <mrvn> pretty sure later
10:24:00 <mrvn> In 64biut mode 1G pages are optional.
10:25:00 <GeDaMo> https://en.wikipedia.org/wiki/Page_Size_Extension "It was introduced in the original Pentium processor, but it was only publicly documented by Intel with the release of the Pentium Pro"
10:25:00 <bslsk05> ​en.wikipedia.org: Page Size Extension - Wikipedia
10:26:00 <zid`> I think that's only 2M
10:27:00 <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.
10:28:00 <mrvn> zid`: Do you have some mechanism to defragment physical pages so you get contiguous and aligned ranges of 1GB memory?
10:28:00 <zid`> aha it was pentium 2
10:31:00 <zid`> no, p2 added PSE36 which was an alternative to PAE, wtf
10:35:00 <mrvn> You should ignore everything below long mode.
10:39:00 <zid`> westmere is the answer it seems
13:58:00 <marshmallow> other doubt, in ARM64, say that the kernel is compromised, is the attacker still not meant to access the secure world?
13:58:00 <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?
13:59:00 <mrvn> marshmallow: is the kernel running in secure mode?
14:01:00 <mrvn> So in 700E teil oder 1700E?
14:01:00 <mrvn> ups
14:01:00 <marshmallow> mrvn: well yes, the kernel runs on EL1 context, whereas the secure world should run in EL3
14:02:00 <marshmallow> uhmm no OK sorry, I think I'm mixing up secure monitor w/ trustzone, which are two actually different things
14:12:00 <kingoffrance> re: memcpy, IIRC thats fine for c89 memcpy at least. memmove i think must handle overlap, memcpy it is undefined
14:13:00 <kingoffrance> i mean, seems kind of odd "why doesnt it just call memmove() then?" but seems permitted IMO
14:14:00 <kingoffrance> err, linux says "The memory areas must not overlap" so that is more strong
14:14:00 <kingoffrance> maybe that is proper :D
14:15:00 <kingoffrance> quote: "(POSIX and the C standards are explicit that employing memcpy() with overlapping areas produces undefined behavior.)"
14:15:00 <kingoffrance> so, can go either way :D
14:30:00 <Griwes> he's talking about memcpy_s, not memcpy
14:38:00 <kingoffrance> sure, but why should it not be "orthogonal" ?
14:38:00 <kingoffrance> thats even worse if it is not
14:51:00 <kingoffrance> https://en.cppreference.com/w/c/string/byte/memcpy for both c99 and _s it says overlap is a violation of restrict, so :D
14:51:00 <bslsk05> ​en.cppreference.com: memcpy, memcpy_s - cppreference.com
15:34:00 <mrvn> kingoffrance: memcpy_s, not memcpy
15:34:00 <mjg_> tidbit https://twitter.com/M_Labs_Ltd/status/1539174943950221312
15:34:00 <bslsk05> ​twitter: <M_Labs_Ltd> First step when receiving a Windows XP spectrum analyzer: Boot FreeBSD on it and backup the internal disk with netcat. https://pbs.twimg.com/media/FVw-9e1UUAANr7y.jpg https://pbs.twimg.com/media/FVw_ExSUcAILGtu.jpg
15:34:00 <mrvn> c++reference says it will zero out dst on overlap and return an error
15:35:00 <mrvn> If it reports overlap as error it should not also corrupt memory.
15:52:00 <kingoffrance> yeah, but im sure that's "safe" to some ppl
17:01:00 <sonny> Is it still true that system calls have to be implemented in assembly?
17:04:00 <j`ey> do you mean from the userspace side or the kernel side?
17:05:00 <j`ey> (as in.. the implementation of the sys call, or the actual sys call 'instruction')
17:06:00 <sonny> the implementation
17:08:00 <j`ey> i dont think they ever had to be asm
17:09:00 <sonny> oh, nevermind then
17:09:00 <sbalmos> the transition from userspace to kernelspace, "yes"
17:10:00 <j`ey> the interrupt/exception handler will probably be some asm before jumping into a higher level language
17:24:00 <mrvn> On the lower ARMs foolow the C calling convention for IRQs and syscalls
17:25:00 <mrvn> s/foolow/follow/
17:48:00 <dh`> none of the _s stuff was coherently designed
17:48:00 <dh`> best to not waste time thinking about it
19:46:00 <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
20:32:00 <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
21:25:00 <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.
21:45:00 <geist> yah sometimes going back and reading them is useful
21:45:00 <geist> even once you're experienced
21:45:00 <geist> it dusts off old neural pathways
21:47:00 <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.
21:49:00 <geist> yeah
21:49:00 <geist> i think more completely, iirc all apps start by default unless you mark them as no-start-on-boot
21:50:00 <geist> ther eis a way to manually start them with a command line, which is the idea for the no-start-on-boot apps
21:50:00 <sbalmos> right. I found the pseudo-command line and was working backwards
21:50:00 <geist> apps are discovered by a special section they are put in
21:50:00 <sbalmos> I saw the start-on-boot app array that's iterated at the end of the bootstrap2 process
21:50:00 <geist> right
21:50:00 <geist> it's like the LK commands, they're put in an array that the linker script coalesces
21:50:00 <sbalmos> but it was that final "okay, is the command shell part of that auto boot array?"
21:51:00 <sbalmos> yeah, that was the last thing was I saw the modules defs in the linker scripts
21:51:00 <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
21:52:00 <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
21:52:00 <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
21:52:00 <geist> but really should do something so i can finally write on-server unit tests instead of requiring they be run manually
21:53:00 <geist> i could also inject commands into the command line i suppose, but figured i'd do it a little cleaner than that
21:54:00 <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
21:54:00 <sbalmos> right
21:54:00 <geist> it's sort of like the loop() in arduino style of where you put your bits
21:54:00 <geist> so usually they have a single app
21:55:00 <sbalmos> yup, no biggie. no need for userspace or such.
21:55:00 <geist> right, though i have a lkuser project in another repo that inserts its own 'app' that basically kicks off the main process
21:56:00 <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
22:28:00 <clever> geist: but unlike arduino, it has threads, and you can register multiple apps!
22:28:00 <clever> the way ive been using it, is both what you said, and animations that run on the gui
22:28:00 <geist> yep at some point i actually ported some arduino code to it and it worked pretty well
22:29:00 <geist> just ran the arduino sketch in a thread and it was totally fine
22:29:00 <geist> and you can easily. have background servers doing stuff
22:29:00 <clever> yeah, just need some bindings to translate gpio over
22:29:00 <geist> and worker threads for stuff like net stacks or bluetooth or whatnot
22:29:00 <clever> yep
22:30:00 <clever> https://www.youtube.com/watch?v=BQyyVtmmVg8
22:30:00 <bslsk05> ​'rpi open firmware boot' by michael bishop (00:02:23)
22:30:00 <clever> one app is running a shader and displaying the triangle
22:30:00 <clever> one app is bouncing the rpi logo
22:31:00 <clever> the shells arent really a thread or app, but maybe should be
22:31:00 <clever> i ran into infinite recursion if i try to print inside a gfx console
22:32:00 <clever> both of the animations are using a blocking primitive, to wait for a vsync irq
22:43:00 <heat> from what I understand that's one of the big advantages of lk
22:43:00 <heat> you get threads, etc like a full fledged kernel but it's flexible and small enough you can build a bootloader or firmware out of it
22:43:00 <gog> you can sew with it
22:44:00 <gog> with the threads
22:44:00 <heat> comedy with gog
22:44:00 <gog> thank you
22:44:00 <gog> i'll be here all night
22:45:00 <klange> I can change that.
22:45:00 <heat> 🤨
22:46:00 <klange> I won't, but I _can_.
22:47:00 <heat> big dick energy right here
22:48:00 * kingoffrance throws gog a fish "try the fish"
22:48:00 * gog chomps fishy
23:14:00 <geist> heat: i think that's it. also a lot of folks actally just like the build system and it's fairly easy to just <insert code here> and go
23:14:00 <geist> and it depends on nothing external except a compiler
23:15:00 <geist> the folks that have problems wit it are when they have some big pile of code or another opinionated build system that's incompatible with it