channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=21&m=10&d=2
01:29:00 <Griwes> > PANIC: Unexpected IRQ: 6
01:29:00 <Griwes> oh that's not good
01:31:00 <Griwes> ah *literally* ud2 because of a missing return statement
01:31:00 <Griwes> nice
01:32:00 <gog> PANIC! at the IRQ
01:37:00 <Oli> Pattent pending
06:32:00 <geist> yah ud2s instead of a warning are annoying as heck
06:33:00 <geist> but seems to be the way of all compilers now
06:33:00 <geist> on top of that, grepping dissassembly for UD2 isnt' necessarily sufficient (though interesting) since sometimes the compiler will go ahead and insert a UD2 in essentially dead code that it can't 100% determine is such
06:34:00 <moon-child> i think there's a warning, but you have to turn it on?
06:35:00 <geist> not that i know of. at least on clang. rationale: undefined code paths are sometimes only determined post-optimization and they dont want to emit warnings like that
06:35:00 <geist> that's at least what the clang devs said
06:36:00 <geist> gcc has some optimization triggered warnings, though i think they also try to keep that to a minimum
06:36:00 <geist> it seems like a bit of a cop-out but there ya have it
06:40:00 <moon-child> I think almost all of gcc's non-trivial (flow sensitive) warnings are optimization triggered
06:40:00 <moon-child> or at least they used to be. I think they have been trying to do less of that recently, because it means you're prone to lose location information, and you don't get warnings at -O0
06:41:00 <geist> yah
06:42:00 <geist> you'd think that most undefined language stuff should be discoverable at -O0 but it guess clang at least only does some expensive stuff in the interest of optimizations. lots of dead code removal, etc
06:43:00 <zid> yea without O levels you get shitty warnings in gcc, and it makes sense and I don't blame it
06:47:00 <zid> Doing the analysis that's required for the optimization to produce the diagnostic but then not editing the output based on it is a bit of a waste
06:47:00 <zid> and probably makes the code messier too
07:37:00 <geist> yah i'm guessing one of the problems is farther down the optimization path you go, the harder it is to generate a warning that points toa particular line
07:37:00 <geist> since you're farther and farther from the original code
07:37:00 <zid> nod
07:38:00 <moon-child> same problem w/ debug info
07:38:00 <zid> When LTO is involved it often can't even give you the relevent /function/ that produced a machine code line
07:38:00 <zid> it becomes a lot more abstract and synthetic
11:52:00 <ZetItUp> i was having some issues with filenames while working on a FAT implementation, so when i finally has some kind of read function working, i tried adding a write and delete function, added some stuff, fixed alot of error and then i updated the test data and just copy/pasted the filename all over the place where i needed it
11:52:00 <ZetItUp> incl. DeleteFile()
11:52:00 <ZetItUp> well good news is, my DeleteFile() function works :D
11:59:00 <sortie> ZetItUp, woohoo
11:59:00 <sortie> Filesystem fun :)
11:59:00 <clever> i still dont have SD write, so i havent bothered looking into fs write
12:02:00 <ZetItUp> im looking for a kind of design like "Load the basics, have a file with a list of the drivers you want to load from disk, point at where they are and load them"
12:02:00 <clever> ZetItUp: that sounds a lot like how grub and linux function
12:03:00 <ZetItUp> yeah
12:03:00 <clever> i also dont have any loadable module support in my current code
12:04:00 <clever> chainloading doesnt really count
12:06:00 <ZetItUp> i don't really know what stuff i want to count as "basic" yet either, i guess ill figure it out when i get to that point, if it really needs to be loaded before something else :D
12:06:00 <Oli> I consider that getting tests to pass on FAT12 filesystem construction as satisfying. Congratulations for your achievements on, ZetItUp!
12:07:00 <ZetItUp> Oli im using a FAT32 fs right now, but i have dumbd it down alot haha
12:07:00 <ZetItUp> it's basicly FAT16 but it reads a FAT32 disk image
12:08:00 <ZetItUp> only taking care of the 8.3 filenames right now and skipping long filenames etc
12:08:00 <ZetItUp> just wanted to start somewhere
12:09:00 <ZetItUp> according to the documents a long filename can span over several files
12:11:00 <Oli> FAT16 and FAT32 seems nice to work with in comparison; on FAT12, 2 allocation tables abc and xyz, are merged in three bytes, as cb za yx!
12:11:00 <ZetItUp> yeah FAT12 seems to be way too complicated to even touch
12:12:00 <clever> Oli: at least its not RAW10 from a camera sensor!
12:13:00 <clever> 4 10bit ints, are stored in 5 bytes, as 4 8bit quantities, and then 4 2bit quantities
12:13:00 <clever> so you need to take an 8bit fragment, and a 2bit fragment from different places, and piece them together
12:16:00 <ZetItUp> why do people design stuff like that :|
12:17:00 <ZetItUp> i mean sure to save space
12:17:00 <ZetItUp> but still
12:17:00 <clever> ZetItUp: if you only care about 8bit samples, you can discard the 5th byte with the lower 2bit fragments
12:17:00 <clever> so whats left, is just a flat array of 4 8bit samples
12:18:00 <ZetItUp> hmm
12:18:00 <ZetItUp> https://pastebin.com/6B05FDRY test output :D
12:19:00 <ZetItUp> now i just need to make it work with the kernel
12:20:00 <Oli> I also intend to let long file name support for later, and focus on other scopes of the software I feel more attracted working in for now. clever: A decoder for that data structure sounds as satisfying to implement once solved!
12:21:00 <clever> Oli: instead of fixing the fat32 support in LK, i just extended the ext2 to support ext4
12:21:00 <clever> ext already has long filenames
12:28:00 <kingoffrance> eh, that raw10 actually sounds somewhat sensible. compare 2 alternatives <8 bits><2 bits, 6 unused>[repeat 3x for 40 bits total] == 8 bytes total needed, versus 5 and storing directly adjacent: <8 bits><2 bits, 6 bits><2 bits, 2 bits, 4 bits> <4 bits, 2 bits, 2 bits> <6 bits, 2 bits> 5 bytes but more complicated/arbitrary masks needed
12:29:00 <Oli> ZetItUp; I recall reading about an approach to keep a nice 8 bit array of originally 10 bits of data, by storing it as lossy, logarithmic data on 8 bits; entries with lower value, being more accurately represented than higher valued entries on.
12:29:00 <clever> kingoffrance: exactly
12:31:00 <clever> http://caxapa.ru/thumbs/799244/MIPI_Alliance_Specification_for_Camera_S.pdf
12:32:00 <clever> kingoffrance: page 72, details each of the standard formats for a CSI camera
12:36:00 <clever> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/media/platform/bcm2835/bcm2835-unicam.c#L23-L30
12:36:00 <clever> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/media/platform/bcm2835/vc4-regs-unicam.h#L197-L216
12:36:00 <clever> kingoffrance: the unicam (csi input peripheral) has very limited repacking support, to shuffle those bits around as they get stored to ram
12:37:00 <clever> and then the ISP deals with converting the raw data in ram, into rgb
14:33:00 <dzwdz> does anyone here use clang instead of gcc for cross-compilation?
14:34:00 <dzwdz> the wiki article on it is incomplete and i wonder how hard it is to setup
16:57:00 <heat> dzwdz: define cross compilation
16:58:00 <heat> compiling bare metal code should be pretty easy, just pass the right flags (ffreestanding and whatnot) and the correct --target
16:58:00 <dzwdz> oh right, that was too broad of a term ^^
16:58:00 <dzwdz> yup, i meant compiling for bare metal
16:59:00 <dzwdz> does clang have its own linker?
16:59:00 <heat> yes, lld
17:00:00 <heat> you may or may not have it, it's kind of optional and usually its own package in linux
17:00:00 <dzwdz> i don't
17:01:00 <dzwdz> i guess it uses the gnu linker as a default?
17:01:00 <heat> yes
17:02:00 <dzwdz> aight
17:02:00 <dzwdz> i'll try adding clang support to my kernel then, it sounds pretty easy
19:00:00 <heat> ahhh i forgot to do something special for the 1000th commit
19:01:00 <heat> well, nothing more special than fixing a typo I guess
19:02:00 <jimbzy> Nice job, heat.
19:03:00 <heat> i had thought of incrementing the version number last night but I completely forgot I got bored of having a number and just set the version to "rolling" 2 years ago
19:19:00 <pitust[m]> use the commit hash as a version