Search logs:

channel logs for 2004 - 2010 are archived at

#osdev is the only channel with logs prior to 2004

daily #osdev logs after 12sep2018 are not available until midnight PDT
use the link below if you need today

Friday, 15 February 2019

01:27:15 <jmp9> ok guys
01:27:22 <jmp9> it seems that there is no ATA PIO buses
01:48:42 <jmp9> i got 0xFF status on all ata pio devices
01:50:53 <klange> What is a "PIO device"?
01:52:11 <jmp9> i mean ata bus
01:52:15 <jmp9> on port 0x1F0
01:52:48 <jmp9> primary: master 0x1F0 slave 0x170
01:53:03 <jmp9> secondage: master 0x1E8 slave 0x168
01:53:40 <jmp9> when i read primary master
01:53:43 <jmp9> 0x1F6 status
01:53:45 <jmp9> i got 0xFF
01:54:29 <klange> Are you checking if these devices actually exist or blindly trying to read them? Is this real hardware? Is it SATA hardware? Have you enabled legacy PATA emulation?
01:55:02 <jmp9> okay okay my fault
01:55:05 <jmp9> i should use pci
01:55:08 <jmp9> to detect port
01:55:10 <Mutabah> Check the PCI bus for the ATA conttroller
01:55:17 <jmp9> yes i did it right now
01:55:18 <jmp9> and it worker
01:55:22 <jmp9> actually port is 0xC080
01:55:24 <jmp9> :-)
01:55:33 <Mutabah> What BAR is that?
01:55:45 <Mutabah> The PCI device iirc has 5 bars
01:56:02 <Mutabah> (one each for the ATA ports, and another for the DMA controller)
02:02:08 <doug16k> jmp9, what prog_if does that device have in the PCI config?
02:02:43 <geist> i wonder if you need to enable the device at PCI for it to work
02:02:55 <geist> probably not, because otherwis eyou wouldnt be able to use it if you didn't have a pci bus driver
02:02:58 <geist> ie, DOS
02:04:41 <jmp9> i have pci
02:05:09 <doug16k> jmp9, real machine?
02:05:24 <jmp9> on real machine pci works fine
02:05:45 <jmp9> I aimed on serial ata
02:05:51 <doug16k> if so, my guess is you have to go into the bios and select whether the sata controller is ide, ahci, or raid
02:05:52 <jmp9> because my laptop uses serial ata
02:06:17 <doug16k> check the prog_if in the pci config. it will tell you what type of ahci conroller it is
02:06:25 <doug16k> er sata controller
02:06:41 <doug16k> 1 == AHCI
02:12:08 <jmp9> pci tells that interrupt line on sata equal 0
02:13:11 <jmp9> should i change it manually?
02:13:22 <doug16k> prog_if is short for programming interface
02:13:47 <doug16k> nothing to do with interrupts
02:14:08 <doug16k> I told you yesterday that that field is informational and changing it has no effect
02:14:43 <jmp9> prog_if = 1
02:14:50 <doug16k> then it is an AHCI controller
02:15:13 <jmp9> it does not support ata pio?
02:15:18 <doug16k> if you want to use the old IDE interface, it is possible to switch that to legacy mode
02:15:28 <jmp9> how to do this
02:15:29 <doug16k> instructions are in the AHCI specification
02:15:49 <doug16k> basically write some bits to somewhere and the AHCI largely disappears an IDE suddenly appears
02:17:10 <doug16k> that's usually what is happening when you set those BIOS settings to IDE/AHCI/RAID... you're putting the RAID controller in either AHCI or IDE mode
02:17:52 <doug16k> RAID usually means its own native interface not necessarily following a widely implemented specification
02:19:28 <doug16k> labelled raid because people aren't surprised when they need a special driver for that and it often has some software raid capability
02:21:33 <jmp9> is it possible to use ahci in ata pio mode?
02:21:39 <geist> no
02:21:42 <doug16k> yes
02:21:48 <geist> oh. wait never mind
02:21:56 <jmp9> FIS_TYPE_PIO_SETUP = 0x5F, // PIO setup FIS - device to host
02:21:58 <geist> i thought pure ahci controllers have no backwards compat?
02:22:24 <geist> i guess if they're in compatibility mode they can support both interfaces?
02:22:57 <doug16k> they arent required to have legacy interface, but they often do, and there is a capability bit for it to see
02:23:01 <jmp9> okay after reading ata pio page i have little understanding of ahci
02:23:55 <doug16k> AHCI_HC_HC 3.1.2 Global HBA control, bit 31 = 0 means IDE mode
02:24:06 <doug16k> in the AHCI spec
02:25:34 <doug16k> need to check "AHCI_HC_CAP 3.1.1 HBA capabilities" bit 18, SAM = 1 means no legacy interface implemented
02:25:49 <jmp9> i didn't get one thing
02:25:50 <jmp9> "After the device receives this FIS and successfully read the 256 words data into its internal buffer, it sends a PIO Setup FIS – Device to Host to tell the host that it’s ready to transfer data and the data size ("
02:26:09 <jmp9> how the fuck it transmits FIS_REG_H2D structure?
02:26:37 <doug16k> none of that applies if you are using legacy mode
02:26:45 <doug16k> are you planning to write an actual AHCI controller?
02:26:56 <doug16k> er driver. lol
02:27:03 <jmp9> OH i hate myself
02:27:14 <jmp9> t PCI base address register (BAR[5], header offset 0x24) points to the AHCI base memory, it’s
02:27:27 <jmp9> i don't want get my previous problem
02:27:32 <jmp9> when i wrote my 16 bit demo
02:27:35 <jmp9> it worked only on emulator
02:27:41 <jmp9> and this is terrible
02:27:48 <doug16k> jmp9, the real thing ->
02:27:56 <jmp9> i fear that my laptop will not support old pio mode
02:28:12 <jmp9> thanks for doc
02:30:09 <geist> that's entirely possible
02:32:08 <rajasrijan> hey
02:32:33 <rajasrijan> anyone have working USB uhci driver?
02:33:16 <doug16k> only xhci
02:33:28 <rajasrijan> hmm
02:34:05 <rajasrijan> I can't seem to be able to assign address to devices :(
02:34:27 <doug16k> ya that part is very different for xhci
02:34:55 <doug16k> xhci is optimized to be virtualizable so it offloads some things like address assignment handshake stuff
02:36:01 <rajasrijan> I can't use xhci protocol with uhci device right?
02:36:21 <doug16k> xhci supports all
02:36:29 <doug16k> from 3.1 all the way down to 1.1
02:36:48 <rajasrijan> huh, thanks :)
02:37:17 <doug16k> it was hard to get the driver working because everything is so dynamic but really it wasn't that hard
02:37:28 <doug16k> the device does a lot for you, the interface is high level
02:38:38 <jmp9> is it bad that i'm copy pasting structures from os dev?
02:39:03 <doug16k> don't trust that they are correct
02:39:20 <doug16k> you should understand as much as possible, not cheat forward, imho
02:39:51 <jmp9> i don't want waste time because of some mismatch in structure
02:39:59 <jmp9> because i'm blindfuck that sometimes type wrong
02:52:37 <jmp9> oh nice
02:52:47 <jmp9> i can't directly map HBA to my kernel .bss section
02:52:50 <jmp9> can*
02:52:55 <jmp9> i can*
02:59:55 <doug16k> what's wrong with the place the firmware put it?
03:00:43 <doug16k> you can't just put it at any arbitrary address, it has to be naturally aligned to a boundary that is a multiple of the size of the thing being placed
03:01:52 <doug16k> placing it on top of system memory is not the best idea
03:03:27 <jmp9> it's physical address
03:03:29 <doug16k> so, let's say the BAR size is 1024 bytes. that means that you must place it at an address that is a 1024 byte boundary
03:04:02 <doug16k> this way, the bottom 10 bits will be the register offset and it doesn't need to do a full arbitrary subtraction
03:04:39 <doug16k> it can just toss out bit 10 up ( in my 1024 example, 2^10=1024)
03:05:08 <doug16k> the size of a BAR will be some power of two
03:05:34 <doug16k> (unless you do some fancy advanced pcie thing on something that supports resizable bar)
03:14:23 <doug16k> the bar only sets the required value of some number of upper bits of the address. it may not implement the full range of physical addresses either. the bits not implemented will be stuck as zero
03:14:58 <doug16k> the size may be inferred by the number of low bits stuck at zero, bit 4 and up
03:15:40 <jmp9> what is "PRDT entry"?
03:15:44 <doug16k> bit 3 to 0 have fields that have other meanings
03:15:59 <doug16k> physical region descriptor
03:16:11 <doug16k> it is a way to tell the hardware the address you would like to use for DMA
03:16:25 <doug16k> address and often some extra other metadata about the transfer
03:16:44 <doug16k> you will see some variation of those on pretty much all devices using DMA
03:17:53 <doug16k> so, if some program reads some file, and you fill some buffer cache page with some cluster from the drive, you'd tell it where in memory to put it when reading using one or more PRDT entries
03:18:47 <doug16k> writes would be giving it what place to read from in memory to write the data to the disk
03:27:52 <doug16k> you could do a huge read of several megabytes and scatter it to different pages (that are a bit fragmented due to paging) and it just works
03:28:51 <doug16k> one operation to read into several different pages, not individually micromanaged, by giving it an array of places and to use and how long to keep using each region (its size)
03:42:29 <jmp9> okay so
03:42:31 <jmp9> in sata port
03:42:48 <jmp9> i get some physical address 0x03FDFB00
03:54:51 <jmp9> it's very nice
03:55:04 <jmp9> that AHCI provides me allocated addresses
03:55:12 <jmp9> and i don't care about memory allocation
04:05:59 <jmp9> okay
04:06:06 <jmp9> how to run "identify" command
04:06:09 <jmp9> in ahci
04:06:24 <jmp9> i get confused with all that DMAs
04:06:54 <Mutabah> You send a command, and expect 256 words back
04:07:09 <jmp9> oh
04:07:17 <jmp9> so it uses DMA
04:07:21 <jmp9> to store data
04:07:22 <jmp9> i get it
04:16:52 <doug16k> jmp9, something like this
04:57:34 <doug16k> glad he asked, spotted a bug near there (always used 48 bit read/write instead of checking use_48bit)
06:11:27 <Jarizh> re: howdy
06:14:38 <klange> Greetings.
06:30:31 <Jarizh> Start Me Up - Windows 95
06:30:40 <Jarizh> it crashed, sold more just by doing it
06:42:40 <nyc> I suppose that's encouragement for those of us who might be having crashes.
07:34:46 <Affliction`> n\
08:22:39 <jjuran> "And the printer's going to say, 'I see you've plugged in a new device, and…' whoa."
08:23:21 <jjuran> "… I guess that's why we're not shipping Windows 98 yet."
08:30:43 <nyc`> I'm not very versed in the
08:43:20 <nyc`> 10 years of not kernel hacking has taken a toll.
09:30:04 <nyc> <<<=== ```The above tools could theoretically be used to compile, build, and bootstrap an entire FreeBSD, Linux, or other similar operating system kernel onto MMIX hardware, were such hardware to exist.```
09:30:56 <mrvn> if you port FreeBSD, Linux, or other similar operating system kernel for MMIX
09:31:01 <nyc`> Color me stunned.
09:31:15 <mrvn> It's saying: Hey, this compiler is a compiler.
09:32:42 <nyc`> I suppose it attests to simulator features as well.
09:34:28 <nyc> I looked that up when I ran into a bunch of MMIX relocations in the bfd docs.
10:23:57 <nyc> Apparently the bfd docs spend a long time going over the strange symbol table structure used by the custom binary format made up by Knuth for MMIX. I had more practical goals in mind for RTFM'ing.
11:54:44 <nyc`> mrvn: I think the architecture lacks virtual memory, interrupts, and privilege modes, so it actually couldn't run most OS's.
12:01:31 <lkurusa> i really should buy a capable FPGA dev kit so I can try some of these "hobbyist" architectures
12:02:11 <nyc`> Hammering out a simulated architecture like MMIX must be mind-numbingly tedious. The action is all in the Verilog.
12:04:36 <nyc`> Ikurusa: I'd probably want to try things with MMU's.
12:12:05 <lkurusa> i wonder if you could port qemu to MMIX, i.e. qemu-system-mmix
12:12:28 <lkurusa> not like i know much about MMIX, just read the wikipedia article
12:13:39 <klys> wouldn't it make more sense to port qemu to dos
12:14:03 <klys> just curious on your thinking
12:16:57 <lkurusa> just fun
12:17:31 <lkurusa> i like learning about cpu architectures, as i said i don't know enough about MMIX, but from the people behind it i judged it to be worth a look
12:18:45 <lkurusa> ah i meant, not port qemu to an mmix-based os, but emulate mmix via qemu
12:20:05 <mrvn> root@grml ~ # dd if=/dev/nvme0n1 of=/dev/null bs=1M count=10240
12:20:07 <mrvn> 10737418240 bytes (11 GB, 10 GiB) copied, 5.30522 s, 2.0 GB/s
12:20:09 <mrvn> Nice.
12:20:42 <lkurusa> Oh
12:27:23 <knebulae> andrewrk released the patch to zig master last night that fixes all the problems I encountered with C interoperability in an os context. If you guys haven't checked it out, zig is great for bare-metal dev. For those of you on more "experiemental" paths. I haven't checked it out yet, because I won't have time until tonight, but it's great news.
12:34:12 <vai> hi
01:01:41 <mrvn> knebulae: what is zig? url?
01:01:55 <lkurusa> mrvn:
01:04:57 <mrvn> that page should have a hello.zig example
01:23:22 <nyc`> It doesn't do the big thing I need from alternative languages, but is certainly viable.
01:24:06 <lkurusa> what's the big thing
01:24:07 <lkurusa> ?
01:24:19 <mrvn> Coroutines are one big thing
01:24:34 <mrvn> I want type inferecne though
01:25:57 <nyc`> Continuation passing or otherwise more control over the stack so interrupt model programming doesn't need trampolining.
01:27:11 <mrvn> nyc`: coroutines should give you Continuation passing easily
01:32:08 <nyc`> Coroutines involve changing the stack, though it takes doing that in a particular way they would not normally be used for to do what I want. The setup and teardown is usually a little heavyweight in comparison, too.
01:39:37 <nyc`> It would all make aio easier.
01:41:07 <lkurusa> Here's a good keyboard
01:41:30 <lkurusa> Err sorry, wrong terminal
01:45:50 <Galaxor> Detecting available memory (x86_64): If I'm reading this right, the "bios int 15, e820" method can only refer to memory below 4GB. How do you detect memory above that? Manual probing, and nobody maps io devices to there so it's ok?
01:47:12 <bcos_> Galaxor: You're not reading it right - the "area address" and "area size" fields are both 64 bit
01:47:24 <Galaxor> bcos_: Ohh ok, thanks!
01:50:31 <mrvn> and the bootloader should tell you about memory
01:52:34 <mrvn> nyc`: setting up a stack is one malloc call. Continuation passing is just the same.
01:53:14 <mrvn> anythig supporting callcc needs to allocate a stack frame.
02:07:32 <lkurusa> Galaxor: if you are using GRUB or a multiboot-compliant loader, you can ask them via a simple flag
02:07:39 <lkurusa> it's a pretty decent memory map from my experience, as well
02:28:00 <mrvn> I hate centos: g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
02:30:54 <klange> old means stable™
02:32:00 <nyc`> Microsoft proved that one wrong.
02:32:03 <mrvn> stale[tm]?
02:32:57 <klange> stale, stable, only one letter difference
02:39:16 <mrvn> /build/brederlo/pkg/ql-soft/ql-mcast/build/centos7/0.15/debuild/src/common/ warning: invalid access to non-static data member 'QluCast::Packet::BlockData::data' of NULL object [-Winvalid-offsetof] iov_[0].iov_len = intptr_t(((Packet::BlockData *)nullptr)->data);
02:39:25 <mrvn> How do I do that correctly in C++11?
02:40:01 <mrvn> data being an struct Foo { ...; uint8_t data[]; }
02:40:11 <nyc`> RHAS2.1 refused to die for a long time. It got very stale.
02:41:26 <mrvn> That code comes from: #define OFFSETOF(T, m) ((intptr_t)&(((T*)0)->m))
02:44:58 <nyc`> Linux uses those sorts of things a lot. I'm generally a bigger fan of information hiding etc.
02:49:36 <nyc`> I would probably always keep structure definitions private and provide accessor functions if I could get away with it.
02:49:36 <xenos1984> mrvn: ?
02:49:37 <mrvn> sure. They used it so much that C/C++ now has offsetof. Except offsetof(Packet::BlockData, data) is implementation defined behaviour and gives a warning in gnu++17
02:50:11 <mrvn> nyc`: that code is in the classes own alloc() static function
02:51:39 <mrvn> And before you suggest it sizeof(Packet::BlockData) adds padding so it's too big.
02:52:48 <nyc`> Find the offset of data[0]?
02:52:52 <mrvn> yep
02:54:50 <nyc`> I think they just gamble on people not using it on components that are arrays often enough to generate many questions.
02:57:10 <mrvn> nyc`: on arrays it is fine, just not variable size arrays
02:57:28 <mrvn> you know, the place where you really need it
02:58:04 <nyc`> That's worth a groan.
02:59:36 <mrvn> So the problem is: How do you allocate the exact memory for struct Foo { size_t len; uint32_t flags; uint8_t data[]; } for a given len?
03:11:03 <nyc`> I guess offsetof(struct Foo, data[0]) + len fails.
03:19:26 <mrvn> nyc`: see above, implementation defined if that works or not
03:20:14 <mrvn> nyc`: see above, implementation defined if that works or not
03:20:51 <nyc`> ouch
03:35:49 <nyc`> (Random status update: I've been RTFM'ing and gdb'ing binutils to work out a solution for mips64-elf.)
04:32:44 <mrvn> Who was the idiot that though ext4lazyinit was a good idea?
04:34:43 <rain1> yo
04:35:08 <zhiayang> i knew it
04:37:10 <andrewrk> mrvn, it actually has coroutines which work in freestanding mode. but I'm about to rewrite how they work
04:39:30 <mrvn> how does it compile? convert to single assignment or continuation passing or something else?
04:41:25 <mrvn> and is the zig compiler written in zig yet?
04:42:59 <andrewrk> mrvn, I want to repeat, I'm about to rewrite how it works, but here's status quo: and self hosting isn't done yet, no
04:44:25 <andrewrk> it's continuation passing
04:44:38 <andrewrk> using LLVM's coroutine support (which I think is problematic and will not be using in the rewrite)
04:45:33 <nyc`> I wouldn't bother self-hosting unless it were an extremely high-level language. I'd write compilers for a language in a higher level language than the source language.
04:46:21 <mrvn> if the language isn't even helpful writing the compiler then why should *I* use it?
04:49:20 <nyc`> andrewrk: Very interesting for continuation passing.
04:49:48 <andrewrk> nyc`, here's the self hosting plan:
04:50:17 <andrewrk> it's actually beneficial for making it easy to cross compile the compiler for any target
04:50:51 <andrewrk> but it won't be a O(n) stepping stone process like it is for rust (no offense rust is a great language etc)
04:51:15 <nyc`> mrvn: Not every language specializes in writing compilers. I'd even expect systems languages to not be that great for compiler writing.
04:52:32 <rain1> if you self host then you suddenly have a bootstrapping problem
04:52:50 <andrewrk> rain1, I've avoided that problem entirely
04:52:55 <mrvn> rain1: that's what the stable version of the compiler is for
04:53:26 <andrewrk> by declaring that the stage1 c++ implementation shall be maintained forever and must always be able to build the self hosted one. so bootstrapping is always O(1)
04:53:33 <rain1> The goal should be that every programming language implementation can be built using a 'lower' one
04:53:49 <rain1> then everything can be bootstrapped from some small core set of seed binaries
04:54:07 <rain1> that's a great way to do it andrewrk
04:54:19 <andrewrk> zig already depends on LLVM which depends on C++ so that's my "lower" one
04:54:43 <rain1> a bit like how rust is self hosted but can be built with mrustc, and golang by gccgo, and a few others take on this strategy
04:57:16 <nyc`> I'd probably go for some nutty AI/research language to write a compiler in in the hopes that the fancy language reduces the amount of work to do to write it and write off self-hosting from day one.
04:57:23 <rain1> oh I get what you mean by O(1) now
04:57:40 <mrvn> th AI langage improves the language itself. :)
04:57:42 <rain1> unfortunately mrustc builds a pretty old rust which needs to build a few 'N' intermediates before the current rust
05:01:19 <andrewrk> I'm not trying to do anything radical with zig. it's the same programming concepts everyone is already familiar with from popular programming languages, except engineered really carefully to make programmers more productive and encourage more optimality & fewer bugs
05:01:36 <zhiayang> how tf is my kernel 2mb in size
05:01:46 <andrewrk> anyway, back to #osdev :)
05:02:10 <mrvn> zhiayang: alignment
05:02:33 <zhiayang> nope
05:02:40 <nyc`> andrewrk: CPS may make things good for asynchronous IO.
05:02:40 <zhiayang> LOAD 0x001000 0xfffffffff8000000 0x0000000000000000 0x0938c8 0x0938c8 R E 0x1000
05:02:56 <zhiayang> and LOAD 0x095000 0xfffffffff8094000 0x0000000000094000 0x0549f8 0x057f90 RW 0x1000
05:03:50 <andrewrk> nyc`, yes and I'm definitely exploring that:
05:04:29 <zhiayang> (ok, i have a crapton of debug info -- code+data alone is a little over 1mb still)
05:05:50 <nyc`> 1MB is a lot of code.
05:05:59 <mrvn> could be data
05:06:10 <zhiayang> it's about 590kb of code, 350 of data
05:06:17 <zhiayang> probably just template bloat, tbh
05:06:43 <nyc`> Ah, C++ will do that.
05:09:11 <nyc`> Statically allocated data might merit using other structures that self-size, e.g. hash tries instead of statically allocated separately chained hash tables.
05:09:26 <bcos_> 590k + 250k = 940k < 2048k
05:10:12 <nyc`> I think they said half of it was debug info.
05:10:19 <bcos_> Hrm - over 1 MiB of debugging info(!)?
05:12:31 <zhiayang> bcos_: [ 7] .debug_info PROGBITS 0000000000000000 0e99f8 0b636a
05:12:40 <zhiayang> and [12] .debug_str PROGBITS 0000000000000000 1d680c 0312e9
05:12:59 <zhiayang> name/type/address/offset/size
05:34:47 <nyc`> I haven't really committed to an Implementation language for TalOS yet. I have a main() in C, but it's just return 0; I could easily switch to C++ or Ada or Zig.
05:34:58 <zhiayang> nyc`: oh, you settled on a name? that's nice
05:35:35 <zhiayang> oops
05:38:06 <nyc`> zhiayang: Not 100% but I'm leaning toward it. I probably need to google to see if anything is already using the name and give myself time to come up with better names if possible.
05:40:37 <nyc`> A bunch of things are already called that. Next idea, whenever something comes to me.
06:01:57 <mrvn> nyc`: c + c++ namespaces, constexpr, mixins and a few spare templates
06:19:14 <nyc`> mrvn: I'm squeamish about relying on contributors not to use forbidden features.
06:22:22 <geist> true, but it may be a bit early to worry about that much
06:22:58 <geist> best way to avoid contributors relying on forbidden stuff is to clearly specify it in a contribution guide and be a tyrant about it
06:29:33 <mrvn> things like RTTI and exceptions need extra support and everything else is fine, isn't it?
06:33:27 <nyc> Maybe my instincts are off about it.
06:35:06 <geist> right, things like tha tyou can simply turn off in te build system (at least for the kernel)
06:35:20 <geist> my experience with zircon though is dont try to limit user space features. they will rebel
06:35:28 <geist> folks will bring whatever runtime, language features, etc they want
06:36:06 <nyc> In reality the decision can be deferred because I'm busy with binutils issues and the only runtime code I'm dealing with is in asm.
06:36:16 <geist> but for kernel stuff you can usually push back and most folks treat kernel programming as voodoo scary place. linux has likely contributed to that
06:36:37 <geist> right, technically you need contributors for any of that to matter, and most hobby oses never get to the contributor phase
06:38:02 <nyc> I also need to write high-level language code for it to matter, too.
06:38:39 <nyc> Setting up a stack and calling main() is a bit short of that.
06:40:54 <geist> right. it's a bit of horse in front of cart, but it's good to think about stuff down the road
06:41:08 <geist> the trick is of course spending the appropriate amount of time on future things
06:42:07 <geist> cart in front of horse actually
06:42:30 <geist> still drinking coffee and booting up. i can type, but what i say may be meaningless
06:59:51 <aalm> .theo
06:59:51 <glenda> Since you don't supply diffs, you are a waste of skin.
07:07:19 <geist> aww that's pretty harsh
07:13:43 <aalm> younger me did send some irrelevant diffs to tech⊙oo, just to see his reaction, and he did deliver:]
07:23:26 <geist> hah
07:23:35 <geist> trolling theo should be a national sport
09:07:50 <mischief> #define __Variant __attribute__((section(".variant")))
09:07:55 <mischief> anyone know what this is supposed to do
09:09:38 <mahackemu>
09:10:32 <mischief> no shit
09:10:40 <mischief> what is the significance of the .variant section
09:10:49 <mischief> it's not referenced elsewhere in this code
09:11:51 <mahackemu> i don't know, paste all of your code and i'll do all the work for you /s
09:29:02 <mrvn> The linker script probably does something special for the variant section
09:36:42 <mischief> no linker script fwict, gren for variant returns nothing except this macro
09:36:57 <mischief> this is userspace code and the macro is being used on static char[]'s
09:37:02 <mischief> *shrug*, mostly just curious
09:37:22 <mischief> s/gren/grep
09:48:07 <geist> yah by tlseif it just puts things in the variant section
09:48:21 <geist> but you usually only do that because there's some linker script trickery to collapse them together or whatnot
09:48:37 <geist> so it entirely depends on the environment that code is supposed to compile in
09:51:20 <mischief> some gross vendor code for CPE routers
09:51:22 <mischief> :-)
11:21:45 <bluezinc> o/
11:22:09 <bluezinc> Maybe I'll get to make some significant progress this weekend on something.
11:33:14 <doug16k> mischief, could simply be a locality optimization to put certain things close together. things output to there would end up contiguous in a .variant output section if not mentioned in the linker script
11:44:29 <doug16k> putting frequently written things together is nice because it maximizes the usefulness of write back caching and avoids dirtying lines that are mostly read only but have one mutable thing, instead of being discarded for replacement they'd be written back
11:45:24 <doug16k> linux has a similar concept, where it puts "read mostly" things together
11:45:53 <bluezinc> doug16k: is there a compiler option to do that, or is it just a standard optimization?
11:46:11 <doug16k> profile guided optimizations can do it afaik
11:46:23 <doug16k> but often it is done manually after doing manual perf analysis
11:47:24 <doug16k> you just tag some really hot things that are never modified as being in an area you never write, and things you write all the time being put in a place with other things that are written all the time
11:49:31 <Ameisen> It is annoyingly difficult to process a lot of conditional tasks in parallel in bash or zsh, while preventing it from spawning potentially thousands of jobs.
11:49:36 <Ameisen> finally managed to do it though
11:50:25 <bluezinc> Ameisen: I've always gone with the "spawn thousands of jobs" approach.
11:50:26 <Ameisen> dislike that zsh and bash handle flock differently, though
11:50:29 <Ameisen> I had that.
11:50:34 <Ameisen> I was getting spurious crashes.
11:50:39 <bluezinc> O.o
11:50:43 <Ameisen> I had to restrict the number of things that were executing at once
11:50:53 <Ameisen> this is running in WSL, so I presume NT didn't like it
11:51:31 <Ameisen> so, using a randomly-generated lock file and flock, I implemented a crude semaphore which I use to prevent more than N jobs from executing at a time
11:52:01 <mischief> doug16k: they are static char[]'s
11:52:03 <mischief> const i think
11:52:16 <mischief> they're just returned from functions for shit like build time and commit >_>
11:52:37 <doug16k> const doesn't sound very "variant". strange
11:55:20 <Ameisen> I do think that C and C++ need an 'immutable' modifier as well
11:55:34 <Ameisen> since const just indicates that the variable itself cannot be changed _by that scope_
11:55:50 <Ameisen> either immutable or 'pure' variables
11:58:20 <doug16k> could be a hacky thing where they can patch strings in the executable, placing them in a special section makes that less insane