xFCFFDFFFFEFFFAF has quit [Ping timeout: 240 seconds]
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
skydhash has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<GreaseMonkey>
was messing with a real NE2000 clone (yep, that ISAPnPshit card) and managed to extract and apply the MAC address w/o much fuss, i'd need to do a bit more documentation reading to work out how to receive packets properly but it honestly doesn't seem like a particularly difficult card to use outside of an emulator
<geist>
GreaseMonkey: huh you were actually using the ISAPNP bios or reading the data structures directly?
<geist>
i only vaguely remember reading some technical bits on how it worked
<geist>
oh i see on the ne2000 itself? yeah it's very simple. lots of cards of that era had a similar design. IIRC it just puts the RX packets in a circular buffer and the TX is... i forgoet. load up a fifo and say go
<geist>
much like how the later rtl8139 worked
<Mutabah>
8139 had four TX descriptors, so you can be preparing an outgoing packet while the previous is sending
<Mutabah>
but... no scatter-gather DMA, so loses points there
<geist>
and you could point them in memory somewhere. i think the ne2000 era stuff was all onboard memory
<Mutabah>
yup
<geist>
and iirc the on board memory was like 2K. so you were pretty tight, basically had enough buffer to cache a packet
<azonenberg>
Scatter-gather is never something i've had to use myself, but my IP stacks tend to be very simple and lightweight
<azonenberg>
like, the one i use in most of my firmware now isn't bsd sockets API or close to it
<azonenberg>
it's a zero-copy flow where you explicitly request a MTU-sized buffer from the buffer list and push your frame content to the payload region
xenos1984 has quit [Read error: Connection reset by peer]
<azonenberg>
then send
<geist>
yah usually i build an mbuf style chain buffer thing for the net stack, and then when you get down to the device if it supports scatter gather you can just dma into/out of the individual buffers
<azonenberg>
So if you're sending to a TCP socket, you don't send(local pointer)
<geist>
worst case you have to flatten it (oe memcpy) to a buffer and DMA from that
<Mutabah>
Withoug SG DMA you need to ensure that the packet doesn't cross a page boundary
<azonenberg>
you GetTxFrame() then fill out the content
<azonenberg>
and just can't send more than one MSS per request
<geist>
which at least for 1500 bytes you can basicall split a page into two 2K buffers and go to town
alpha2023 has quit [Read error: Connection reset by peer]
<azonenberg>
Yeah i'm also working on cortex-m7 not x86 here :)
<azonenberg>
i dont even think it has a concept of paging although the hardware DMA does have some alignment restrictions iirc
<azonenberg>
right now my ip stack isn't even using DMA on this particular board, since i'm not using the hard ethernet MAC on the chip (I'm hanging my micro off an FPGA that has a 10G fiber MAC on it, and it takes packets of interest for the management system and shoves them in a FIFO I read over quad SPI when IRQ is asserted)
<azonenberg>
i can definitely get more performance using DMA but it's still surprisingly fast
<geist>
yeah
<azonenberg>
like, something like 85 ms from TCP SYN to SSH console open
<azonenberg>
(this is with hardware accelerated crypto, the MCU has hard AES-GCM and I have curve25519 offload in the FPGA)
alpha2023 has joined #osdev
<azonenberg>
ssh-ing to this itty bitty stm32 feels as performant as going to an x86 system lol
<azonenberg>
So i havent really felt the need to spend time adding DMA support when it's that fast already
<geist>
as with lots of embedded stuff: most of the time it just needs to be fast enough, doing it any more efficiently than that gets you nothing but wasted time
<azonenberg>
Yep. that said, this is a platform i will be using on a lot of future projects
<azonenberg>
so i want it capable enough to handle current and future needs, not today's needs
<azonenberg>
Which is why i'm working on OTA firmware update now
<azonenberg>
and a proper bootloader flow
<azonenberg>
(doing it right, by my definition - no sketchy web form you push a file to, it'll just use sftp)
<azonenberg>
the challenge is that this is a multi-chip system involving components that i can't just trivially shut off and hope for the best
<azonenberg>
(for example, one of the processors controls power to everything else on the board)
<azonenberg>
For this design i dont think i have enough flash to include bootloader+app partition on that chip but the next project i'll choose something larger so i can enable that
xenos1984 has joined #osdev
<geist>
yeah the stm32f7s are nice. i hvae a couple of the discovery boards with the big LCD that i use as the main cortex-m testing grounds for LK
<azonenberg>
this is a h735
<azonenberg>
on the main processor
<azonenberg>
but the system as a whole has the h735, an L431 on the front panel running the display and LEDs, an L031 on the intermediate bus converter, an L031 on the logic board doing power/reset sequencing, and a Kintex-7 FPGA doing the heavy datapath lifting
<azonenberg>
so figuring out ota update for as much of the system as possible is proving to be fun. I think I'll swap the L031 for maybe a L081 or something in future projects to get more flash space
<azonenberg>
the 031 is fine for stuff i'm never going to update but a bit small for e.g. bootloader plus A/B images
<azonenberg>
and the H735 is annoying because although it has a ton of flash it's 128 kB erase blocks so i'm limited in how i can structure my firmware
<geist>
yeah
<azonenberg>
in particular i have to allocate two whole erase blocks, a whopping 256 kB, to the key-value store i use for storing the SSH key, IP address, and other user-writable config
<azonenberg>
(since this board doesnt have any off-chip flash, which in retrospect was probably a mistake)
<azonenberg>
so if i have one for the bootloader that's only five left over for the app, which is a bit constraining if i want to have A/B images
<azonenberg>
So I'm thinking what i will do instead is have only one app partition, and the bootloader/recovery partition in the first flash block will have enough firmware to bring up a sshd and let me reflash the app
<azonenberg>
That will leave 640 kB free for the app which should be more than enough
vai has joined #osdev
<GreaseMonkey>
geist: for ISAPnP, i made a mental note of what the BIOS's ISAPnP settings are today, although for a more serious one i'd do an ISAPNP bus probe after grabbing the read I/O address + card count from the PNPBIOS
<GreaseMonkey>
and i think the buffer size is 8 KB?
<azonenberg>
Hmmmm
<geist>
yeah that rings a bell. is it 8KB for both tx and rx? maybe iirc you have to configure how you chop it up
<GreaseMonkey>
8 KB total AFAIK
<geist>
like you set the offset registers where the rx and tx end and start
<azonenberg>
If I wanted a unique ID for a firmware build - doesnt matter how it's derived, as long as two compiles give different values - at a known, constant flash address
<azonenberg>
i wonder what the easiest approach is
<vai>
maybe Elon Musk got the idea of X.com from xchat ?
<azonenberg>
i guess i could just make a global static const buffer containing __TIME__ and __DATE__ that i explicitly put in a section at the start of flash
<azonenberg>
right after the vector table
<geist>
azonenberg: for LK i ghave this lib/version thing that stamps a build date into a known data structure
<geist>
it puts a magic/etc around it and using the linker script puts it near the start of the binary
npc has joined #osdev
<geist>
so a) the binary knows what its build is since it’s just a global
<geist>
and b) you can easily grub through a .bin file somewhere and figure out the build id by looking for the structure
<bslsk05>
github.com: lk/lib/buildsig/buildsig.c at master · littlekernel/lk · GitHub
<geist>
basicaly puts that build signature near the start of the build, and then there's a utility functio there to search for it. useful for a bootloader build
<bslsk05>
github.com: lk/lib/version/buildid.sh at master · littlekernel/lk · GitHub
<geist>
feel free to steal any or all of thatif you want
<geist>
the only real trick isthe linker script has to have a callout for .text.boot to put it near the start
<geist>
though really it doesn’t matter if its anywhere in particular, but putting it near the start of the binary limits how far you need to search
<azonenberg>
yeah so what i decided to do here is just put it at a 32-byte aligned address after the vector table
<azonenberg>
which is a known size
<azonenberg>
so it should be at a constant address with no searching needed
<azonenberg>
The use case is a checksumming bootloader. basically i want to allow me to jtag a new firmware whenever
<azonenberg>
but once i've loaded a firmware it should detect corruption
<azonenberg>
so the idea is, it will see if the firmware version string i have cached in the config store matches the image in flash
<azonenberg>
if so, it will crc/sha the firmware, check if the image matches the saved hash, and only let it boot if it passes
<azonenberg>
if the version strings are different, i assume i've been updated (there is a small but nonzero chance of bitrot affecting the version string, i accept that risk)
<azonenberg>
it will then re-hash the current flash contents and save for the future
<azonenberg>
basically trust-on-first-use like SSH
<azonenberg>
the idea is, i can jtag a new binary over the app partition and the bootloader will automatically integrity-check it after the first boot
<azonenberg>
(if i load a new image via the bootloader, however, the expected hash will be pre-computed as part of the update process allowing me to detect a bad flash)
<azonenberg>
this seemed like the best option to get integrity verification while not forcing *all* updates to go through the bootloader, at least during dev
* geist
nods
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
gbowne1 has quit [Quit: Leaving]
xenos1984 has quit [Ping timeout: 256 seconds]
<GreaseMonkey>
today's achievement: i managed to do the fancy song and dance that it takes to get a Linux 64-bit process to run 16-bit code
<GreaseMonkey>
on x86, 64-bit code can handle a 32-bit flat stack, and 32-bit code can handle a 16-bit segmented stack, but 64-bit code cannot use a 16-bit segmented stack unless one really wants to map something into the first 64 KB of virtual memory space
<GreaseMonkey>
so while running in a 32-bit process one can use a 16-bit segmented stack for as long as one can get away with only having 64 KB in a stack... for a 64-bit process, if the bulk of the code is in there, then one has to switch to the 32-bit stack to call out to 64-bit code
<azonenberg>
gotta love special magic SFRs that do nothing
<azonenberg>
its just a random 8-bit memory mapped register
<azonenberg>
Also, does anybody else wish libc had an optimized "memcpy without incrementing destination address" method?
<azonenberg>
as in for(i=0 to len) sfr = input[i]
<GreaseMonkey>
ah yes, the STM32 CRC unit
<GreaseMonkey>
protip, don't use that without DMA, it's *possibly* faster to do it in software... but with DMA it should be possible to go faster than software
alexander has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
<GreaseMonkey>
(also, doing it in software has the advantage of not having to work out who gets to use the CRC unit when)
<GreaseMonkey>
a libc function for that would actually be quite useful but if you're using whatever the heck nano libc is called these days then it's still going to give you an annoyingly slow one
vai has quit [Ping timeout: 256 seconds]
goliath has joined #osdev
<GreaseMonkey>
(for some stupid reason the memcpy and memset provided not only does one byte at a time, but it also does the hideous double-jump arrangement)
<GreaseMonkey>
(as in, 2 jump instructions per loop, rather than jumping into the middle and then doing one conditional jump for the whole loop)
alexander has joined #osdev
Burgundy has joined #osdev
Burgundy has quit [Remote host closed the connection]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
aws has joined #osdev
GeDaMo has joined #osdev
navi has joined #osdev
navi has quit [Client Quit]
navi has joined #osdev
aws has quit [Quit: leaving]
<azonenberg>
i'm using newlib and have not looked at their implementation of __builtin_memcpy (or whether they use something from gcc vs something in newlib)
<azonenberg>
And i'm just doing a simple software implementation to start but will probably set up DMA at some point
<azonenberg>
first step is just make it work
vdamewood has joined #osdev
<GreaseMonkey>
update on the 16-bit-on-64-bit thing: i am now able to call out to 32/64-bit code \:D/
<azonenberg>
woop ok my bootloader is checksumming the application partition and detecting both JTAG reflashes (in which case it records the current checksum for validation next boot) and flash corruption (in which case it falls into the DFU flow)
<azonenberg>
and then it prints out a log message saying it's booting the application but doesnt actually do so :p
<azonenberg>
So now i have to actually write the logic to boot the app
<azonenberg>
I think this should be as simple as updating VTOR to point to the new vector table, updating the stack pointer to point to the stack pointer at the start of the vector
<azonenberg>
then jumping to the reset vector
k0valski18891621 has joined #osdev
vai has joined #osdev
gog has joined #osdev
srjek has joined #osdev
leg7 has joined #osdev
<leg7>
hello
<leg7>
I'm trying to write an 8042 ps2 controller driver but when I test the devices it fails?
<bslsk05>
github.com: LigmaOS/src/kernel/architecture/x86/32/io.nasm32.asm at 8042 · leg7/LigmaOS · GitHub
<leg7>
well my io function were wrong
<leg7>
I didn't reset the stack frame on the function calls because I'm not using the stack but I forgot to use esp to access the parameters instead of ebp
* leg7
facepalm
<ddevault>
oh shit my waitqueue implementation worked on the first try
<ddevault>
somehow I end up in userspace with interrupts disabled, though
<ddevault>
but I think that may predate all of my waitqueue stuff
foudfou has quit [Remote host closed the connection]
<ddevault>
oh, no, rflags is fine, but something is wrong with the PIT IRQ
foudfou has joined #osdev
<ddevault>
ah, I see.
<ddevault>
yeah, the waitqueues are good. woohoo!
m257 has joined #osdev
d5k has joined #osdev
<azonenberg>
ddevault: userspace with interrupts disabled
<azonenberg>
lol
<azonenberg>
I actually looked into a system years ago that would do this on purpose
<azonenberg>
Maybe one day i'll have time to get back to it
<ddevault>
you can do this on purpose if you only have one schedulable task
<ddevault>
well, no
<ddevault>
you can disable the PIT in that case, not interrupts entirely
<azonenberg>
The basic idea was to create a version of my Antikernel OS for the xilinx Zynq SoC or a similar FPGA+CPU platform
<azonenberg>
so, you map some chunk of RAM plus one AXI bus to the FPGA into memory for the arm core
<azonenberg>
set the vector table to an unmapped address
<azonenberg>
disable interrupts
<azonenberg>
and drop to userspce
<azonenberg>
Now you're stuck in a padded cell, you can't touch anything but what you were given access to
<azonenberg>
and you can never get it back
<azonenberg>
but, this is the key, only your software on the CPU has these restrictions
<azonenberg>
the rest of the FPGA is not so sandboxed
<azonenberg>
So, my plan was to have a timer running in the FPGA that would periodically access the CoreSight APB bus
<azonenberg>
halt the CPU from the outside
<azonenberg>
save all of the registers to a saved context structure in FPGA fabric, then load a new context and resume the CPU at a different address with a different page table
<azonenberg>
essentially implementing pre-emptive multitasking from outside the CPU
<azonenberg>
without the CPU itself ever entering supervisor/kernel mode after the initial boot had completed
<azonenberg>
but, this is the important part, the CPU is unable to do anything the FPGA doesn't permit it to
<azonenberg>
once you do the initial sandbox creation, for example, access to any other memory mapped IO is impossible
<azonenberg>
all you can do is push messages to the one axi link to the FPGA and have it do whatever it wants with that traffic
<azonenberg>
it's almost like inverse TrustZone
<azonenberg>
except instead of having ultra-trusted code on the CPU that has special rights, you do the opposite, the CPU is explicitly untrusted
m257 has quit [Ping timeout: 250 seconds]
m257 has joined #osdev
d5k has quit [Ping timeout: 256 seconds]
<leg7>
There is a command to write to the second ps2 device input buffer (0xD4). Is there a command to write to the buffer of the first device?
theyneversleep has joined #osdev
d5k has joined #osdev
Matt|home has quit [Quit: Leaving]
frkazoid333 has quit [Ping timeout: 268 seconds]
d5k has quit [Ping timeout: 245 seconds]
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
leg7 has quit [Ping timeout: 240 seconds]
m257 has quit [Ping timeout: 250 seconds]
frkazoid333 has joined #osdev
edr has joined #osdev
m257 has joined #osdev
m257 has quit [Quit: Client closed]
heat has joined #osdev
Left_Turn has joined #osdev
skydhash has joined #osdev
skydhash has quit [Client Quit]
xenos1984 has quit [Ping timeout: 268 seconds]
xenos1984 has joined #osdev
<ddevault>
how do most unicies handle the keyboard hand-off from the kernel vt to userspace, i.e. when starting x11
<ddevault>
my uninformed guess is that they just stop using it for vt input as soon as anyone in userspace has opened the device file
goliath has quit [Quit: SIGSEGV]
<heat>
linux has a console ioctl
<heat>
yeah KD_GRAPHICS, see console_ioctl(4)
<heat>
and KDSKBMODE
<ddevault>
I see
<ddevault>
well, I do not particularly like it. seems cleaner to have the kernel stop using the fb and kb automatically as userspace makes use of those files
<ddevault>
maybe I just hate ioctls
<ddevault>
and I do hate ioctls
<heat>
maybe
<ddevault>
I'm going to avoid ioctls as long as possible so I'll go with this route
<heat>
what's a unix without ioctls
<ddevault>
a fucking good unix, finally
<heat>
it's like a circus without clowns
<ddevault>
well, really, what's a unix without signals
<ddevault>
therefore a good unix is not possible
<heat>
correct!
<heat>
how are you doing termios? syscalls?
<ddevault>
I'm not doing termios
<heat>
darn
<heat>
well that's important
<ddevault>
if I do I'll do fucking ioctls
<ddevault>
because posix
<heat>
also don't forget fcntl, the fd's ioctl
<ddevault>
I already sold my soul when I decided to make a unix, I'm just pretending it's not so for as long as possible
<ddevault>
fcntl is not the worst, it's kind of poorly designed but I don't harbor the same hatred for it as I have for ioctl
<heat>
ioctl is objectively iffy as long as you get into ioctl number soup with undocumented binary data going back and forth
<heat>
other multiplexing syscalls are /okay/ but e.g fcntl is a mess of crap they decided to throw in there without making a proper syscall
<clever>
ive managed to panic my kernel, by just loading the wrong mesa driver
<clever>
one of the very first things the vc4 driver does, is issue a ioctl to query the kernel vc4 version
<clever>
the ioctl number, lines up with a totally unrelated function on the amdgpu driver, and oh, the buffer userland supplied was the wrong size, *OOPS*
<Ermine>
Idk how to design a system without ioctls or similar
<clever>
id say you should start, by having a better api on how to know when an ioctl is supported
<clever>
for example, some standard way to know if the driver behind a DRM node is vc4 or amdgpu
<clever>
and then you can avoid firing vc4 calls at an amdgpu driver
<heat>
early CSRG papers had the idea of having a control() call (IIRC, cant remember the name) with in and out buffers with the data being ASCII text
<heat>
clever, fwiw oopsing on a bad input is awful design and very unsafe
<mjg>
lol
<mjg>
it is safe if you unsafe { } around it
<clever>
heat: yeah, i reported it upstream and they fixed things
<clever>
but it definitely smells like somebody needs to fuzz DRM
<bslsk05>
github.com: syzkaller/sys/linux/dev_i915.txt at master · google/syzkaller · GitHub
nur has quit [Remote host closed the connection]
xenos1984 has quit [Ping timeout: 268 seconds]
<GeDaMo>
I tried to find something about the control call heat mentioned but no luck
<heat>
there's a man page on it, console_ioctl(4)
<heat>
oh, wait, the control() stuff
<heat>
lemme see if i can find the paper
<GeDaMo>
Plan 9 apparently had a ctl file «These options may be set after boot by writing to the device's ctl file using a space as the separator between option and value, e.g. echo 'key2 1d8f65c9a52d83c8e4b43f94af' >/net/ether0/0/ctl» https://plan9.io/magic/man2html/8/plan9.ini
<bslsk05>
plan9.io: Plan 9 /sys/man/8/plan9.ini
m257 has joined #osdev
<dostoyevsky2>
GeDaMo: I wish it was easier in Linux to write new filesystems, I guess plan9 has some concepts that make it easier, but not sure
<mjg>
and FEARLESS CONCURRENCY IN RUST, however real or imagine, is of no consequence
<netbsduser`>
i am making mine less unix in how it presents itself though
<Bitweasil>
(I've been buried in there lately, I wrote a particularly clever and hard to run down bug where a load64 exclusive actually only loads 32 bits...)
<mjg>
Bitweasil: :p
<netbsduser`>
mjg: you hit on exactly my issue with rust they make big promises around fearless concurrency, as if one doesn't have to get into frightful concurrency (and frightful lifetimes) to scale nowadays
<heat>
you don't need to get into frightful concurrency in most cases
<heat>
that's the thing
sbalmos has joined #osdev
<netbsduser`>
that's an entirely fair comment
<netbsduser`>
it is not a big deal for a lot of programs
<heat>
most programs are not frightfully concurrent software with lots of shared state
<heat>
i.e a web server thread doesn't *really* need to share state with anything else
<netbsduser`>
in many cases you can localise state well between threads, or have quite naturally parallel problems
<netbsduser`>
but this is not so much in the worlds of databases and kernels
<mjg>
let literally_the_same = Arc::as_ptr(&self.inner) == Arc::as_ptr(&other.inner);
<mjg>
if literally_the_same {
<mjg>
return true;
<mjg>
}
<mjg>
not sayi8ng anything wrong is going on here, but it does read funny to me
heat has quit [Remote host closed the connection]
heat has joined #osdev
<heat>
netbsduser`: correct, but there's a very restrict group of people that need to write scalable databases and kernels
<heat>
such that they need RCU
<heat>
NT has done fine for 30 years without RCU
<mjg>
SCALABILITY DAY
<netbsduser`>
heat: i suppose it was about 30 years
<netbsduser`>
they have RCU now
<heat>
zircon runs perfectly fine without RCU or mega scalability
<netbsduser`>
also an object caching slab allocator
<heat>
yeah, does anyone know where they're deploying RCU?
<heat>
they also got kasan IIRC
<netbsduser`>
someone on the osdev discord knows a use i think
<netbsduser`>
or possibly it's the resident nt kernel dev there who spoke of it
<acidx>
NT has even BPF now
<mjg>
NTinux kernel!
<netbsduser`>
they looked like quite a siloed kernel whose last infusion of foreign influence was the unix people (richard rashid of mach fame) was at its inception, until quite recently, now that's changed at last
<heat>
welcome to the 2010s mr cutler
<dostoyevsky2>
acidx: Well, eBPF is that thing where you can write any kind of program and let it be run inside the linux kernel (if the code checker doesn't reject it) BPF was just for firewall rules, so not really much compared to eBPF
<heat>
they have eBPF
<acidx>
dostoyevsky2: they have eBPF
<heat>
(classic BPF was also not just for firewall rules)
<kazinsal>
the filterer for packets from berkeley did a great many things
<heat>
including seccomp, still does
<acidx>
(it's just that BPF these days became kind of a synonym with eBPF, and the classic one ends up being called cBPF or something)
<dostoyevsky2>
Also, the name... Berekeley Packet Filter ... you'd think they could find a better name, except the original one which was just about the firewall performance
<acidx>
I was at MS when they announced it during its internal operating systems conference. it was pretty cool to see the demos. :)
<mcrod>
hi
<heat>
i also heard NT has or is experimenting with rust
<heat>
the MS firmware already deploys rust
<dostoyevsky2>
I tried to figure out what the eBPF code checker is actually doing... so I thought maybe it's doing it via an SMT solver... but seems it doesn't do that...
<bslsk05>
www.theregister.com: Microsoft is rewriting core Windows libraries in Rust • The Register
<heat>
i firmly believe the eBPF checker is useless
<heat>
they had a big idea for unprivileged eBPF but that went down the drain
<netbsduser`>
the NT chap reported that the rust is going into win32k (which was supposed to be userland code but was moved into the kernel in nt 4 to solve a problem of that time) but not elsewhere
<netbsduser`>
something called the store manager (whose responsibilities include memory compression, but that's all i know), a proper kernel component, apparently was the first to be written in C++
<acidx>
font rendering in NT happend in the kernel during NT4 days but it's since moved to usermode
<dostoyevsky2>
heat: If it's useless it might be easy to crash the kernel with eBPF programs... I guess time will tell.. OTOH if you can run code as root on a linux system you can always just start qemu and e.g. overwrite anything on / to your liking
<netbsduser`>
dostoyevsky2: that would be a big blow to the groupies that built up around it
<netbsduser`>
a few years ago they may as well have proposed to reduce linux into a runtime for eBPF proglets to do everything else
<netbsduser`>
rustication stole away much of that hype but a curious hybrid of rustication and bpf has taken root, with people writing bpf scriptlets in rust
<zid`>
rust but all your unsafe{} is epbf
<netbsduser`>
zid`: a fantastic solution
<netbsduser`>
as ebpf.io, the ebpf homepage (!) tells me, eBPF has Performance, Security, Flexibility
<netbsduser`>
coupled with Rust's Fearless Concurrency and Blazing Fast, you have 5 traits of undeniable yearning
<dostoyevsky2>
but those code checkers I studied a bit: firecracker and gvisor seemed to be too much code to ever be really safe, so I think there are probably quite a lot of problems left in those
<netbsduser`>
once we figure out how to add webasm to this, making the trifecta of the future, we will solve all problems in software
<zid`>
I mean, there's that funny js talk
heat has quit [Ping timeout: 250 seconds]
<zid`>
OSes won't be truly fast until everything is in javascript so we don't need memory protection anymore
<netbsduser`>
zid`: nintendo research tried this with something called ES-OS
<netbsduser`>
it has webidl and all the other buzzwords of 2009
<netbsduser`>
for example it turns out you can relax a lot of things if you can guarantee that a certain area of memory will remain stable in type, even if the lifetime of the object you were expecting to find has concluded
<zid`>
FEARLESS (unless you do complex type things)
<dostoyevsky2>
netbsduser`: in databases they use these allocators that have two LRU lists... LRU-K since in a database you don't want to change data bacause of all the transactions going on...
<mcrod>
zid`: have I reached my complaint counter?
<netbsduser`>
dostoyevsky2: i would like to study databases some day
<netbsduser`>
much crossover with kernels
<dostoyevsky2>
netbsduser`: I am monologuing over at #database-design from time to time, when then CMU database lectures are released, but currently they just finished the semester
<bslsk05>
'S2024 #21 - Yellowbrick Data Warehouse System (CMU Advanced Database Systems)' by CMU Database Group (01:21:10)
heat has joined #osdev
<heat>
dostoyevsky2: correct, but you *are* root
<heat>
the only problem would be writing malicious ebpf programs and fucking with the kernel like that (defeating secure boot)
<geist>
ah was gonna comment on the arc::as_ptr comparison logic, since iirc the usual strategy is arc returns you some raii thing and if you used two of them in a row like that its probably undefined which grabs the lock first
<geist>
but i guess as_ptr bypasses the lock. is that unsafe?
<heat>
i think we can say probably not
<heat>
it doesn't need unsafe {}
<geist>
hmm, i'm surprised though, i thought in general if you're futzing with ptrs you need unsafe
<geist>
though i guess i should go read up on arc again, but i thought it was basically a lock that holds a reference to the thing, and only gives up its thing while it holds the lock
<heat>
yeah but you're comparing them, that doesn't sound unsaf
<childlikempress>
it would make sense if dereferencing pointers is unsafe, but i don't see why comparing them would be
<childlikempress>
yeah
<geist>
oh wait, arc is the ref counted thing, not the lock thing
<geist>
well yeah but we're dealing with rust here. i thought in general if yo uhave a ref to it the ref had better be diddled, or you go unsafe
gildasio has quit [Remote host closed the connection]
<bslsk05>
'Randy Scouse Git' by The Monkees - Topic (00:02:34)
goliath has joined #osdev
<heat>
linkedin people are clinically insane
<heat>
does anyone know if macOS 14 changed /bin/sh?
<heat>
my /bin/sh-fearing script is having issues on my macOS CI actions...
<childlikempress>
GNU bash, version 3.2.57(1)-release (arm64-apple-darwin23)
<heat>
if [ "$#" -ne "2" ]; then
<heat>
this is failing for some reason
<heat>
hm.
<heat>
i am adding some homebrew gnubin stuff, i wonder if that's the problem
<heat>
but it shouldn't matter...
<heat>
waiiiiit this might be getopts
<heat>
getopt i mean
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<heat>
yep, the path seems to have changed, i need to use $(brew --prefix) properly
heat has quit [Quit: Client closed]
heat has joined #osdev
voidah has quit [Ping timeout: 252 seconds]
<dostoyevsky2>
heat: I replaced all my shell scripts for macos with Go programs
<mjg>
macos confidential informant
<Ermine>
Doesn't macos ship zsh?
<childlikempress>
zsh default shell, but bash as /bin/sh
<childlikempress>
not sure why tbh--i'm pretty sure zsh has a posix compatibility mode, so should be good to just use that as /bin/sh?
<dostoyevsky2>
shell scripts often use bashisms these days, which is hard to get on macos because it's not bsd licensed, so they made the default shell zsh and /bin/sh is some kind of bourne shell compatible shell but probably not enough for today's bashisms
<childlikempress>
it is a bash, but an old bash--i think the last gplv2 one?
voidah has joined #osdev
Turn_Left has joined #osdev
vdamewood has joined #osdev
Left_Turn has quit [Ping timeout: 256 seconds]
gbowne1 has joined #osdev
<heat>
yeah last gplv2 one
<heat>
my scripts are not really bash'ed but they do depend on GNU coreutilsisms
<heat>
while macOS still has the BSD stone age tools
<heat>
i bet they don't even have long options or --help
theyneversleep has quit [Remote host closed the connection]
<heat>
why does homebrew use EMOJIS
<netbsduser`>
i wonder whether i can employ RCU in an improvement i will make to my kernel
<netbsduser`>
instead of creating a fresh mapping when read()/write()'ing a file then unmapping it after doing the copy, keeping a fixed number of mapping windows, and replacing LRU these windows
<heat>
configure: error: Building GCC requires GMP 4.2+, MPFR 3.1.0+ and MPC 0.8.0+.
<heat>
but i have them installed AHHHHHHHHHHHHHHHH
<childlikempress>
lolll
<netbsduser`>
i have an intuition that i'll end up with stupid locking if then have each vnode carry an tree or similar of active mapping windows
<heat>
the true scalable solution is to not do mapping window nonsense
<nikolapdp>
heat use geist's script
<netbsduser`>
i thought about having userland be responsible for maintaining its own mapping windows instead which has some merits
<heat>
i can't use geist's script
<netbsduser`>
that's what johannes helander did in his Lites system
<heat>
i suspect it's not picking up my homebrew libraries now...
<netbsduser`>
his lites was a bsd server on mach 3, so he wanted to avoid mach ipc roundtrips between the bsd server and apps
<heat>
okay CPATH might work
<nikolapdp>
heat what are you doing on macos
<heat>
my CI builds toolchains for macOS too
<heat>
in the offchance someone might want to build Onyx on macOS, although i don't really test it and you'll need to install a lot of GNU tooling
<nikolapdp>
do you have a mac
<heat>
nope
<nikolapdp>
i have a macos vm
<nikolapdp>
i could test it for you at some point
<heat>
that'd be cool
<heat>
freebsd would probably also work
<heat>
it's the same awful tooling anyway
<nikolapdp>
sure
<nikolapdp>
let me know what you need
<nikolapdp>
i'll boot up the vm
<zid`>
pencil
<heat>
uh i don't think i need anything right now
<heat>
i *probably* have everything under control
<heat>
i would tell you to grab a macOS toolchain and build onyx but it probably won't work now that github actions migrated to M1
<heat>
they're also symlinking clang to gcc which is a... dubious idea
<nikolapdp>
that is dubious indeed
<nikolapdp>
why wouldn't it work
<nikolapdp>
why does m1 matter
<heat>
>warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead
<heat>
lol
<nikolapdp>
lol wat
<heat>
nikolapdp, i'd assume you're on x86
<nikolapdp>
since when
<nikolapdp>
i am
<heat>
so it does matter
<heat>
the toolchains you'd download run on the wrong arch
<nikolapdp>
ah that
<nikolapdp>
i thoughjt i needed to build a toolchain anyway
<heat>
i mean, you can
<heat>
ermine documented that stuff for me
<nikolapdp>
so do i do it or not
<heat>
if you want to
<heat>
yeah i'll need to stop building apple toolchains ATM
<heat>
apple clang cannot build gcc apparently
<nikolapdp>
odd
<nikolapdp>
thought gcc was supposed to be buildable anywhere
<zid`>
try build it with tcc I dare you
<heat>
i might be able to save it
<nikolapdp>
tcc can't build cpp
<heat>
that's exactly why i use cpp
<heat>
to keep shit compilers away from my code
<nikolapdp>
boohoo
<heat>
that's why i also have a couple of VLAs
<heat>
so the 2nd shittiest compiler MSVC can't build it
<nikolapdp>
ok i'll give you that one
<heat>
a C99/C11 feature a day keeps the MSVC away
<nikolapdp>
lol
<childlikempress>
do gcc/clang even support vlas in c++ mode
<childlikempress>
lol
<heat>
yep
<heat>
they recently started warning about it
<nikolapdp>
for some reason, bloody gcc is allocating 2 gigs of ram
<nikolapdp>
and it's not stopping
<heat>
it's building rust crates
<heat>
quick make it stop
<heat>
it's going to make your whole system a rust crate
<heat>
it'll publish it in cargo.io
<nikolapdp>
oh i know what happened
<nikolapdp>
-fanalyzer happened
<nikolapdp>
i forgot i added that options lo
<nikolapdp>
*option lol
<Griwes>
childlikempress, re vlas, yes, and you'd be amazed how many times this comes up in c++ committee discussions in the form of "what you are proposing is going to lead people to accidentally write vlas and I am going to have to explain to them what happened"
<heat>
you can't accidentally write a vla with std::array
<heat>
which, to be clear, is a huge disadvantage
<heat>
VLA VLA VLA VLA VLA
<netbsduser`>
VLAs and _alloca() trash
<Griwes>
vlas are a crime deserving of 10 years of writing everything in brainfuck
<heat>
-Wno-vla
<heat>
if i force gcc and g++ onto CC and CXX it seems to build
<heat>
this is good
<zid`>
vlas have the same issue iostream has, go
<zid`>
figure that one out
<heat>
with my !apple clang i can get gcc to build up to the point it tries to figure out what multilibs it needs to build
<nikolapdp>
wonder why apple clang is different to non apple clang
<heat>
might have patches, might have been rewritten in rust
<heat>
we'll never know
<zid`>
mingw gcc very different to gcc
<heat>
gcc build portability is definitely a lie though
<heat>
you can compile LLVM with gcc, you can't necessarily compile gcc with clang
<zid`>
that means gcc > clang
<nikolapdp>
lol
<nikolapdp>
fax
<heat>
one side needs to be buildable using the other
<Griwes>
not being able to compile gcc sounds like a feature to me
<zid`>
"You can compile tcc with gcc, but you can't compile gcc with tcc, so tcc is better" --heat
<heat>
the other side likes pretending LLVM bad
<zid`>
oh, nik
<zid`>
it is may 1st
<heat>
this is not about tcc
<nikolapdp>
sure is zid1
<nikolapdp>
zid`
<zid`>
that means
<heat>
this is about GNU being adversarial wrt LLVM and clang and lld since day 1
<heat>
because their tools suck
<nikolapdp>
yet the world is built on gnu
<nikolapdp>
*foss world
<heat>
is it?
<Griwes>
clang is matching their builtins to existing gcc ones
<Griwes>
gcc invented new spellings for existing clang ones several times
<nikolapdp>
more animals to bully
<heat>
if you submit a bug report "oh this doesn't compile on clang" they'll say "good." and close the report
<nikolapdp>
based
<heat>
just like they didn't accept fuse-ld=lld for *ages*
<nikolapdp>
what if fuse-ld=lld
<heat>
despite GNU gold being shitty and GNU ld being shitty^2
<nikolapdp>
*what is
<heat>
makes CC use ld.lld
<nikolapdp>
why fuse-ld for that lol
<nikolapdp>
silly option names
<heat>
use-ld
<nikolapdp>
aah it's -fuse
<nikolapdp>
got it
<heat>
and their only argument was "boohoo this weakens the free software movement!!!!!"
<netbsduser`>
fuse-ld, the first link editor providing a FUSE-based FS to help it cache objects
<Griwes>
it's funny how gnu is doing so much to increase the vendor lock in these days :V
<heat>
maybe if the free software movement could write good linkers lld wouldn't have these many users
<netbsduser`>
heat: stallman and his famous rant against clang?
<heat>
stallman and his ilk
<netbsduser`>
"this a terrible compiler which sets back the free software movement by decades", i believe he said
<nikolapdp>
that's a valid reason
<heat>
he said that about GCC???? based
<nikolapdp>
no
<Griwes>
/s lol
<netbsduser`>
in fairness you can understand stallman's frustration
<netbsduser`>
after hard work the free software organisation is making good progress towards a monopoly on compilers with GCC
<netbsduser`>
then along comes some american from the usa and introduces a new gcc ripoff
<kof673>
"american" i'm not going there but this word means nothing in law :D
<heat>
ugh don't you hate it when people don't let you establish a monopoly
<netbsduser`>
the stated strategy of stallman and the GNU organisation is to try to make copyleft software universal
<netbsduser`>
so he might have accepted Clang were it also copyleft
<heat>
not only copyleft but they insist in 1) GPL 2) GNU project 3) FSF copyright assignment
<Ermine>
Otoh arm made its fork, armclang, and it produces really small code
<Ermine>
more than 2x smaller
<Ermine>
otoh they came up with their own linker script format
<Ermine>
btw arm used to use gcc for their tooling shipped with keil/arm studio
<kof673>
> wonder why apple clang is different to non apple clang nextstep had gcc+ o bjective-c stuff, but at least some/most was also (eventually) in mainline gcc, different "runtimes" though. also mach-o as object format, apple had cctools instead of binutils IIRC. in any case, building a cross toolchain from a "non-next" system was "not possible" per se, although i think much later people hacked up solutions
<kof673>
no idea if that type stuff still exists, just there is a long tradition lol
<kof673>
or: if it was like that with gcc, what is preventing clang?
<klys_>
my DEC dual RX02 unit arrived
<nikolapdp>
very nice klys_
<dostoyevsky2>
does clang have anything to do with gcc?
<kof673>
no idea, just saying that goes way back :D
Turn_Left has quit [Read error: Connection reset by peer]
<klys_>
nikolapdp, it seems pretty wonky, and I'm moving to another apartment in the adjoining town soon.
<klys_>
seems it's upwards of 80 lbs
<klys_>
I think the wheels are coming in another shipment
<klys_>
3/4 wheels remain
<dostoyevsky2>
kof673: the code reads very different for sure... llvm is in C++ and gcc is some C monstrosity that doesn't even do memory management
<klys_>
oh it has a floppy in drive 1
<kof673>
> thought gcc was supposed to be buildable anywhere at some point gcc needs C++ to build, but not sure of the details -- i.e., is that just particular languages, what if only freestanding c, etc.
<kof673>
*at some version 4.x or so i believe?
<heat>
gcc is not in C
<heat>
although lots of its code is C in a .cpp
<nikolapdp>
4.x was
<dostoyevsky2>
heat: I see they renamed all the .c files in gcc to .cc now
<dostoyevsky2>
kof673: what llvm features are apple only these days? I thought maybe something like bitcode, but it's deprecated now
<kof673>
> NIKOLA: wonder why apple clang is different to non apple clang
<kof673>
i don't have any modern stuff, that is a nikola question :D
netbsduser` has quit [Ping timeout: 264 seconds]
* kof673
starts jeopardy music timer countdown
<GreaseMonkey>
iirc 4.7.x is the last series of GCC versions that don't require a C++ compiler
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
<kof673>
"from the usa" just to clarify, > Article I. The Stile of this confederacy shall be, “ The United States of America .” that was the pre-1860s version. then whatever other entities later also called themselves that lol
hunta987 has joined #osdev
<Ermine>
I wonder why windows decided to require popcnt
<klys_>
the other day I learned qbasic.exe is a stripped down copy of early windows internals
<klys_>
from comments about the source release of msdos4.00
<nikolapdp>
when was popcnt introduced to x86
<hunta987>
2006
<nortti>
kof673: isn't that from the pre-1790s version?
<heat>
Ermine, speed probably?
<heat>
i know they require cmpxchg16b because of lockless linked list trickery
<zid`>
heat: as in, the shell env ide thing part?
<heat>
hm?
<zid`>
[00:36] <klys_> the other day I learned qbasic.exe is a stripped down copy of early windows internals