<mjg>
mcs trades throughput for bounded latency for everyone
<mjg>
as in it may arbitrarily suck, but when it does, sucks the same for everyone
<mjg>
greedy locks may starve other cpus
<moon-child>
screw other cpus
AFamousHistorian has joined #osdev
<moon-child>
shoulda been faster
<mjg>
ye sucks to be you, the other cpu!
<heat>
locks are such a we live in a society moment
<mjg>
there is a misconception that mcs "scales better"
<moon-child>
lol
srjek has quit [Ping timeout: 272 seconds]
<mjg>
it is particuarly bad with numa in that aspect
<mjg>
but you probably want it anyway
<mjg>
there were people fucking around with a hybrid lock
<mjg>
you do mcs within a domain and backoff otherwise
<mjg>
and other ideas to that extent
<mjg>
say you have a 2 node ystem
<mjg>
every single cpu thread wants to take the lock once
<mjg>
least slow variant would be: everyone on node 0 gets the lock an fucks off, then it is send across the interlink and everyone in node 1 does the same
<mjg>
the end
<mjg>
the slowest possible variant would be ping ponging the lock across the interconnect *every fucking time*
<mjg>
which, in worst case, mcs will end up doing
<mjg>
greedy lock will favor local cpus up to a point
<heat>
and this is why capitalism is good
<heat>
thank you mjg
<mjg>
it's mr Warren BUffet for you
<mjg>
now imagine an 4 or 8 node system
<mjg>
's not good for the fair lock innit
<moon-child>
hmmm, so
<moon-child>
how does the node that doesn't hold the lock figure out when it can grab it?
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
srjek has quit [Ping timeout: 252 seconds]
heat has quit [Ping timeout: 256 seconds]
epony has joined #osdev
<dinkelhacker>
So I have a question regarding initrd: From what I get the main argument is to keep the kernel smaller. But since dist vendors don't know what machine they'll be booing on they might end up in a catch22 where they need a file to load the module of the file system driver. However, initrds or initramfs are also shipped by the vendor and not specific to my machine right? So they kind of still have the
<dinkelhacker>
problem, that all the drivers whould have to be in the ram disk? So what's the point here?
<Mutabah>
A default initrd might have all of the driver modules in it, but it's very easy to rebuild to have a smaller set...
<Mutabah>
However... that's not really its main role, most kernels (linux and hobby ones) have all of the drivers they need
<dinkelhacker>
Yeah but why wouldn't you just put them into the kernel to begin with?
<Mutabah>
It's there to give a small userland stub that's hard to corrupt, before doing the potentially complex disk mounting
<dinkelhacker>
Okay... could you elaborate on that? Why do you need that hard to corrupt userland stub?
<Mutabah>
To be honst, I don't know enough about linux to be completely sure
<dinkelhacker>
And maybe going back to what I wrote: Is it actually true that the initramfs is not specific to my hardware? Or is it created during the installation process and actually contains the right modules. If so, that would make a lot more sense..
<Mutabah>
In my old kernel, I did have a initrd - which was mostly just a disk image containing a small userland, could have booted straight of storage
<Mutabah>
And I assume linux can do that too...
<Mutabah>
dinkelhacker: initrds are (afaik) installation specific on linux
<Mutabah>
(Note: This is not #linux)
foudfou has quit [Remote host closed the connection]
<Mutabah>
Example: Your initrd might contain the modules for a specific raid setup, or non-standard disk controller
<Mutabah>
Things that are not part of a standard kernel, but are needed before the disks can be read
<dinkelhacker>
Yeah sure I'm asking because I'm wondering if I need that for my hobby OS^^. Okay if it is created during the installation that makes sense because otherwise they would just shift the problem of having all the drivers in the kernel to having them in the initrd/initramfs.
foudfou has joined #osdev
<Mutabah>
Well, it's a lot easier to add/remove drivers from an initrd than it is from a kernel binary
<dinkelhacker>
bc you have to reconfigure/recompile?
<Mutabah>
Yep
<klange>
My entire system runs out of an 'initial' ramdisk. =)
<Mutabah>
and recompiling a kernel requies having the source and a build environment
<zid>
You will want one during dev anyway
<zid>
regardless if you end up with one at the end
<Mutabah>
while remaking an initrd might be as simple as calling `tar`
<zid>
It's kind of hard to write a filesystem driver without a vfs to use it against, kind of hard to write a vfs without a filesystem driver etc etc
<zid>
ramfs solves a bunch of nasty problems
<sham1>
Now you need a ramfs driver, which depending on the kernel model can be either trivial or very annoying
<zid>
what's a ramfs driver, it's just a pre-populated disk cache ;)
<moon-child>
lol
<dinkelhacker>
zid: why is it easier to implement a fs driver against a ramdisk than against a file system that is on "real hw" (say emmc)? Because you'd also need the driver for the emmc?
<zid>
and the filesystem
<zid>
and usb or ahci
<zid>
or ide
<sham1>
And the women and children too
<dinkelhacker>
kk... so the strategy would be to for example have an ext2 fs as a ramfs and just implement the ext2 driver against that?
<klange>
you could do that, but ext2 is annoying to build from scratch
<zid>
the kernel ues 'cpio'
<klange>
I mean literally "an ext2 filesystem image" is annoying to build. I used to do this, with genext2fs.
<zid>
which is the tape backup archive format I think
<zid>
like tar
<zid>
or something idk
<zid>
klange: needs root on linux to do easily, which is weird
<sham1>
squashfs is also one to consider
<sham1>
Since it's meant for this
<zid>
losetup /dev/loop0 file.fs; mkfs.ext2 /dev/loop0 mount /dev/loop0 fs/;
<dinkelhacker>
So cpio and squashfs are less annoying?^^ good to know.
<zid>
cp files fs/
<clever>
zid: mkfs can copy files on its own
<klange>
genext2fs does not need root, but ext2 is still a bit heavy for these purposes; the good choices are all "write once" formats that almost don't count as "filesystems".
<clever>
mkfs.ext4 -d ./rootImage blk.bin
<klange>
cpio, of course, as zid said Linux uses; I use tar but there's lots of different extensions to tar so it can be tricky to ensure you're getting a consistent format
<klange>
squashfs is newer and fancier and more specifically designed for this purpose
<zid>
but that shouldn't be your starting goal
<zid>
your starting goal is "can I get *A* file loaded"
<zid>
so just a directory entry and no nesting support is plenty at first, it'll let you establish a lot of supplemental crap
<zid>
hand made in a hex editor for all it matters
<sham1>
Eww
<klange>
that's more than just "*A* file", start with a single static executable and run it :)
<dinkelhacker>
klange: you said your entire system is running out of a ramfs. ToarusOS does not support any non-volatile storage?
<sham1>
One should at least have a tool for that
<klange>
dinkelhacker: it does but I build live CDs because they are much easier to iterate on, and I also haven't put much effort into my ext2 write implementation so it's very fragile and prone to breaking :)
<klange>
I have a test VM sitting around that does a persistent install on a disk image. I was able to install Doom on it from my package manager and it still plays fine.
<dinkelhacker>
nice!
<sham1>
Microkernels would make iterating easier as you should be able to just iterate on the design and replace the filesystem server on the fly
<zid>
(no they don't)
<sham1>
In practice, yeah. Sad
<zid>
I should write a vfsy thing at some point
<zid>
I'd probably just do it in userspace
<zid>
startup code that mmap's an archive, and a main that is just a test rig for manipulating some files
<zid>
and I implement it all then just copy pate it into kernel
<zid>
nce it's done
<dinkelhacker>
zid: how do you hand make a file system? tbh I have no knowledge about file systems so the qustion might be obvious, but I assume they have some kind of format/encoding/standard? So wouldn't you have to decide if you wanna use cpuo/squashfs, create a ramfs of that kind and then implement the driver for reading/writing from/to that?
<zid>
sure, but, you don't need write support at first (or perhaps ever), and the format doesn't have to be complicated because of that
<zid>
so you could literally just do something like "name",len,0xdatadatadata
<zid>
which is buildable in a bash script or something :P
<sham1>
Add some alignment, god damn
<zid>
fine, name, offset, len and all the files go at the end
<zid>
with a fancy binpack algo to minimize padding
<dinkelhacker>
Okay I see, that would be a home grown fs
<zid>
minimizing all the *other* problems lets you write more of the supplemental stuff, then you can complixify it later, is the point
<sham1>
Yeah, that's like the most trivial thing. As said, should be buildable in bash, although a C version would be basically just as trivial
<zid>
once the supplemental stuff is in and tested
<zid>
trying to hook up a vfs + fs driver + ahci driver all simultaneously with no way to test any of them in isolation first will be a nightmare
<sham1>
The hardest part would be to deal with the C, but hey, that's also most likely the hardest part of the OSDev, so it's all good
<dinkelhacker>
what do you mean with supplemental stuff? Say if I make up my own toy fs like you said, what could I actually reuse once I switch to something real like squashfs?
<zid>
once you have your crappy filesystem put in, you can add a vfs driver to talk to it with, and then replace it with an 'on disk' version, and your test rig suddenly becomes 'does it stop working'
<zid>
instead of 'idk, I can ask it for data, but nobody actually does anything with that data yet'
<sham1>
It's integration testing on crack
<zid>
then you can replace the disk format with ext2
<zid>
and if it still works.. you're finished
<zid>
never having written anything that wasn't testable
<sham1>
Sadly osdev isn't all that amicable towards TDD. It's impractical in many ways
<sham1>
Microkernels do help because in theory you can test the servers in the development environment, but in practice it's not that easy now is it
<zid>
I can do that without it being a microkernel though
<zid>
incremental linking acts just the same way
<sham1>
Sure, if you decouple things well enough
<zid>
I can test it all in userspace, and move the .o across :P
<klange>
I do tend to do some microkernelly things when iterating on device drivers; like for USB, I built a shim device interface as a module that a Kuroko script poked to interact with the XHCI card from userspace :)
<sham1>
A microkernel would be decoupled well by design… unless you just end up essentially making a system Daemon (a systemd, if you will) that's essentially just a monolithic kernel but in userspace
<zid>
good osdev is coming up with good ways to test things :P
<klange>
Most of my kernel modules spin up threads to do stuff. They're basically microkernel services, they just run in priveleged space.
<dinkelhacker>
couldn't you just test a USB driver against qemu?
<zid>
test it to do what? in what environment?
<klange>
lol not really
<zid>
usb is actually one of the super easy things to test on hw because of iommus :P
<zid>
can just boot a VM using a real hub
<zid>
I have like 6 hubs, I could passthrough one np
<klange>
that still doesn't help me when I'm trying to test an rpi4 natively.
<zid>
could do each hub in turn so you get usb 1 2 and 3 too :P
<zid>
I even have an irl OHCI test setup available :o
<clever>
klange: of note, the vl805 xhci controller on the pi4, has a hardware bug, certain combinations of xhci requests, plus certain latencies on the usb end, cause it to repeat entire buffers
<zid>
wait no I don't, that device broke
<clever>
klange: as a result, doing 512 byte sector writes over usb, can horribly corrupt your fs
<dinkelhacker>
Can't you make qemu to connect the USB to a real thing on my pc? So you could test the driver against it?
<zid>
dinkelhacker: yea that's what I was talking about
<clever>
2022-12-05 19:33:19 <clever> read this comment and weep! :D
<bslsk05>
github.com: Raspberry Pi 4 : USB3 SSD Connected via USB3 Hub : BOOT Files Corrupted Following Reboot · Issue #4844 · raspberrypi/linux · GitHub
<klange>
lovely
<clever>
that kind of defective xhci device, isnt something you can just test around on any machine, you would need to get a vl805 pcie card, and install it into your desktop
<klange>
I just want to talk the keyboard on a 400
<clever>
but if you use 4096 byte clusters, the problem doesnt occur
<zid>
VL2616 for life
<clever>
the keyboard is just native usb hid on the pcie xhci controller, so youll need pcie drivers, the special vl805 init sequence, xhci, and hid
<clever>
and the bug involves certain combinations of hubs, and outgoing writes, both seem like they will never happen with the internal HID
<zid>
finding out that it needs 512 byte sectors to trigger must have been a bear
<clever>
zid: the bug only showed itself on the /boot partition, where it was trashing dtb files
<clever>
512 byte chunks of the dtb where replaced with chunks from other dtb files
<zid>
yea I am reading it
<zid>
I don't need to tab back and read it again :p
<clever>
i think the biggest problem in this bug, is that you need a usb analyzer to even confirm the problem
<klange>
I have pcie and vl805 init as of earlier last year, then I went on vacation, then I promptly forgot everything and now it's a year later.
<klange>
I am at the point where I need to build the XHCI / USB / HID stack and that is something I can feasibly do in QEMU with a bog standard XHCI emulation.
<klange>
So we'll get there.
<clever>
yep
<clever>
i think the only thing special on the rpi, is that the controller needs the xhci scratch space setup
<clever>
thats an optional thing, so not all xhci controllers require it
<clever>
my rough understanding, is that it basically makes the xhci controller cheaper, why put more ram on it, when you can steal some host ram?
<clever>
and qemu isnt constrained by how much ram they include on the "xhci chip"
<clever>
ive heard nvme can do the same, a cheap stick can store the translation cache in host ram
<clever>
while an expensive stick with the identical controller, can store it in a local dram chip
bgs has quit [Remote host closed the connection]
<dinkelhacker>
so regarding vfs. Is there on that everybody uses? Do people roll their own?
<klange>
The vfs is a concept that you need to build yourself, not a thing you can pull a design off the shelf for.
vdamewood has joined #osdev
<mjg>
::]
<mjg>
well the classic unix vfs is reasonably documented i think in OS books
<mjg>
ont that i would recommend it
<Mutabah>
The VFS is just your API between the user (userland or bits of the kernel that want file access) and the filesystem drivers
<mjg>
where is a non-crap vfs though
<mjg>
aking for a friend
<zid>
and interfaces with things like disk caches
<epony>
there are designs on that in the FreeBSD and BSD shelves in the library and it has source code and books too.
<epony>
supposedly the Linux shelf has some of that too
<epony>
it's a high level details explanations with technical details enough to understand the system sources then
* sham1
chomps on trout
<zid>
sham1: still included in what I meant
<zid>
it needs to chop the C part off, figure out what *device* C means
<sham1>
Yeah, but now you don't necessarily need to look at mount points
<zid>
It's still a mount point, it's just.. simpler
<zid>
but either way you end up with a 'struct opened_file_yo { struct device *d; ... };'
<sham1>
Simple and neat. DOS did have some good things while also being a steaming pile
<dinkelhacker>
gosh I'm not even done with my seconf coffee and my brain is already smoking. Thx for the recommendations and explanations. Just 8 hours work ahead xD
<sham1>
But yeah, you still need a handle to the drive, but it's easier with Windows paths arguably (of course there still are non-drive letter mount points in modern windows, bleh)
<zid>
plus UNC paths
<zid>
which may need to do networky stuff
<zid>
\\?\ best syntax btw
<sham1>
Networky stuff is the problem of the filesystem server
<zid>
I mean yea you just treat it like a device as far as the vfs part is concerned
<zid>
but your vfs needs to parse it
<sham1>
Well, VFS server needs to know that the path is networky, but eh
PapaFrog has quit [Ping timeout: 246 seconds]
<mjg>
dos?
<mjg>
godo things?
<mjg>
like what
PapaFrog has joined #osdev
gabi-250 has quit [Remote host closed the connection]
gabi-250 has joined #osdev
<sham1>
Clearly delineated devices. It's obvious from the path, what device you're talking about
<zid>
mount points and links
<zid>
are kinda annoying to reason about
<zid>
mount points means you can hide files underneath other files, links break your security and deletion is funky, blah blah
<sham1>
Plan9 did away with links, and the rationale was very sane.
<sham1>
Of course, one could just have a 9p server that implements symlinks, but why one would do so, I have no idea
<clever>
on linux, the working directory acts like a file handle, and renaming a directory doesnt break the cwd, i assume there is then a tree of pointers in ram, re-creating part of the directory structure
<clever>
but some of that could be cache like, and discarded/recreated on demand
<zid>
hardest part of a vfs imo is not making it just.. run out of memory if you add a big device :P
<zid>
easy to want to cache a trillion directory entries blindly if I do find /mnt/bigdev
<clever>
but ive also seen LK, where the working directory is just a string, cd just appends/deletes elements without validating, and every time you open a file, it traverses the entire path again from /
<sham1>
Unused RAM is wasted RAM though
<clever>
but LK also doesnt really have processes, so a working directory kinda doesnt fit
<zid>
I mean, that command ooms the kernel and it powers offf
<zid>
is easy to implement
<clever>
zid: you need memory pressure, and the ability to delete vfs entries when malloc fails, then retry malloc
<clever>
and dynamically recreate them on demand
<zid>
yes
<zid>
but that's more code
<zid>
than not doing it at all
<zid>
hence, harder
<clever>
yeah
<clever>
LK doesnt cache any vfs state, only the raw blocks of the backing block dev
<clever>
so it has to re-parse the fs on every action
<sham1>
Disgusting
<clever>
LK wasnt really meant to be an os, i think its meant more to be a bootloader?
<clever>
so its usually going to read a couple files, then die
<sham1>
Well okay, then it makes sense
<clever>
and even the cases where i am abusing it as an OS, it only does disk io once during boot, and then never again
<clever>
because linux is going to take over the block device, and sharing hardware between 2 kernels isnt easy
lockna has joined #osdev
<zid>
I think if I just wanted some 'light' caching I'd just pool allocate the structs out of a fixed block of memory
<zid>
and then if I wanted to be extra fancy, come up with an eviction strategy
lockna has quit [Quit: lockna]
lockna has joined #osdev
fedorafan has joined #osdev
bauen1 has quit [Ping timeout: 268 seconds]
eroux has quit [Ping timeout: 260 seconds]
eroux has joined #osdev
<geist>
clever: like hell it's meant to be a bootloader
<geist>
it's just not trying to have that level of overhead in the FS layer
<geist>
it's more of an embedded system, where in general trading memory for caching is not desirable
<geist>
OTOH i would like to spiff up the VFS, but i also have other things to work on
<clever>
geist: thats why i had a ? at the end, wasnt sure
<geist>
note the strategy if treating the CWD as a string is not that strange, it's just not a unixy thing to do
<clever>
yeah, its just an alternative solution
<geist>
VMS notably did it that way. in general your working dir is basically a 'prefix' to your path
<Mutabah>
Pretty sure I did that in my previous attempt
<geist>
ie, `set def [foo]` kinda stuff
<geist>
vms operates much more along the line of having lots of process and job and shell variables that are somewhat more powerfuly expanded by the OS than unix does environment variables
heat has joined #osdev
<kazinsal>
a fun one is the Cisco OSes, which have no concept of working directory
<kazinsal>
all paths are absolute
<geist>
yeah exactly. working directory is just one of those things that seems fairly universal now, but really isnt required per se
danilogondolfo has joined #osdev
<geist>
unix made it somewhat of a first class citizen in that the kernel tracks the cwd of a process, but it doesn't really *have* to
<geist>
it's just a thing that seems kinda natural now because everything has it
<clever>
with the recent additions like `openat`, the cwd could be entirely in userland
<kazinsal>
this can get a bit funky on some devices where the path/filespec "running-config" may be "memory:/running-config" or "system:/running-config" or just a nebulous "running-config"
<clever>
and you could even have a seperate working dir for every light thread (userland context switching)
<kazinsal>
imo it makes sense to make cwd a userland thing especially if you have a standard, system-provided userland library that's either dynamically linked or a vDSO type thing
<geist>
yah, whether orn ot it's performant and/or breaks your security model is a different thing
<kazinsal>
the vfs and subsequent pfs (is that a term?) endpoints get simplified a lot if you always provide them absolute paths
<clever>
the only case i can see where cwd kinda leaves userland, is with execve, how do you pass that working dir over to the new exe?
<geist>
yah tis why i'm not overly interested in revisiting the cwd as a vfs construct
<clever>
do we just extend stdin/out/err, and make cwd the 4th fh?
<geist>
could do it VMS style: a system variable
<geist>
in whatever mechanism env vars are passed
<kazinsal>
clone the existing environment and use the `char** envp` to update
<clever>
i can also see how you might entirely delete the concept of the / and chroot
<kazinsal>
maybe this isn't valid per the posix spec, I'm not sure
<clever>
just pass the root dir as a second file handle, along stdin/out/err/cwd
<clever>
then chroot is just changing what handle you give to execve
<geist>
probably not. i have a suspicion that not having a kernel mediated CWD would break some other stuff, like renaming dir structures that you're a cwd in and whether or not posix says it has to follow
<clever>
i'm thinking along the lines of cwd is still a file handle, but its in the normal open file table, not a magical field on the proc
<geist>
ie, if your CWD is /foo/bar and foo gets renamed to foo2 does it still work? in posix it does, your cwd is just now intrinsically /foo2/bar but dunno if its specced that way
<geist>
or just is that way because that's how it works
<clever>
and userland is free to have multiple dirs open
<clever>
so it will follow the rename as before
<kazinsal>
now becomes a problem of where you maintain the cwd path to vfs/inode mapping
<moon-child>
what if userspace cwd is a pointer instead of a pathname?
<Mutabah>
Challenge with a fd based cwd is - how do you go up?
<moon-child>
right
<kazinsal>
and this is why my two to-do OS projects are dumb and don't give a rat's ass about the end user experience
<moon-child>
fuchsia answer is: you can't, and that's a feature
<clever>
Mutabah: openat(cwd,"..")
<moon-child>
I think that's not unreasonable
<clever>
now you have a handle to the parent dir
<Mutabah>
assuming that's present in the filesystem
<geist>
*this* is why .. exists
<clever>
then you close the old cwd, and overwrite the cwd var {tls|global} var
gog has joined #osdev
<clever>
geist: i feel like .. existing on-disk, is also to allow for a dumber fs driver, an ext{2,3,4} file handle could just be an inode# alone, and you can still .. your way up to the root, without having to track the directory structure in ram
<geist>
right
GeDaMo has joined #osdev
<clever>
and thats also a reason you cant hardlink directories
<geist>
and . lets you look up the inode number of a dir based on just the dir entries itself
<clever>
which parent does .. point to?
<geist>
correct
<sham1>
Right up until you'll have to cross a mount point, so at least those are needed to augment the otherwise naïve processing
<clever>
sham1: and thats also where chroot escape exploits arise
<gog>
mew
<mjg>
sham1: the device letter thing is imo a major drawback
<gog>
i have to work with google analytics again today somebody kill me
* kazinsal
pets gog
<mjg>
gog: do you happen to have a bottle of bleach nearby?
<gog>
yes
<mjg>
gog: check under the sink or perhaps in the bathroom
<mjg>
perfect
<mjg>
now open it
<gog>
ok
<gog>
then what?
<mjg>
call help
<gog>
:P
<sham1>
This is the Google Analytics prevention hotline
<epony>
you have been prevented to analyse yourself
<mjg>
press 1 to for help finding bleach
<mjg>
press 2 for life guidance
<kazinsal>
we're here to reassure you that everything is okay, ML is just a fad, and the six speed manual transmission will be here for decades to come
<epony>
7 speed
<mjg>
your call is very important to us
<zid>
ML is not a fad, but it will always suck
<mjg>
8 to pick an optin at random
<epony>
press * for the matrix
<sham1>
I'm doing ML stuff at uni and I can confirm, it does indeed suck
<epony>
no, your Uni sucks
<epony>
you'll suck later when you graduate too
<zid>
stochastic parrot
<mjg>
can we use more inclusive language here
<mjg>
lemme lead the charge
<zid>
it.. turbo mega fucks the pooch?
<mjg>
this is unprofessional zid
<epony>
for now, just Turbo Basic
<zid>
How do I be professor
<epony>
you can't
<mjg>
if you have concerns about quality of a solution, project or whatever else
<mjg>
you can raise them respectfully
bauen1 has joined #osdev
<sham1>
I mean, there's interesting tech behind ML, but the problem is that it's touted as a silver bullet. Although that's just marketing department
<moon-child>
you also have to have at least 3 avxes
<mjg>
people say the world ends not with a bang, but with a wimper
<zid>
If stochastic parrots are the solution to your problem, it's not a very interesting problem
<mjg>
but it really ends with ML results on IOT
<kazinsal>
doomerism is the most boring thing my fellow millennials could have devoted themselves to and I hate it
<zid>
I'm already implicitly allowing you to set cookies by visiting your domain, if I didn't want third party cookies I'd block them anyway which.. I do
lockna has quit [Quit: lockna]
<heat>
but I do use chrome on mobile so no ublock for me
<zid>
so to me it PURELY fucked me over
<zid>
as now I have to actually accept a EULA
<sham1>
Is Microsoft a disability now?
<zid>
in order to make the website's stupid banner stop blocking the content
<heat>
i have my cat on my lap
<heat>
this is nice
<zid>
did you find it?
<zid>
or buy it?
<sham1>
PET IT
<heat>
i am petting it
<heat>
zid, we found it ye
<zid>
I was talking to the cat.
<heat>
we no buy animals, buying animals bad
<heat>
oh ok, he says ""
<kazinsal>
do catgirls count as animals
<heat>
yes and no
<LivewareProblem>
i mean kinda?
<sham1>
I suppose
<clever>
do humans count as animals?
<LivewareProblem>
oh right
<sham1>
Although you probably couldn't own one
<LivewareProblem>
humans are animals
<LivewareProblem>
i forgot
<heat>
sham1, don't kink shame
<LivewareProblem>
yeah so clearly catgirls are also animals
<LivewareProblem>
heat: lmao
<sham1>
No, they're actually fungi
<kazinsal>
mycelium catgirl body pillow
<moon-child>
lol
<sham1>
Anyway, office slippers are so nice
<heat>
wtf
<heat>
why do you have them
<epony>
NZ PM steps down to attend to fungi too.
<sham1>
Because I'm in an office. Duh
<LivewareProblem>
sham1: pog
<moon-child>
all slippers are slippers if you're in an office!
<heat>
a part of me wants to go out and get some decent coffee, another part of me wants to go watch the tennis, but the largest part of me just wants lap cat
<heat>
GeDaMo, possibly is an understatement
<zid>
heat: buy me a coffee, make the cat watch the tennis
<zid>
there, problems solved
<zid>
why I have to do all the thinking round here
<heat>
the cat does not give a shit about tennis
<heat>
he's a badminton cat
<zid>
*make*
<zid>
Have you seen a clockwork orange
<heat>
no
<zid>
you should
<heat>
why
<sham1>
Have you read it though?
<zid>
It is relevent, and also a good movie
* gog
catgirls
<heat>
gog, cat
<LivewareProblem>
gog: moon-child needs a cat
<heat>
moon-child, go to your local cat shelter
<heat>
plenty of them cats
<gog>
catgirl shelteer
<moon-child>
can't. landlord policy
<moon-child>
:\
<heat>
lmao
<kazinsal>
no pet policies in my current lease but I can't find any unwanted catgirls
<kazinsal>
sigh
<zid>
why would you get a cat girl
<zid>
when you can get a goth gf
nyah has joined #osdev
<kazinsal>
tag team them against the femboys and we'll see what the real outcome looks like
<LivewareProblem>
why not both?
<heat>
because cat girl and cat boi cannot live in peace
<heat>
there can only be one
<zid>
My type is 'demon lord' but I don't think there's a dating site for those
<kazinsal>
you'd think catgirl and catboy would just be ruttin mad like hamsters
<epony>
you can get your own food timestamps
<gog>
a catgirl and a goth gf can be one in the same
<epony>
not in Iran
<LivewareProblem>
gog: that's what I said
lockna has joined #osdev
<gog>
oh
<gog>
:)
<moon-child>
who the fuck is LivewareProblem
<moon-child>
is it aoei
<gog>
yes
<zid>
what's an aoei
<zid>
is it the person who was quantumbanana the other day
<moon-child>
maybe?
<LivewareProblem>
nah, I'm actually a demon lady
<kazinsal>
yo where do I get a goth catgirl gf who will fuckin step on me^H^H^H^W^W^W^W^W^W
<zid>
named dan?
<zid>
or is it jan
<LivewareProblem>
kazinsal: I can do 2/3
<epony>
a Japanese word for them your PC is on screen safe mode
* LivewareProblem
is not a catgirl
<zid>
kazinsal: Sounds like you want a demon lord also
<LivewareProblem>
or a demon lady!
<zid>
lord is neuter
<LivewareProblem>
is it?
<moon-child>
not _yet_
<LivewareProblem>
it sounds so masc
<sham1>
I just saw the new Wikipedia. Eugh
<epony>
or just a landlord
<kazinsal>
demon *mommy* god dammit you fucks
<zid>
it's the same for me so far, but I did see someone else moaning
<zid>
oh no I don't want a mommy
<sham1>
If you're going to do a redesign, why not have the top-bar of the page also stick to the top of the screen
<heat>
why do cats breathe so fucking fast
<zid>
that's way out of my strike range
<heat>
it's nuts
<zid>
heat: higher heatbeat
<zid>
smaller thing
<zid>
mice are like 800bpm
<heat>
zid, they need to calm the fuck down
<GeDaMo>
Oh, I just read about the redesign
Starfoxxes has joined #osdev
<GeDaMo>
Eh ...
<moon-child>
heatbeat
<GeDaMo>
I'm not sure that's an improvement
<heat>
the arch wiki went through the redesign a few months ago
<heat>
maybe year?
<LivewareProblem>
kazinsal: so uhhh i heard you're lookin for a demon mommy huh
<zid>
shion > nina
<GeDaMo>
At least it still works without JS
<epony>
after 7-8 pages of scroll down
<epony>
500 lines of text to first paragraph.. fantastic stupidity
<GeDaMo>
Why do sites insist on so much blank space at the sides?
<epony>
because people have very narrow eyes like cats
<epony>
and sheep
<zid>
cus they aren't columnated
<Ermine>
because text width should be less than 80-100 characters
<epony>
it's a sheeple redesign for more baaah
<zid>
and there's no real advantage to super long lines
<zid>
the question is why do people have their browsers 8000 pixels wide
<zid>
We should settle on all websites being A4 sized
<sham1>
GeDaMo: having the top bar stick would also work without JS. You just need a bit of CSS. Hell, the ToC already stays with your scroll position
<Ermine>
Wide lines are unergonomical. That's something book publishers know for quite a lot time
<epony>
first scroll 8 pages
<zid>
position: fixed;
invalidopcode has quit [Remote host closed the connection]
<zid>
float absolute
<zid>
blah blah
<zid>
I did css once, 20 years ago!
<GeDaMo>
The site shouldn't be trying to dictate how wide the text is, I can adjust my window if it's too wide
invalidopcode has joined #osdev
<Ermine>
zid: wide browsers can be used for more columns I guess
<zid>
GeDaMo: I disagree, I'd rather be able to chop content off by resizing
<sham1>
There's a full-screen button at the bottom right, which widens the text
<zid>
it's been impossilble for a decade to say, crop down a website so that you can only see the video player
<zid>
or paragraph of text you're interested in
<sham1>
Although I guess that doesn't work without JS
<zid>
because they now all reflow
<GeDaMo>
sham1: :|
<zid>
so I have to have bbc iplayer open fullscreen or whatever just to have a 480p video player onscreen
<sham1>
Why don't website vendors remember that Reader mode exists specifically for the reading experience if one needs it
<zid>
because users don't
<zid>
users ruin everything afterall
<sham1>
True
<heat>
zid, oi do you have a tv license
<epony>
it's a cone spiracy of halitosis and bad headache from eating too much concetrated garlic farts
<zid>
yes
<zid>
do you pay your netflix licence
<epony>
it's called petfleax
<heat>
yes
<Ermine>
GeDaMo: going further, the fact of site being able to control how data are presented to user is flaw of HTML/CSS. Stuff like gemini tries to address this.
<zid>
html should be latex, and document size should be fixed to A4, fite me irl
<Ermine>
Ah, LETTER is some other paper size which I never cared about...
<zid>
PC LOAD LETTER
<Ermine>
too many LETTERs
<Ermine>
bloody muricans indeed
<epony>
and then the letterbox
<epony>
and forking noto fonts
vdamewood has joined #osdev
<zid>
Warning: This program containad strong language and adult themes
<zid>
and por spelig
bauen1 has quit [Ping timeout: 265 seconds]
<heat>
best spelled efi spec
<epony>
it was supposed to be UFOY but ended up UEFIed up
<epony>
Apple always gets things wrong..
mrvn has joined #osdev
<mrvn>
happy new year
<Ermine>
happy new year mrvn
<mrvn>
I've been pondering debugging kernel crashes better so tell me if this is the greatest idea since sliced toast: each core gets a ring buffer for debug output and when investigating crashes you turn on debugging in suspected functions (compile time, runtime, whatever system you have) and that just dumps all the output into the ring buffer. Then on BUG(), GP, panic() the debug ring buffer is dumped along with
<mrvn>
the register and stack dump.
<epony>
CPUs have now USB debugging exposed
<mrvn>
That way you aren't flooded with debug output while everything still works but on crash you can all the output you missed to the extend of the ring buffer.
<mrvn>
+see
<heat>
but you're still slow in that case, aren't you?
<mrvn>
as slow as converting the debug stuff to ascii is.
<mrvn>
not as slow as waiting for it to be written to a file.
lockna has quit [Quit: lockna]
<epony>
China will be having the best viralunar new year any time now, very soon.
<clever>
epony: the usb debugging that ive seen (ehci debug), is less of a jtag port, and more of a uart, that lets you talk over a usb cable without a usb stack
<epony>
jtag is nice
<clever>
basically, the ehci controller, can drive an ehci debug dongle, without a usb stack
<clever>
and you can just give it bytes, like a dumb uart
<epony>
processors have management controller systems in them now too
<clever>
but as part of the design, its usb2 only, it cant downgrade to usb1
<zid>
I've seen usb3 snifferers
<zid>
they're expensive af though
invalidopcode has quit [Ping timeout: 260 seconds]
invalidopcode has joined #osdev
gog has quit [Ping timeout: 252 seconds]
<mrvn>
clever: does Linux network console work on RPi?
<mrvn>
(or rather how well?)
<clever>
mrvn: hmmm, ive not really tried it
<clever>
the firmware also has its own net console
<dinkelhacker>
Does anybody know if I can emulate a raspi3/4 like system timer peripheral with the virt machine type?
<clever>
mrvn: let me try setting it up, and see what happens
<clever>
dinkelhacker: pi3/pi4 are using the standard arm generic timer, which qemu should emulate
<clever>
the vpu timer is still present, but doesnt have enough channels
<clever>
and cant do per-core irq's
bauen1 has joined #osdev
<dinkelhacker>
clever: I find a "armv8 timer" in qemu's dts but it has no "reg" specified o.O ?
<clever>
dinkelhacker: you access it with msr/mrs
<dinkelhacker>
So i was assuming this is some core interal timer which might be accessed via system registers.
<clever>
i think
<clever>
let me check how LK does it
<clever>
yep
<dinkelhacker>
yeah but the bcm2711 has a system timer mapped to 0xFE003000
<bslsk05>
github.com: lk/arm_generic_timer.c at master · littlekernel/lk · GitHub
<clever>
dinkelhacker: 0x7e003000/0xFE003000 is the vpu timer, entirely seperate from the arm timers
<clever>
the vpu timer has a CLO/CHI 64bit counter, that counts as 1mhz, and 4 compare (C0/C1/C2/C3) channels, that fire an irq each, when CLO matches
<clever>
but the VPU firmware needs 2 of those channels
<clever>
and the VPU timer cant trigger per-core irq's on the arm
<mrvn>
clever: how does the firmware net console work? mailbox on the RPi side and same format as linux on the ether?
<clever>
so it basically became useless the moment the arm got 4 cores
<clever>
mrvn: its only active during the firmware bootloader, and dies as soon as start4.elf is executd
<clever>
the official docs, recommend using it to dump usb logs, when it cant boot from usb
<clever>
because it doesnt have the same bandwidth limits as uart
<mrvn>
dinkelhacker: the vpu timers are common to all RPis and run at 1MHz.
<dinkelhacker>
clever: yeah right.. I've been using that so far on the actual HW to trigger the scheduler but now that I want to work more with qemu I wondered if I it can emulate that
<clever>
dinkelhacker: qemu does emulate the VPU timer, at the same address
<clever>
but using the arm generic timer is better
<clever>
each core has its own timer, and irq's go back to that core
<dinkelhacker>
but only if I use the rpi3 machine type right? not with virt?
<clever>
yeah, only the rpi based machines have the vpu timer
<mrvn>
dinkelhacker: virt on an RPi?
<clever>
if you use arm virt, youll only have generic arm timers
Burgundy has joined #osdev
<dinkelhacker>
Makes sense.
<mrvn>
If you use ARM virt then you also get memory at 0x20000000 unlike the RPi that has it at 0x0. The kernel gets loaded to a different address.
<mrvn>
iirc
<clever>
thats also why you should be parsing dtb if you can
<clever>
in theory, you can build one kernel, that works on both virt and rpi, including real hardware
<clever>
it should just parse the dtb, and initialize the right drivers for the current system
<dinkelhacker>
mrvn: I started developing on the actual pi, than fiddled around with the -M rpiX and now want to use virt to be a bit more flexible.
<mrvn>
which is indeed quite hard
<dinkelhacker>
Yeah parsing the dtb is on my TODO list.
<clever>
personally, i would start by ignoring dtb, and get uart, printf, and maybe heap online
<clever>
then use that to debug the dtb stuff, and start using dtb
<mrvn>
dinkelhacker: you need to hand craft asm code to be position independent and relocate your kernel or map virtual memory and jump there. Can't do it in C.
<mrvn>
(safely)
<clever>
but most of my arm stuff, has been in a pre-dtb situation, so i havent really been able to do that
<dinkelhacker>
mrvn: For me it loads actually to 0x40080000
<mrvn>
or link your kernel to where the cpu model you emulate has the memory.
<mrvn>
dinkelhacker: so you can put that into the linker script and check where the UART is in the dtb by hand and hardcoded that too and you cna print debug stuff for the rest.
<dinkelhacker>
I have uart working, basic smp, locking and now wanted to dig deeper into heap stuff. But for that I wanted to get a nicer qemu setup so I won't become insame with the real hw.
<mrvn>
all of that breaks when you switch from RPi to virt, probably.
<mrvn>
The DTB describes the hardware layout and since you don't parse that you won't adjust to the changed layout.
<dinkelhacker>
but from what I understand I basically just have to change my timer code to use the ARM generic timer, and have a second memmap for the virts peripheral base adresses and than I should be good
<mrvn>
at a minimum
<dinkelhacker>
Yeah of course I have to adjust all the addresses as long as I don't have the dtb parsing.
<clever>
the rpi is using a pl011 uart, the same as arm-virt
<mrvn>
the DTB tells you which uart to use as console too
<clever>
so you just have to change the base addr of the uart, and that should come back
<clever>
assuming you have the basics (mmu, ram) working
<mrvn>
clever: depends on BT being active or not
<clever>
yeah
<clever>
bt can also run on the mini-uart
<dinkelhacker>
bt?
<mrvn>
Is anyone developing their RPi kernel with BT activated?
<clever>
bluetooth
<mrvn>
bluetooth
<clever>
some might, by not knowing how the muxing works, and what options exist
<dinkelhacker>
I just tried a minimal image with qemu and I get output from the pl011 so that seems to work. So yeah gotta change the timer code so I can have all 4 cores print heartbeat messages every second (that's basically all it does so far >D). Then it should work on qemu and the p.
<mrvn>
how do you multitask with just the vpu timer? Fixed time slices?
<dinkelhacker>
yes... like every second I get an interrupt, and all cores swich to the next task
<mrvn>
doing tickless multitasking has real benefits.
<dinkelhacker>
I root the interrupt to one core and that interrupts all other cores with sgis^^
<dinkelhacker>
Well this was just "convenient" to work on spinlocks..anyway it's just a toy/learning setup at the moment. What do you mean with tickless multitaskin?
<clever>
dinkelhacker: if there is only 1 task scheduled on a core, dont set a timer to interrupt it
<mrvn>
you don't generate an interrupt every second but you set the timer to fire when you next need to wake up.
<clever>
let it be!
<mrvn>
E.g. if some process does "usleep(500);" you set it to 500us from now. When you only have one process ready to run you might not set a timer at all.
<mrvn>
If a process started with a 1s time slice but got interrupts 0.6s into that slice you set the timer for the remaining 0.4s.
<zid>
That's a very very minor detail
<clever>
when LK is built with dynamic timers, it does a bit of both
<dinkelhacker>
Oh yeah of course there are much better strategies for "real" applications. Sice I wanted to see if the task switching works that was just the first thing I came up with.
<clever>
there is a software timer layer, that keeps track of every timer
<clever>
and then the hw timer, schedules an irq for when the next software timer will expire
<clever>
but, then scheduler wont create timers, if there are no more runnable threads
<clever>
so if there are enough cores to go around, it never ticks
<mrvn>
clever: the "no timer with just one process" is actually much harder than the rest I feel.
<clever>
but if there is a sleeping thread, with a 12 second timer left on it, then in 12s, it will create a hw timer for 12s, and and then consider context switching then
<moon-child>
why?
<clever>
above statement is a bit jumbled, paused mid-sentence
<mrvn>
moon-child: many special cases. You have to add the timer when some other process wakes up. Have to account for the time run without timer. add timer on fork, ...
<clever>
mrvn: what causes the wakeup?
<mrvn>
do you have one task per core? Can you reshuffle so they are evenly distributed? Any of them pinned to a core?
<mrvn>
clever: any interrupt. e.g. NIC getting data
<clever>
smp LK, is something i understand less
<clever>
lets say LK gets a NIC irq, and then decides to wake a thread that was waiting for data
<mrvn>
or one core forking and tasks getting reshuffeled.
<clever>
at the end of the irq handler, it will then consider context switching to that new thread, based on how much of a timeslice the previous thread had used
<clever>
i'm fuzzy on if it always context switches, or sets a timer and doesnt
<clever>
so the nic irq, is what triggers the context switch, and gets it out of a timer-free state
<mrvn>
It should switch if the woken up task has a higher priority or larger time slice remaining.
<clever>
and now 2 threads are runnable, so a timeslice irq is setup
<clever>
i would assume it always has a large timeslice, if all slices default to the same
<clever>
because it would have been sleeping, and has a fresh slice
<mrvn>
clever: ahh, so you don't create a software timer for the time slice but just add that in hardcoded at the last moment
<clever>
yeah, there was only 1 runnable thread, so no timer exists
<clever>
the NIC/uart irq then breaks it out of that stale-mate
<mrvn>
A sleeping process should only get a new timne slice if it slept long enough that it would have run again.
<clever>
also depends on why it is sleeping
<mrvn>
not really.
<clever>
was it blocked on a fifo? or sleeping a set time?
<clever>
ah, you mean about sharing cpu evenly, rather if a timer should exist
<mrvn>
then it runs on the remaining time slice if the sleep was short or a fresh one if the sleep was long enough to round-robin at least once.
<mrvn>
yeah
<mrvn>
Otherwise you get the old unix behavior where tasks get more CPU time when you enter keys every now and then because the keyboard interrupt refreshes your time slice.
<clever>
that actually sounds like a bug i get when the mouse all the time
<clever>
if i'm dragging an icon, and its at the edge and causing scrolling, its rather slow
<clever>
if i wiggle the mouse around, within the trigger, it scrolls faster
<clever>
because its scrolling both on mouse-move, and on timer
<epony>
that's the UI, not the mouse doing it
<mrvn>
If you have dynamic priorities then calling "yield();" just before your timeslice is up can also screw with that.
<clever>
epony: id say its a bug in the UI, doing 1 tick of scrolling, every time an event happens
<mrvn>
clever: ahh, I think that faster scrolling is a feature by now.
<clever>
and the mouse is able to span events faster then the configured timer
<clever>
spam*
<mrvn>
Might have started as a bug of exactly that nature but I've seen that in a lot of apps.
<bslsk05>
qifi.org: pure JS WiFi QR Code Generator
<clever>
mrvn: ah nice, i had trouble finding such a site before
<clever>
the last hit i found in google, was uterly stupid
<clever>
no matter what type of qrcode you try to generate, its always a tiny-url back to their domain
<clever>
so they can track every single use
<clever>
and if you need the qrcode to get on the wifi, good luck :P
<mrvn>
" Don't trust your browser either? Just pipe the string WIFI:S:<SSID>;T:<WPA|WEP|>;P:<password>;; through the QR code generator of your choice after reading the documentation. "
<bslsk05>
developer.arm.com: Documentation – Arm Developer
<clever>
ah, 68mb, thats better
<zid>
8.25 byts, nice!
<zid>
8.5 I can count.
<mrvn>
It's called _EL0 because it's readable from EL0?
<dinkelhacker>
Yeah maybe... according to the pseudo code in the spec it is
<mrvn>
by the way: What does DDI0487F stand for?
<clever>
i think the F at the end, is a revision for the doc
<clever>
since GeDaMo has the I version
<mrvn>
0487 looks like a running number for docs
<clever>
no clue what the rest are, some kind of id#
lockna has joined #osdev
<clever>
yeah
<mrvn>
Distributed Document Id? *wild guess*
<clever>
DDI0500J_cortex_a53_trm.pdf is the docs for a specific armv8 core
<clever>
you can also see, its after the number for v8 in general
<mrvn>
or Distribution ...
<GeDaMo>
Maybe developer
<mrvn>
also plausible
gog has joined #osdev
ptrc has quit [Remote host closed the connection]
ptrc has joined #osdev
gxt has quit [Ping timeout: 255 seconds]
gxt has joined #osdev
micttyl has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
<mrvn>
building Linux CONFIG_DEBUG_INFOS enabled: -rwxrwxr-x 1 brederlo users 521M Jan 19 10:12 vmlinux
<mrvn>
I don't think I will use that as default.
craigo has joined #osdev
Terlisimo has quit [Quit: Connection reset by beer]
bauen1 has quit [Ping timeout: 260 seconds]
Matt|home has joined #osdev
<heat>
lol
<heat>
yes
<heat>
you're not supposed to use debug info in linux except for debugging
Terlisimo has joined #osdev
<sham1>
One wonder what use debug info would have beyond debugging
<clever>
sham1: you might want to pre-build with debug info, so when you do later get a backtrace, you can debug it without having to reproduce
<heat>
sham1, backtracing
<clever>
the symbol table can give functions, but ive had issues before, where i wanted line numbers
<sham1>
I class that under (very crude) debugging, but fair enough
<heat>
not only debugging e.g profiling too, tracing
<heat>
but since dwarf sucks linux developed their own format
<heat>
ORC. it's essentially just a struct {where is sp, where is bp;} for every IP in the kernel :)
<sham1>
That's… a lot
<sham1>
Although it is indeed simpler than DWARF
<clever>
wasnt it dwarf, where its basically a bytecode, that returns that data, when given an IP?
<clever>
and then the compiler generates switch, if, and lut's?
elastic_dog has quit [Read error: Connection reset by peer]
<sham1>
If so then I'm not surprised that JITs don't bother generating that
<heat>
dwarf is a lot more complex
elastic_dog has joined #osdev
<heat>
it needs a full interpreter and shit
<sham1>
Debug information for JIT compiled code is its own can of worms
<heat>
which in theory would be fine except that it's slow as balls and error prone. slow as balls doesn't really belong to a linux profiling code path
<sham1>
Especially trying to make it so that an attached debugger can make use of it
<clever>
while nix lacks JIT, it does have exceptions
<clever>
basically, an exception within the internal language, is just thrown as a c++ exception, but the "run function" function, catches it, adds to the guest stack, then re-throws
<clever>
so its unwinding the host stack in chunks, one guest stack frame at a time
<sham1>
Well nix is mostly used for config, is it not? Not sure a JIT compiler would add much
<clever>
sham1: but it is a turing complete functional programming language
<clever>
and the module system can wind up producing a backtrace 100's of calls deep
<sham1>
Right, but I still don't know whether it'd need a JIT most of the time. The implementation being an interpreter should be rine
<clever>
sham1: when evaluating 100 machines in nixops, it can take 5+ mins, and over 20gig of ram....
<sham1>
Although does it at least compile down to even a bytecode? Because if not then that's just bleh
<clever>
sham1: its currently just an AST, a giant tree of structs, with function pointers everywhere
<sham1>
Ooh
<sham1>
No wonder then
<clever>
any given value, can either be a concrete type (string, int, list, set, others), or a thunk (a function pointer and some args)
<clever>
forceValue turns thunks into concrete types, by editing the struct in-place
<sham1>
Yeah, tree-walking famously isn't all that good for performance
<clever>
and then recursion runs thru the entire ast, to spit out the final derivation
<clever>
and lazyness lets it ignore leaves that it doesnt need
<clever>
{ a = f 1; b = f 2; c = f 3; }, a set is strict on the keys, but lazy on the values
<sham1>
Like from what I've understood, Guix benefits greatly from the fact that Guile actually compiles both to a bytecode and JITs hot code
<sham1>
I feel like a similar benefit could be seen in Nix
<clever>
so if you are using listToAttrs, or mapAttrs, or "foo${n}" = f n;, it must evaluate every key
<clever>
before it can query for a specific key
<sham1>
Eww
<sham1>
Sounds like JS
<mrvn>
Isn't there a target to split the vmlinux into the kernel and debug infos in the format gdb expects (BUILD ID thingy)? I don't mind having 500MB debug infos on the build server but a 500MB kernel for netboot would be bad.
<sham1>
Dynamically computing keys like that isn't exactly great. Eval is another
<clever>
mrvn: the above vmlinux file, is the ELF build, there should also be a zImage or similar, that i would expect to be smaller
<mrvn>
heat: CONFIG_DEBUG_INFOS adds DWARF stuff to the kernel.
<heat>
i know
<sham1>
Well Fedora for example manages to split the vmlinuz into debuginfo, as does Debian, so I'd suppose so
<clever>
sham1: yeah, thats why you need to be aware of this cost, and try to avoid dynamic keys depending on too much state
_xor has quit [Ping timeout: 268 seconds]
<clever>
if you want good performance
<sham1>
Is there a reason why nix doesn't have a compilation step to linearize the tree?
<sham1>
Would also allow for other optimization
<clever>
sham1: things like overlays can mutate the ast at almost any point
<sham1>
Or is it just them not bothering
<clever>
and if your modifying an overlay, thats going to add a compile cost every time you edit it
<mrvn>
-rw-rw-r-- 1 brederlo users 5.8M Jan 19 10:13 arch/x86/boot/bzImage
<mrvn>
(if you build the later)
<sham1>
And I'll assume that overlays cannot be determined in a nice manner without running the program? Great
<clever>
sham1: another large complexity is the module framework, which is mostly implemented in nix, not c++
_xor has joined #osdev
<clever>
the c++ part, is the builtins.genericClosure function, a way to walk a web of nodes, and generate a list of energy node in the web
<clever>
you give it a starting set (modules), and a function to get more (for example, reading .imports from a module)
<clever>
and it will then recursively run that function, until it has visited every module, and built up a list of all of them
<clever>
then entirely in nix, you have to import every module, find the .options, and merge those trees recursively
<clever>
then in a second pass, find the .config of every module, and merge those, based on the rules defined in .options
<clever>
and that is heavily doing dynamic keys, and entire dynamic trees
<clever>
sham1: another issue, in the case of deploying 100 machines with nixops, each one has different modules loaded, so you cant just pre-compile a single machine sub-tree, and reuse it
<clever>
sham1: i feel like you would need to partially compile every file seperately, then have a kind of LTO pass to optimize it further
<clever>
with the lack of `do` blocks haskell has, i have a hard time picturing what i would even put into an llvm-ir codeblock
xenos1984 has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 256 seconds]
heat has joined #osdev
srjek has joined #osdev
xenos1984 has joined #osdev
<ddevault>
what the heck am I missing with these IRQs
_xor has quit [Ping timeout: 256 seconds]
_xor has joined #osdev
<zid>
a mask bit somewhere
<ddevault>
oh my god
<ddevault>
the pl011 manual is fucking stupid
<ddevault>
>On a write of 1 to the particular bit, it sets the corresponding mask of that interrupt. A write of 0 clears the corresponding mask.
<ddevault>
1 /enables/ the interrupt
<zid>
yea
<zid>
actually you'd assume 1 disables from how it's written
<zid>
masked interrupts = non-firing
<ddevault>
"sets the mask" to me sounds like it masks the interrupt
<ddevault>
"clear the mask" sounds like it unmasks the interrupt
<zid>
yes
<zid>
and 1 sets the mask bit
<zid>
so 1 = disable
<ddevault>
wrong
<ddevault>
1 enables it
<ddevault>
hence my confusion
<zid>
Not according to what they wrote :P
<ddevault>
yep
<ddevault>
which is why I was confused.
lockna has quit [Quit: lockna]
<ddevault>
another page has the correct description
<ddevault>
>You can enable or disable the individual interrupts by changing the mask bits in the UARTIMSC register. Setting the appropriate mask bit HIGH enables the interrupt.
<ddevault>
but I was tearing my hair out because the docs are wrong
<ddevault>
lol
<zid>
You can enable or disable the individual interrupts by changing
<zid>
on page 3-17. Setting the appropriate mask bit HIGH enables the
<zid>
the mask bits in the Interrupt Mask Set/Clear Register, UARTIMSC
<zid>
interrupt.
<ddevault>
yeah I quoted this above
<zid>
so they're using the word mask wrong, but they're using it wrong *consistently* at least
<zid>
so it's still possible to write a working driver
<zid>
they meant 'enabled' everywhere they wrote 'masked' basically
<ddevault>
okay good
<ddevault>
my interrupts do work
<sham1>
What I don't get is why they'd use mask like that
<sham1>
Everywhere else it means to disable the interrupt
<zid>
cus they're dumbos
<zid>
"Enable the reversal of the inverse of the mask of the interrupt disable enable register bit"
fedorafan has quit [Ping timeout: 252 seconds]
<mrvn>
clever: you can use continuation-passing-style for most functional languages very easily. Everything is a function that ends by calling another function tail recursively. results are build up in the env/stack object that you pass around.
<sham1>
There's also ANF, which has the benefit of not being as funky as CPS
<mrvn>
ddevault: Your confusion is about how you interpret "mask". It's mask, not maskED. So the IRQ fires if IRQ & MASK != 0.
<ddevault>
kk
<ddevault>
that makes more sense, thanks
<mrvn>
Iirc x86 works the other way around. You have a mask of IRQs that are blocked, i.e. masked.
fedorafan has joined #osdev
<mrvn>
sham1: Flughafen Antofagasta?
<sham1>
Wot?
<mrvn>
ANF, it's the airport in Antofagasta. Wherever that is.
<mrvn>
I don't think it makes a difference for "do" blocks. They become a function taking a unit/void parameter either way.
foudfou has joined #osdev
<mrvn>
ANF seems to be just extending CPS to functions with multiple parameters.
<mrvn>
but the wikipedia article is rather sparse on A-normal form. Might be wrong.
<sham1>
ANF differs from CPS in that it's in direct style, as opposed to CPS which by definition is not.
<mrvn>
what's direct style?
<sham1>
So for example, in CPS the Wikipedia example of f(g(x), h(y)) is g_cnt(x, (v0 -> h_cnt(y, v1 -> f_cnt(v0, v1, rest_of_program))))
<mrvn>
sham1: or v0/v1 are stored in ENV and not passed to f_cnt. At least v0 not anyway.
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
<mrvn>
sham1: the CPS we used in out compiler course only allowed one argument per function.
<sham1>
Well we can make it into a tuple, but the point remains
<sham1>
Basically direct style doesn't have that kind of control inversion
<zid>
are you talking about compiler nonsense
<sham1>
Yes
<mrvn>
We compiled ocaml and there every function is curried so: f(v0, v1) is actually (f v0) v1
<zid>
disgusting
<mrvn>
sham1: so what you are saying is that ANF doesn't have a continuation?
<sham1>
Yeah, but that'd most likely be a front-end thing, while this CPS would be an IR and thus wouldn't necessarily need the currying. But one can still imagine it being in place
<zid>
oh at least we're getting curry
<sham1>
Oh, ANF does have a continuation. It's just that it doesn't reify it the same way
<mrvn>
Sometimes you need it. We started with just always having it and never went on to optimizing calls with multiple args.
<mrvn>
zid: functional programming is fun, and you get food.
rwxr-xr-x has quit [Remote host closed the connection]
<mrvn>
isn't ANF also a static single assignment form?
<mrvn>
(as is cps)
<sham1>
Yeah, they're all technically equivalent
gdd has quit [Ping timeout: 252 seconds]
<sham1>
They all enforce an evaluation order as well, of course
<mrvn>
Or maybe not exactly. In CPS the merging of two branches is done at runtime due to the tail calls being done and isn't an explicit node in the ast
<sham1>
CPS is convenient for certain things. For example you can get call/cc for free. The problem usually is that you want to have your activation frames in a stack, and to do that with CPS you have to "un-CPS" it back into direct style. You also lose call/cc
<mrvn>
sham1: *hand wave* there is no stack.
<mrvn>
" SSA is formally equivalent to a well-behaved subset of CPS excluding non-local control flow, which does not occur when CPS is used as intermediate representation."
<sham1>
Right. But for some things like compatibility, it's nice to have the stack there even if I can heap-allocate and GC the activation records technically
<mrvn>
Doing FFI calls without stack is a pain. For speed reasons you bets keep some dummy stacks around that you reuse for FFI calls so you don't have to allocate huge blobs of memory on every FFI call.
<mrvn>
s/bets/best/
<sham1>
I've actually read "Compiling with continuations", "compiling without continuations" and the third paper in the series, "compiling with or without continuations, whatever". It's neat how many ways there are to represent a computation
craigo has quit [Read error: Connection reset by peer]
craigo has joined #osdev
<sham1>
I personally prefer ANF as my λ-calculus for representing programs. Easier for me to reason about and arguably easier to compile
<sham1>
Although SSA isn't all that bad, if you happen to be C or similar
<mrvn>
yeah, it's generally SSA style stuff for imperative languages and continuations in functional languages in compilers.
<mrvn>
Although I wonder how the increased use of lambdas in c++ would benefit from CPS.
node125 has quit [Ping timeout: 260 seconds]
dutch has joined #osdev
spikeheron has quit [Ping timeout: 272 seconds]
lockna has quit [Quit: lockna]
elastic_dog has quit [Ping timeout: 246 seconds]
Starfoxxes has quit [Ping timeout: 272 seconds]
elastic_dog has joined #osdev
eroux has quit [Ping timeout: 260 seconds]
Starfoxxes has joined #osdev
bgs has joined #osdev
eroux has joined #osdev
gog has quit [Quit: Konversation terminated!]
bauen1 has joined #osdev
xenos1984 has quit [Ping timeout: 252 seconds]
xenos1984 has joined #osdev
gog has joined #osdev
heat has quit [Ping timeout: 256 seconds]
c2a2 has joined #osdev
c2a2 has quit [Ping timeout: 246 seconds]
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
epony has quit [Quit: QUIT]
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
lockna has joined #osdev
heat has joined #osdev
<heat>
my cat took my chair
<heat>
no irc 4 me
<sham1>
:(
<zid>
thanks cat
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<gog>
kitty
srjek has quit [Ping timeout: 268 seconds]
micttyl has quit [Quit: leaving]
lockna has quit [Quit: lockna]
danilogondolfo has quit [Remote host closed the connection]
<kaichiuchi>
hi
* geist
waves
<gog>
hi
<geist>
hi!
<geist>
i should figure out how to manually use the qemu balloon device
<kaichiuchi>
i've been running freebsd on a separate partition
<kaichiuchi>
and I have to say, it works pretty well on the desktop minus the fact netflix will not work
arminweigl has quit [Ping timeout: 246 seconds]
<geist>
yeah, it's a nice system
<geist>
haven't used it in a desktop like situation in a while but i still have a fondness for freebsd
<kaichiuchi>
what kills me is people don't really care about BSD it seems
arminweigl has joined #osdev
<kaichiuchi>
a lot of companies do, but that's all it seems to be for
<geist>
that wasn't always the case, but i've generally seen things erode in the last 10-15 years
<geist>
tis a shame, but linux got the mindshare and then somewhat took off with it
<geist>
side note i read a thing the other day that AIX was finally officially stopped, the last proprietary big iron unix
<kaichiuchi>
I just don't get how linux took over honestly
<kaichiuchi>
BSD was around long before
<gog>
the lawsuit
<geist>
oh i'm sure entire books have been written on the topic, but i suspect it was a bunch of smaller factors, no one thing
<kaichiuchi>
the sco vs at&t thing you mean got?
<geist>
that was the first shoe yeah, let some space
<kaichiuchi>
gog
<gog>
the lawsuit was among the first things
AFamousHistorian has quit [Quit: Leaving]
<geist>
though in my experience linux didn't start really getting serious until the early 2000s
<gog>
no, the at&t vs csu berkeley
<gog>
linus wrote linux to be something that could replace bsd unix on the 386
<gog>
before the lawsuit
<gog>
then it got noticed when people were concerned about the legal future of bsd
<kaichiuchi>
I was shocked to find that NVIDIA provides official BSD drivers
AFamousHistorian has joined #osdev
<geist>
i also suspect there was some general cultural issues at play there for a long time
<kaichiuchi>
ZFS is too cool to not use *BSD for a NAS though
<geist>
though i have no experience with dealing with the BSD(s) dev team(s) in the 2000s i think i've heard they were pretty conservative and hard to deal with
<gog>
there's also that
<geist>
not that linux isn't, but its a bit more wild west and what's just fine for lot sof folks
<kaichiuchi>
well, in my experience a lot of people in the unix world are conservative
<kaichiuchi>
that's what drives me mad, really
<gog>
linux is by far my least favorite open source kernel and OS but it's got the most support for things
<geist>
but i do remember in the mid 2000s, especially for these new ARM cores that were just starting to get powerful enough to seriously run a multiple-address-space system (ie, 920t, and definitely arm1136) it was still somewhat open whether or not netbsd or linux or whatnot was going to be what folks ran on them
<geist>
and aside from darwin, a bunch of companies essentially simultaneously voted about 2007-2010 and then i think that's when the ball really got rolling in that space
<geist>
and one can argue in the end all that matters is arm
zxrom has joined #osdev
<kaichiuchi>
the only two things I'm missing in freebsd desktop land are a native discord client and DRM for amazon video/netflix
<geist>
(not really) but it's i'd say at least half of linux's success
<kaichiuchi>
otherwise, absolutely everything else appears to work fine
<kaichiuchi>
i dunno, it really blows because i've sorta fallen in love with bsd
<geist>
i do assume you mean freebsd right?
<kaichiuchi>
yeah
<geist>
(being that there are multiple BSD OSes, etc)
<kaichiuchi>
the thing for me is, it's not just a kernel
<kaichiuchi>
it's a whole goddamn ecosystem
<kaichiuchi>
and it's great
<kaichiuchi>
i'm kinda fanboying a little bit, but
<geist>
yep, i like that too
<sham1>
Linux is the Windows of free software. CMW
<sham1>
CMV*
invalidopcode has quit [Remote host closed the connection]
<brynet>
the desktop discord is basically just that, using electron right?
<brynet>
also hi from the "other" bsd camp. o/
<kaichiuchi>
essentially, yeah
<geist>
yah i eventually decided that electron discord isn't really any different. i *think* there may be some advantages if you're streaming the desktop or whatnot
<geist>
but other than that i think it's the same thing
<qookie>
one thing is that you have global push-to-talk with the electron app
<brynet>
yeah, been using the web version on openbsd for a few months, all the old instant messaging platforms are dead and people keep dropping from irc.
<geist>
qookie: ah yeah that might be it
<brynet>
I imagine that's important for people using it for gaming
<brynet>
I know of at least one podcast that uses it now, bryan cantrills oxide and friends.
joe9 has joined #osdev
<mjg>
yo check out find(1) manpage
<mjg>
-type c
<mjg>
File is of type c:
<mjg>
[snip]
<mjg>
D door (Solaris)
<mjg>
on linux
<mjg>
there you go heat
<mjg>
kaichiuchi: does the discord client work under linux emul?
<kaichiuchi>
good question I have no idea
<mjg>
this can be a pretty seamless experience man
bgs has quit [Remote host closed the connection]
<kaichiuchi>
maybe
<kaichiuchi>
unrelated but I'm really tired of hearing people cry premature optimization for basically anything these days.
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 272 seconds]
srjek has joined #osdev
Burgundy has joined #osdev
dude12312414 has joined #osdev
Matt|home has quit [Quit: Leaving]
heat_ has joined #osdev
heat has quit [Ping timeout: 256 seconds]
<mjg>
kaichiuchi: dawg
<mjg>
premature optimization is a knee jerk reaction to be called out on doing something stupid
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]