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=osdev&y=19&m=2&d=12

Tuesday, 12 February 2019

12:00:26 <mahackamo> knebulae: yeah ada95 (with very slim RTS, no tagged records, secondary stack, etc) but i don't have performance numbers i'm in the very early stages
12:01:40 <mahackamo> gcc-gnat and probably other compilers do not run with full validation by default, and this will be the first thing i benchmark when i get timers running
12:11:14 <jmp9> Okay, I've implemented scanf/sscanf. Now I can interpret user commands
12:11:17 <mahackamo> so i assume it's generaly on par or a bit below C performance
12:11:32 <mahackamo> with these missing validation checks by default.
12:11:53 <jmp9> https://i.imgur.com/rDZrgEH.png
12:22:21 <knebulae> @mahackamo: if you could keep me posted when you do get some of those numbers, that'd be awesome. I don't want to use Ada in kernel, but Spark is speaking my language for some things.
12:23:12 <mahackamo> knebulae: does spark completely eliminate exceptions? i don't know much about it
12:23:33 <mahackamo> i'll add you to "the list" when i have something worthy of presentation :)
12:24:24 <knebulae> @mahackamo: if I recall, no exceptions (or interrupts at all), and no changes in context "outside the code" were the biggest strikes against a kernel in Spark.
12:25:06 <knebulae> Basically anything Spark can't statically analyze & verify.
12:25:34 <mahackamo> i guess the preconditions / postconditions handle validity checks?
12:25:45 <mahackamo> i need to read up on post ada95
12:26:04 <knebulae> Now I just did a cursory reading of Spark and Ada 2020 at the website they posted on reddit a few days ago. It was a quick read, and I wasn't taking notes.
12:33:36 <knebulae> This took me way too long to dig up (given the url), but this was the site the ada guys posted, and I just followed along with the comparisons between Ada and Spark, which led to my conclusion about Spark being unsuitable for a kernel: https://learn.adacore.com/
12:34:09 <knebulae> Most specifically: https://learn.adacore.com/courses/intro-to-spark/book/01_Overview.html#limitations
12:34:50 <mahackamo> all i could find on reddit is http://www.adaic.org/2017/08/community-input-for-ada/ their search function is uhh, challenged.
12:35:30 <klange> reddit's? you don't search reddit with reddit, you use google.
12:35:35 <knebulae> @mahackamo: the ada guys put it in their comments on an NVIDIA Cuda w/Ada article.
12:35:48 <mahackamo> ++klange
12:36:06 <knebulae> @mahackamo: reddit's search is worthless enough for titles, let alone comments.
12:36:37 <knebulae> I read more about Spark's limitations though- these are not the only ones.
12:40:55 <mahackamo> oh yeah one thing that caught me by surprise, make sure you know how the and/or operator works, like if you have multiple and's in an if check then unlike C they will all be evaluated! there are additional short cut operator keywords: and then / or else
12:41:18 <knebulae> no access types (aren't these Ada pointers?), no allocators, no exceptions, no side effects in expressions, no goto. Pretty bad for a kernel.
12:42:09 <mahackamo> hort-circuit
12:42:11 <mahackamo> whatever
12:42:18 <knebulae> Those were my reasons against Spark anyway.
12:42:36 <mahackamo> yeh i need access for interfacing with machine code
12:42:48 <mahackamo> sanely using types instead of hacky address attribute
12:43:41 <knebulae> @mahackamo: right- Spark might be a good idea, but a kernel has to do unsafe things for hardware.
12:45:34 <mahackamo> haven't done any allocators yet, probably will need that stuff too. i'm really an ada noob but i've done enough C to make my way this far
12:45:55 <mahackamo> this is a pretty weird way to learn a new language lol
12:48:35 <knebulae> @mahackamo: I didn't mind the verbosity, and it does make things nice in a lot of areas. But I found that I didn't *understand* what I was doing in setting up the runtime, etc. I was just following a guide. I wouldn't dare write a kernel in Ada. Zig though? In a heartbeat.
12:49:33 <mahackamo> it's much easier because you can disregard all information about the RTS and standard library, reinvent everything as you go
12:49:37 <knebulae> hear that andrewrk? Get moving man. ;)
12:50:04 <mahackamo> for learning purposes anyway, not very practical to reimplement the world
12:50:07 <bluezinc> well, clearly all kernels would be better with dynamic typing.
12:50:40 <knebulae> dynamic typing? bluezinc: the first kernel in php.
12:51:26 <andrewrk> who rubbed my lamp? you get 3 wishes
12:52:09 <knebulae> it was me. I just threw down a zig reference, so I had to name drop.
12:52:45 <bluezinc> zig?
12:53:29 <jmp9> oka yg uys
12:53:32 <jmp9> ok guys
12:53:34 <andrewrk> knebulae, looks like this person on GitHub agrees with you: https://github.com/sjdh02/trOS/compare/817f0cf057...39cda4b516
12:53:39 <jmp9> i wantto reai
12:53:42 <jmp9> i wan t
12:53:45 <andrewrk> look at that first commit message and last one
12:53:46 <jmp9> i want to read data from disk
12:53:47 <bluezinc> oh geez. what is the point of zig?
12:54:14 <jmp9> what you'll recommend me
12:54:19 <jmp9> for reading disk
12:54:39 <andrewrk> bluezinc, have a look here and tell me this does not look attractive for OS dev: https://github.com/andrewrk/clashos
12:55:10 <andrewrk> also this (last link and i'll stop) https://andrewkelley.me/post/zig-stack-traces-kernel-panic-bare-bones-os.html
12:55:53 <knebulae> @andrewrk: so is that 2 kernel projects now in Zig (obvs. excluding my little trivial examples).
12:58:09 <knebulae> @andrewrk: he made the decision in 1 day! zig is great. I would love to do the libc in it, but I know there were a couple of lingering compiler issues. But that's a decade away. :)
12:58:49 <knebulae> I meant my libc is a decade away btw.
12:59:09 <nyc`> Ada95 could be interesting in certain ways. I might seriously consider using that instead of C.
12:59:57 <nyc`> I don't know anything about Zig.
01:00:00 <bluezinc> andrewrk: it's actually not that bad-looking.
01:00:18 <knebulae> @bluezinc: I did a full uefi treatment with Zig. very capable.
01:00:46 <knebulae> It just has a problem distinguishing between a pointer to one and a pointer to many in C structs, which made my life (and by extension, andrewrk's) a living hell.
01:01:02 <knebulae> :)
01:02:11 <nyc`> Zig looks reasonable, though very C-like.
01:03:30 <bluezinc> I debate between just going with C for something portable and basic vs. going with something flashier.
01:03:39 <knebulae> @nyc: but it gets rid of many C-annoyances.
01:03:57 <bluezinc> knebulae: it also keeps many many C-annoyances.
01:03:57 <nyc`> knebulae: Like what?
01:04:09 <knebulae> I
01:04:21 <knebulae> whoops- It's been a couple months
01:04:33 <knebulae> Offhand, it's just "cleaner"
01:06:13 <nyc`> My big issue with C is that it is too heavily tied to a stack discipline so interrupt model programming is more difficult and often needs asm support to force tailcalls and otherwise work around the calling convention.
01:06:28 <knebulae> I can put the zig uefi stuff back up. It was just confusing in the barebones, because the barebones is now in C.
01:07:15 <nyc`> There are software engineering and stylistic issues with C, too.
01:07:35 <bluezinc> there's also really the question of why I should use something that's almost-C, when I have to use real C for other projects/work.
01:07:50 <bluezinc> if I'm going to use another language, there'd better be significant benefits.
01:08:24 <bluezinc> (relative to the benefit of using the most-common language)
01:08:30 <nyc`> Oh, how arrays work in C ruins alias analysis for autoparallelization and formal verification.
01:09:00 <bluezinc> nyc`: how?
01:09:17 <knebulae> @bluezinc: My biggest issue with using <INSERT_NOT_C_C++_ASM_HERE> is that you still have to provide and interface and a runtime for C code, no matter what. Unless you don't intend to run anything.
01:10:11 <knebulae> @nyc: I know some of those words
01:10:14 <bluezinc> either you have to write a C-compatibility layer, or find a userland written in other languages.
01:10:28 <klange> or write your own
01:10:47 <nyc`> bluezinc: Well, easy, implicit decay and other derived pointers mean that Fortran-like assumptions of array parameters being distinct or equal break down.
01:10:47 <knebulae> TempleOS II - Still doesn't run shit.
01:10:51 <bluezinc> klange: I'd lump that in under "find a userland written in other languages"
01:11:01 <mahackamo> theres a GBA emulator for TempleOS
01:11:15 <mahackamo> oh II
01:11:17 <mahackamo> ;)
01:11:48 <nyc`> Do userspace in Lisp and Prolog and such.
01:12:05 <nyc`> Or Haskell or whatever.
01:12:09 <andrewrk> btw knebulae I am at this very moment working on the "C pointer type" which fixes all your problems and it should be in master branch by tomorrow evening
01:12:40 <klange> this is #osdev not #kerneldev, if you're not building the OS why are you here? :)
01:12:48 <klange> the whole OS*
01:13:10 <knebulae> @andrewrk: now I've got some thinking to do- damnit ;)
01:13:33 <nyc`> klange: The big idea I'm trying to showcase is actually a relatively narrow aspect of the kernel.
01:13:54 <bluezinc> nyc`: or you just check that they're not doing anything real stupid with derived pointers, then treat them as fortran-like.
01:15:04 <nyc`> bluezinc: The actual solution C uses is to have compiler implementations define pragmas to blindly treat them as non-aliasing.
01:15:35 <jjuran> Doesn't `restrict` do that?
01:15:35 <bluezinc> klange: because I like firefox?
01:16:05 <jmp9> what difference between osdev and kerneldev?
01:16:31 <jjuran> You can recognize the value of packaging a particular application for your OS without liking it
01:16:42 <nyc`> There are other things about multidimensional arrays and so on that I've not been paying attention to for 20+ years because I went into the kernel and left numerics once I got out of school.
01:16:44 <klange> bluezinc: psh, write your own browser engine
01:17:37 <bluezinc> klange: I may be crazy enough to write a kernel, but I'm not crazy enough to try a browser engine.
01:17:45 <nyc`> Most of my complaint about C is basically not being able to force tailcalls.
01:17:51 <jjuran> It probably won't take a skilled individual more than ten years.
01:18:11 <jjuran> Though by then, the standard will have evolved.
01:18:21 <jjuran> Zeno was right!
01:18:33 <nyc`> Or otherwise explicitly managing the stack more.
01:19:12 <jjuran> C has no way to specify that two values are returned in respective registers.
01:19:56 <bluezinc> nyc`: why would you want to explicitly force tailcalls?
01:20:34 <knebulae> @jjuran: which is infuriating because it's obviously supported by a cpu, and it's natively supported by llvm (at least 2 return registers).
01:21:45 <knebulae> @jjuran: you might be able to return multiple values with a custom calling convention, which I've investigated, and is pretty straightforward in llvm.
01:22:09 <jjuran> knebulae: Mostly it's 68K I care about :-)
01:22:27 <knebulae> right, but this was helpful (it's cpu agnostic): https://learning.oreilly.com/library/view/llvm-cookbook/9781785285981/ch08s02.html
01:22:41 <knebulae> shoot, that might be a subscriber link.
01:22:51 <knebulae> well, it's free for a month, lol.
01:23:03 <jmp9> what difference between osdev and kerneldev?
01:23:19 <Mutabah> one is a superset of the other/
01:23:27 <bluezinc> the size of klange's ego?
01:23:30 <jjuran> A duck?
01:23:34 <knebulae> jmp9: osdev means the kernel + all programs; so linux != osdev. GNU/Linux == osdev.
01:23:58 <jmp9> ah
01:24:00 <jmp9> thanks
01:24:00 <knebulae> well, not *all* programs. But more than the kernel. uhh, yeah.
01:24:25 <nyc`> bluezinc: Treating things like interrupts means that things don't really return, or don't past a certain point.
01:24:27 <klange> I think bluezinc is failing to detecting sarcasm and humor.
01:24:40 <bluezinc> knebulae: I guess if your kernel is monolithic enough, technically it could all be within kerneldev.
01:25:14 <jjuran> In-kernel HTML parser
01:25:19 <bluezinc> it's just that when firefox is compiled into your kernel, that's really pushing the limits of the term "monolithic kernel"
01:25:34 <knebulae> @bluezinc: right, but commands like mkdir and ls are a necessary part of an operating system, but are NOT kerneldev. :)
01:25:44 <nyc`> bluezinc: Even just forcing tailcalls isn't really enough because there may be multiple stack frames to blow away.
01:25:49 <klange> Since everything is moving towards web apps anyway, having a kernel HTML engine is obviously the future.
01:25:53 <bluezinc> klange: I think yo're failing to detect my detection of sarcasm and humor.
01:26:23 <bluezinc> knebulae: what if your shell is part of your kernel?
01:26:49 <bluezinc> seems like most early OSes have a shell of some sort in their kernels.
01:27:04 <knebulae> well, you can run a user application in supervisor mode, but that doesn't make it a kernel.
01:27:20 <knebulae> Much like printing hello world on bare metal ;)
01:27:49 <bluezinc> knebulae: but where do you draw the line? if it's compiled into the kernel, it would strike me as being more kernel code than app code.
01:28:21 <knebulae> @bluezinc: the word "kernel" has a specific definition; hint- it's not simply "it's linked into the binary"
01:28:59 <bluezinc> knebulae: how do you define it, then?
01:29:30 <knebulae> *I* don't: https://en.wikipedia.org/wiki/Kernel_(operating_system)
01:29:38 <nyc`> The kernel concept is of an operating system structured to have a particular "center" or "nucleus" that may not actually apply to many system designs.
01:29:47 <bluezinc> are drivers in the kernel? is the scheduler?
01:30:31 <jjuran> The original Mac OS didn't have a kernel as such.
01:31:14 <bluezinc> knebulae: I really don't see much of a definition there.
01:31:28 <knebulae> @jjuran: it most certainly had what was, at that time, called a system executive (i.e. a kernel).
01:32:02 <bluezinc> beyond "is the core of a computer's operating system", and "one of the first programs loaded on startup"
01:32:27 <bluezinc> there's really not a good definition for what actually falls under "kernel"
01:32:34 <bluezinc> because it's different for every OS.
01:32:57 <knebulae> @bluezinc: and it's different for every type of kernel, of which there are many. So?
01:33:25 <bluezinc> so I don't think it's unreasonable to have a shell be considered part of the kernel.
01:33:25 <nyc`> "Master control program."
01:33:57 <knebulae> @bluezinc: bro, this is *not* a hill I'm willing to die on tonight; if you want to call your shell part of your kernel, man, have at it.
01:33:58 <bluezinc> as long as it's not a clearly separate program.
01:36:44 <nyc`> ... now define operating systems for Turing machines.
01:43:21 <nyc`> I'm not sure they're Turing machines, but I think there are relatively abstract machine models that operating systems make sense for.
01:44:34 <jmp9> yay
01:44:35 <jmp9> https://pp.userapi.com/c845418/v845418594/19e39b/0HcETbA0cDg.jpg
01:44:42 <jmp9> i've created little terminal for my os
01:45:15 <nyc`> The theorizing has already been done. Where to find it is a good question.
01:52:57 <nyc`> A theory of NUMA gang scheduling on some mathematical model extending Turing machines enough to make it make sense is easily conceivable, for example.
01:53:11 <jmp9> street gang wars
01:54:07 <nyc`> Gang scheduling is trying to schedule all the threads and processes of a gang to run at the exact same time.
01:55:18 <nyc`> jmp9: Consider a VM where guest OS's use spinlocks, for example. If the holder gets scheduled away the rest of the threads spin uselessly.
01:57:37 <nyc`> The point is that it's an SMP model where the timing considerations make the difference in basic correctness: if they're not running at the same time, it's not gang scheduling.
01:58:07 <jmp9> that's some complicated topics
01:58:37 <jmp9> cybernazis from intel want make everything harder
02:00:10 <nyc`> The stuff I know where to find is lockfree data structure theory.
02:00:27 <nyc`> Herlihy IIRC.
02:11:49 <nyc`> Wait-free data structures are the big thing.
02:16:13 <nyc> https://cs.brown.edu/~mph/Herlihy91/p124-herlihy.pdf
02:23:24 <nyc> http://www.cs.technion.ac.il/~erez/Papers/lfbtree-full.pdf
02:32:16 <nyc> The B+ tree still converges at around a 5x speedup.
02:35:56 <nyc> https://en.wikipedia.org/wiki/Parallel_slowdown
02:38:25 <nyc> https://en.wikipedia.org/wiki/Non-blocking_algorithm <--- wait-free algorithms seem to be floating around thanks to Timnat & Petrank
02:41:16 <knebulae> @nyc: I know this is going to be a simple point in a complex train of your thought, but I have read in various spots that lock-free is one of those things that's great in theory, but sucks in practice, because you wind up running code that just backing up and trying again over and over needlessly when a simple mutex would've handled the contention graciously. Thoughts, because I don't want to become an expert in lock-free algos just to know if those
02:41:17 <knebulae> "voices" were full of shit or not.
02:41:55 <nyc> http://sci-hub.tw/https://dl.acm.org/citation.cfm?doid=2692916.2555261
02:42:08 <nyc> knebulae: Wait-freedom is a lot stronger than lock-freedom.
02:45:40 <knebulae> @nyc: "The Lock-Free property guarantees that at least some thread is doing progress on its work"
02:45:56 <knebulae> @nyc: "The Wait-Free property guarantees that any given thread provided with a time-slice will be able to make some progress and eventually complete"
02:46:21 <knebulae> @nyc: I'm having a hard time conceptualizing why these two cases are different in practice
02:46:48 <nyc> knebulae: Starvation can happen in the lock-free case.
02:47:28 <knebulae> @nyc: not according to the definition of Lock-Free
02:47:56 <knebulae> @nyc: I'm not challenging you, I'm just saying maybe that's where I have a problem, because that's not what (this) definition says.
02:49:16 <nyc> knebulae: In starvation, you might have a thread S starving while two series of threads say {A_k}_{k=1}^\infty and {B_k}_{k=1}^\infty make progress indefinitely while some A_k or B_k is always in flight.
02:49:20 <knebulae> @nyc: s/problem/misunderstand/
02:50:24 <knebulae> @nyc: I see. I read "at least some thread" as "if there's not 0 threads, there's no starvation..." Thanks.
02:51:48 <knebulae> @nyc: So, how PERFORMANT are those algos in practice?
02:52:04 <nyc> knebulae: There are graphs of performance metrics.
02:52:10 <knebulae> @nyc: MIPS and/or SPARC numbers are acceptable.
02:53:58 <knebulae> @nyc: oh, missed the link. sorry- that was a paper :)
02:54:17 <nyc> knebule: There have been multiple papers.
02:54:43 <knebulae> @nyc: so there were.
02:54:47 <knebulae> thank you
02:56:08 <nyc> knebulae: One major goal is to defer the point of parallel slowdown.
02:59:01 <nyc> knebulae: There's an algorithm that Petrank & Timnat have to transform lock-free to wait-free.
03:00:06 <knebulae> @nyc: I have some reading to do.
03:00:45 <knebulae> @nyc: my questions would just be a nuisance to you right now.
03:01:10 <nyc> knebulae: The brilliant thing about it is (a) RCU makes it easy to do a lot of things lock-free and (b) going wait-free isn't patent-encumbered.
03:01:30 <knebulae> @nyc: gotcha
03:02:41 <nyc> knebulae: I think RCU's patent is going to expire soon anyway.
03:03:18 <Griwes> a good policy is to never talk about patents
03:03:44 <Griwes> and it's annoying, but that policy also covers not talking about why you never want to talk about patents in public
03:21:34 <geist> agreed, i do not want to discuss or take part in any discussion of patents here
03:46:33 <jmp9> I have question
03:46:46 <jmp9> I can't write grub to usb flash drive
03:47:00 <jmp9> it tells that fat filesystem doesn't support embedding
03:47:58 <jmp9> help
03:48:35 <jmp9> help
03:50:05 <jmp9> okay
03:50:06 <jmp9> fuck it
03:50:08 <jmp9> i'm gonna sleep
03:50:21 <zhiayang> what an interesting turn of events
03:50:31 <knebulae> \o/
03:50:42 <knebulae> sorry, wrong window
04:20:04 <zhiayang> update everything works on bochs which is a good sign, but it's way too painfully slow to actually use
04:42:43 <nyc> qemu-system-i386 -hda linux.img -boot n -net user,tftp=/path/to/tftp/files,bootfile=/pxelinux.0 is a netbooting example.
05:00:51 <nyc> qemu-system-sparc64 -nographic -M sun4u -net nic,model=sunhme -boot n -net user,tftp=/home/nyc/src/bld.nmcp/sparc/sys/sparc,bootfile=/nmcp # <<<------- this is not flying
05:10:51 <zhiayang> i'm so confused
05:11:01 <zhiayang> gcc's register extension doesn't "activate" in a template function
05:19:14 <immibis> the one where you can assign them to specific registers? that's odd
05:19:35 <zhiayang> yea, the register int eax asm("eax") feature
05:19:53 <zhiayang> it says "ooo iso c++17 forbids register storage class"
05:20:29 <klys> ooo
05:20:49 <klange> owo
05:21:52 <immibis> lol
05:21:56 <zhiayang> lol: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58118
05:21:59 <immibis> but only in a template function?
05:22:02 <zhiayang> reported 2013
05:22:12 <zhiayang> as far as i can tell, yea
05:38:10 <nyc> Trying net...
05:38:10 <nyc> No valid state has been set by load or init-program
06:04:11 <radens> geist: do you disable the 8259 PIC in zircon? The osdev wiki says you should do that before using the apic, and I think I saw that in the intel manual too.
06:14:25 <zhiayang> you should be
06:18:09 <zhiayang> whatever google is using for their google git is trash, you can't search
06:19:07 <zhiayang> https://fuchsia.googlesource.com/zircon/+/master/kernel/platform/pc/interrupts.cpp#47 -- answer appears to be yes
06:35:42 <mobile_c_> klange:
06:36:51 <mobile_c_> klange: what variable in your linker is the string Table
06:37:36 <mobile_c_> as printing object->string_table + table->d_un.d_val results in nothing (eg "" )
06:38:44 <mobile_c_> klange: when it should be printing, either strTab + table->d_un.d_val = libdl.so.2 or strTab + table->d_un.d_val = libc.so.6
06:40:21 <klange> mobile_c_: You have the wrong string table.
06:40:36 <klange> mobile_c_: Those strings are in the dynamic string table, which is object->dyn_string_table
06:41:43 <klange> object->string_table is the section header string table, which is unused; I will remove it
06:41:52 <mobile_c_> ok
06:42:47 <mobile_c_> object->dyn_string_table + table->d_un.d_val returns the same result
06:43:02 <mobile_c_> TRACE_LD("adding dependancy %s", object->dyn_string_table + table->d_un.d_val);
06:43:09 <mobile_c_> 1549953743.583847 [Dynamic Linker] resources/toaruos/linker/linker_original.c:00947 - [ adding dependancy ]
06:43:39 <klange> :00947 - you have clearly added quite a few lines to this, so I can't really help you anymore
06:44:05 <klange> Either your objects are breaking an assumption I'm making with regards to the dynamic table being loaded, or you messed something up somewhere
06:46:45 <mobile_c_> https://paste.pound-python.org/show/QHnExHzOE3GVSYlHYp9W/ this is the diff of it
06:47:51 <klange> why are you rounding vaddrs
06:48:06 <klange> that's extremely wrong
06:48:34 <zhiayang> 'THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED'
06:48:47 <mobile_c_> cus mmap requires an aligned address
06:49:15 <mobile_c_> zhiayang: lel
06:49:17 <Mutabah> so, handle unaligned
06:49:21 <klange> you still need to use the unaligned one
06:49:41 <Mutabah> (As in, use mmap for aligned mappings, and custom handling to handle the misaligned)
06:49:43 <klange> whatever address you use for the mmap doesn't matter, the data needs to be loaded at the right offset from the base
06:50:27 <klange> You don't seem to understand the fundamentals of loading code from an ELF.
06:51:30 <mobile_c_> is i use the unaligned address i get [ map failed with -1 and errno 22: Invalid argument ]
06:51:49 <zhiayang> jeez
06:52:18 <klange> you need to map pages but you still need to the data to the correct vaddr, you can't go and change it, it doesn't work that way
06:53:12 <klange> need to load the*
06:53:24 <mobile_c_> then how to i map it at the base + phdr.p_vaddr without mmap returning EINVAL
06:53:40 <klange> you map only the page aligned bits and read the unaligned bits
06:54:03 <klange> or you just read the whole thing for now and you can do the direct file mapping stuff later after you've figured out whether things work at all
06:54:51 <mobile_c_> so wtf do i align it to
06:55:21 <klange> Stop using mmap for a minute.
06:55:48 <klange> Stand back and look at what you are trying to do.
06:56:30 <mobile_c_> mimic whatever sysfunc(TOARU_SYS_FUNC_MMAP, args); is doing
06:59:30 <klange> All that function does is ensure that the virtual addresses from start through start+size are mapped.
06:59:41 <mobile_c_> why does your kernel have to be incompatible with linux ;-; ;-; ;-;
06:59:48 <klange> BECAUSE IT'S MY FUCKING KERNEL
06:59:58 * Mutabah hi-fives klange
07:00:05 <mobile_c_> ;-;
07:03:49 <mobile_c_> welp if do fread(mem, phdr.p_filesz, 1, object->file); (even though it was segfaulting before when attempting to read the full memory, which it doesnt seem to be doing now o.o) i get
07:03:56 <mobile_c_> 1549954957.927747 [Dynamic Linker] resources/toaruos/linker/linker_original.c:01307 - [ Loading dependency libc.so.6 ]
07:03:58 <mobile_c_> Failed to load dependency 'libc.so.6'.
07:04:35 <klange> You need to allocate the virtual memory to write into first.
07:04:40 <klange> That's what your mmap is supposed to be doing.
07:05:13 <klange> If you need to align manually for mmap to work, then you need to align manually for mmap to work, but you still need base+vaddr through base+vaddr+memsz to be available in virtual memory.
07:05:16 <mobile_c_> nvm its cus my libs are not in the standard paths
07:05:39 <klange> How you do that is uip to you. My kernel has a hacky syscall to do it specifically to support this use case.
07:05:52 <mobile_c_> there in /lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu
07:06:11 <klange> Generally, the "right" way to do this is to map the page aligned bits directly to the file with mmap, and copy the non-aligned bits into pages you allocate yourself.
07:06:44 <klange> The elf file will be set up so things have the same alignment if you don't pick a stupid base address, so you can map *most* things directly, there's just little bits you may not get to do that with to pack the ELF more sensibly.
07:09:16 <klange> That's why there's an alignment in the PHDR that doesn't align with the start of the data. The data is in the file somewhere. The start and end may not be flush with page boundaries.
07:10:05 <mobile_c_> and i get a seg fault when relocating the main object
07:10:26 <mobile_c_> btw is libdl meant to be loaded at 0x0 ?
07:10:38 <klange> There is no libdl.
07:11:09 <klange> The linker itself is meant to be a static binary that loads at something before 0x40000000.
07:11:17 <klange> There is an included linker script.
07:11:27 <klange> . = 0x3F000000;
07:17:42 <klange> Also this whole thing might not work on Linux because it makes assumptions about how malloc works...
07:29:55 <geist> klange: also high five
07:31:48 <mobile_c_> fk this
07:41:42 <geist> an appropriate response when dealing with ELF loaders
08:30:16 <nyc> I'm still trying to get qemu-system-sparc64 to load a kernel as a guest on an x86-64 host. I got waylaid by some Discord call.
08:32:37 <geist> happens
08:32:50 <geist> i get nostalgic and fire up the old sparcstation sometimes
08:34:51 <nyc> I still cry some nights about the destruction of the sparc32 maintainer collection while I was hospitalized for MRSA in 2008.
08:35:33 <geist> all i have left is a little sparcstation lx, which is a really cute but extremely slow microsparc 40mhz
08:35:51 <geist> and a dual core sparcstation 20 with i think 85Mhz supersparc IIs and 192MB ram
08:36:11 <geist> that would have been a real beast of a machine at the time
08:38:26 <geist> i dont remember what i did with it but years ago i had a weirdass hyundai sparcstation 2 clone
08:38:49 <geist> i ran my mail server on it for a while. figured if anyone could hack it they get the prize
08:40:23 <nyc> I had a large collection of engineering samples of 32-bit SPARC hardware that were passed along to me because I had been named the maintainer of the 32-bit SPARC architecture port of Linux.
08:41:51 <geist> i'd run the ss20 more but when i kill-a-watted it it was a real pig
08:41:59 <nyc> I had an 8x SPARCserver 1000E.
08:42:05 <geist> iirc, it burns a constant 180W or so, independent of cpu load
08:42:23 <geist> ooooh, now a sparcserver 1000 is a real machine. that's like a 7U or something, right?
08:42:24 <nyc> I had a lot of things.
08:43:02 <geist> but alas, it's just old obsolete goop now
08:43:08 <nyc> It wasn't rackmount-compatible largely by dint of front-back depth.
08:43:13 <geist> it's fun, but nothing worth really making a big deal of
08:43:37 <geist> yah, i remember the two main unix boxes that ou could get an account on at school (TAMU) when i was in college was a sparcserver 2000 i think
08:43:57 <geist> scully and mulder i think
08:44:14 <nyc> geist: It and most of everything else I owned or had in my possession disappeared from the apartment I lived in 10 years ago when I was in the hospital for MRSA in 2008.
08:44:14 <geist> pretty impressive that they had like 3000 logins of people running pine
08:44:26 <geist> one of my real first exposure to unix
08:44:38 <geist> nyc: yes i know. you have pointed that out many times
08:45:10 <geist> in the end it's probably worth losing most of your stuff and starting over
08:45:19 <nyc> It's hard for me to get over.
08:45:22 <geist> after all, it doesn't make sense to be shackled by your possessions
08:45:55 <klys> i used to collect computer graphic illustrations
08:46:23 <geist> i did a fairly good purge a few years ago before moving to seattle. my main constraint was useful stuff not end up in a landfill
08:46:51 <geist> so i sold most of my functioning legacy systems (SGI, nextstation, etc) to folks at work that i figured would probably actually do something with
08:47:07 <nyc> Losing all of that sure didn't endear me to the Linux community, at least not judging by my employment situation.
08:47:54 <klys> when my things were stolen, i also was in a hospital of sorts
08:47:59 <geist> heh vry little has endeared me to the linux community
08:49:15 <geist> Axil was the mfg of the sparcstation clone
08:49:20 <geist> which i think was just hyundai
08:49:30 <nyc> Well, my career etc. was very centered on Linux, so not being in their good graces has hurt me badly.
08:55:27 <bcos_> nyc: Sounds like self-inflicted "pigeonholing" to me - probably no real reason you couldn't be a (Linux) server admin, or write a book about Linux internals, or write documentation for Gentoo, or switch to FreeBSD/NetBSD/OpenBSD, or switch to a completely different career path (gardening, old age care, ...)
08:56:13 <mahackamo> they're idiots anyway who cares if you're not in their good graces
08:56:22 <renopt> if you say you can't, then you can't
08:57:18 <renopt> . o O (motivational fortune file)
08:57:43 <nyc> Well, I won't continue this discussion any further than to say that bcos_'s analysis is grossly inaccurate.
09:06:36 <geist> nicely put
09:10:41 <mahackamo> i don't know the "grossly" part just leaves me with more questions
09:12:25 <mahackamo> like you think an employer actually cares that you pissed off some linux nerd ?
09:13:07 <bcos_> mahackamo: Apparently, it's even one of the questions on the job application form at McDonald's
09:17:55 <immibis> unless you were a linux kernel developer
09:22:14 <nyc> You know that Nadia Yvette Chambers in kernel/profile.c, kernel/sched/wait.c, kernel/pid.c, mm/hugetlb.c, mm/hugetlb.c, fs/hugetlb/inode.c, lib/bitmap.c, include/linux/hash.h, etc.?
09:22:29 <nyc> C'est moi.
09:22:35 <immibis> i can't say I do
09:22:55 <nyc> immibis: Who do you think you're IRC'ing to? /whois nyc
09:23:15 <immibis> I still can't say I know you, nor that I'm familiar with any of those source files
09:23:31 <nyc> immibis: They're Linux kernel source files.
09:23:58 <nyc> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/profile.c
09:24:25 <nyc> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/hugetlb.c
09:24:27 <geist> i guess what may be happening here is there's a general backlash against name dropping this sort of stuff
09:24:41 <geist> it generally isn't looked upon nicely, so may not be worth making a big deal about
09:24:46 <mahackamo> hey that's cool, if you become desperate for money you could always start litigating
09:24:49 <nyc> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/hugetlbfs/inode.c
09:24:51 <immibis> i can tell they're linux source files from the context, i'm just saying, i don't know them
09:26:07 <nyc> geist: It probably wasn't worth making the point that it did indeed matter because of my work history.
09:26:56 <geist> i suppose
09:34:40 * nyc installs noweb to document her code at a random point when the more system administrative task of getting some kind of network sniffing set up in order to see what's going wrong with the tftpboot process for OpenBIOS on qemu-system-sparc64 is of greater concern.
11:02:08 * mrvn isn't sure what stuff gtting stolen has anything to do with the linux community. It's not like some nerd from norway will drive over to callifornia to steal an obsolete 200kg 7U sparcserver.
11:24:54 <mawk> you speak french nyc ?
11:25:15 <nyc> mawk: Seulement un peu.
11:25:29 <mawk> Yvette sounds french
11:25:57 <nyc> mawk: Nadia sounds Russian (French would be Nadine).
11:26:07 <mawk> ah
11:26:07 <mrvn> da
11:26:11 <mawk> I'd have said arabic
11:26:32 <mawk> Nâdiya
11:27:11 <mawk> Nadja
11:28:52 <nyc`> Надя
12:08:01 <nyc> OpenBIOS git seems to indicate that tftpbooting has no actual implementation.
12:51:43 <mrvn> Fun with containers: https://seclists.org/oss-sec/2019/q1/119
12:59:15 <klange> I don't speak French, but I like to think I have a knack for etymology, so with some thought, that sentence is readable.
01:00:54 <nyc`> My French is pretty limited.
01:01:07 <klange> Seulement... sounds like solo-ment, -ment sounds like -mento in other romance languages I have studied, acts as a word modifier, solely? Only? "un" is obvious for anyone with romance language exposure. peu sounds like few, and few has a PIE root that is much closer to 'po' or 'peu', so I'm guessing few or little. "Only a little."
01:01:20 <klange> And then I looked up all the etymologies of the French words and... I was right :D
01:02:00 <klange> Helps that English stole a lot of French, though we got 'few' through German.
01:05:58 <jmp9> Hello everyone
01:06:08 <jmp9> I really need install GRUB on USB flash drive
01:07:14 <Lowl3v3l> I suppose this is the wrong channel for you.
01:07:26 <jmp9> Why?
01:07:43 <jmp9> I need install my os to usb stick because i want experimnet
01:08:05 <klange> You can generally produce an ISO and just write it to a USB stick.
01:08:12 <klange> It should work.
01:08:44 <mrvn> klange: only hybrid isos
01:08:55 <jmp9> I followed this turorial
01:08:56 <jmp9> https://wiki.osdev.org/GRUB_2#USB_instructions
01:09:01 <jmp9> and it completely doesn't work
01:09:11 <jmp9> I just get on my screen GRUB _ and nothing else
01:09:12 <Lowl3v3l> jmp9: because I usually expect osdevs here to at least be able to ask smart questions ;)
01:09:20 <jmp9> Yes i know
01:09:22 <jmp9> i'm beginner
01:09:50 <mrvn> jmp9: that's a stage 1(.5) failure.
01:10:16 <klange> Output of grub-mkrescue should be a hybrid that functions on a USB stick.
01:10:25 <klange> The manual suggests as much.
01:11:01 <jmp9> when i reading Disk image instructions, I saw that there is different partion for OS and some space reserved below 1 MB
01:11:02 <Lowl3v3l> jmp9: a good question would have included from the beginning what you want to do, what you tried, and exactly at which point it fails followed by a specific description of the failing.
01:11:16 <mrvn> jmp9: have you tried the disk image istruction and copied the image to the USB stick?
01:11:22 <jmp9> yes
01:11:26 <jmp9> but image is 128 MB long
01:11:28 <nyc`> klange: Você fala português? Parli italiano? Sprichst du Deutsch? ¿Hablas español? Spreek je nederlands ? Du talar svenska? Türkçe biliyorsun? Ты говоришь по русский?
01:11:28 <jmp9> and usb is 4 gb
01:11:35 <jmp9> Да
01:11:40 <jmp9> Я русский
01:11:48 <mrvn> The USB instructions seem wrong because even sticks use partitions.
01:11:57 <jmp9> Oh
01:12:08 <mrvn> jmp9: doesn't matter. you can always copy a smaller image to a stick
01:12:15 <lkurusa> i only see some unicode escape codes lol
01:12:19 <nyc`> jmp9: Spiffy
01:12:22 <lkurusa> pretty sure my terminal is broken
01:12:56 <mrvn> jmp9: does the disk.img boot in bochs/qemu?
01:13:03 <jmp9> perfectly
01:13:16 <mrvn> jmp9: but not from usb stick?
01:13:22 <jmp9> but not from usb stick
01:13:34 <mrvn> and you used dd if=disk.img of=/dev/sdX?
01:13:38 <jmp9> yes
01:14:05 <klange> nyc`: Hablo un poco de español pero japonés が上書きされました。
01:14:05 <mrvn> and then using /dev/sdX as disk in qemu does what?
01:14:40 <jmp9> that's works fine
01:14:47 <klange> Sticks don't *need* partitions, but it's complicated.
01:14:58 <klange> eg. if you shit an ISO out onto them, no partitions :D
01:15:03 <jmp9> sudo qemu-system-x86_64 -hda /dev/sdb
01:15:06 <nyc`> klange: Japanese is good.
01:15:42 <klange> 日本に住んでいるので日本語上手になりたいけど難しい言葉です。
01:15:51 <jmp9> weeaboo
01:15:59 <Lowl3v3l> damned, i am out. Kanji are hard
01:16:50 <jmp9> okay
01:16:54 <jmp9> last attempt with dd
01:17:00 <jmp9> i'll reboot now to see what happens
01:17:05 <jmp9> see me in next 2 minutes again
01:17:29 <nyc`> Internationalization is good for operating systems.
01:17:31 <klange> に上書き* ugh, particles and intransitives...
01:18:06 <Lowl3v3l> for me to learn japanese, i'd need some kind of furigana-slave subtitling EVERYTHING for me :D
01:18:08 <klange> My Japanese support in ToaruOS is really bad now that my main text rendering system doesn't support Unicode and I don't have Japanese fonts. With Freetype and the third-party fonts I used to ship, it was fine.
01:18:42 <klange> Lowl3v3l: rikai* for browsers, reading at an appropriate level for manga, lots of dictionary usage for everything else
01:19:37 <klange> I thought leaving here would yield improvements in my language skills, but working at an English-speaking office, going to the same places to eat, and spending too much time on English-language IRC channels has negated all of that.
01:20:35 <jmp9_> It doesn't work
01:20:42 <jmp9_> I turned on USB legacy mode
01:20:49 <nyc`> I'm actually mostly clueless about internationalization, but am "ideologically aligned" with being very international about everything.
01:20:53 <Lowl3v3l> Yeah i heard all those tips :P I still struggle with on-yomi and kun-yomi all the time^^ And to be quite honest, on my language-list, japanese is pretty low ^^
01:21:01 <jmp9_> but I saw in boot settings that my usb recognizes as "EFI: SanDisk"
01:21:19 <jmp9_> and it skipped booting from my usb
01:21:56 <klange> on-yomi kun-yomi is mostly bullshit anyway, it's just "know what word uses what reading" and the difference between where the two kinds of readings show up is more of a statistical amusement
01:22:20 <nyc`> I mostly think my odds of either integrating or doing much in the job market there are low, so I haven't looked much at Japanese.
01:22:42 <jmp9_> UTF-8 rulez
01:22:46 <jmp9_> winapi kikes get out
01:23:24 <Lowl3v3l> klange the whole japanese language seems to be a gigantic joke on cost of the poor gaijin :D
01:23:26 <klange> jmp9_: This is a formal warning that your choice of language is not suited to this channel.
01:23:49 <jmp9_> what
01:23:52 <klange> Lowl3v3l: I wonder if English learners feel the same way.
01:24:06 <jmp9_> i just said that utf-8 rulz and nothing more
01:24:21 <klange> jmp9_: "kike" is a slur for Jewish people. Please refrain from using language like that in this channel.
01:24:29 <jmp9_> huh
01:25:09 <jmp9_> alt-right communities left a mark on my vocabulary :p
01:25:10 <nyc`> Not a native English speaker, hence possibly not understanding the slur in full.
01:26:16 <jmp9_> okay one question
01:26:23 <jmp9_> in grub disk tutorial we use this
01:26:24 <jmp9_> sudo grub-install --root-directory=/mnt --no-floppy --modules="normal part_msdos ext2 multiboot biosdev" /dev/loop0
01:26:58 <lkurusa> F
01:27:21 <jmp9> sudo grub-install --root-directory=/mnt --no-floppy --modules="normal part_msdos ext2 multiboot biosdev" /dev/loop0
01:27:39 <jmp9> how do i do this with usb
01:27:50 <jmp9> like /dev/loop0 below 1 MB
01:27:55 <jmp9> and /dev/loop1 for FAT fs
01:33:02 <mrvn> jmp9: just like it says in the wiki
01:34:00 <mrvn> jmp9: If the stick works in qemu but not on real hardware then you will have to fix your hardware. Turn off secure boot, enable legacy boot, .... all that stuff you have to do to make modern systems boot from good old USB.
01:34:40 * Ameisen is going to sleep.
01:34:48 * klange is doing similarly
01:34:54 <klange> Have an important phone call at 7am >_>
01:35:00 <mrvn> I never had that problem for OS dev work because I always made those changes to install Linux in the first place.
01:35:00 <Ameisen> exhausted my brain working on LTO issues, and trying to figure out a way to handle pointer/reference aliasing sanely at a language level
01:35:25 <jmp9> ok i'm zeroing my flash drive
01:35:32 <jmp9> to do everything from beginning
01:35:33 <mrvn> Ameisen: simple: everything is immutable. Aliasing is irelevant.
01:35:56 <knebulae> @mrvn: ah, the good old immutable variable by default :shakes head:
01:35:58 <mrvn> jmp9: try downloading the small image from grml.org and boot that from USB.
01:36:09 <mrvn> knebulae: not just by default. Always. :)
01:36:14 <Ameisen> not just const, but immutable even
01:36:17 <mrvn> knebulae: functional programming to the rescue.
01:36:26 <Ameisen> now, how do I handle it in a procedural language.
01:36:27 <knebulae> @mrvn: variable - definition please?
01:36:38 <mrvn> knebulae: no such thing
01:36:48 <Ameisen> also my head hurts from arguing with some... rustnauts?
01:36:52 <Ameisen> rusticles?
01:36:56 <mrvn> hehe
01:36:57 <knebulae> @Ameisen: My algebra teacher from middle school would disagree.
01:37:24 <knebulae> @Ameisen: rustaceans is the preferred nomenclature at this instant in time
01:37:35 <Ameisen> you say a simple thing like modern C++ makes it so you shouldn't be running into memory safety issues
01:37:39 <Ameisen> and suddenly you're brigaded.
01:37:50 <nyc`> Ameisen: Ouch.
01:38:02 <knebulae> @Ameisen: yes, they are not totally in tune with reality
01:38:08 <mrvn> Ameisen: except where the language prevents you from using those features.
01:38:22 <Ameisen> Then you certainly shouldn't be running into those safety issues
01:38:30 <Ameisen> since you must not be writing the code!
01:38:34 <Ameisen> :D
01:38:56 <jmp9> no code - no problems
01:39:02 <Ameisen> the Dlang people are at least sane
01:39:03 <jmp9> just play russian roulette
01:39:11 <Ameisen> jmp9 - no-idea is also nice
01:39:17 <Ameisen> can't have any problems if you don't have an idea in the first place.
01:39:17 <knebulae> @jmp9: that's my mantra; I got 99 problems, but having code ain't one.
01:39:50 <mrvn> Ameisen: Like a vector of unmovable objects. Can't be done since vector resize might have to move them.
01:40:31 <Ameisen> you'd usually use some other kind of construct
01:40:47 <Ameisen> sleep though
01:40:52 <Ameisen> it's quite late... early
01:40:58 <Ameisen> latearly
01:41:06 <mrvn> nearly 3pm, time to start work
01:41:13 <Ameisen> 8 AM
01:41:25 <Ameisen> time in the only place that matters - where I live
01:41:48 <nyc`> I've completely missed Rust and D. What do they have over C and Ada for kernel hacking?
01:42:04 <lkurusa> Rust is bae
01:42:09 <knebulae> @nyc: rust can do some nice things, but you have to fight it for a kernel.
01:42:09 <mrvn> I don't like my timezone but I get payed in it and I like to eat.
01:42:12 <Ameisen> D is like C++ but supposedly better.
01:42:16 <lkurusa> I've never tried D but heard good things
01:42:20 <Ameisen> Rust is like... something else.
01:42:30 <Ameisen> but apparently has a sorta... annoying community.
01:42:46 <lkurusa> most of the fighting Rust when it comes to kernel is due to the infancy of tooling
01:42:51 <lkurusa> not the limitation of the language
01:42:56 <Ameisen> The fact that D's classes are always reference types seems a performance problem to me.
01:43:31 <nyc`> I'd probably want to do my own language anyway.
01:43:41 <knebulae> @nyc: rust is its own beast. Immutability by default, you must "borrow" every reference, and maintain lifetime scoping. It's a great thought, but it's very heavy-handed, which with the advances in C++ is very offputting for a lot of people. The attitude of the community doesn't help much in that regard either.
01:44:28 <lkurusa> could you elaborate on the community aspect?
01:44:31 <nyc`> knebulae: What's borrowing references and lifetime scoping?
01:44:48 <knebulae> @nyc: in rust, you can't have pointer aliasing like occurs in c/c++
01:44:52 <Ameisen> lkurusa - really defensive and tend to brigade/jump over people who aren't using Rust.
01:44:56 <knebulae> You have to borrow the reference
01:45:14 <knebulae> And the compiler enforces it over an object / variable's scope (lifetime)
01:45:15 <lkurusa> Ameisen: ah, aren't most language comminutities like that? not saying it's good
01:45:16 <Ameisen> in my experience, at least.
01:45:16 <mrvn> knebulae: In C++ you have to work to make it safe. In Rust it is safe and you have to work to make it work at all.
01:45:26 <Ameisen> lkurusa - probably, but it seems... 'worse'
01:45:35 <Ameisen> like, I don't usually see D programmers jumping over me for using C++
01:45:40 <Ameisen> but how dare I use C++ when _Rust_ exist!
01:45:49 <lkurusa> I see
01:45:53 <lkurusa> well, that's a shame
01:46:06 <Ameisen> I assume they're just an annoyingly-vocal subset of the community
01:46:08 <mrvn> Ameisen: why are you in a rust channel if you are using c++?
01:46:23 <Ameisen> though one of them apparently has a blog where he shoots down 'myths' about C++'s safety.
01:46:29 <Ameisen> which is sorta.. creepy, to me
01:46:34 <knebulae> Ameisen is right. The community is quick to disparage and call you unknowledgeable for choosing C++ when Rust exists. It's like dude, I was hand-assembling code before your parents were dating. A little perspective, please.
01:46:39 <Ameisen> mrvn - general programming. Rustoleums just happened to be there.
01:47:11 <mrvn> Ameisen: C++ isn't safe. Just last month I developed a multicast server from scratch using C++17 features and still had several segfaults.
01:47:35 <Ameisen> Nothing is perfectly safe. Modern C++ is still way safer than legacy C++
01:47:49 <Ameisen> Rust had segfaults in their standard library up until not long ago, and it's written in Rust.
01:47:55 <mrvn> still too easy to forget something, like deleting a move operator
01:48:34 <knebulae> @mrvn: honestly, it's not really the borrow checker I don't like about Rust. I don't really care for the fact that they chose composition and completely neglected any form of oo, which while I know the problems with oo, it's still necessary for a lot of things.
01:48:56 <knebulae> And I love composition. I just wish it wasn't zero-sum with Rust.
01:49:01 <mrvn> More and more my gut feeling is that c++ has too much magic. It's hard to follow what the compiler will do with all the template stuff.
01:49:26 <Ameisen> I think that the Committee is putting the magic in the wrong places.
01:49:40 <Ameisen> I have... strong disagreements with the Committee about many things
01:49:42 <mrvn> And now it has for (auto x : y)
01:49:48 <Ameisen> and have gotten into arguments with members in the past
01:50:05 <knebulae> @mrvn: it's not magic - C++ just doesn't impose a specific way to do anything, so you have to know all the options available. Move semantics, elision, etc. etc. Most programmers don't care or even know the power C++ truly offers.
01:50:09 <jmp9> okay so i need to create 1 partition for grub?
01:50:42 <mrvn> just yesterday we discussed that std::List now has a size_ and splicing then has to count how many elements you splite between two lists making it O(n)
01:50:45 <Ameisen> knebulae - I just realized that I want a gif of Palpatine yelling 'UNLIMITED POWER!', and then while he's laughing, we get a BSOD.
01:50:54 <mrvn> jmp9: no. just for everything else
01:51:23 <Ameisen> however, sleep time for real.
01:51:40 <knebulae> @Ameisen: get some sleep
01:51:56 <mrvn> knebulae: c++ has a ton of stuff it automatically adds under the hood. Like default copy constructor if A | B & C & ~D apply.
01:52:18 <mrvn> knebulae: and implicit type conversions, fun.
01:53:05 <jmp9> i need to create fat16 bootable partition
01:53:09 <mrvn> You know you truely got into C++ when you get a one line error message that's 120k long.
01:53:30 <nyc`> It's like dude, I'm using C as a glorified multi-arch macro assembler. I'm not going to be sold on object-oriented language features esp. when my biggest complaint is C obscuring the management of the stack.
01:53:59 <Lowl3v3l> mrvn: my experience has been that you can certainly program around lots of those quirks. For low level stuff i have just not found anything that is by far as comfortable, which kind of bugs me, i have to agree
01:54:31 <Lowl3v3l> nyc`: OOP is, on my list of c++ features I wouldn't want to miss at best at place 4 or 5^^
01:54:46 <Ameisen> nyc` - you'd love my AVR C++ toolchain.
01:54:46 <mrvn> nyc`: hehe. I use c++ because namespaces. And sparingly templates and inheritance. E.g. my struct Task inherits List<All>, List<State>, List<Mutex>
01:55:36 <mrvn> Lowl3v3l: OOP is pretty much the only way I can see a GUI toolset work.
01:56:58 <Lowl3v3l> mrvn: depending on what you mean by OOP I'll agree or disagree. I can see it working with prototype-based OOP as well or using traits. There seem to be purely declarative ways as well, but I never looked into those
01:57:45 <jmp9> OKAY GUYS
01:57:47 <jmp9> grub installed
01:57:49 <jmp9> no warnings
01:57:58 <jmp9> sudo grub-install --no-floppy --root-directory=/media/usb_3 /dev/sdb
01:58:02 <jmp9> i typed this command
01:58:02 <mrvn> Lowl3v3l: It's a Widget, it has a width and height. Wether that's a trade, and interface, a parent class, who cares.
01:58:21 <jmp9> in yesterday attempt I FORGOT to add /dev/sdb at ending of command
01:58:35 <mrvn> Lowl3v3l: Point is a button, a table, a list, ... are all Widgets and you can add them to a window for example.
01:59:09 <Lowl3v3l> mrvn: that's the only way I know of as well. But my knowloedge on GUI's is exceptionally limited^^
01:59:10 <mrvn> jmp9: grub install installs on all listed devices, even if that is none. :)
01:59:38 <mrvn> Lowl3v3l: GUI just realy screams for OOP. I think it's the best example to use to demonstrate OOP.
02:00:05 <mrvn> Lowl3v3l: everyone has used a GUI before and can visualize it and understand the examples.
02:00:37 <Lowl3v3l> mrvn: and still I'd love to see alternative approaches. When all you have is a hammer, everything looks like a problem( or sth along those lines :P)
02:07:25 <lkurusa> jmp9: it might be beneficial to read the manual page of a command before executing it
02:15:59 <mrvn> jmp9: does it work now?
02:24:05 <nyc`> It would be good to have multiple high-level languages able to be used at once in userspace, like Haskell and Prolog. The kernel can't really use all that stuff, though.
02:24:35 <mrvn> nyc`: naything with a GC I feel is out. kernel kinds of needs static memory management.
02:41:30 <renopt> just think, if you use my OS you can write drivers in javascript
02:42:28 <renopt> *not included: a js runtime or anything resembling support for a js runtime
02:42:35 <Lowl3v3l> renopt: which leaves two important questions : a.) who would even want to do this? and b.) how do you plan on getting your os out of a mental institution ? :P
02:43:35 <renopt> a) beats writing C, b) a man, a van, a plan
02:44:46 <Lowl3v3l> :D remembers me of Korpiklaani - "A man with a plan"
02:45:50 <aalm> :D
02:50:31 <jmp9_> okay
02:50:34 <jmp9_> that's not working
02:51:04 <jmp9_> bios tells that is my flash stick is a "UEFI: SanDisk"
02:51:38 <mrvn> does it have a 2nd stick/partition?
02:52:06 <jmp9_> no
02:52:14 <jmp9_> everything in 1 partition
02:52:37 <mrvn> some sticks show up as 2 devices/partitions. One of them tiny just for booting.
02:53:40 <jmp9_> https://hastebin.com/uqotelewem
02:53:42 <jmp9_> fdisk
02:54:20 <mrvn> and sdb2? or sdc?
02:54:48 <jmp9_> sdb and sdb1
02:58:31 <nyc`> My next approach is trying to run silo (SPARC lilo) in a qemu userspace emulator. When I get back up I'll give it a shot.
03:08:05 * bcos_ didn't realise bootloaders run in userspace
03:19:05 <ybyourmom> Objection your honour
03:20:42 <nyc`> The boot code doesn't run in userspace, the disk image editor does.
03:22:04 <mrvn> nyc`: userspace emulation only works for linux binaries, not boot stuff
03:22:27 <nyc`> silo has parts to drop things on a disk and parts that run at boot.
03:22:43 <mrvn> like grub and grub-install?
03:22:54 <nyc`> Yes.
03:23:04 <mrvn> that should work then
03:23:17 <nyc`> This would be the part like grub-install.
03:30:00 <knebulae> @renopt: are you the nebulet guy? Nice name bro. That was sweet to see all over reddit ;)
03:31:13 <nyc`> It might make more sense to use an image of a disk that isn't a CD-ROM. Then I could just rely on the filesystem updates from loopback mounts. I still have to run silo on it once, though.
03:34:45 <nyc`> I might be able to find a small disk image with silo already installed on the boot block etc.
03:35:36 <knebulae> @jmp9_: I can put up a 1.44MB floppy with grub on it. I've had an image for years.
03:38:40 <renopt> knebulae: nono not me, I work in the shadows...
03:39:55 <knebulae> @renopt: ok :)
03:40:23 <renopt> ok
03:46:38 <zhiayang> hm, is there any way to detect the presence of msrs, and if not, what happens when you write to a non-existent one?
03:48:34 <mrvn> zhiayang: I think cpuid will tell you and either you get an exception or nothing happens.
03:48:45 <bcos_> If you read or write to a non-existent MSR you get a GPF (so trying it and seeing if you get a GPF is one way to detect them); but beyond that you can determine the CPU's model (CPUID, "family:model:stepping") and figure out which model specific registers the model supports that way
03:48:52 <gaze__> Does geist still hang out here?
03:49:03 <bcos_> gaze__: Yes
03:49:04 <mrvn> yes
03:49:15 <gaze__> yay
03:49:43 <gaze__> good to hear
03:50:08 <zhiayang> bcos_: hm, i see
03:51:00 <bcos_> Of course the majority of MSRs you'll care about are either "architectural" or tied to some other feature (where detecting that feature via. the flags in CPUID is good enough to determine if its MSR is there)
03:51:27 <zhiayang> yah, but i happened to chance upon this: https://forum.osdev.org/viewtopic.php?f=1&t=18945
03:51:37 <zhiayang> and it looks like ia32_misc_enable is not on amd chips
03:54:40 <bcos_> That one isn't even standard on Intel
03:54:44 <zhiayang> gg
03:54:51 <mrvn> what does it even do?
03:55:08 <bcos_> (its existence is standard, but which flags do what is a little model specific)
03:55:19 <zhiayang> there's a apparently a bit inside that disables the nx feature
03:55:30 <bcos_> Intel uses it for things like enabling/disable L3, enabling/disable "fast strings", etc
03:55:39 <mrvn> and why would you want to disable that? WTF?
03:56:10 <zhiayang> no, it might be disabled, and i would want to un-disable it
03:56:17 <bcos_> Should/might be documented in Intel's manuals
03:56:49 <bcos_> (but you'll have to check which CPU models use it and which don't)
03:59:33 <zhiayang> eh, i don't really have any intel-based machines i'm willing to test on
04:02:02 <bcos_> zhiayang: That's makes it a lot easier - you just append a new line to your "todo.txt".. ;-)
04:05:04 <zhiayang> hehe
04:07:21 <Ameisen> hmm
04:07:23 <Ameisen> didn't sleep much
04:07:25 <Ameisen> :(
04:07:36 <Ameisen> I did have some more thoughts on how to handle aliasing in a procedural language, potentially
04:08:26 <Ameisen> mainly strict, default-non-aliased. Don't allow casting of types within a function without either an aliased { } or restrict { } block around the operation(s) to determine semantics.
04:18:34 <knebulae> @Ameisen: interesting. I'm still not sure why we're not relying on larger stores of meta-data we KNOW about the functions (since we're writing them) in order to guide the compiler?
04:18:57 <knebulae> It sucks to type, but imagine being able to instruct your compiler of valid casts right from the get-go.
04:20:11 <knebulae> I think Spark provides some excellent guidance there. We (programmers) are just constantly caught in a battle to reduce typing; one guy can only type so much code.
04:22:18 <nyc`> The pain of dealing with register windowing etc. hasn't even started. I'm going to need some sleep before I try all that.
04:23:10 <knebulae> And a quick test I always use to see if a language's generics implementation is semantically sound is to put together a micro ORM with generics. That activity alone will tell you if the generics of the language will truly provide a bonus over the long term. That's my litmus test anyway.
04:27:17 <knebulae> @Ameisen: this is how andrewrk (and his group) chose to tackle the issue in Zig, which was pleasant: https://ziglang.org/documentation/0.1.1/#type-based-alias-analysis
04:27:53 <andrewrk> knebulae, that is no longer correct - the section is not found in newer documentation
04:28:31 <andrewrk> currently zig has a well defined memory model, and type punning, pointer casting, etc are well defined
04:28:55 <Ameisen> knebulae - because the programmer can (and probably will) write code in a way that makes aliasing ambiguous and impossible to determine effectively
04:29:02 <Ameisen> especially if code talks to outside libraries.
04:29:43 <Ameisen> that documentation, at least, is very similar to C and C++'s strict aliasing rules
04:30:08 <Ameisen> type-based, with the exception of u8 (char */void *), which can perform conversion to and from their own type (but not between types)
04:30:21 <andrewrk> however I plan to experiment with a "nothing is allowed to alias at all, unless you annotate it" rule, with some (in debug builds) runtime verification
04:30:26 <knebulae> @andrewrk: sorry, it's been 2 months ;)
04:30:35 <Ameisen> andrewrk - similar to what I described above?
04:30:49 <Ameisen> explicit aliasing annotations, along with aliasing/non-aliasing blocks when you cast?
04:31:11 <Ameisen> I remember looking at zig.
04:31:14 <andrewrk> Ameisen, yes, something like that. I haven't created a proof of concept yet
04:31:17 <Ameisen> though I also found that it was somewhat weird looking.
04:31:34 <Ameisen> also, wasn't sure why it has 3, 4, 5, 6, and 7-bit integers
04:31:37 <Ameisen> but not 48-bit integers.
04:31:41 <andrewrk> if it's been a while, it probably looks less weird now
04:31:45 <Ameisen> or i2
04:31:48 <andrewrk> and it has all integer types now
04:31:57 <Ameisen> I implemented uint1_t and uint2_t in GCC once
04:32:03 <Ameisen> that was weird.
04:32:33 <Ameisen> pff, you don't have c_longerdouble
04:32:42 <Ameisen> and c_longestdouble
04:32:44 <andrewrk> no way, please tell me that's not a thing
04:32:52 <Ameisen> at which point you'd think they'd be quadruple, octuple, etc
04:33:08 <Ameisen> long long short long double
04:33:13 <andrewrk> zig (and I think C) has 128 bit floats
04:33:34 <Ameisen> GCC has 128-bit floats, but they aren't guaranteed to be octuple-precision.
04:33:35 <knebulae> @andrewrk: does zig support multiple register return?
04:33:41 <Ameisen> Just guaranteed to take up 128-bits, and be 128-bit aligned.
04:34:03 <Ameisen> for x86-32, they'll generally be 80-bit floats but take up 128-bits of space. for x64, they'll be 64-bit floats taking up 128-bits.
04:34:25 <andrewrk> you're describing `long double` yes? I'm talking about __float128
04:34:42 <Ameisen> __builtin_int_t(N) woudl be interesting.
04:34:56 <Ameisen> arbitrary precision types.
04:35:18 <Ameisen> no idea how to implement that on the compiler-side, or the language side
04:35:33 <Ameisen> as neither C nor C++ really support the concept of types as a value.
04:35:42 <andrewrk> knebulae, zig has a few calling conventions available: "unspecified", "C calling convention", "cold", "naked", "stdcall"
04:35:49 <Ameisen> you could wrap it using decltype, though
04:35:58 <andrewrk> the default one is unspecified, which means zig can pass args and return values however it wants to
04:36:53 <andrewrk> if your function returns a struct, and you use the unspecified calling convention, and turn on optimizations, you're probably going to get multiple register return
04:36:55 <Ameisen> andrewrk - just glancing at the source files...
04:36:55 <knebulae> @andrewrk: ok; that was the other thing I really want is better access to calling conventions, even within the same code modules.
04:36:59 <Ameisen> like bigfloat.cpp
04:37:12 <Ameisen> why bigfloat_init_128, bigfloat_init16, bigfloat...
04:37:20 <Ameisen> and not bigfloat_init<T>?
04:37:32 <Ameisen> to give it an entirely consistent interface?
04:38:03 <Ameisen> also curious why it's very... C-style.
04:38:24 <andrewrk> I don't really spend time considering these kinds of questions, about how much of C++ features am I going to use. I just write the code and think about how the code is supposed to work
04:38:32 <Ameisen> bigfloat_init_128(BigFloat *dest, float128_t x) vs a constructor or static member
04:38:42 <andrewrk> I prefer to debug my application rather than debug knowledge of my programming language
04:38:44 <Ameisen> sure, it's just non-idiomatic, and you could reduce duplication.
04:39:05 <knebulae> @Ameisen: most languages are C-style. In fact, not using a C-style is almost a sure-fire way to have no one but programming language wonks use it.
04:39:11 <andrewrk> if I wasn't using LLVM/clang API I wouldn't even be linking libstdc++
04:39:16 <Ameisen> I've found the other approach easier to debug, but I'm used to it.
04:39:39 <Ameisen> why not link libc++ in that case?
04:39:46 <andrewrk> why link it?
04:39:58 <andrewrk> the null hypothesis is to not have stuff you don't need
04:40:04 <Ameisen> knebulae - I'm talking about the implementation-side
04:40:05 <Ameisen> which is C++
04:40:32 <Ameisen> andrewrk - you said you're linking libstdc++ because of LLVM
04:40:33 <knebulae> @Ameisen: sorry
04:40:40 <Ameisen> I'd think if your only dependency is LLVM, you'd link libc++ instead
04:40:54 <andrewrk> Ameisen, right, LLVM depends on it, so I have to link it. what do you mean instead?
04:41:05 <Ameisen> libstdc++ is g++'s stdlib
04:41:11 <Ameisen> libc++ is clang++'s stdlib
04:41:40 <andrewrk> it was not my intention to distinguish between which libc++ to link. just that if I didn't have to, I wouldn't link against any c++ runtime
04:41:47 <Ameisen> libc++, IIRC, is lighterweight, anyways
04:41:55 <andrewrk> I think you're missing my point
04:42:00 <Ameisen> probably.
04:42:19 <Ameisen> Just saying that if you _have_ to link against a c++ runtime, might want to distinguish a preference?
04:42:49 <Ameisen> I know for my MIPS toolchain I wasn't even able to get libstdc++ working.
04:42:53 <Ameisen> so I just went all LLVM lib tere.
04:42:55 <andrewrk> huh? that's not how it works. libc++ is chosen by your compiler. and your compiler is chosen by your dependencies (if you depend on system package manager)
04:43:17 <Ameisen> clang, at least, can specify which runtime and c++ stdlib you want it to use in the command line.
04:43:21 <Ameisen> -stdlib=, -rtlib=
04:43:30 <jmp9> okay
04:43:34 <jmp9> my os works on real hardware
04:43:40 <Ameisen> g++ can do it as well, just a bit messier.
04:43:41 <andrewrk> jmp9, congrats!
04:43:47 <jmp9> the problem is my laptop doesn't want to boot my flash drive
04:43:54 <jmp9> because he's a moron
04:43:58 <andrewrk> oh, I jumped the gun
04:43:59 <jmp9> i tried on another laptop
04:44:00 <Ameisen> jmp9 - my laptop doesn't want to boot my main drive, and it's running Debian!
04:44:01 <jmp9> and it worked
04:44:14 <Ameisen> (aptitude broke it)
04:44:22 <Ameisen> (aptitude and myself, in combination)
04:45:01 <Ameisen> andrewrk - I'm curious what the final binary size and potential differences are between zig linked against libc++ and libstdc++
04:45:21 <andrewrk> knebulae, noted about the calling conventions. if you feel generous with your time, I would invite you to open an issue in zig, explaining how this would benefit your project, and we can take it from there
04:45:28 <Ameisen> I know that libc++ was explicitly designed to be able to be imported as modules, and was designed with LTO in bind.
04:46:06 <andrewrk> Ameisen, my actual point is that I use so little C++ features that I won't even get undefined symbols if I omit the c++ runtime
04:46:49 <Ameisen> andrewrk - your coding style confuses me, but to each their own.
04:46:54 <knebulae> @andrewrk: I will refresh in a little bit on calling conventions in zig so I can make an educated post.
04:47:12 <Ameisen> I presume zig cannot self-host?
04:47:59 <andrewrk> Ameisen, not yet. closest we have is a self-hosted parser and renderer (zig fmt). But self hosted compiler will always depend on LLVM/clang which are in C++. more details: https://github.com/ziglang/zig/issues/853
04:49:12 <knebulae> If purity is not your goal, hitching your language to the llvm project is a very good idea for many practical reasons. What does self-hosting gain, other than a notch on the belt?
04:50:40 <andrewrk> for zig it actually has some practical benefits - described in that issue. in particular building compiler-rt from source, which makes a self-hosted compiler able to be cross compiled on any target
04:51:24 <knebulae> @andrewrk: right, but not having that doesn't in any way limit the effectiveness of zig right now.
04:51:45 <knebulae> @andrewrk: but I understand the points; I've read the docs before.
04:52:00 <nyc`> I could use a language for continuation passing sans RTS.
04:52:33 <andrewrk> nyc`, what does RTS stand for in this context?
04:53:45 <nyc`> Run Time System
05:02:17 <ebrasca> Do you have some recomendations for implementing BTRFS in Mezzano OS?
05:04:09 <knebulae> So I know some of you are redditors, and you don't need articles posted, and that's probably not what you're here for. If that's you, just ignore. But an internal MS analysis found 70% of security vulnerabilities in their products are directly related to memory safety issues in C/C++: https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
05:04:44 <knebulae> Which is right in line with the aliasing discussion / Rust / zig, et. al.
05:06:55 <nyc`> I think kernels have to do unsafe things rather often.
05:07:00 <knebulae> So these new languages are on to something. But the question becomes which one is going to hit that "sweet" spot.
05:07:36 <knebulae> @nyc: I can't think of many things within the confines of a well-designed systems programming language that would be "unsafe"
05:07:47 <knebulae> @nyc: for a kernel, that is.
05:08:39 <knebulae> It's mostly invalid casting and overflow exploits that cause the major problems.
05:09:55 <nyc`> Userspace data access, device memory access, implementing allocators, virtual windowing, etc. are all there.
05:10:17 <knebulae> @Ameisen: I have an inkling that the reddit comments will touch on Rust a time or two: https://old.reddit.com/r/programming/comments/apm5g6/microsoft_70_percent_of_all_security_bugs_are/ But I haven't read them yet.
05:10:37 <nyc`> Userspace data access is probably the top exploit area.
05:10:49 <knebulae> @nyc: right
05:11:26 <Ameisen> knebulae - yes, I already got into arguments there
05:11:54 <Ameisen> what I didn't like is that they were rather insiduous about how they were suddenly accusing me of moving goalposts/claiming to be perfect
05:12:08 <Ameisen> and I don't have high tolerance for things like that at 5 AM or so
05:13:55 <Ameisen> the entire thread pretty rapidly devolved into a self-congratulatory thread about how amazing Rust is.
05:13:56 <nyc`> But you basically have to go fishing through physical memory esp. pagetables, virtually window into it, then with the fresh virtual address derive a precise starting address and decode starting from there etc.
05:15:20 <nyc`> The memory handling safety mechanisms just wouldn't apply.
05:16:11 <Ameisen> nyc` - I have a strong suspicion that many of the Rusticles haven't actually worked at that level.
05:16:36 <Ameisen> I also have a strong suspicion that they haven't used modern versions of C++ or similar.
05:17:34 <nyc`> Ameisen: I think it's a more general issue with trying to use language safety to address kernel exploits.
05:19:48 <nyc`> That is that the precise places where exploits happen involve things that would necessarily need to bypass language safety.
05:19:50 <jmp9> ok
05:19:54 <jmp9> do I need PCI?
05:19:59 <jmp9> implement
05:21:23 <lkurusa> depends on what you're doing
05:22:23 <jmp9> i need to read sectors from disk
05:22:41 <jmp9> and i don't know what I should do
05:22:44 <jmp9> to read sectors
05:23:01 <lkurusa> what disk
05:23:13 <nyc`> I think sparse tries at least to distinguish between user and kernel addresses.
05:23:19 <jmp9> hard drive
05:23:27 <lkurusa> jmp9: SATA, PATA, IDE?
05:23:41 <jmp9> oh yes
05:23:44 <jmp9> thanks
05:23:52 <lkurusa> this isn't userspace programming where you just call read lol
05:24:07 <lkurusa> you need to be aware of what your hdd is and program it accordingly
05:31:36 <mrvn> Ameisen: The memory safety features of c++ are pretty much irelevant as they aren't enforced. You have to work to use them. Rust enforces theirs and THAT is what prevents bugs.
05:31:55 <geist> jmp9: basically depends on the interface
05:32:49 <geist> there are multiple levels of ide interface. the simplest one does not require PCI
05:34:23 <mrvn> Ameisen: e.g. you can use std::shared_ptr, you don't have to. And even if you do nothing stops you from storing a pointer to the object it points to, freeing the shared_ptr and then accessing the deleted object.
05:35:14 <knebulae> @mrvn: I just had a hard time moving from essentially c with oo to having the borrow checker, having explicit lifetimes, traits, function composition, and ZERO forms of inheritance. It's a lot to swallow all at once.
05:36:09 <mrvn> knebulae: nobody said it would be easy. :)
05:36:12 <isaacwoods> I really like Rust, but there's definitely a subset of people who think programs magically become bug-free from using it (even when they use rampant unsafe)
05:36:19 <isaacwoods> Redox is especially bad
05:36:23 <knebulae> @isaacwoods: bingo
05:37:43 <mrvn> isaacwoods: I use ocaml. That basically takes care of all segfaults, they simply can't happen (unless you call C functions through the FFI interface and screw that up). Still plenty of bugs left in the code.
05:37:47 <knebulae> Making blanket statements about Rust's safety without a laundry list of caveats tells me some of them don't actually understand the issues they think they are protected from.
05:39:01 <knebulae> Hell, I don't think *I* understand some of them.
05:39:16 <isaacwoods> mrvn: same with safe rust - problem is when people think it prevents logic bugs
05:40:00 <mrvn> on the other hand the same logic bugs you have in C/C++ too. So you aren't worse off.
05:40:55 <knebulae> @mrvn: they require a substantial investment in their "community," whatever the hell that means. To me, it's a liability for future development in Rust, period. I don't care how great its ideas are.
05:41:40 <isaacwoods> and I would say logic bugs are harder because of better ergonomics (its easier to see stuff when string concat is `a + b` rather than `malloc, strcpy, strcat`)
05:41:42 <knebulae> too easy to sway the lemmings
05:41:53 <nyc`> I love using the fully functorial style in ocaml. I wish other languages would adopt similar module systems.
05:43:19 <nyc`> Bolting an ML-like module system onto a kernel-suitable language like C would be fantastic.
05:43:31 <mrvn> It's too bad that ocamls data structures don't lend themself for kernels. You don't want to allocate a block of memory for an int in kernel space.
05:44:43 <mrvn> And for inlined data structures you would need something that's a pointer to the main struct + offset to the member being parsed around.
05:45:01 <mrvn> or lending and borrowing like rust.
05:45:02 <nyc`> Module systems have no runtime overhead except maybe for making it easier to have a larger amount of generated code.
05:45:41 <mrvn> nyc`: do you mean plain module = struct ... end or first class modules?
05:45:58 <mrvn> The former is just c++ namespaces.
05:46:45 <nyc`> mrvn: Higher-order modules (first class starts bordering on OOP).
05:46:51 <mrvn> functors are basically templates and first class modules you sort of do with classes
05:47:40 <mrvn> first class modules is more like passing OO in C where you pass a struct with data and function pointers around.
05:48:01 <nyc`> C++ can do functors parametrized by types and values.
05:48:38 <nyc`> A little less structured, but you can simulate it.
05:48:45 <mrvn> nyc`: so can ocaml because both are part of the module signature
05:49:13 <nyc`> Well, ocaml's module system is what I would actually want.
05:49:45 <mrvn> nyc`: I think you pretty much have it in C++. One thing that doesn't map between the two are recursive modules.
05:51:22 <mrvn> There are some cases in C++ where you can't pre-declare a class A then use that in the declaration of class B and last use class B in the declaration of class A.
05:51:26 <nyc`> mrvn: I think you're stuck using objects/classes to simulate modules at the cost of useless data / empty records
05:52:21 <mrvn> nyc`: a first class module is nothing else. It's just syntactic suggar hiding the (empty) struct from you.
05:53:16 <nyc`> mrvn: I think there are also module system examples where it's unclear which of several types a module's function would transform to a method of.
05:54:12 <mrvn> nyc`: in ocaml there can't be several types. It's always exactly one type, which may be polymorphic but then it always is.
05:55:26 <nyc`> mrvn: They can simulate each other but they're conceptually distinct ways to structure programs. Hence why ocaml actually implements both OOP objects and higher-order modules.
05:56:24 <nyc`> mrvn: I meant which of several types in a module before it's transformed to an OOP equivalent.
05:56:25 <mrvn> nyc`: ocamls OOP is always a runtime lookup of method calls. It's noticably slower than higher order modules or functors.
05:57:11 <nyc`> mrvn: Well, it's supposed to be prepared to vary dynamically from object to object.
05:57:57 <mrvn> nyc`: it's a hash table.
05:58:27 <mrvn> With modules I think it's a struct with fixed offsets.
05:59:28 <nyc`> mrvn: I'm not really tuned in to the OOP wavelength, so I really want it to be a module system.
06:00:25 <mrvn> nyc`: I more missing the variant types.
06:01:22 <mrvn> And matching those over multiple levels
06:01:23 <nyc`> Variant types need runtime support from tags and the like. I love them in userspace, though.
06:01:51 <mrvn> nyc`: enum + union in C/C++. except matching is not easy.
06:02:06 <dminuoso> nyc`: Why do you need runtime support?
06:02:10 <nyc`> Modules can be brought into the kernel whole hog because there's zero runtime impact.
06:02:30 <nyc`> dminuoso: For which part?
06:02:46 <Ameisen> I'm also investigating if it's possible to have pointer-types and GC-handle types in the same environment, mainly if they can be passed universally in some way
06:02:59 <Ameisen> without extracting a pointer from a GC-handle type, or requiring boxing of pointer-types
06:03:06 <nyc`> dminuoso: Variants make demands on the data layout.
06:03:19 <mrvn> Ameisen: what's a pointer type and what's a GC-handle type?
06:03:42 <mrvn> nyc`: enum + union. not realy rocket science.
06:03:50 <Ameisen> pointer being a pointer to memory that was manually allocated (and thus released), a handle being a handle you got from a garbage-collected memory system.
06:04:11 <Ameisen> hard to interchange the two with most functions
06:04:16 <mrvn> Ameisen: you mean like a pointer and a Node in C++?
06:04:36 <Ameisen> sorta.
06:04:48 <Ameisen> Something like a node would be a 'universal' passing mechanism, but adds indirection overhead
06:04:49 <mrvn> Ameisen: just template them and both support operator()
06:04:51 <mrvn> ->
06:04:52 <nyc`> mrvn: See struct page in Linux.
06:04:53 <mrvn> *
06:06:22 <nyc`> mrvn: Bitflags sometimes not even adjacent to the unions determine which union members to use.
06:07:12 <Ameisen> could make the parameters autogenerate templates for handles and pointers, but that could lead to code bloat
06:08:09 <mrvn> Ameisen: i don't see a problem there at all. You simply add template <typename T> and your function already does everything you want.
06:11:21 <Ameisen> the more arguments you have, the more template parameters you potentially need to handle all of the permutations
06:11:23 <Ameisen> can add up
06:11:39 <Ameisen> though I suppose if your handles themselves are stored in a constrained bit of memory, the indirection isn't too expensive
06:11:57 <Ameisen> especially if you can make a guarantee that the handles would always be in the lower 32-bit memory range.
06:12:08 <nyc`> I think there are standard C library functions that take pointers to unions as some parameters whose interpretation is controlled by other parameters, so the tags are exposed in ways unfaithful to ML variants.
06:12:50 <geist> i'm going blank, what do you mean by 'ML' in this case?
06:13:08 <nyc`> I've seen people cram tag bits into all sorts of weird places by hand.
06:13:57 <nyc`> geist: It's an advanced programming language or family thereof. Meta Language not machine language.
06:14:31 <geist> ah, meta language
06:14:45 <geist> ML around work is generally machine learning, but that's obviously not here
06:15:10 <nyc`> I think there's a trick to encode red-black tree bits in the order of the children.
06:15:54 <nyc`> geist: A very small number of people have been crazy enough to write kernels in it.
06:17:04 <geist> yah, theres usually a few
06:18:15 <cormet_> hello
06:18:31 <Ameisen> Write a kernel in Apache Jelly
06:18:36 <Ameisen> https://en.wikipedia.org/wiki/Apache_Jelly
06:19:19 <geist> cormet_: hi
06:19:26 <nyc`> I was just pooh-poohing the idea of borrowing a runtime language construct from ML (variants, basically prepackaged discriminated unions) in a systems programming language. I've been singing the praises of the ML module system, though.
06:19:26 <cormet_> I have a question about this patch https://patchwork.kernel.org/patch/1046072/ at bottom there is: - cache_is_vipt_nonaliasing() ? "VIPT nonaliasing" : "unknown", + cache_is_vipt_nonaliasing() ? "PIPT / VIPT nonaliasing" : "unknown",
06:19:44 <cormet_> it means that PIPT is the same as VIPT non aliasing?
06:22:29 <nyc`> FWIW I'm not up to write my own systems programming language compiler, so grain of salt and all.
06:22:29 <mrvn> Ameisen: the compiler instantiates every variant. Can be exponential.
06:23:00 <mrvn> Ameisen: on the other hand it can't be more variants that invocations. So it's O(1) too
06:23:57 <geist> cormet_: from the point of view of software, yes
06:24:07 <geist> most L1 caches on modern machines, for exmaple, are VIPT
06:24:40 <geist> differently put a non aliasing VIPT acts as if it were PIPT from a coherency point of view
06:24:45 <cormet_> what do you mean with software point of view?
06:25:05 <geist> as in there's no real special software requirement to deal with aliasing issues
06:25:13 <cormet_> ah ok
06:25:18 <mrvn> nyc`: ocaml works verry well with witness types.
06:25:59 <mrvn> nyc`: even goes so far that you have the bits for the union crammed into one argument and that garantees that the other 4 will all be that type.
06:26:17 <mrvn> nyc`: and the return type is therefore that other type
06:27:58 <nyc`> mrvn: Don't get me wrong, I love ocaml, I just don't think the language features beyond the module system are easy to deal with in the kernel.
06:28:29 <mrvn> Only thing that's problematic is the GC and indirections in the memory model for data types.
06:29:46 <mrvn> nyc`: I've thought long in the past on how to get around the GC and allocations but a lot of functional stuff you simply can't do without dynamic allocations that would be unsuitable for most of the kernel.
06:31:22 <nyc`> mrvn: Oh for sure.
06:31:52 <mrvn> I would love to have ocamls type system in an imperative language and C like data structures.
06:32:10 <nyc`> mrvn: I think there could be a serious role for GC as more scalable than recounting.
06:32:49 <mrvn> nyc`: you can use the GC for caches
06:33:18 <nyc`> mrvn: I would have uses for a language like that too.
06:34:16 <mrvn> nyc`: I've been playing with the idea of using ocaml in a microkernel. The kernel itself would be mostly C but for each driver you start an ocaml instance.
06:34:45 <nyc`> mrvn: Slab caches are where I would want to use GC most immediately.
06:35:19 <nyc`> mrvn: That would be pretty cool.
06:35:35 <mrvn> and with 10-100 ocaml instances the GC would parallize nicely too.
06:36:46 <nyc`> I'm still trying to get some sleep so I can do battle with SPARC emulators again.
06:37:54 <mrvn> nyc`: last time I played with that notion someone was working of modifying ocaml so you could start multiple instances, one per core. Removing all the global state into a struct so the instance you have a pointer to it. But since them I considered simply creating true processes for each ocaml instance. With their own memory and all. True microkernel way.
07:36:04 <mobile_c_> https://stackoverflow.com/questions/54651841/during-dynamic-linking-loading-how-is-the-base-address-obtained
07:44:31 <geist> mobile_c_: what are you actually trying to *do*?
07:44:39 <geist> you have been on this for as far as i can tell months
07:44:40 <geist> what is it?
07:45:45 <geist> this question is confusing and complicated
07:45:59 <geist> the statement is one thing but then it goes off and tries to describe some complicated situation
07:46:24 <geist> the answer to 'how does it figure out the base address' is 'it decides based on whatever the policy is of the system'
07:46:40 <geist> as in, maybe it picks a random address, maybe it puts it in a section of the address space where it's supposed to, maybe it packs it in with the last one
07:46:58 <geist> depends. there's no hard rule about it. it can simply pick anywhere as long as there's enough space in the address space for it
07:48:06 <geist> you should in principle just be able to pick any address as long as it fits
07:48:20 <geist> (modulo any limitations in the architecture)
07:54:43 <geist> mobile_c_: but i guess you're not really here, you were just fishing for more responses on your stackoverflow?
07:54:47 <geist> please dont do that
08:24:10 <rajasrijan> Where's @Love4Boobies at?
08:35:05 <geist> Mutabah is their name now
08:35:05 * Mutabah is away (Sleep)
08:35:22 <geist> i think, or maybe that's tpg
08:35:42 <FireFly> the latter
08:48:17 <knebulae> uh oh, someone butthurt over the rust thread has taken to medium.
08:48:27 <knebulae> o_O
08:48:39 <gaze__> sup geist?
08:49:41 <knebulae> I'll save the reddit drama: https://medium.com/@sgrif/no-the-problem-isnt-bad-coders-ed4347810270
08:51:24 <gaze__> I agree with the article... the opposing viewpoint to it reminds me of this dude with a fixie I met that swore his bike was safer without brakes
08:54:54 <cormet_> this Rust circle j*rk.
08:55:28 <sortie> Hello
09:05:12 <knebulae> actually not a bad article
11:06:01 <knebulae> so stupid Q here, but is all I have to do to use C++ in kernel avoid exceptions, turn off rtti, and provide a new and delete function? I mean, no stdlib of course.
11:06:38 <knebulae> Because it seems like neither clang nor ms-link have any problems with c++
11:07:05 <knebulae> Just complaining of the aforementioned undefined symbols
11:09:38 <Mutabah> pretty much
11:10:04 <knebulae> @Mutabah: thanks
11:19:31 <Ameisen> hrmm
11:19:51 <Ameisen> Also working out if it's necessary to have a pointer type _and_ a reference type (I'm working on my own language and have been for some time)
11:20:11 <Ameisen> because doing that, I'm going to end up with pointers, references, handles, and universal references
11:20:17 <Ameisen> which... is a lot to keep track of.
11:20:53 <Ameisen> I'm wondering if in the vast majority of programs, 'pointers' can be replaced by a language construction, like a mutable reference.
11:21:14 <Ameisen> which would also dissuade pointers from being used, I'd think
11:29:31 <knebulae> "function previously declared with an explicit exception specification redeclared with an implicit exception specification" - I'm assuming this is because operators new and delete are supposed to be delcared cdecl, but for some reason, clang doesn't like __cdecl?
11:30:45 <knebulae> i.e. it gives syntax error on __cdecl
11:49:32 <nyc`> I think you can actually use exceptions and RTTI but have to write runtime system code to use them.
11:54:44 <nyc`> I have no idea about the specifics.
11:59:52 <eryjus> is ARM like x86 in that if the page for the next instruction after enabling the MMU is not properly mapped, it will fault? Or will it take the insturction out of cache and not fault until a few instructions down?