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=5&d=14
01:54:00 <wxwisiasdf> hello
01:54:00 <vdamewood> Olleh
01:55:00 <wxwisiasdf> i am making an os :D
01:55:00 <vdamewood> I'm sorry to hear that.
01:55:00 <wxwisiasdf> and i am doing tcp/ip thing
01:55:00 <vdamewood> I'm sorry to hear that, too.
01:55:00 <wxwisiasdf> heh
01:56:00 <Griwes> yeah, that's very unfortunate
01:56:00 <wxwisiasdf> :^)
01:56:00 <vdamewood> We've all been down that road, too. We understand your pain.
01:56:00 <Griwes> especially since now you'll have to interact with things that are probably just barely rfc compliant
01:56:00 <wxwisiasdf> no it's actually going pretty smooth
01:57:00 <Griwes> the internet is held together with enormous amounts of tape
01:57:00 <vdamewood> Even sandpaper feels smooth when you're too drunk to tell the difference.
01:57:00 <kazinsal> BGP is the most fascinating nightmare circus
01:57:00 <wxwisiasdf> i'm implementing some ssl ciphers and things and i already got some arp stuff
01:57:00 <Griwes> ...you are rolling your own crypto? my condolences
01:57:00 <kazinsal> my sympathies to your users
01:57:00 <wxwisiasdf> lol
01:58:00 <Griwes> we're very cheerful tonight
01:58:00 <vdamewood> Okay, We're joking about the condolences and such for osdev, but not for crypto dev.
01:58:00 <wxwisiasdf> most insecure crypto challenge :^)
01:58:00 <kazinsal> yeah I'm rolling as much of my own stuff as possible but there's no way in hell I'd roll my own crypto
01:58:00 <wxwisiasdf> bet my xtea implementation ain't that secure
01:58:00 <wxwisiasdf> but hey it's a hobby os
01:58:00 <vdamewood> That's what Linus said
01:59:00 <wxwisiasdf> but linus isn't coding a mainframe os
01:59:00 <wxwisiasdf> checkmate.
01:59:00 <Griwes> yeah crypto and libm are huge no-nos for me
01:59:00 <vdamewood> Linux has shown that "It's just a hobby" always has the possibility to be false.
01:59:00 <vdamewood> wxwisiasdf: Yes he is.
01:59:00 <Griwes> not touching those with a ten foot pole
01:59:00 <wxwisiasdf> oh no
01:59:00 <kazinsal> yeah math is the other one
01:59:00 <vdamewood> Griwes: Really, libm?
01:59:00 <kazinsal> I'm bad at math. no way do I want anyone to use math code I've written
02:00:00 * Griwes ruminates about ten foot Poles
02:00:00 <wxwisiasdf> Griwes: i implement sqrt with babylonian method :p
02:00:00 <kazinsal> no way do *I* want to use math code I've written
02:00:00 <Griwes> vdamewood, I mean there's a reason why there is essentially A Single libm Implementation in the world
02:00:00 <wxwisiasdf> i dont have a full blown libc and libm
02:00:00 <wxwisiasdf> but i do have the basics like fopen, fclose, cosf, tanf, modf, abort, signal, etc
02:01:00 <vdamewood> Griwes: Well, on macOS and MSBV libm is integrated into the standard lib.
02:01:00 <vdamewood> MSVC
02:01:00 <vdamewood> I will consider my standard lib complete once it has memcpy and puts
02:01:00 <Griwes> but if you trace it back through the source code history, you'll find it's the same code base
02:02:00 <vdamewood> Griwes: O really? Is it from 4.4BSD or somewhere else?
02:02:00 <Griwes> something like that yeah
02:02:00 <Griwes> I don't think there's a widely used libm that doesn't have direct roots in the bsd libm
02:03:00 <vdamewood> Whatever floats your point.
02:03:00 <vdamewood> Well, fascinating. I'll have to look into that, then.
02:04:00 <vdamewood> Would I be totally masochistic if I planned on implementing my C lib in assembly for each CPU?
02:04:00 <Griwes> yes
02:04:00 <wxwisiasdf> yees
02:04:00 <vdamewood> Excellent.
02:04:00 <wxwisiasdf> but you know what would be worse? implementing your own C lib that works on every os, in asm
02:05:00 <wxwisiasdf> [every os = linux,bsd,win,mac]
02:05:00 <kazinsal> I have a few optimized assembly libc routines but most of it is in C
02:05:00 <wxwisiasdf> well my libc is unsurprisingly all written in C
02:05:00 <vdamewood> wxwisiasdf: You might want to specify which BSD(s) since there are way more than the big 3 now.
02:05:00 <wxwisiasdf> vdamewood: the best bsd ever, dragonfly bsd
02:05:00 <kazinsal> the other BSDs are all derivative of the big three
02:05:00 <vdamewood> wxwisiasdf: When I tried dragonfly BSD it wouldn't let me use a secure password, so I dropped it.
02:06:00 <wxwisiasdf> best bsd move
02:06:00 <kazinsal> which are all conveniently derivative of 386BSD
02:06:00 <vdamewood> kazinsal: Even one of the big 3 is a derrivative of one of the others.
02:06:00 <vdamewood> (OpenBSD was forked from NetBSD)
02:06:00 <wxwisiasdf> and wasn't netbsd forked from freebsd?
02:06:00 <kazinsal> yeah I used to have a neat "BSD family tree" graphic around here somewhere
02:06:00 <vdamewood> Nope. NetBSD and FreeBSD were developed independently of each other at first.
02:07:00 <wxwisiasdf> ah ok
02:07:00 <wxwisiasdf> i assume the freebsd are the at&t guys right
02:07:00 <wxwisiasdf> and the netbsd where idk, some michigan ppl?
02:07:00 <vdamewood> BSD isn't an AT&T thing
02:07:00 <wxwisiasdf> oh
02:07:00 <kazinsal> FreeBSD was the result of maintainers of a patchset for 386BSD becoming disgruntled with the 386BSD developers' release schedule
02:07:00 <klange> this one is neat https://eylenburg.github.io/os_familytree.htm
02:07:00 <bslsk05> eylenburg.github.io: Operating Systems: Timeline and Family Tree
02:08:00 <klange> might be biased because in the sea of disconnected OSes ToaruOS is in there :)
02:08:00 <vdamewood> Both NetSD and FreeBSD are based on 386BSD and rebased on 4.4BSDLite
02:08:00 <kazinsal> NetBSD was the result of a different set of 386BSD users going "what if we made one grand unified BSD instead"
02:08:00 <wxwisiasdf> unics :D
02:08:00 <klange> (with a start year of 2017, which isn't really accurate, that's just when I finally bothered to release a "1.0")
02:08:00 <Griwes> > MEPIS
02:08:00 * Griwes tries to not make a MEPIS joke
02:08:00 <vdamewood> Also, the reason different BSDs exist is beause UCB discontinued the project.
02:09:00 <wxwisiasdf> no way
02:09:00 <wxwisiasdf> you have IBM mainframe os family tree?
02:10:00 <klange> disappointed there's no branch for PonyOS, I should submit a pull request!
02:10:00 <wxwisiasdf> sudden realization robotron took the name UDOS first, and my OS being named UDOS :u
02:10:00 <Griwes> oh, qnx is fully just it's own thing? interesting
02:10:00 <vdamewood> OpenBSD was the result of Theo de Raadt going "We;ll make our own BSD with blackjack and hookers!"
02:11:00 <kazinsal> hrm. I should submit a correction there. Data ONTAP is currently FreeBSD based but it's listed as spontaneously appearing in 1991
02:11:00 <kazinsal> (alternatively, a more accurate description of its family tree is "classic Data ONTAP no longer exists, and Clustered Mode Data ONTAP is a FreeBSD-based operating system)
02:12:00 <wxwisiasdf> i should probably rename my OS into something more proper :p
02:12:00 <vdamewood> Hmm... Now I want to try to figure out an inappropriate name for my OS.
02:12:00 <vdamewood> Is Poo OS taken?
02:12:00 <vdamewood> I could claim it's named after my favorite Earthbound character.
02:16:00 <kazinsal> oh wow. didn't know there was a new patch for 2.11BSD this year
02:16:00 <kazinsal> that's impressive
02:17:00 <vdamewood> There is?
02:17:00 <kazinsal> https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/473
02:17:00 <bslsk05> www.tuhs.org <no title>
02:17:00 <vdamewood> That means my CSRG Archive CD set is obsolete now.
02:17:00 <Griwes> hmm, in a completely different topic: did qemu 7 change how memory is allocated?
02:18:00 <kazinsal> looks like there was a biiiig patch in 2020 that made the 2.11BSD system mostly ANSI C compatible
02:18:00 <wxwisiasdf> wait did they release qemu7 already???
02:19:00 <kazinsal> yeah, about a month ago I think
02:19:00 <Griwes> I'm seeing my OS just hang there when it's reading the memory map, and I'm suspecting it's because it touches every 2MiB of physical memory once to build a "linked list" of free frames
02:19:00 <vdamewood> Was 2.11 based on 4.2, 4.3, or 4.4?
02:19:00 <kazinsal> 2.11 is a continuation of 2BSD for the PDP-11
02:19:00 <vdamewood> Right, but later 2.x contains backported code form 3 and 4.x
02:19:00 <Griwes> and the only reason I can see is that qemu must've changed something about memory allocation and doing what I've been doig
02:19:00 <vdamewood> s/form/from/
02:19:00 <Griwes> doing* is much more expensive now?
02:19:00 <kazinsal> I think it's 4.1something
02:21:00 <vdamewood> 4.1town-in-nevada
02:21:00 <Griwes> I was *right*
02:21:00 <Griwes> -mem-prealloc makes it not spend seconds in pmm init
02:22:00 <kazinsal> interesting
02:22:00 <kazinsal> good catch
02:22:00 <vdamewood> Good catch is great to hear, unless its a hand grenade
02:22:00 <Griwes> don't worry, I counted to 3 so I'm safe
02:23:00 <vdamewood> Not to 4? Not to 2, except to proceed to 3? Was 5 right out?
02:23:00 <Griwes> yes, 5 was right out
02:25:00 <vdamewood> That's that Berkeley said when numbering the versions of BSD.
02:25:00 <vdamewood> s/that/what/
02:25:00 <kazinsal> 4.1BSD would have been called 5BSD but AT&T was about to unleash System V on the world and shit a brick
02:26:00 <vdamewood> Yeop
02:26:00 <vdamewood> Yep
02:26:00 <vdamewood> So, I guess it's what AT&T said.
02:27:00 <Griwes> the weird thing is that quick googling doesn't reveal a recent change in prealloc behavior...
02:52:00 <geist> right there was a #BSD
02:52:00 <geist> 3BSD
02:53:00 <geist> i think 2.11 is a recent thing, based on the 2.x version explicitly because it's for old hardware that had been removed in later versions
02:53:00 <geist> yah what kazinsal said
03:38:00 <energizer> i heard of some new networking api that's an alternative to bsd sockets but i can't remember what it's called. any ideas?
03:46:00 <vdamewood> energizer: winsock?
03:50:00 <kazinsal> winsock is just berkeley sockets for windows
03:51:00 <vdamewood> It is. But I've experienced too many people thinking that something is completely different just because it has a different name.
03:52:00 <kazinsal> SVR3 and SVR4 had STREAMS TLI but I would hardly call a networking API from 1987 "new"
03:55:00 <energizer> i should give up this search because all i know is it had a one syllable name
03:56:00 <wxwisiasdf> i will just throw my socket and make it seem like a file
03:56:00 <energizer> i cant even remember where i heard it from :\
04:23:00 <kazinsal> I should write down a to-do list and order of operations for things I want to accomplish this weekend in the realm of osdev
04:23:00 <kazinsal> maybe if I actually put something down "on paper" I'll be able to stick to it
04:25:00 <kazinsal> (should also write down "ask doctor about ADHD diagnosis" on a to-do list, hrm)
05:12:00 <sikkiladho> "b.gt label" in ARM64 means "branch if greater than" but what registers does it use for comparison? do they use some flags? I read the docs for b.{cond} and I still have this confusion.
05:47:00 <kazinsal> sikkiladho: conditional branch instructions in most architectures (arm included) use condition flag bits in a condition register. iirc in arm it's the top four or five bits of the status register
05:48:00 <sikkiladho> Thank you!
05:49:00 <kazinsal> my arm knowledge is pretty minimal but that's a good general assumption for a lot of architectures
05:49:00 <sikkiladho> I'll look into the condition register and see if it's related.
05:49:00 <geist> thats right, arm is a condition register based arch
05:49:00 <geist> so it's based on whatever the previous operation was that modified the condition flags
05:50:00 <geist> pretty standard NZVC (negative, zero, overflow, carry) flag set
05:54:00 <sikkiladho> yeah got that! thanks.
06:26:00 <geist> a good modern counter example to that is risc-v which has no condition flags
06:27:00 <geist> so the conditional branches are all based on comparing two registers to each other, and based on the result branching
06:27:00 <gamozo> risc-v <3
06:28:00 <geist> downside of that approach is you limit the amount of immediate offset you have, since you burn 10 bits of instruction to encode two 5 bit register fields
06:28:00 <geist> so it's a tradeoff
06:28:00 <moon-child> aiui the issue with condition registers is false dependencies. But, as with most 'cisc problems', it seems to be solvable in practice by throwing silicon and logic at the problem
06:29:00 <geist> right, condition registers can be register renamed just like any other ones, so the cpu is already aliasing them like crazy
06:29:00 <geist> arm is a bit nicer than x86 since you can in many cases choose if an instruction writes back to the condition register or not
06:38:00 <Griwes> I really like how PTX does it, but PTX can do it the way it does it because it's a virtual ISA with infinite registers
06:39:00 <Griwes> you declare virtual "predicate" registers that you can then use as explicit arguments to comparison ops and others, and you can specify them as branch conditions
06:40:00 <Griwes> ...sorry, I lied a bit, *all* instructions can have a predicate specified that controls if they run
06:43:00 <Griwes> (on the other hand that's how you end up with a binary called 'ptxas' that is actually... an optimizing compiler)
07:07:00 <sikkiladho> Hi geist, you are setting 6:9 bits before returning to EL1, here: https://github.com/littlekernel/lk/blob/bce9599d807ac5142e1b380b9dcf371bd995f0d0/arch/arm64/asm.S#L101 what does it do?
07:07:00 <bslsk05> github.com: lk/asm.S at bce9599d807ac5142e1b380b9dcf371bd995f0d0 · littlekernel/lk · GitHub
07:08:00 <sikkiladho> by reading docs, it says these are irq,fiq,serror and debug exceptions masks.
07:08:00 <sikkiladho> but what does they do?
07:08:00 <geist> that's exactlyright
07:08:00 <geist> all three of those mask those type of interrupts from firing
07:09:00 <geist> so it's making sure when it drops to EL1 (from EL2 or above) that they continue to be masked
07:09:00 <geist> since this is early boot, it keeps that stuff masked off until later
07:09:00 <geist> since each EL level has it's own set of those masks. you could drop from EL2 with them masked to EL1 with them enabled, for example
07:09:00 <geist> and it would instantly fire
07:09:00 <geist> (if something was pending)
07:11:00 <sikkiladho> masking means it stops these exceptions from firing?
07:11:00 <geist> correct
07:12:00 <sikkiladho> got it!
07:12:00 <geist> in x86 this is like cli/sti except it's 4 bits for 4 types of exceptions
07:12:00 <geist> and this code is setting it up before eretting to a lower exception level, so that when it arrives things are still masked off
07:14:00 <sikkiladho> I've started learning systems with arm64 so I don't know much about the devel x86 except for userspace x86 with irvine library XD.
07:14:00 <geist> okay
07:16:00 <kazinsal> honestly these days I wonder if that's actually a good thing to get people into osdev
07:16:00 <kazinsal> less weird CISC and legacy 70s/80s crap for people to footgun themselves with
07:18:00 <kazinsal> "ls: not found" ahhh, I love the user-hostility of install disks for 90s unixes
07:19:00 <geist> ugh fighting newlib. about to give up
07:19:00 <geist> trying to return an error from open() and drilling through the layers
07:20:00 <geist> -1 is not sufficient, it also wants errno to be set to something nonzero
07:20:00 <geist> like, cripes.
07:40:00 <geist> ah found it out, was chopping off results from the syscalls on riscv64 because i had written it like rv32 and tried to split a 64bit result code across two regs
07:47:00 <moon-child> Griwes: so ... it's not actually an architecture
07:49:00 <Griwes> it's a virtual ISA
10:09:00 <mrvn> On risc-v conditionals are based on comparing 2 registers? Not just comparing 1 register against 0?
10:09:00 <GeDaMo> MIPS has that too
10:10:00 <GeDaMo> Something like beq r2, r3, target
10:11:00 <mrvn> kazinsal: echo *
10:12:00 <mrvn> alpha uses just one register for conditional. So you have to sub r0, r1, r2 yourself.
10:17:00 <mrvn> https://godbolt.org/z/o5Y6evv33 How can sizeof(Original) differ between compilers?
10:17:00 <bslsk05> godbolt.org: Compiler Explorer
10:18:00 <GeDaMo> Packing?
10:20:00 <mrvn> How do I tell clang to compile for the windows ABI?
10:21:00 <GeDaMo> Cross compiler?
10:22:00 <mrvn> clang is a cross compiler for everything
10:22:00 <GeDaMo> Maybe -target i686-pc-win32 https://stackoverflow.com/questions/23248989/clang-c-cross-compiler-generating-windows-executable-from-mac-os-x
10:22:00 <bslsk05> stackoverflow.com: Clang C++ Cross Compiler - Generating Windows Executable from Mac OS X - Stack Overflow
10:23:00 <mrvn> fatal error: 'cstdlib' file not found :( Seems compiler explorer doesn't have it all
11:40:00 <mrvn> It's interesting that i686-pc-win32 has a size 12 for the class while sysv abi has size 8. Except when you make everything public so it's an aggregate. Then they all have size 12.
12:59:00 <mrvn> You know what all Star Trek ships could really use? Seat belts.
13:04:00 <klange> they just need to upgrade the interntial dampeners
13:04:00 <klange> intertial, whatever
13:07:00 * kingoffrance queues clerks monologue Do you think the average stormtrooper knows how to install a toilet main?
13:25:00 <heat> klange, my OS is also there even though I've never released a 1.0 :V
13:30:00 <mrvn> kingoffrance: so do the contractors deserve to die or are they innocient?
13:31:00 <mrvn> Personally I don't think the contractors had a choice. They werent hired to build the death star, they were conscripted.
13:57:00 <kingoffrance> i dont know, im just wondering if that would explain star trek as well. either they were in a hurry, and hired bad contractors, or they should've hired contractors and didn't
14:39:00 <jjuran> Neither of my OSes is in the list :-(
14:53:00 <GeDaMo> In the first Star Trek movie (or at least the novelization), there was a restraining device on the Captain's chair
14:57:00 <GeDaMo> "a safety restraint mechanism that allowed the armrests to hold down the occupant during turbulence and red alert." https://memory-alpha.fandom.com/wiki/Captain%27s_chair
14:57:00 <bslsk05> memory-alpha.fandom.com: Captain's chair | Memory Alpha | Fandom
15:01:00 <wxwisiasdf> red alert...
15:56:00 <mrvn> we come in peace, shoot to kill
15:58:00 <GeDaMo> Klingons off the starboard bow :P
15:58:00 <GeDaMo> https://www.youtube.com/watch?v=FCARADb9asE
15:58:00 <bslsk05> 'The Firm - Star Trekkin'' by roopert (00:03:33)
15:58:00 <mrvn> it's life, but not as we know it
16:00:00 <jimbzy> Howdy!
16:00:00 <heat> howd
16:02:00 <jimbzy> How are you doing, heat?
16:03:00 <heat> fine
16:03:00 <heat> its very warm and i'm not getting any osdev done
16:03:00 <heat> currently bored implementing a circular buffer for my tracing thing
16:04:00 <heat> and you?
16:05:00 <mrvn> with MMU support or without?
16:06:00 <heat> without
16:06:00 <heat> the awkward part is that all these tracing records have variable length
16:06:00 <heat> it's not just a simple ringbuffer
16:06:00 <jimbzy> I'm just reading about the 65816. It's a beast.
16:07:00 <mrvn> that makes it complicated to do "% size"
16:07:00 <mrvn> Have to insert a dummy record whenever the next record doesn't fit in the remaining sace of the ring buffer before warparound.
16:07:00 <heat> mrvn, yup, so circular buffer of bytes it is
16:08:00 <heat> and that too
16:08:00 <mrvn> That's really the use case that calls for MMU support (or mmap in userspace)
16:08:00 <mrvn> Map the buffer twice then record can warp around the end to the start.
16:10:00 <mrvn> It's the time of the day again when the sun shines on my monitor.
16:11:00 <heat> yup, possibly
16:11:00 <heat> all I want is a tracing system that I can pipe into the host (probably through networking)
16:12:00 <heat> i tried building GNU hello but I keep hitting a weird bug
16:12:00 <mrvn> do you have to fix the alignment or endianness?
16:12:00 <heat> felt like a tracing system that I could pipe into chrome would work fine
16:12:00 <heat> no?
16:13:00 <heat> i mean, i packed the structures, and i'l pipe it to the host in json form
16:13:00 <mrvn> so the ring buffer is actually just the json string?
16:13:00 <heat> no
16:14:00 <heat> this is for the kernel, still raw bytes
16:14:00 <heat> my idea is to have a userspace program get the ktrace records, serialize them in chrome trace viewer format and send them through the network
16:14:00 <mrvn> if it's packed then you have to read/write it byte-by-byte so doing the warp around is kind of trivial.
16:15:00 <jjuran> Sulu, go to warparound
16:16:00 <mrvn> no sure why you would pack it just to json it in the next step though.
16:17:00 <mrvn> heat: shouldn't the user space provide a bunch of buffers to the kernel for trace output and then wait for a buffer to be filled and returned in a loop?
16:18:00 <heat> i want to compact ktrace records to not waste space
16:18:00 <heat> yes, that's the design
16:18:00 <mrvn> So no ring there. just buffers. And the userspace has to re-add buffers once it has processed them.
16:19:00 <heat> traditionally, this is done in a ring buffer
16:20:00 <mrvn> With a ring buffer the userspace would supply one buffer only and then the kernel sends events how many records to read. The user space would track the position in the ring buffer internally.
16:20:00 <mrvn> shared memory between user space and kernel.
16:21:00 <heat> for now, i'll just add a read syscall, no mmapping
16:21:00 <heat> userspace creates a ktrace listener, specifies the length of the buffer (creation allocates memory for the buffer)
16:22:00 <heat> so i'm not actually providing a buffer to the kernel
16:23:00 <mrvn> and then copy from the kernel buffer to the buffer argument in read?
16:24:00 <mrvn> man am I happy that my kernel doesn't have that at all. All buffers are transfered by mapping pages.
16:24:00 <heat> yup
16:24:00 <heat> mmapping a ring buffer and letting userspace do stuff could work
16:25:00 <clever> i think pcap does that in one mode?
16:25:00 <mrvn> it's a huge performance improvement.
16:25:00 <heat> clever, yes
16:25:00 <heat> PACKET_MMAP
16:25:00 <clever> mainly because you have high thruput and you cant stall the source
16:25:00 <clever> most other cases can block the writer
16:26:00 <heat> no, the writer doesn't block
16:26:00 <heat> you just drop data
16:26:00 <clever> exactly
16:27:00 <clever> but in other api's like plain tcp or filesystem, you block the writer when the buffer is full
16:27:00 <clever> so the overheads arent as important
16:27:00 <clever> but with pcap, any overhead leads to lost packets
16:27:00 <clever> and you cant throttle the source to make it fit
16:28:00 <mrvn> well, with TCP you could. but who wants that?
16:28:00 <clever> yeah, you could drop the packet, but thats just going to incur a retry
19:41:00 <geist> GeDaMo: haha i haven't heard that song in forever
19:41:00 <geist> used to hear it on Dr Demento forever ago
19:42:00 <geist> never knew it had a video
19:52:00 <mrvn> std::stack<int> s; s.top(); // fun
19:53:00 <mrvn> my cat is pregnant and I don't even have a cat.
19:58:00 <geist> question for folks that have dealt with existing libcs (instead of writing one) recently
19:58:00 <geist> any suggestions for which one would be simplest to port to a vaguely posixy system?
19:58:00 <geist> ie, musl, glibc, bionic, etc?
19:58:00 <geist> probably musl, but glibc is technically more highly portable i suppose
19:59:00 <geist> orrrr, if there are any new ones as part of hobby projects that are pretty good quality and thus portable
19:59:00 <geist> i did one years ago for newos but frankly i just dont want to bother with it again and would rather start with an existing libc
19:59:00 <mrvn> I think glibc is rather complex. What about newlib?
20:00:00 <geist> i'm using that right now but it seems highly limited
20:00:00 <geist> notably it doesn't really seem to be set up for a multithreaded environment
20:01:00 <geist> its embedded roots are sticking through
20:01:00 <bauen1> klange: where can i find the sources / build scripts for the repository of packages for toaruos ?
20:01:00 <geist> or at least it has some amount of support for threading but it's mostly in the form of 'you provide a Big Lock' for it to work with, i think
20:02:00 <geist> but i should dive into it a bit. but that's what i'm using now for this project
20:04:00 <geist> also it's unclear if you can even build it as a shared lib
20:19:00 <heat> geist, musl is relatively simple
20:19:00 <geist> yah that's probably where i'll go
20:19:00 <heat> glibc is well, glibc
20:19:00 <geist> it's pretty linuxy, but we made it work for fuchsia so that's a thing
20:19:00 <heat> the static linking in glibc is totally broken so that's probably not the libc you want for lk
20:19:00 <geist> well this is for a user space for LK
20:20:00 <heat> bionic... i'm not sure anyone has ever used it besides android
20:20:00 <geist> lk has it's own libc and i'm happy with that. i'm building up user space which will need to be a more proper libc, so would rather not write all of that
20:20:00 <geist> and in that case shared libc is much more desirable
20:20:00 <heat> yeah i know, but glibc would make it a thicc kernel :P
20:20:00 <geist> again, this is for user space
20:21:00 <heat> *shrug* static linking is still pretty slim
20:21:00 <geist> and thus a separate set of binaries, wont link with the kernel
20:21:00 <heat> but yeah, musl is a good choice for both ways
20:21:00 <geist> yah probably will look at that
20:21:00 <geist> is that what you're using for yours?
20:21:00 <heat> yes
20:21:00 <geist> i'm feeling a bit left out of the userspace os club lately
20:22:00 <heat> :D
20:22:00 <geist> though i did it 21 years ago for the first time, i can't really claim that works right now
20:22:00 <geist> since the code has aged
20:22:00 <geist> also it was a much simpler time
20:25:00 <heat> notes for musl: IO uses readv and writev; new malloc uses brk + mmap, oldmalloc uses brk almost exclusively; networking stuff has a lot of AF_NETLINK code for listing network interfaces, addresses, etc; threads require futex(2), although more precisely, the FUTEX_WAIT, FUTEX_WAKE and FUTEX_CMP_REQUEUE(can't remember if this is the actual name)
20:25:00 <heat> threads also spawn themselves with clone(), you may want to fix that
20:26:00 <geist> how hard was it to rip out the linux syscall layer and add your own? did you add your syscalls inline with musl or call over into another lib
20:26:00 <geist> the latter is what i was thinking of doing, sort of vdso style
20:26:00 <geist> or is there at least a syscalls/<add os here/ layer?
20:28:00 <heat> i didn't
20:28:00 <heat> my syscalls use linux style calls (i.e volatile asm ("syscall" :: ...))
20:28:00 <geist> ah so you basically implemented more or less verbatim linux syscalls?
20:28:00 <j`ey> what about the syscall numbers?
20:28:00 <heat> I think 32-bit x86 code uses the vsyscall to do system calls so you can probably look into that
20:29:00 <heat> but calling actual system calls? you'd need to convert the internal syscall(SYS_blah) into blah(...) calls
20:29:00 <geist> so what i was hoping to do is more or less what i'm doing with newlib now: ther's a switch for --disable-newlib-supplied-syscalls or whatnot
20:29:00 <heat> each arch has a syscall.h.in that has the system call numbers
20:29:00 <gamozo> Oh no who's digging into newlib?
20:29:00 <geist> it just expects you to implement a bunch of _open _read, etc syscalls in some lib somewhere
20:29:00 <heat> that thing is preprocessed so each __NR gets a __NR and a SYS_
20:29:00 <geist> so i then just have a liblk.a that i link with it
20:30:00 <geist> gamozo: i am currently, but not particularly happy with the results
20:30:00 <gamozo> Awhh :( I love newlib as a concept but it never seems to do quite what you want. I used it with cc65 to build OpenSSL against 6502, and I was surprised it worked for that.
20:31:00 <heat> tl;dr: you can probably get rid of most of the system calls by transforming the internal syscall calls (__syscall, __syscallN, __syscall_cp, probably more) into vdso calls
20:31:00 <heat> s/most of/most of the linux/
20:31:00 <heat> possibly in an automated way if you're a regex god
20:32:00 <geist> gamozo: yah i thik that's really what its designed for. largely single instance embedded style things
20:32:00 <geist> and i'm not faulting it for that really
20:32:00 <heat> some system calls are done in assembly (clone.s for instance) but those are very few
20:33:00 <geist> heat: yah i think that's probably what we did for fuchsia. i think we added effectively a layer below it that was more posixy, so that the libc is sitting on top of something like libio which is on top of the vdso (libzircon)
20:33:00 <geist> i remem er years ago BeOS did something like that which i always thought was a good idea
20:33:00 <geist> vs having syscalls directly in the libc
20:34:00 <geist> (or in the process)
20:34:00 <heat> you mean libfdio?
20:34:00 <geist> yah though it may all be gone now, but that's what we did initially
20:34:00 <heat> the docs still mention it
20:35:00 <geist> to try to keep from overcustomizing musl for fuchsia directly, and anyway kinda had to because the kernel syscall layer has no concept of file descriptors or hatnot
20:35:00 <geist> so either you end up jamming most of what is inside libfdio into libc, or put it as a layer below that gives a vaguely posixy environment (at least as it comes to files) and have libc be another customer of that
20:36:00 <geist> for lack of any better ideas i think i'll just morph this lkuser thing into a vaguely beosish syscall layer
20:37:00 <geist> which basically supports posix as far as files and pipes and wehatnot is concerned, but otherwise has its own threading and VM api raw api that can handle stuff like clone and mmap but not implement directly in syscalls
20:42:00 <heat> huh
20:42:00 <heat> how raw of a VM api?
20:43:00 <geist> oh like create region, delete region, etc
20:43:00 <geist> or maybe even something more vmoish
20:44:00 <geist> like dodsn't need to use shenanigans like mapping /dev/zero to really mean make an anoymous region
20:44:00 <geist> can have a vm_create_region() and a vm_map_file() for example as two calls
20:45:00 <geist> the posix VM stuff is always a bit restrictive for me, basically something that grew over time and had little things shoved in the corners as special cases
20:46:00 <geist> hmm mlibc looks interesting
20:46:00 <geist> https://github.com/managarm/mlibc
20:46:00 <bslsk05> managarm/mlibc - Portable C standard library (63 forks/480 stargazers/MIT)
20:49:00 <zid> I'd rather write my own than trust a rando libc from github tbh
20:49:00 <zid> at least i'll know how to debug it
20:49:00 <geist> yeah i get the appeal, but i really dont feel like dorking with writing yet another libc
20:49:00 <zid> It depends what you're after
20:49:00 <zid> if you're after the basic C stuff that needs to work 'okay' in the 'normal' cases it probably works absolutely fine
20:50:00 <zid> I just.. worry about the non-those cases
20:50:00 <geist> right, but i dont necessarily think that i'd do any better
20:50:00 <zid> I think we'd both have them, but at least if I wrote it, I'd also know how to debug it
20:50:00 <geist> or at least i dont have that much interest and time to really put in the effort to build a production quality libc
20:50:00 <zid> because I wrote it
20:50:00 * geist nods
20:50:00 <geist> there's some sort of llvm libc maybe in the works?
20:51:00 <geist> musl is probably the best bet and hope i dont have to debug it too much
20:56:00 <heat> "in" "the" "works"
20:56:00 <heat> llvm-libc is the worst idea ever
20:56:00 <j`ey> why?
20:57:00 <heat> why would a toolchain need its own libc? a libc is also super intricate and hard to get right
20:57:00 <j`ey> it has a c++ lib!
20:57:00 <heat> libc++ requires a lot more compiler introspection (i.e type_traits) than a libc
20:57:00 <j`ey> glibc is part of the gnu project like gcc?
20:58:00 <heat> the GNU project is supposedly a OS project, not a toolchain
20:59:00 <heat> musl still has compatibility issues in 2022, 11 years after it was started
20:59:00 <heat> note that this is a fully maintained libc
20:59:00 <j`ey> isn't a decent amount of that due to glibc issues?
21:00:00 <geist> heat: i'm not sure it's so much tied to the toolchain as comes out of the same team
21:00:00 <heat> yes
21:00:00 <geist> but yeah, i'm always annoyed a bit that libcs nowadays tend to be so OS centric
21:00:00 <geist> back in my day libc just depended on a layer of calls that something else provided
21:00:00 <heat> glibc is decently portable
21:00:00 <geist> but alas, i think they're just complicated
21:00:00 <heat> it's just a *lot to port*
21:01:00 <j`ey> heat: as long as google is doing all the work.. :P
21:02:00 <heat> let them have fun I guess
21:02:00 <heat> maybe we don't realise the full scope of the project. but there's a good reason why fuchsia went with musl
21:03:00 <geist> yah i think we drew a lot of ire from the musl project maintainers over it, but alas
21:03:00 <geist> since i think our changes were generally so incompatible there was no real way to merge it back
21:03:00 <geist> but then they explicitly set out to make a linux libc, so we had to make some deep cuts
21:04:00 <mrvn> heat: is there any libc that supports nss modules that can do static linking? They kind of conflict.
21:04:00 <heat> yeah as I understand it the real issueis the "no giving back" part
21:04:00 <heat> mrvn, does any libc support nss modules other than glibc?
21:04:00 <mrvn> heat: aparently not. :)
21:05:00 <heat> i genuinely don't know. had the impression nss was a glibc concept
21:05:00 <geist> also iirc we ripped out the musl heap because it's insane
21:05:00 <geist> but that's probably highly modular for more or less any libc (or i'd hope)
21:05:00 <mrvn> Does BSD have /etc/nsswitch.conf?
21:05:00 <geist> oh also netowrking and that sort of stuff IMO should be a separate lib
21:06:00 <zid> I blame posix for extending C
21:06:00 <geist> libnet.so or libsocket.so or whatnot. i dont understand why all that stuff has gotten pulled into libcs over time
21:06:00 <heat> geist, the musl heap has been rewritten
21:06:00 <geist> whatever one we forked was some of the most inpenetrable code i've seen
21:06:00 <heat> you looked at oldmalloc/, they have mallocng which is a lot better, although still slow
21:06:00 <zid> posix changes fread/fwrite's semantics, so all your lovely 'posix' code ends up inside the libc
21:06:00 <mrvn> geist: sockets aren't bad. But named service lookups needs plugins.
21:06:00 <geist> one of those classic no comments all single character variable things
21:06:00 <heat> that's classic musl
21:07:00 <heat> the musl I fell in love with 😍
21:07:00 <zid> imo a slow malloc isn't a dealbreaker, if I need allocation performance I am writing a pool allocator on top of it anyway
21:07:00 <geist> yah i mean i'm down with tight code but tight code doesn't *always* mean unreadable
21:07:00 <geist> variable name sizes dont slow code down :)
21:07:00 <mrvn> zid: well, there is slow and stupidly slow.
21:08:00 <heat> brace yourselves
21:08:00 <heat> https://elixir.bootlin.com/musl/latest/source/src/network/dns_parse.c#L4
21:08:00 <bslsk05> elixir.bootlin.com: dns_parse.c - src/network/dns_parse.c - Musl source code (v1.2.3) - Bootlin
21:08:00 <geist> ahahaa
21:08:00 <zid> That's.. sorta readable tbh
21:08:00 <mrvn> heat: first thing I would always do right away with such code: typdef the callback.
21:08:00 <zid> record, record length, a callback, and a general context
21:08:00 <geist> they used spaces, but otherwise it looks like properly formatted obfuscated code
21:08:00 <zid> and it's extracting various bytes of the dns record
21:09:00 <zid> without the __dns_parse name though it'd be utter nonsense
21:09:00 <mrvn> r + rlen are kind of short names. What's that? the request as raw bytes?
21:09:00 <geist> like a comment describing the record format and what it's extracting would help immensely
21:09:00 <zid> stick a link to the dns rfc at the top ;)
21:09:00 <geist> right exactly
21:09:00 <zid> It just needs a couple of comments for what those fields represent and it's fine imo
21:09:00 <mrvn> Is that parsing the request or the response?
21:09:00 <geist> right
21:10:00 <zid> /* Discard records that don't have the response bit set */ if(r[3] & 15) return 0;
21:10:00 <zid> or whatever
21:10:00 <heat> response
21:10:00 <geist> and if someone here spouts out the usual thing of 'but but comments get out of sync and are bad' i'll get out the wet trout
21:10:00 <zid> You can comment, or you can assign everything to vars with useful names
21:10:00 <zid> but that'd be a full rewrite
21:10:00 <heat> but but comments get out of sync and are bad
21:10:00 <geist> this is a perfect example of putting a note as to what rfc this is decoding by definition can't get out of date
21:10:00 <zid> comments are simpler in this case
21:10:00 <heat> self documenting code
21:11:00 <geist> unless the function literally gets repurposed for some different thing
21:11:00 <mrvn> zid: yeah, that code needs an enum for 15 and 193
21:11:00 <zid> On the plus side, those are tabs
21:11:00 <zid> and the includes are clean
21:11:00 <heat> the musl libc folks know what they're doing
21:12:00 <heat> but the code is usually unreadable as shit
21:12:00 <geist> yah the 15 and 193 are pretty dumb
21:12:00 <zid> I don't like the lack of spaces around the < and > operators
21:12:00 <heat> although it has gotten better, mallocng is pretty readable
21:12:00 <zid> I'm on the fence about random enums
21:12:00 <geist> yah that one is annoying, but that gets fairly subjective so i'm just leaving it out
21:12:00 <mrvn> zid: except later it has spaces. inconsistent
21:12:00 <mrvn> zid: nameless enums. Just the C way of declaring constants.
21:12:00 <geist> agreed. i dont think you have to enum/define *everything*, or if you do at least do it near the thing
21:13:00 <geist> i've seen cases in our codebase where we've doggedly applied 'no constants must be enumed' rule and it made things much harder
21:13:00 <geist> since now you define some constant 500 lines away to be used exactly once
21:13:00 <zid> randon enums are nice that they feed into the whole 'just document via names' that I like, but bad in that they're over there *points* and basically never get reused so they're just pollution
21:13:00 <geist> right
21:13:00 <geist> so i have used it in the past to satisfy the rule by putting it nearby, in the same function, etc
21:13:00 <geist> if it's used once
21:13:00 <zid> I've done interprocedural defines a few times
21:13:00 <geist> and then i think that's probably a decent compromise
21:13:00 <mrvn> geist: the enum should be right before the function and just define the constant the function uses.
21:13:00 <zid> int main() { #define LEN 512 ..... #undef LEN }
21:13:00 <zid> :D
21:14:00 <geist> mrvn: yeah but then there are dogged rules about 'can't put things in between functions, should be at the top' etc
21:14:00 <geist> that inevitably get applied
21:14:00 <mrvn> geist: that's a bad rule then
21:14:00 <zid> I prefer that rule to 'enum everything'
21:14:00 <geist> agreed. but rules are rules
21:14:00 <zid> if I had to pick between two rules
21:14:00 <geist> mrvn: aren't you german?
21:14:00 <mrvn> geist: so?
21:14:00 <mrvn> rules are mend to be broken. :)
21:14:00 <geist> rules!
21:14:00 <mrvn> Hey, put the function in it's own file then the enum is at the top :)
21:14:00 <geist> there's a procedure!
21:15:00 <mrvn> like here
21:15:00 <geist> ah i see, there's a rule but as long as you can find a way to satisfy the rule then it still works. gotcha
21:15:00 <geist> thta's like the Sabbath Mode my oven has
21:15:00 <mrvn> What's qdcount and ancount?
21:15:00 <heat> obviously, they're the count of qd's and an's
21:16:00 <heat> self documenting code
21:16:00 <geist> i guess if i just knew the format it'd be easier
21:16:00 <geist> i also dot completely get the 193 and whatnot. thats out of ascii range
21:17:00 <mrvn> geist: it's a const unsigned char *, it's not a string.
21:17:00 <heat> https://elixir.bootlin.com/musl/latest/source/src/malloc/mallocng <-- this is a lot more readable, newer musl code
21:17:00 <bslsk05> elixir.bootlin.com: mallocng - src/malloc/mallocng - Musl source code (v1.2.3) - Bootlin
21:17:00 <heat> it has *sigh* comments??
21:17:00 <heat> actually, *gasp*
21:17:00 <heat> or 😲
21:18:00 <geist> mrvn: oh so this is some binary strcutre? I guess i should have read the comments describing the format
21:18:00 <mrvn> geist: well, the type kind of documents it. strings are just char* by convention and have no length argument.
21:19:00 <mrvn> pre+size is usualy a buffer
21:19:00 <mrvn> ptr+*
21:19:00 * geist smacks forehead
21:19:00 <mrvn> but comment for the RFC see above. :)
21:20:00 <mrvn> "r[4]*256 + r[5]" isn't that pattern something so common it should have a helper function? It already appears 3 times just in that function.
21:21:00 <zid> I rewrote it a bit
21:21:00 <zid> just mainly into my style so I could read it better
21:21:00 <zid> https://gist.github.com/zid/32635c33dd291438dee96b81fdbe12a7
21:21:00 <bslsk05> gist.github.com: dns.c · GitHub
21:21:00 <zid> I like whitespace
21:21:00 <geist> same
21:21:00 <zid> I think it erm
21:21:00 <mrvn> I hate "p += 5 + !!*p;". stupid hack to turn a bool into 0/1.
21:21:00 <zid> seeks through each record, of which this is an array of
21:22:00 <zid> and skips all bytes below 128, but dies on bytes that are >193 unless they are followed by 255
21:22:00 <heat> ya see, that's better
21:22:00 <heat> https://www.openwall.com/lists/musl/ git send-email that shit
21:22:00 <bslsk05> www.openwall.com: musl mailing list
21:23:00 <mrvn> In line 35 (of zids url) why is p[1] never out-of-bounds?
21:24:00 <zid> https://gist.github.com/zid/32635c33dd291438dee96b81fdbe12a7 v2
21:24:00 <zid> *stealthily fixes a bad return*
21:24:00 <mrvn> Actually why is *p even allowed?
21:25:00 <mrvn> Say the "while" before that exits because "p-r == rlen" then *p is accesing the response one byte after the buffer.
21:25:00 <zid> I need to know more of what the code is trying to do to change this more I think
21:26:00 <mrvn> zid: I think that dns_bad_seq is less readable.
21:26:00 <mrvn> zid: net_short_at is UB
21:26:00 <zid> I think literally everything you say is incorrect, so that's basically a badge of honor.
21:27:00 <mrvn> well, implementation defined
21:27:00 <mrvn> On systems where int is 16bit it overflows. So actually really UB.
21:28:00 <heat> oh no
21:28:00 <heat> the famous 16-bit linux systems
21:28:00 <mrvn> heat: no, the musl port to avr.
21:28:00 <mrvn> or ARM with thumb
21:28:00 <heat> 404 not found
21:29:00 <mrvn> But don't worry, the original was UB already.
21:29:00 <heat> how is that UB anyways?
21:30:00 <zid> It isn't he doesn't know what it means
21:30:00 <mrvn> heat: 193 << 8 is a signed integer overflow
21:30:00 <zid> good job it's unsigned then
21:30:00 * geist feels the heat from the burns
21:31:00 <mrvn> zid: it isn't. unsigned char gets promoted to int before the shift operation
21:31:00 <geist> SICK BURN
21:31:00 <heat> bern
21:32:00 <zid> If R1 has an unsigned type, the value of the result is E1*2^E2, reduced modulo one more than the maximum value representable in the result type.
21:32:00 <zid> E1*
21:32:00 <zid> I guess that's post promotion though
21:33:00 <mrvn> zid: indeed: https://en.cppreference.com/w/c/language/conversion 4) Otherwise, both operands are integers. Both operands undergo integer promotions (see below); then, after integer promotion, one of the following cases applies:
21:33:00 <bslsk05> en.cppreference.com: Implicit conversions - cppreference.com
21:34:00 <zid> Still isn't UB, it just has a chance of being UB
21:34:00 <zid> on a platform on which this isn't
21:34:00 <mrvn> Integer promotion is the implicit conversion of a value of any integer type with rank less or equal to rank of int ...
21:34:00 <zid> One of the many joys of the C spec
21:34:00 <mrvn> zid: as said, it fails when int is 16bit.
21:34:00 <zid> which it isn't
21:34:00 <zid> things being UB only if they're in certain cases is one of the *really* shitty things about C
21:34:00 <mrvn> zid: what isn't? The source? The source has no arch.
21:35:00 <heat> musl doesn't fit in 64K or 1MB
21:35:00 <zid> It's an invariant of the code
21:35:00 <zid> same reason I can do b[0] and b[1] without some magic length check
21:35:00 <heat> this is for real architectures, not an 80286
21:35:00 <zid> It's required that the parent function calls it in a way that that won't be UB
21:36:00 <mrvn> The bad part actually is that you basically can't write this code not to be technically UB at all.
21:36:00 <zid> You absolutely can
21:36:00 <zid> You just need to manually promote, or make it an invariant, which it already is
21:37:00 <zid> It isn't UB until you try to compile it, just throw an error in autoconf or whatever about 16bit int, done
21:37:00 <mrvn> For this specific construct casting to u16 will be enough.
21:38:00 <mrvn> if you had a b[0] * b[1] in there then it gets tricky.
21:38:00 <geist> heat: uh oh you've stirred the angry god of 16 bit Protected Mode
21:38:00 <zid> I fell foul of small unsigned to larger signed a couple of times in some bitmath years ago
21:38:00 <zid> I've never slept properly since
21:39:00 * heat gets descriptor table'd to death
21:39:00 <mrvn> It really sucks that you can not turn the integer promotion off at all
21:39:00 <zid> -Wconversion -Werror
21:39:00 <zid> done
21:39:00 <zid> Now it's off
21:39:00 <mrvn> no, now it just gives warning for some cases
21:40:00 <mrvn> (and then fails)
21:41:00 <heat> anyway
21:41:00 <mrvn> anyway, back to the original code. In line 18 or line 24 doesn't that risk a buffer overflow?
21:41:00 <heat> some musl code bad, some musl code good, most musl code correct
21:42:00 <heat> fun fact: systemd still can't compile with musl without a bunch of patches
21:42:00 <heat> they explicitly require glibc
21:42:00 <mrvn> Should be: if (p>r+rlen-6 || *p>193 || (*p==193 && p[1]>254))
21:42:00 <j`ey> systemd bad
21:43:00 <heat> unix philosophy good
21:43:00 <mrvn> First check if there is enough bytes left in the response, then test those bytes.
21:43:00 <heat> give pipe and small program
21:44:00 <mrvn> Line 27 another buffer overflow
21:44:00 <zid> Anyway, this comes back to my "I'd rather I just wrote it, it's going to be of dubious quality either way"
21:45:00 <zid> I'd probably end up with a little accessor macro or function or something that checked rlen against the offset
21:45:00 <heat> you realise that none of those are actual problems since root is the one who sets the dns server, right?
21:45:00 <zid> people run the wrong things setuid a lot :(
21:45:00 <zid> Then people claim it's a CVE in your code, not a CVE in their distro
21:45:00 <zid> rude
21:45:00 <mrvn> Line 24 I think should be: if (p>r+rlen-12 || *p>193 || (*p==193 && p[1]>254))
21:46:00 <mrvn> heat: you have a local DNS server on your system? Not using 8.8.8.8?
21:46:00 <zid> One thing a friend did recently that I kinda liked was make a throwaway struct to abstract out a buffer
21:46:00 <heat> is 8.8.8.8 pwning you?
21:46:00 <zid> struct buffer { const char *u; int len; int pos; } and then just wrote a 'pop' function that refused to give you bytes past the end of the buffer
21:47:00 <heat> and yes, lots of people have local dns servers
21:47:00 <heat> like systemd-resolve
21:47:00 * heat hurr durrs systemd bad
21:47:00 <zid> systemd bad.
21:47:00 <mrvn> heat: I wouldn't trust it to never send me corrupt dns repsonses.
21:47:00 <zid> sysvinit is also bad, but systemd bad.
21:47:00 <heat> systemd horrendous
21:47:00 <heat> systemd made my wife leave me
21:47:00 <zid> systemd made my X break
21:47:00 <zid> cus I can't remember which greeter package I installed to fix it
21:47:00 <heat> mostly because i kept rambling how systemd is horrible and ignored her for 15 years
21:48:00 <zid> It probably starts with an x, so I can't tab complete it
21:48:00 <zid> because it's like x [17843 results]
21:48:00 <geist> one cool feature of systemd that i did figureo ut recently was it has a fairly nice integrated nfs automounter
21:48:00 <zid> "xdm, xwm, xgreet, x... yea sure one of these is probably right..."
21:48:00 <geist> you just have to tag the fstab entry with some magic goop and then it just works
21:48:00 <heat> b-b-but systemd bad?????
21:49:00 <geist> but of course figuriung out the magic goop was to copy paste it off the internet
21:49:00 <geist> so that's bad
21:49:00 <zid> systemd is a necessary thing to like, make a modern system like say, windows 95
21:49:00 <zid> but systemd itself is just a bad implementation
21:49:00 <heat> systemd is just linux's launchd
21:50:00 <zid> They spelled launchd wrong, can we bugrep that
21:50:00 <heat> linux people are more focused in the "muh choice muh freedom" and less in the "we have something that works"
21:50:00 <geist> i was under the impression it was somewhat inspired by the apple thing
21:50:00 <heat> zid, nvidia is looking for a good spell checker you might wanna help out as well
21:50:00 <zid> If I wanted something that worked why would I install linux
21:50:00 <geist> i forget what it is called,launchd? i forget
21:50:00 <zid> riddle me that
21:50:00 <zid> I think geist may be scrolled up
21:51:00 <heat> hahahaha
21:51:00 <geist> yah i had no interested in reading your gripes
21:51:00 <geist> did someone mention that before?
21:51:00 <j`ey> interestd
21:51:00 <zid> zied
21:51:00 <heat> yeah maybe someone mentiond that before
21:52:00 <zid> heat: Didn't answer my incredibly serious question about why I'd install linux if I wanted a machine to work
21:52:00 <geist> okay. i saw someonemention linux launchd, but i think apple has a whole different thing
21:52:00 <zid> launchd is the apple thing
21:52:00 <geist> but kinda similar in the big pluggable init replacement thingy
21:52:00 <geist> ah
21:52:00 <geist> didn't know it was open sourcableenough to be ported
21:52:00 <heat> the systemd author was directly inspired by launchd
21:52:00 <heat> but it's a different thing
21:53:00 <zid> wiki page says 2006 ubuntu considered it, but rejected it due to the licence
21:53:00 <heat> although it's been ported to some BSDs before (all rotted)
21:53:00 <geist> yah also i remember android had/has something kinda similar
21:53:00 <zid> late 2006 apple relicenced it, and it got ported to freebsd, etc
21:53:00 <geist> i *do* remember back in 2009 or so when working on webos were actually really annoyed with udevd and how slow it was to run all of the hooks on boot
21:53:00 <geist> on a say 600mhz arm it would actually take seconds to spawn 1000 sh scripts to decide to do nothing at all
21:54:00 <zid> That's another program with a missing e
21:54:00 <zid> I'd like a sysvinit that was just written in C instead of bash
21:54:00 <geist> i think as a result we wrote our own udev replacement and rolled it into our init, or something like that
21:54:00 <zid> but I'm not interested in hacking a registry on windows, or systemd's binary configs etc when I wanna get into a mess
21:54:00 <geist> sped things up by an order of magnitude since we didn't need udevd's ability to run arbitrary shell scripts on device detection
21:55:00 <heat> systemd doesn't have binary configs
21:55:00 <geist> and on boot linux delivers basically a huge pile of udev notifications
21:55:00 <heat> it's all budget .ini's
21:55:00 <zid> really? that was everybody's main gripe I kept seeing
21:55:00 <zid> binary this and binary that
21:55:00 <heat> launchd has the .ini's and binary configs now IIRC
21:55:00 <geist> well .ini files that drive binary logic is still probably a hell of a lot faster than a bunch of fork/execs to run shell scripts
21:55:00 <zid> I love ini
21:56:00 <geist> or at least on low end machines. on high end machiens you probably can't tellthe difference
21:56:00 <zid> People who aren't using ini get a serious amount of side-eye from me unless they are *exactly* a javascript 'program' using json that never gets sent over a network
21:56:00 <zid> because javascript can't open files, only eval other 'scripts'
21:56:00 <heat> i commonly use json
21:56:00 <geist> agreed. ini files are a nice format honestly
21:57:00 <zid> People kept trying to get me to use YAML on one of my projects
21:57:00 <geist> clearly limited, but nice to work with as a human
21:57:00 <zid> Literally nobody could explain to me why
21:57:00 <zid> "It has a date format!"
21:57:00 <heat> json is compact and there are already parsers for it in any language
21:57:00 <zid> Okay but.. if it parses the date, it's going to give me the date in some struct, and I will have to use the posix date functions to turn it into a date I can use anyway
21:57:00 <heat> and I hate writing parsers
21:57:00 <zid> so I've skippped.. precisely 0 steps, but now the config takes 10x as long to load and uses a custom format
21:57:00 <geist> there's a quote in there somewhere
21:58:00 <geist> here to chew bubblegum and parse json...
21:58:00 <heat> and im all out of json
21:59:00 <zid> It can validate it is *a* date, but it can't validate *the* date, which I have to do anyway, which means I have to run it through stratime or getlocaltime or whatever *anyway*, probably exactly twice because yaml already did exactly that 'for' me
21:59:00 <zid> so yea, people will avoid ini like the plague just.. to make their code slower, apparently
22:01:00 <clever> ive been considering using lua for my config
22:02:00 <zid> Do you mean 'runtime moduluar behavior' by 'config'
22:02:00 <zid> or 'config'
22:02:00 <clever> config with the ability to change params based on arbitrary data, like model or serial#
22:02:00 <zid> okay sounds like you still want ini to me
22:03:00 <clever> the rpi has a mess of [gpio4=1] to make certain blocks only run if a gpio is high
22:03:00 <heat> i think you all want xml
22:03:00 <clever> and [pi4] to make certain blocks only run on a pi4
22:03:00 <zid> heat with the best ideas only
22:03:00 <clever> but if you do both, they become an AND condition!
22:03:00 <zid> That sounds like a job for.. two ini files :P
22:03:00 <clever> so you cant just run it thru a standard ini parser, you need to know that 2 sections occured in a certain order
22:04:00 <clever> i dont want to make the mess worse, so i'm just going to throw a proper turing complete language at it
22:04:00 <zid> they just decided to be 'clever' and try to embed logic into a config file
22:04:00 <clever> and the user can make whatever mess they want :P
22:04:00 <zid> instead of just making two files
22:04:00 <clever> the rpi firmware can also make config conditional on EDID model names
22:04:00 <zid> so can filenames
22:04:00 <clever> and serial#
22:05:00 <zid> which is how like, literally thousands of my pieces of software already work
22:05:00 <clever> except, all of those conditional flags, gate the same single set of options
22:05:00 <clever> and when you define an option in 2 files, what is the priority?
22:05:00 <zid> you open blah/ for the settings and icons and stuff for your 'blah' module
22:05:00 <zid> generic.ini sits outside of it
22:06:00 <clever> but then how do you use gpio pins to filter things?
22:06:00 <zid> stat() now does all your heavy lifting instead of some bizzare custom parser, it's easier for the end user to edit, etc
22:06:00 <heat> use bytecode
22:06:00 <clever> also, the firmware can swap between config.txt and tryboot.txt for testing
22:06:00 <clever> heat: lua can be pre-compiled to bytecode, problem solved
22:07:00 <zid> not sure why the gpio thing is even a problem
22:07:00 <heat> boring
22:07:00 <heat> roll your own bytecode
22:07:00 <zid> put it in a block
22:07:00 <clever> zid: you can combine gpio and model filters, so adding multiple files into the mix complicates it
22:07:00 <heat> what if
22:07:00 <heat> and hold on for a second, you're going to love it
22:07:00 <heat> you use
22:08:00 <heat> AML
22:08:00 <mrvn> forth
22:08:00 <clever> lol
22:08:00 <zid> clever: SO you're worried about there being repetition, or what?
22:08:00 <clever> zid: thats part of it
22:08:00 <zid> If we're talking thousands of model combinations or whatever I could understand it
22:08:00 <heat> need conditions? ✅
22:08:00 <clever> just having a lua function, where state goes in, config comes out, is simple
22:08:00 <heat> need to describe hardware? ✅
22:08:00 <zid> but with like.. 8.. I really don't care
22:08:00 <zid> I'd just make 8 ini files
22:09:00 <zid> don't make it a code problem until it's a code problem sort of deal
22:09:00 <clever> but the official firmware has an [all] section in its config, for applying defaults to any model
22:09:00 <zid> yup, generic.ini as mentioned
22:09:00 <clever> https://www.raspberrypi.com/documentation/computers/config_txt.html#combining-conditional-filters
22:09:00 <bslsk05> www.raspberrypi.com: Raspberry Pi Documentation - The config.txt file
22:09:00 <zid> and then model/whatever specific overrides in the matching filename file
22:10:00 <clever> it also has a [board-type=0x15] filter
22:10:00 <clever> so you can filter on models that dont yet have an official name
22:10:00 <zid> The problem comes if you have hundreds of models and half of them do the same overrides but with 1 change, and you'd like to share more of that
22:10:00 <clever> yeah
22:11:00 <heat> i feel like writing a good ol driver
22:11:00 <zid> you either end up writing a heirarchical filesystem sort of thing that gets sorta messy, or a sort of messy custom config
22:11:00 <zid> the reality is the problem, reality is messy
22:13:00 <heat> hierarchical bytecode thing that describes hardware
22:13:00 <heat> where have i heard of that before
22:13:00 <clever> device tree!
22:13:00 <heat> hmm no, that's not bytecode
22:14:00 <clever> acpi?
22:14:00 <zid> ACPI
22:14:00 <mrvn> device tree has no conditionals
22:14:00 <heat> that's it
22:14:00 <heat> ACPI
22:14:00 <zid> none of this is conditional to be fair, it's just matching
22:14:00 <clever> i think acpi is turing complete?
22:14:00 <zid> which ini is fine on
22:15:00 <heat> clever, what do you need to be turing complete?
22:15:00 <zid> considering ini is just a hashmap and makes no demands on what you put on the left hand side, I tend to just use dots and stuff to make it heirarchical
22:15:00 <zid> and you just strtok on dots and strcmp things
22:15:00 <clever> heat: i dont need turing completeness, but having it would enable some boot to basic style things
22:16:00 <clever> zid: the rpi config files are more complex then just section.key=value
22:16:00 <geist> ini plus some something variable substitution, single pass, might be nice
22:16:00 <geist> ie, lightweight c-preprocessor style stuff
22:16:00 <zid> just run cpp over it
22:16:00 <heat> wordexp does substitution
22:16:00 <geist> or that, but i'm saying for a runtime thing
22:17:00 <geist> like in your bootloader, etc
22:17:00 <geist> you could do some ${FOO} style inline replacement
22:17:00 <zid> oh so like, you have internal #defines you set at boot
22:17:00 <zid> and that impacts how the config parses
22:17:00 <geist> right
22:18:00 <heat> edk2's configs have wildcards
22:18:00 <geist> not saying it's a great solution, but it might be a simple solution that gives you basically what yuo ant without too much compelxity
22:18:00 <geist> uboot does stuff kinda like this, but mostly in the form of a shell like scripting language
22:18:00 <zid> I mean it's ultimately the same as just checking the key with strcmp
22:19:00 <zid> just phrased differently
22:19:00 <geist> and lots of environment variables that among other thigns contain snippets of shell script
22:28:00 <heat> i915, nvme or usb?
22:28:00 <zid> 82810
22:29:00 <heat> no i810
22:29:00 <zid> but it has a hardware rng!
22:30:00 <heat> so does x86
22:30:00 <heat> they're both crap
22:30:00 <zid> x86 didn't between skylake and i810 :(
22:30:00 <mrvn> but can you trust them? 8-P
22:31:00 <geist> well, it's entropy
22:32:00 <geist> that's what you shouldtreat it as, it's not a rng, it's an entropy source
22:32:00 <zid> xor it with 47
22:32:00 <zid> then it's secure
22:32:00 <mrvn> I always have to smile when people say they can't trust the hardware RNG, it could purposefully give weak keys. But they do trust the CPU that generates the key from the random bits not to do the same.
22:33:00 <zid> if it was capable of adding negative entropy I think it'd have to be spying on your other entropy sources to cancel them out
22:33:00 <heat> if rdrand is compromised you have larger issues than that
22:33:00 <zid> so you're already fucked at that point
22:33:00 <clever> zid: the rpi firmware has a list of keys in it, protected by an xor against a constant, lol
22:33:00 <zid> that actually counts as DRM
22:33:00 <clever> if you dont know what your looking for, its invisible
22:33:00 <mrvn> zid: assuming you have other sources
22:33:00 <zid> which makes circumventing it illegal under UK DMCA
22:33:00 <clever> zid: those keys are also naked in the OTP, and can simply be read out
22:33:00 <clever> you just need 1 of every model
22:33:00 <zid> I think vice city for ps2 was xored with 47
22:34:00 <mrvn> zid: european law doesn't accept weak crypto as protected DRM
22:34:00 <heat> they should've xor'd the definitive edition with 47 too
22:34:00 <zid> The UK is not in europe bro
22:35:00 <mrvn> zid: sure. but I'm not in the UK and don't care what they consider legal.
22:35:00 <zid> We're officially part of the north pole
22:35:00 <zid> so why are you talking
22:35:00 <heat> "EU legislation as it applied to the UK on 31 December 2020 is now a part of UK domestic legislation"
22:36:00 <zid> EU member states can enforce the laws however they like, and do whatever extra laws on top they like, happen to have an eidetic memory for UK law? :p
22:41:00 <jimbzy> Good gravy. I sat down in the recliner and lost 3.5 hours of my day.
22:42:00 <zid> You have an incurable vagus nerve syndrome where the change in your position causes you to black out, I am sorry you found out this way
22:44:00 <jimbzy> Hah. Nah, I just stayed up till 3:00 this morning and got back up around 6:00
22:51:00 <zid> I also have it
22:51:00 <zid> I lose about 8 hours a night to it
22:52:00 <mrvn> covid made it worse
23:02:00 <heat> screw it
23:02:00 <heat> i'm rouletting it
23:03:00 <mrvn> red 7
23:04:00 <jimbzy> 8 hours? I haven
23:04:00 <heat> i got usb
23:04:00 <jimbzy> 't had 8 hours of sleep in a row in years...
23:04:00 <heat> do i want to do usb? meh
23:04:00 <mrvn> jimbzy: that isn't healthy, seriously not healthy
23:05:00 <jimbzy> mrvn, Yeah I know, but sleeping meds literally put me in a coma.
23:06:00 <mrvn> well, sleeping meds are just as bad
23:06:00 <jimbzy> That's the only way I'll sleep more than 6 straight.
23:10:00 <jimbzy> In other news, I think I'm going to have a go at building a 65C02-based microcomputer.
23:10:00 <zid> neat, expect it to be able to do anything, or just going to poc it?
23:11:00 <jimbzy> Pretty much poc, but who knows?
23:12:00 <zid> A fancy knightrider box is always fun still
23:12:00 <mrvn> jimbzy: you can buy a C64 kit with board, all the chips and even the breadbox.
23:13:00 <jimbzy> I've already owned a C64, mrvn.
23:13:00 <mrvn> don't want one back?
23:14:00 <jimbzy> Maybe some day, but I want to build something different.
23:14:00 <zid> I think most fun would just be using it as a project box for other things
23:14:00 <zid> like, exposing its memory bus or whatever
23:14:00 <zid> and then using it sort of like an arduino
23:14:00 <zid> make it a memory mapped network card, or video card, or whatever
23:15:00 <mrvn> I have 90% of an actual video card build myself.
23:15:00 <jimbzy> I think Ben Eater has a VGA card kit.
23:15:00 <zid> it's also terrible because it isn't memory mapped
23:16:00 <zid> it uses shared memory via bus sharing
23:16:00 <mrvn> I have video ram that have 2 ports.
23:16:00 <mrvn> The read/write port connects to the bus, the read-only port for the video output.
23:16:00 <jimbzy> Yeah. It's literally billed as "The Worst video card ever" XD
23:17:00 <zid> It'd honestly have been easier to build it better :p
23:18:00 <jimbzy> Well, when I get to that point you can advise me. ;)
23:19:00 <zid> I don't have any 15kHz displays :(
23:19:00 <mrvn> Ben Eater's VGA card can be all bad, it has PORN. Well, the Lena picture from Playboy common to many graphic tests.
23:19:00 <mrvn> zid: your TFT has no VGA in?
23:19:00 <zid> I don't have any 15kHz displays.
23:22:00 <kazinsal> I just imagine a bunch of engineers sitting around trying to figure out what image to user for graphics/colour reproduction testing and looking over and seeing jimbo in the corner "reading it for the articles"
23:23:00 <jimbzy> I thought about doing something with the m68k, but that's still a bit out of my league I think. Another option is the 65C816.
23:25:00 <jimbzy> They actually had some interesting articles in the old ones. I mean, you weren't going to find the philosophy of Jean-Paul Sarte or anything that deep, but there are some good reads.
23:25:00 <mrvn> kazinsal: that's actually what happened. But they only scanned in 512 lines because that is the dimension they used for testing and that part is PG. Playboy actually released the cropped image later so you can use it yourself.
23:25:00 <zid> lena has asked for it to not be used anymore, fyi
23:27:00 <mrvn> Odd. It's just a headshot. Nothing to be ashamed about.
23:31:00 <mrvn> retired in 2019, well, it was fun while it lasted.
23:38:00 <mrvn> Delving deeper into the mysteries of C++ history: Why is this a pointer and not a reference? Can this be nullptr?
23:44:00 <mrvn> Hah, I guessed right: "Because this was introduced into C++ (really into C with Classes) before references were added. Also, I chose this to follow Simula usage, rather than the (later) Smalltalk use of self." Bjarne Stroustrup
23:48:00 <jimbzy> I've always been told that "C with Classes" was doing it wrong.
23:49:00 <mrvn> jimbzy: that's how C++ got started.
23:49:00 <jimbzy> Yeah, I know and that's how many of the early C++ books I had taught it.
23:50:00 <mrvn> they learned a lot since then
23:52:00 <jimbzy> Whatever works.