<bslsk05>
eylenburg.github.io: Operating Systems: Timeline and Family Tree
<klange>
might be biased because in the sea of disconnected OSes ToaruOS is in there :)
<vdamewood>
Both NetSD and FreeBSD are based on 386BSD and rebased on 4.4BSDLite
<kazinsal>
NetBSD was the result of a different set of 386BSD users going "what if we made one grand unified BSD instead"
<wxwisiasdf>
unics :D
<klange>
(with a start year of 2017, which isn't really accurate, that's just when I finally bothered to release a "1.0")
<Griwes>
> MEPIS
* Griwes
tries to not make a MEPIS joke
<vdamewood>
Also, the reason different BSDs exist is beause UCB discontinued the project.
<wxwisiasdf>
no way
<wxwisiasdf>
you have IBM mainframe os family tree?
<klange>
disappointed there's no branch for PonyOS, I should submit a pull request!
<wxwisiasdf>
sudden realization robotron took the name UDOS first, and my OS being named UDOS :u
<Griwes>
oh, qnx is fully just it's own thing? interesting
<vdamewood>
OpenBSD was the result of Theo de Raadt going "We;ll make our own BSD with blackjack and hookers!"
smeso has joined #osdev
<kazinsal>
hrm. I should submit a correction there. Data ONTAP is currently FreeBSD based but it's listed as spontaneously appearing in 1991
<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)
<wxwisiasdf>
i should probably rename my OS into something more proper :p
<vdamewood>
Hmm... Now I want to try to figure out an inappropriate name for my OS.
<vdamewood>
Is Poo OS taken?
<vdamewood>
I could claim it's named after my favorite Earthbound character.
<kazinsal>
oh wow. didn't know there was a new patch for 2.11BSD this year
<vdamewood>
That means my CSRG Archive CD set is obsolete now.
<Griwes>
hmm, in a completely different topic: did qemu 7 change how memory is allocated?
<kazinsal>
looks like there was a biiiig patch in 2020 that made the 2.11BSD system mostly ANSI C compatible
<wxwisiasdf>
wait did they release qemu7 already???
<kazinsal>
yeah, about a month ago I think
<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
<vdamewood>
Was 2.11 based on 4.2, 4.3, or 4.4?
<kazinsal>
2.11 is a continuation of 2BSD for the PDP-11
<vdamewood>
Right, but later 2.x contains backported code form 3 and 4.x
<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
<vdamewood>
s/form/from/
<Griwes>
doing* is much more expensive now?
<kazinsal>
I think it's 4.1something
Likorn has quit [Quit: WeeChat 3.4.1]
<vdamewood>
4.1town-in-nevada
<Griwes>
I was *right*
<Griwes>
-mem-prealloc makes it not spend seconds in pmm init
<kazinsal>
interesting
<kazinsal>
good catch
<vdamewood>
Good catch is great to hear, unless its a hand grenade
<Griwes>
don't worry, I counted to 3 so I'm safe
<vdamewood>
Not to 4? Not to 2, except to proceed to 3? Was 5 right out?
<Griwes>
yes, 5 was right out
<vdamewood>
That's that Berkeley said when numbering the versions of BSD.
<vdamewood>
s/that/what/
<kazinsal>
4.1BSD would have been called 5BSD but AT&T was about to unleash System V on the world and shit a brick
<vdamewood>
Yeop
<vdamewood>
Yep
<vdamewood>
So, I guess it's what AT&T said.
<Griwes>
the weird thing is that quick googling doesn't reveal a recent change in prealloc behavior...
Ali_A has quit [Quit: Connection closed]
<geist>
right there was a #BSD
<geist>
3BSD
<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
<geist>
yah what kazinsal said
knusbaum has quit [Ping timeout: 240 seconds]
knusbaum has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
knusbaum has quit [Ping timeout: 248 seconds]
knusbaum has joined #osdev
andrewrk has left #osdev [Leaving]
knusbaum has quit [Ping timeout: 240 seconds]
<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?
knusbaum has joined #osdev
<vdamewood>
energizer: winsock?
<kazinsal>
winsock is just berkeley sockets for windows
<vdamewood>
It is. But I've experienced too many people thinking that something is completely different just because it has a different name.
<kazinsal>
SVR3 and SVR4 had STREAMS TLI but I would hardly call a networking API from 1987 "new"
<energizer>
i should give up this search because all i know is it had a one syllable name
<wxwisiasdf>
i will just throw my socket and make it seem like a file
<energizer>
i cant even remember where i heard it from :\
alpha2023 has quit [Ping timeout: 256 seconds]
<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
<kazinsal>
maybe if I actually put something down "on paper" I'll be able to stick to it
<kazinsal>
(should also write down "ask doctor about ADHD diagnosis" on a to-do list, hrm)
zaquest has quit [Remote host closed the connection]
sikkiladho has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
alpha2023 has joined #osdev
zaquest has joined #osdev
wxwisiasdf has quit [Quit: Lost terminal]
xenos1984 has joined #osdev
<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.
FireFly has quit [Ping timeout: 260 seconds]
jack_rabbit has joined #osdev
knusbaum has quit [Ping timeout: 240 seconds]
<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
jack_rabbit has quit [Ping timeout: 248 seconds]
<sikkiladho>
Thank you!
<kazinsal>
my arm knowledge is pretty minimal but that's a good general assumption for a lot of architectures
knusbaum has joined #osdev
<sikkiladho>
I'll look into the condition register and see if it's related.
<geist>
thats right, arm is a condition register based arch
<geist>
so it's based on whatever the previous operation was that modified the condition flags
<geist>
pretty standard NZVC (negative, zero, overflow, carry) flag set
<sikkiladho>
yeah got that! thanks.
<geist>
a good modern counter example to that is risc-v which has no condition flags
<geist>
so the conditional branches are all based on comparing two registers to each other, and based on the result branching
<gamozo>
risc-v <3
<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
<geist>
so it's a tradeoff
<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
<geist>
right, condition registers can be register renamed just like any other ones, so the cpu is already aliasing them like crazy
<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
<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
<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
<Griwes>
...sorry, I lied a bit, *all* instructions can have a predicate specified that controls if they run
ThinkT510 has quit [Quit: WeeChat 3.5]
<Griwes>
(on the other hand that's how you end up with a binary called 'ptxas' that is actually... an optimizing compiler)
<bslsk05>
github.com: lk/asm.S at bce9599d807ac5142e1b380b9dcf371bd995f0d0 · littlekernel/lk · GitHub
<sikkiladho>
by reading docs, it says these are irq,fiq,serror and debug exceptions masks.
<sikkiladho>
but what does they do?
<geist>
that's exactlyright
<geist>
all three of those mask those type of interrupts from firing
<geist>
so it's making sure when it drops to EL1 (from EL2 or above) that they continue to be masked
<geist>
since this is early boot, it keeps that stuff masked off until later
<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
<geist>
and it would instantly fire
<geist>
(if something was pending)
<sikkiladho>
masking means it stops these exceptions from firing?
<geist>
correct
<sikkiladho>
got it!
<geist>
in x86 this is like cli/sti except it's 4 bits for 4 types of exceptions
<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
<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.
<geist>
okay
<kazinsal>
honestly these days I wonder if that's actually a good thing to get people into osdev
<kazinsal>
less weird CISC and legacy 70s/80s crap for people to footgun themselves with
<kazinsal>
"ls: not found" ahhh, I love the user-hostility of install disks for 90s unixes
<geist>
ugh fighting newlib. about to give up
<geist>
trying to return an error from open() and drilling through the layers
<geist>
-1 is not sufficient, it also wants errno to be set to something nonzero
<geist>
like, cripes.
k0valski1889 has quit [Quit: Peace out !]
<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
k0valski1889 has joined #osdev
<moon-child>
Griwes: so ... it's not actually an architecture
<Griwes>
it's a virtual ISA
FireFly has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
GeDaMo has joined #osdev
nyah has joined #osdev
Likorn has joined #osdev
the_lanetly_052_ has joined #osdev
wootehfoot has joined #osdev
<mrvn>
On risc-v conditionals are based on comparing 2 registers? Not just comparing 1 register against 0?
<GeDaMo>
MIPS has that too
<GeDaMo>
Something like beq r2, r3, target
<mrvn>
kazinsal: echo *
<mrvn>
alpha uses just one register for conditional. So you have to sub r0, r1, r2 yourself.
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 260 seconds]
<bslsk05>
stackoverflow.com: Clang C++ Cross Compiler - Generating Windows Executable from Mac OS X - Stack Overflow
<mrvn>
fatal error: 'cstdlib' file not found :( Seems compiler explorer doesn't have it all
wootehfoot has quit [Ping timeout: 260 seconds]
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 260 seconds]
Likorn has quit [Quit: WeeChat 3.4.1]
sikkiladho has quit [Quit: Connection closed for inactivity]
sikkiladho has joined #osdev
<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.
bauen1 has quit [Ping timeout: 260 seconds]
the_lanetly_052 has quit [Remote host closed the connection]
<mrvn>
You know what all Star Trek ships could really use? Seat belts.
<klange>
they just need to upgrade the interntial dampeners
<klange>
intertial, whatever
* kingoffrance
queues clerks monologue Do you think the average stormtrooper knows how to install a toilet main?
heat has joined #osdev
wootehfoot has joined #osdev
Brnocrist has quit [Ping timeout: 260 seconds]
Brnocrist has joined #osdev
<heat>
klange, my OS is also there even though I've never released a 1.0 :V
<mrvn>
kingoffrance: so do the contractors deserve to die or are they innocient?
<mrvn>
Personally I don't think the contractors had a choice. They werent hired to build the death star, they were conscripted.
mahmutov has quit [Ping timeout: 252 seconds]
sikkiladho has quit [Quit: Connection closed for inactivity]
<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
mahmutov has joined #osdev
wootehfoot has quit [Read error: Connection reset by peer]
gog has quit [Ping timeout: 240 seconds]
knusbaum has quit [Ping timeout: 240 seconds]
knusbaum has joined #osdev
<jjuran>
Neither of my OSes is in the list :-(
wxwisiasdf has joined #osdev
<GeDaMo>
In the first Star Trek movie (or at least the novelization), there was a restraining device on the Captain's chair
<bslsk05>
'The Firm - Star Trekkin'' by roopert (00:03:33)
<mrvn>
it's life, but not as we know it
<jimbzy>
Howdy!
<heat>
howd
<jimbzy>
How are you doing, heat?
V has quit [Quit: We're here. We're queer. Connection reset by peer]
<heat>
fine
<heat>
its very warm and i'm not getting any osdev done
V has joined #osdev
<heat>
currently bored implementing a circular buffer for my tracing thing
<heat>
and you?
<mrvn>
with MMU support or without?
<heat>
without
<heat>
the awkward part is that all these tracing records have variable length
<heat>
it's not just a simple ringbuffer
<jimbzy>
I'm just reading about the 65816. It's a beast.
<mrvn>
that makes it complicated to do "% size"
<mrvn>
Have to insert a dummy record whenever the next record doesn't fit in the remaining sace of the ring buffer before warparound.
<heat>
mrvn, yup, so circular buffer of bytes it is
<heat>
and that too
<mrvn>
That's really the use case that calls for MMU support (or mmap in userspace)
<mrvn>
Map the buffer twice then record can warp around the end to the start.
<mrvn>
It's the time of the day again when the sun shines on my monitor.
<heat>
yup, possibly
<heat>
all I want is a tracing system that I can pipe into the host (probably through networking)
<heat>
i tried building GNU hello but I keep hitting a weird bug
<mrvn>
do you have to fix the alignment or endianness?
<heat>
felt like a tracing system that I could pipe into chrome would work fine
<heat>
no?
<heat>
i mean, i packed the structures, and i'l pipe it to the host in json form
<mrvn>
so the ring buffer is actually just the json string?
<heat>
no
<heat>
this is for the kernel, still raw bytes
<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
<mrvn>
if it's packed then you have to read/write it byte-by-byte so doing the warp around is kind of trivial.
<jjuran>
Sulu, go to warparound
<mrvn>
no sure why you would pack it just to json it in the next step though.
<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?
<heat>
i want to compact ktrace records to not waste space
<heat>
yes, that's the design
<mrvn>
So no ring there. just buffers. And the userspace has to re-add buffers once it has processed them.
<heat>
traditionally, this is done in a ring buffer
<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.
<mrvn>
shared memory between user space and kernel.
<heat>
for now, i'll just add a read syscall, no mmapping
<heat>
userspace creates a ktrace listener, specifies the length of the buffer (creation allocates memory for the buffer)
<heat>
so i'm not actually providing a buffer to the kernel
<mrvn>
and then copy from the kernel buffer to the buffer argument in read?
<mrvn>
man am I happy that my kernel doesn't have that at all. All buffers are transfered by mapping pages.
<heat>
yup
sympt has quit [Remote host closed the connection]
<heat>
mmapping a ring buffer and letting userspace do stuff could work
<clever>
i think pcap does that in one mode?
<mrvn>
it's a huge performance improvement.
<heat>
clever, yes
<heat>
PACKET_MMAP
<clever>
mainly because you have high thruput and you cant stall the source
<clever>
most other cases can block the writer
<heat>
no, the writer doesn't block
<heat>
you just drop data
<clever>
exactly
<clever>
but in other api's like plain tcp or filesystem, you block the writer when the buffer is full
<clever>
so the overheads arent as important
<clever>
but with pcap, any overhead leads to lost packets
<clever>
and you cant throttle the source to make it fit
<mrvn>
well, with TCP you could. but who wants that?
<clever>
yeah, you could drop the packet, but thats just going to incur a retry
Likorn has joined #osdev
terminalpusher has quit [Remote host closed the connection]
bauen1 has joined #osdev
dude12312414 has joined #osdev
<geist>
GeDaMo: haha i haven't heard that song in forever
<geist>
used to hear it on Dr Demento forever ago
<geist>
never knew it had a video
<mrvn>
std::stack<int> s; s.top(); // fun
<mrvn>
my cat is pregnant and I don't even have a cat.
<geist>
question for folks that have dealt with existing libcs (instead of writing one) recently
<geist>
any suggestions for which one would be simplest to port to a vaguely posixy system?
<geist>
ie, musl, glibc, bionic, etc?
<geist>
probably musl, but glibc is technically more highly portable i suppose
<geist>
orrrr, if there are any new ones as part of hobby projects that are pretty good quality and thus portable
<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
<mrvn>
I think glibc is rather complex. What about newlib?
<geist>
i'm using that right now but it seems highly limited
<geist>
notably it doesn't really seem to be set up for a multithreaded environment
<geist>
its embedded roots are sticking through
<bauen1>
klange: where can i find the sources / build scripts for the repository of packages for toaruos ?
<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
<geist>
but i should dive into it a bit. but that's what i'm using now for this project
<geist>
also it's unclear if you can even build it as a shared lib
<heat>
geist, musl is relatively simple
<geist>
yah that's probably where i'll go
<heat>
glibc is well, glibc
<geist>
it's pretty linuxy, but we made it work for fuchsia so that's a thing
<heat>
the static linking in glibc is totally broken so that's probably not the libc you want for lk
<geist>
well this is for a user space for LK
<heat>
bionic... i'm not sure anyone has ever used it besides android
<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
<geist>
and in that case shared libc is much more desirable
<heat>
yeah i know, but glibc would make it a thicc kernel :P
<geist>
again, this is for user space
<heat>
*shrug* static linking is still pretty slim
<geist>
and thus a separate set of binaries, wont link with the kernel
<heat>
but yeah, musl is a good choice for both ways
<geist>
yah probably will look at that
<geist>
is that what you're using for yours?
<heat>
yes
<geist>
i'm feeling a bit left out of the userspace os club lately
<heat>
:D
<geist>
though i did it 21 years ago for the first time, i can't really claim that works right now
<geist>
since the code has aged
<geist>
also it was a much simpler time
<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)
<heat>
threads also spawn themselves with clone(), you may want to fix that
<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
<geist>
the latter is what i was thinking of doing, sort of vdso style
<geist>
or is there at least a syscalls/<add os here/ layer?
<heat>
i didn't
<heat>
my syscalls use linux style calls (i.e volatile asm ("syscall" :: ...))
<geist>
ah so you basically implemented more or less verbatim linux syscalls?
<j`ey>
what about the syscall numbers?
<heat>
I think 32-bit x86 code uses the vsyscall to do system calls so you can probably look into that
<heat>
but calling actual system calls? you'd need to convert the internal syscall(SYS_blah) into blah(...) calls
<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
<heat>
each arch has a syscall.h.in that has the system call numbers
<gamozo>
Oh no who's digging into newlib?
<geist>
it just expects you to implement a bunch of _open _read, etc syscalls in some lib somewhere
<heat>
that thing is preprocessed so each __NR gets a __NR and a SYS_
<geist>
so i then just have a liblk.a that i link with it
<geist>
gamozo: i am currently, but not particularly happy with the results
<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.
<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
<heat>
s/most of/most of the linux/
<heat>
possibly in an automated way if you're a regex god
<geist>
gamozo: yah i thik that's really what its designed for. largely single instance embedded style things
<geist>
and i'm not faulting it for that really
<heat>
some system calls are done in assembly (clone.s for instance) but those are very few
<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)
<geist>
i remem er years ago BeOS did something like that which i always thought was a good idea
<geist>
vs having syscalls directly in the libc
<geist>
(or in the process)
<heat>
you mean libfdio?
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<geist>
yah though it may all be gone now, but that's what we did initially
<heat>
the docs still mention it
<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
<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
<geist>
for lack of any better ideas i think i'll just morph this lkuser thing into a vaguely beosish syscall layer
<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
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<heat>
huh
<heat>
how raw of a VM api?
<geist>
oh like create region, delete region, etc
<geist>
or maybe even something more vmoish
<geist>
like dodsn't need to use shenanigans like mapping /dev/zero to really mean make an anoymous region
<geist>
can have a vm_create_region() and a vm_map_file() for example as two calls
<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
<mrvn>
heat: first thing I would always do right away with such code: typdef the callback.
<zid>
record, record length, a callback, and a general context
<geist>
they used spaces, but otherwise it looks like properly formatted obfuscated code
<zid>
and it's extracting various bytes of the dns record
<zid>
without the __dns_parse name though it'd be utter nonsense
<mrvn>
r + rlen are kind of short names. What's that? the request as raw bytes?
<geist>
like a comment describing the record format and what it's extracting would help immensely
<zid>
stick a link to the dns rfc at the top ;)
<geist>
right exactly
<zid>
It just needs a couple of comments for what those fields represent and it's fine imo
<mrvn>
Is that parsing the request or the response?
<geist>
right
<zid>
/* Discard records that don't have the response bit set */ if(r[3] & 15) return 0;
<zid>
or whatever
<heat>
response
<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
<zid>
You can comment, or you can assign everything to vars with useful names
<zid>
but that'd be a full rewrite
<heat>
but but comments get out of sync and are bad
<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
<zid>
comments are simpler in this case
<heat>
self documenting code
<geist>
unless the function literally gets repurposed for some different thing
<mrvn>
zid: yeah, that code needs an enum for 15 and 193
<zid>
On the plus side, those are tabs
<zid>
and the includes are clean
<heat>
the musl libc folks know what they're doing
<heat>
but the code is usually unreadable as shit
<geist>
yah the 15 and 193 are pretty dumb
<zid>
I don't like the lack of spaces around the < and > operators
<heat>
although it has gotten better, mallocng is pretty readable
<zid>
I'm on the fence about random enums
<geist>
yah that one is annoying, but that gets fairly subjective so i'm just leaving it out
<mrvn>
zid: except later it has spaces. inconsistent
<mrvn>
zid: nameless enums. Just the C way of declaring constants.
<geist>
agreed. i dont think you have to enum/define *everything*, or if you do at least do it near the thing
<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
<geist>
since now you define some constant 500 lines away to be used exactly once
<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
<geist>
right
<geist>
so i have used it in the past to satisfy the rule by putting it nearby, in the same function, etc
<geist>
if it's used once
<zid>
I've done interprocedural defines a few times
<geist>
and then i think that's probably a decent compromise
<mrvn>
geist: the enum should be right before the function and just define the constant the function uses.
<zid>
int main() { #define LEN 512 ..... #undef LEN }
<zid>
:D
<geist>
mrvn: yeah but then there are dogged rules about 'can't put things in between functions, should be at the top' etc
<geist>
that inevitably get applied
<mrvn>
geist: that's a bad rule then
<zid>
I prefer that rule to 'enum everything'
<geist>
agreed. but rules are rules
<zid>
if I had to pick between two rules
<geist>
mrvn: aren't you german?
<mrvn>
geist: so?
<mrvn>
rules are mend to be broken. :)
<geist>
rules!
<mrvn>
Hey, put the function in it's own file then the enum is at the top :)
<geist>
there's a procedure!
<mrvn>
like here
<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
<geist>
thta's like the Sabbath Mode my oven has
<mrvn>
What's qdcount and ancount?
<heat>
obviously, they're the count of qd's and an's
<heat>
self documenting code
<geist>
i guess if i just knew the format it'd be easier
<geist>
i also dot completely get the 193 and whatnot. thats out of ascii range
<mrvn>
geist: it's a const unsigned char *, it's not a string.
<mrvn>
Say the "while" before that exits because "p-r == rlen" then *p is accesing the response one byte after the buffer.
<zid>
I need to know more of what the code is trying to do to change this more I think
<mrvn>
zid: I think that dns_bad_seq is less readable.
<mrvn>
zid: net_short_at is UB
<zid>
I think literally everything you say is incorrect, so that's basically a badge of honor.
<mrvn>
well, implementation defined
<mrvn>
On systems where int is 16bit it overflows. So actually really UB.
<heat>
oh no
<heat>
the famous 16-bit linux systems
<mrvn>
heat: no, the musl port to avr.
<mrvn>
or ARM with thumb
<heat>
404 not found
<mrvn>
But don't worry, the original was UB already.
<heat>
how is that UB anyways?
<zid>
It isn't he doesn't know what it means
<mrvn>
heat: 193 << 8 is a signed integer overflow
<zid>
good job it's unsigned then
* geist
feels the heat from the burns
<mrvn>
zid: it isn't. unsigned char gets promoted to int before the shift operation
<geist>
SICK BURN
<heat>
bern
mahmutov has quit [Ping timeout: 240 seconds]
<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.
<zid>
E1*
<zid>
I guess that's post promotion though
<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:
<zid>
Still isn't UB, it just has a chance of being UB
<zid>
on a platform on which this isn't
<mrvn>
Integer promotion is the implicit conversion of a value of any integer type with rank less or equal to rank of int ...
<zid>
One of the many joys of the C spec
<mrvn>
zid: as said, it fails when int is 16bit.
<zid>
which it isn't
<zid>
things being UB only if they're in certain cases is one of the *really* shitty things about C
<mrvn>
zid: what isn't? The source? The source has no arch.
<heat>
musl doesn't fit in 64K or 1MB
<zid>
It's an invariant of the code
<zid>
same reason I can do b[0] and b[1] without some magic length check
<heat>
this is for real architectures, not an 80286
<zid>
It's required that the parent function calls it in a way that that won't be UB
<mrvn>
The bad part actually is that you basically can't write this code not to be technically UB at all.
<zid>
You absolutely can
<zid>
You just need to manually promote, or make it an invariant, which it already is
<zid>
It isn't UB until you try to compile it, just throw an error in autoconf or whatever about 16bit int, done
<mrvn>
For this specific construct casting to u16 will be enough.
eau has quit [Quit: bleh!]
<mrvn>
if you had a b[0] * b[1] in there then it gets tricky.
<geist>
heat: uh oh you've stirred the angry god of 16 bit Protected Mode
<zid>
I fell foul of small unsigned to larger signed a couple of times in some bitmath years ago
<zid>
I've never slept properly since
* heat
gets descriptor table'd to death
<mrvn>
It really sucks that you can not turn the integer promotion off at all
<zid>
-Wconversion -Werror
<zid>
done
<zid>
Now it's off
<mrvn>
no, now it just gives warning for some cases
<mrvn>
(and then fails)
<heat>
anyway
<mrvn>
anyway, back to the original code. In line 18 or line 24 doesn't that risk a buffer overflow?
<heat>
some musl code bad, some musl code good, most musl code correct
<heat>
fun fact: systemd still can't compile with musl without a bunch of patches
<heat>
they explicitly require glibc
<mrvn>
Should be: if (p>r+rlen-6 || *p>193 || (*p==193 && p[1]>254))
<j`ey>
systemd bad
<heat>
unix philosophy good
<mrvn>
First check if there is enough bytes left in the response, then test those bytes.
<heat>
give pipe and small program
<mrvn>
Line 27 another buffer overflow
<zid>
Anyway, this comes back to my "I'd rather I just wrote it, it's going to be of dubious quality either way"
<zid>
I'd probably end up with a little accessor macro or function or something that checked rlen against the offset
<heat>
you realise that none of those are actual problems since root is the one who sets the dns server, right?
<zid>
people run the wrong things setuid a lot :(
<zid>
Then people claim it's a CVE in your code, not a CVE in their distro
<zid>
rude
<mrvn>
Line 24 I think should be: if (p>r+rlen-12 || *p>193 || (*p==193 && p[1]>254))
<mrvn>
heat: you have a local DNS server on your system? Not using 8.8.8.8?
<zid>
One thing a friend did recently that I kinda liked was make a throwaway struct to abstract out a buffer
<heat>
is 8.8.8.8 pwning you?
<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
<heat>
and yes, lots of people have local dns servers
<heat>
like systemd-resolve
* heat
hurr durrs systemd bad
<zid>
systemd bad.
<mrvn>
heat: I wouldn't trust it to never send me corrupt dns repsonses.
<zid>
sysvinit is also bad, but systemd bad.
<heat>
systemd horrendous
<heat>
systemd made my wife leave me
<zid>
systemd made my X break
<zid>
cus I can't remember which greeter package I installed to fix it
<heat>
mostly because i kept rambling how systemd is horrible and ignored her for 15 years
<zid>
It probably starts with an x, so I can't tab complete it
<zid>
because it's like x [17843 results]
<geist>
one cool feature of systemd that i did figureo ut recently was it has a fairly nice integrated nfs automounter
<zid>
"xdm, xwm, xgreet, x... yea sure one of these is probably right..."
<geist>
you just have to tag the fstab entry with some magic goop and then it just works
<heat>
b-b-but systemd bad?????
<geist>
but of course figuriung out the magic goop was to copy paste it off the internet
<geist>
so that's bad
<zid>
systemd is a necessary thing to like, make a modern system like say, windows 95
<zid>
but systemd itself is just a bad implementation
<heat>
systemd is just linux's launchd
<zid>
They spelled launchd wrong, can we bugrep that
<heat>
linux people are more focused in the "muh choice muh freedom" and less in the "we have something that works"
<geist>
i was under the impression it was somewhat inspired by the apple thing
<heat>
zid, nvidia is looking for a good spell checker you might wanna help out as well
<zid>
If I wanted something that worked why would I install linux
<geist>
i forget what it is called,launchd? i forget
<zid>
riddle me that
<zid>
I think geist may be scrolled up
<heat>
hahahaha
<geist>
yah i had no interested in reading your gripes
<geist>
did someone mention that before?
<j`ey>
interestd
<zid>
zied
<heat>
yeah maybe someone mentiond that before
dh` has joined #osdev
<zid>
heat: Didn't answer my incredibly serious question about why I'd install linux if I wanted a machine to work
<geist>
okay. i saw someonemention linux launchd, but i think apple has a whole different thing
<zid>
launchd is the apple thing
<geist>
but kinda similar in the big pluggable init replacement thingy
<geist>
ah
<geist>
didn't know it was open sourcableenough to be ported
<heat>
the systemd author was directly inspired by launchd
<heat>
but it's a different thing
<zid>
wiki page says 2006 ubuntu considered it, but rejected it due to the licence
<heat>
although it's been ported to some BSDs before (all rotted)
<geist>
yah also i remember android had/has something kinda similar
<zid>
late 2006 apple relicenced it, and it got ported to freebsd, etc
<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
<geist>
on a say 600mhz arm it would actually take seconds to spawn 1000 sh scripts to decide to do nothing at all
<zid>
That's another program with a missing e
<zid>
I'd like a sysvinit that was just written in C instead of bash
<geist>
i think as a result we wrote our own udev replacement and rolled it into our init, or something like that
<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
<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
<heat>
systemd doesn't have binary configs
<geist>
and on boot linux delivers basically a huge pile of udev notifications
<heat>
it's all budget .ini's
<zid>
really? that was everybody's main gripe I kept seeing
<zid>
binary this and binary that
<heat>
launchd has the .ini's and binary configs now IIRC
<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
<zid>
I love ini
<geist>
or at least on low end machines. on high end machiens you probably can't tellthe difference
<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
<zid>
because javascript can't open files, only eval other 'scripts'
<heat>
i commonly use json
<geist>
agreed. ini files are a nice format honestly
<zid>
People kept trying to get me to use YAML on one of my projects
<geist>
clearly limited, but nice to work with as a human
<zid>
Literally nobody could explain to me why
<zid>
"It has a date format!"
<heat>
json is compact and there are already parsers for it in any language
<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
<heat>
and I hate writing parsers
nyah has quit [Quit: leaving]
<zid>
so I've skippped.. precisely 0 steps, but now the config takes 10x as long to load and uses a custom format
<geist>
there's a quote in there somewhere
<geist>
here to chew bubblegum and parse json...
<heat>
and im all out of json
nyah has joined #osdev
<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
<zid>
so yea, people will avoid ini like the plague just.. to make their code slower, apparently
<clever>
ive been considering using lua for my config
<zid>
Do you mean 'runtime moduluar behavior' by 'config'
<zid>
or 'config'
<clever>
config with the ability to change params based on arbitrary data, like model or serial#
<zid>
okay sounds like you still want ini to me
sympt has joined #osdev
<clever>
the rpi has a mess of [gpio4=1] to make certain blocks only run if a gpio is high
<heat>
i think you all want xml
<clever>
and [pi4] to make certain blocks only run on a pi4
<zid>
heat with the best ideas only
<clever>
but if you do both, they become an AND condition!
<zid>
That sounds like a job for.. two ini files :P
<clever>
so you cant just run it thru a standard ini parser, you need to know that 2 sections occured in a certain order
<clever>
i dont want to make the mess worse, so i'm just going to throw a proper turing complete language at it
<zid>
they just decided to be 'clever' and try to embed logic into a config file
<clever>
and the user can make whatever mess they want :P
<zid>
instead of just making two files
<clever>
the rpi firmware can also make config conditional on EDID model names
<zid>
so can filenames
<clever>
and serial#
<zid>
which is how like, literally thousands of my pieces of software already work
<clever>
except, all of those conditional flags, gate the same single set of options
<clever>
and when you define an option in 2 files, what is the priority?
<zid>
you open blah/ for the settings and icons and stuff for your 'blah' module
<zid>
generic.ini sits outside of it
<clever>
but then how do you use gpio pins to filter things?
<zid>
stat() now does all your heavy lifting instead of some bizzare custom parser, it's easier for the end user to edit, etc
<heat>
use bytecode
<clever>
also, the firmware can swap between config.txt and tryboot.txt for testing
<clever>
heat: lua can be pre-compiled to bytecode, problem solved
<zid>
not sure why the gpio thing is even a problem
<heat>
boring
<heat>
roll your own bytecode
<zid>
put it in a block
<clever>
zid: you can combine gpio and model filters, so adding multiple files into the mix complicates it
<heat>
what if
<heat>
and hold on for a second, you're going to love it
<heat>
you use
<heat>
AML
<mrvn>
forth
<clever>
lol
<zid>
clever: SO you're worried about there being repetition, or what?
<clever>
zid: thats part of it
<zid>
If we're talking thousands of model combinations or whatever I could understand it
<heat>
need conditions? ✅
<clever>
just having a lua function, where state goes in, config comes out, is simple
<heat>
need to describe hardware? ✅
<zid>
but with like.. 8.. I really don't care
<zid>
I'd just make 8 ini files
<zid>
don't make it a code problem until it's a code problem sort of deal
<clever>
but the official firmware has an [all] section in its config, for applying defaults to any model
<bslsk05>
www.raspberrypi.com: Raspberry Pi Documentation - The config.txt file
<zid>
and then model/whatever specific overrides in the matching filename file
<clever>
it also has a [board-type=0x15] filter
<clever>
so you can filter on models that dont yet have an official name
<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
<clever>
yeah
<heat>
i feel like writing a good ol driver
<zid>
you either end up writing a heirarchical filesystem sort of thing that gets sorta messy, or a sort of messy custom config
<zid>
the reality is the problem, reality is messy
<heat>
hierarchical bytecode thing that describes hardware
<heat>
where have i heard of that before
<clever>
device tree!
<heat>
hmm no, that's not bytecode
<clever>
acpi?
<zid>
ACPI
<mrvn>
device tree has no conditionals
eau has joined #osdev
<heat>
that's it
<heat>
ACPI
<zid>
none of this is conditional to be fair, it's just matching
<clever>
i think acpi is turing complete?
<zid>
which ini is fine on
<heat>
clever, what do you need to be turing complete?
<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
<zid>
and you just strtok on dots and strcmp things
<clever>
heat: i dont need turing completeness, but having it would enable some boot to basic style things
<clever>
zid: the rpi config files are more complex then just section.key=value
<geist>
ini plus some something variable substitution, single pass, might be nice
<geist>
or that, but i'm saying for a runtime thing
<geist>
like in your bootloader, etc
<geist>
you could do some ${FOO} style inline replacement
<zid>
oh so like, you have internal #defines you set at boot
<zid>
and that impacts how the config parses
<geist>
right
<heat>
edk2's configs have wildcards
<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
<geist>
uboot does stuff kinda like this, but mostly in the form of a shell like scripting language
<zid>
I mean it's ultimately the same as just checking the key with strcmp
<zid>
just phrased differently
<geist>
and lots of environment variables that among other thigns contain snippets of shell script
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
eau has quit [Quit: bleh!]
<heat>
i915, nvme or usb?
<zid>
82810
<heat>
no i810
<zid>
but it has a hardware rng!
<heat>
so does x86
<heat>
they're both crap
<zid>
x86 didn't between skylake and i810 :(
<mrvn>
but can you trust them? 8-P
<geist>
well, it's entropy
<geist>
that's what you shouldtreat it as, it's not a rng, it's an entropy source
<zid>
xor it with 47
<zid>
then it's secure
<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.
<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
<heat>
if rdrand is compromised you have larger issues than that
<zid>
so you're already fucked at that point
<clever>
zid: the rpi firmware has a list of keys in it, protected by an xor against a constant, lol
<zid>
that actually counts as DRM
<clever>
if you dont know what your looking for, its invisible
<mrvn>
zid: assuming you have other sources
<zid>
which makes circumventing it illegal under UK DMCA
<clever>
zid: those keys are also naked in the OTP, and can simply be read out
<clever>
you just need 1 of every model
<zid>
I think vice city for ps2 was xored with 47
<mrvn>
zid: european law doesn't accept weak crypto as protected DRM
<heat>
they should've xor'd the definitive edition with 47 too
<zid>
The UK is not in europe bro
<mrvn>
zid: sure. but I'm not in the UK and don't care what they consider legal.
<zid>
We're officially part of the north pole
<zid>
so why are you talking
<heat>
"EU legislation as it applied to the UK on 31 December 2020 is now a part of UK domestic legislation"
<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
<jimbzy>
Good gravy. I sat down in the recliner and lost 3.5 hours of my day.
<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
<jimbzy>
Hah. Nah, I just stayed up till 3:00 this morning and got back up around 6:00
<zid>
I also have it
<zid>
I lose about 8 hours a night to it
<mrvn>
covid made it worse
scoobydoob has joined #osdev
<heat>
screw it
<heat>
i'm rouletting it
<mrvn>
red 7
scoobydoo_ has quit [Ping timeout: 276 seconds]
<jimbzy>
8 hours? I haven
<heat>
i got usb
<jimbzy>
't had 8 hours of sleep in a row in years...
<heat>
do i want to do usb? meh
<mrvn>
jimbzy: that isn't healthy, seriously not healthy
<jimbzy>
mrvn, Yeah I know, but sleeping meds literally put me in a coma.
<mrvn>
well, sleeping meds are just as bad
<jimbzy>
That's the only way I'll sleep more than 6 straight.
<jimbzy>
In other news, I think I'm going to have a go at building a 65C02-based microcomputer.
<zid>
neat, expect it to be able to do anything, or just going to poc it?
<jimbzy>
Pretty much poc, but who knows?
<zid>
A fancy knightrider box is always fun still
<mrvn>
jimbzy: you can buy a C64 kit with board, all the chips and even the breadbox.
<jimbzy>
I've already owned a C64, mrvn.
<mrvn>
don't want one back?
<jimbzy>
Maybe some day, but I want to build something different.
<zid>
I think most fun would just be using it as a project box for other things
<zid>
like, exposing its memory bus or whatever
<zid>
and then using it sort of like an arduino
<zid>
make it a memory mapped network card, or video card, or whatever
<mrvn>
I have 90% of an actual video card build myself.
<jimbzy>
I think Ben Eater has a VGA card kit.
<zid>
it's also terrible because it isn't memory mapped
<zid>
it uses shared memory via bus sharing
<mrvn>
I have video ram that have 2 ports.
<mrvn>
The read/write port connects to the bus, the read-only port for the video output.
<jimbzy>
Yeah. It's literally billed as "The Worst video card ever" XD
<zid>
It'd honestly have been easier to build it better :p
<jimbzy>
Well, when I get to that point you can advise me. ;)
<zid>
I don't have any 15kHz displays :(
<mrvn>
Ben Eater's VGA card can be all bad, it has PORN. Well, the Lena picture from Playboy common to many graphic tests.
<mrvn>
zid: your TFT has no VGA in?
<zid>
I don't have any 15kHz displays.
<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"
<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.
<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.
<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.
<zid>
lena has asked for it to not be used anymore, fyi
<mrvn>
Odd. It's just a headshot. Nothing to be ashamed about.
<mrvn>
retired in 2019, well, it was fun while it lasted.
<mrvn>
Delving deeper into the mysteries of C++ history: Why is this a pointer and not a reference? Can this be nullptr?
<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
<jimbzy>
I've always been told that "C with Classes" was doing it wrong.
<mrvn>
jimbzy: that's how C++ got started.
<jimbzy>
Yeah, I know and that's how many of the early C++ books I had taught it.