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=osdev&y=18&m=1&d=14

Sunday, 14 January 2018

00:00:00 --- log: started osdev/18.01.14
00:00:09 <geist> but clearly by the time you intend to run real multi user systems you need to tighten all that up
00:00:09 <pounce> I have... 2gb on my laptop? O~O
00:00:21 <graphitemaster> pounce, that's not even enough to launch chrome tho :P
00:00:46 <doug16k> 2GB? my machine throws away 2GB just for a laugh at startup
00:01:12 <pounce> it's better than my 400mb of free space <…<
00:01:14 <graphitemaster> I throw away 8 GB as a ram disk
00:01:18 <geist> huh no more changes to the sandsifter repo since initial commit
00:01:32 <pounce> (running off of a repurposed chromebook is really something)
00:01:36 <graphitemaster> geist, because that guy is now making more crazy shit :P
00:02:00 <graphitemaster> make crazy shit behind closed doors, commit crazy shit in one commit, never update again, move on to next crazy shit
00:02:03 <graphitemaster> that's how he works.
00:02:58 <doug16k> https://github.com/xoreaxeaxeax/sandsifter/issues/45
00:03:00 <bslsk05> ​github.com: Requires an outrageous amount of RAM to summarize · Issue #45 · xoreaxeaxeax/sandsifter · GitHub
00:03:30 <graphitemaster> who doesn't have 128GB of ram in their work station?
00:03:56 <doug16k> I would have 64GB if 16GB sticks existed that work in desktop motherboards
00:04:23 <doug16k> if I go to 64GB, I insist on it being ECC. no such thing
00:04:37 <doug16k> they pretend it exists. zero stock
00:04:52 <geist> hmm, that's a good question. wonder if this workstation has ECC
00:05:07 --- quit: Belxjander (Ping timeout: 256 seconds)
00:05:22 <doug16k> I'm prepared to spend over $1k, but I can't find the sticks, I've tried
00:06:09 <pounce> why do you need ECC? don't want people rowhammering?
00:06:23 <geist> yay ECC
00:06:41 <doug16k> ever used a machine with ECC? totally utterly rock solid
00:06:43 <geist> looks like this machine has a bunch of Hynix HMA41GR7AFR4N-TF dimms
00:07:00 <geist> which is an 8GB RDIMM ECC
00:07:58 <doug16k> ram is one of the weak points in modern machines. if you keep doubling the ram, you are doubling the chance of a bit flip too
00:08:22 <doug16k> and extreme density ram is more likely to have leakovers and stuff
00:08:53 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
00:09:32 <pounce> ah makes sense
00:09:47 --- join: neakitten (alice@hypatia/staff/nea) joined #osdev
00:11:06 <pounce> ty again all. I'm off
00:11:28 <graphitemaster> no
00:11:30 <graphitemaster> sorry
00:11:30 <graphitemaster> no
00:11:41 <geist> so now i wonder, 6 months later, if anyone actually found anything interesting with sandsifter
00:11:45 <graphitemaster> I can't do another one of these ECC ram discussions
00:11:56 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:12:07 <graphitemaster> you are single desktop user, you don't need ECC ram, even if you have 128GB ot 1TB of ram.
00:12:31 <graphitemaster> servers need ECC ram because of the workload and because of EMI from all the other fucking servers
00:12:34 <geist> if it's your server though
00:12:39 <doug16k> that's the story we've been fed yeah
00:12:46 <graphitemaster> no
00:12:55 <geist> even if it's your own server, a file server is a bad one. i have gotten some of my files corrupted with ECC. why i always md5sum that shit
00:13:04 <geist> er corrupted without ECC that is
00:13:28 <graphitemaster> a file server is a special case where it's reasonable, yes.
00:13:33 --- quit: caen23 (Ping timeout: 255 seconds)
00:14:04 <geist> my xeon box at home has ECC, and sure enough if you look at the bios logs it gets a bit flipped about once a month or so
00:14:21 <geist> would it have been something real? statistically speaking, probably not
00:14:36 <graphitemaster> also, ECC memory is approaching the transistor requirement where it is a waste of transistors and sram would be better
00:15:01 <geist> uh, not so sure about that one
00:15:10 <geist> but alas, you can't do another ecc discussion, so you're out
00:15:54 <doug16k> ecc only requires 12.5% more memory, and it is one more chip per stick, so overall they would make more profit since they could sell more ram on less units
00:16:58 <doug16k> ecc stick is 72 bits, regular is 64 bits
00:17:43 <graphitemaster> SRAM can be done with four transistors per bit, we already have ECC ram with more than that.
00:17:50 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
00:18:04 <bcos_> graphitemaster: Have you ever been playing a game or using any normal application and seen a "random" crash that you couldn't reproduce?
00:18:10 <graphitemaster> ECC ram is actually a fraud
00:18:21 <geist> he's trollin us again i guess
00:18:24 <graphitemaster> no
00:18:28 <geist> it's late, graphitemaster is getting randy
00:19:16 <graphitemaster> " In 2008 concerns were raised in the book Wafer Level 3-D ICs Process Technology that non-scaling analog elements such as charge pumps and voltage regulators, and additional circuitry "have allowed significant increases in bandwidth but they consume much more die area". Examples include CRC error-detection, on-die termination, burst hardware, programmable pipelines, low impedance, and increasing need for sense amps
00:19:16 <graphitemaster> <LadyHavoc> (attributed to a decline in bits per bitline due to low voltage). The authors noted that, as a result, the amount of die used for the memory array itself has declined over time from 70–78% with SDRAM and DDR1, to 47% for DDR2, to 38% for DDR3 and potentially to less than 30% for DDR4.[49]"
00:19:38 <graphitemaster> quoting someone else since I had this discussion already 555891289736541987234 times
00:19:59 <graphitemaster> approximately 3 per bit in the best case right now
00:20:22 <doug16k> die area is nonsense. they use the same chips, just 8 more bit width per stick
00:20:23 <geist> even if that were true, 3 < 4
00:20:35 <graphitemaster> DDR memory with ECC is literally approaching the cost of SRAM and in some cases it already _has_
00:20:36 <doug16k> so typically 1 more chip
00:20:54 <geist> sram uses substantially more power, iirc
00:21:01 <graphitemaster> basically all the "hacks" needed to make dram not shit makes basically almost turns it into sram which had none of these problemns to begin with
00:21:12 --- quit: daniele_athome (Ping timeout: 265 seconds)
00:21:31 <graphitemaster> It used to be that DRAM caches were faster than SRAM because DRAM was 2D, so the access time is proportional to the square root of the capacity and caches are small, whereas SRAM is very linear But then we got 2D and 3D sram architectures.
00:21:33 <Mutabah> What's the relative power per bit?
00:21:40 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
00:21:47 <Mutabah> And isn't sram stupidly expensive to fab relative to dram?
00:21:54 <graphitemaster> we're working on it
00:21:54 <bcos_> Erm. SRAM has power consumption problems - can't just charge a capacitor and let it sit without consuming extra power
00:21:59 <doug16k> sram is gates sinking power to hold the latch in its state, dram is charge trapped in a capacitor
00:22:48 --- quit: caen23 (Ping timeout: 276 seconds)
00:23:27 <graphitemaster> anyways from what I've read in more recent papers on SRAM, getting secure, non-leaky, non-broken DRAM to work costs significantly more in both die area, transistor and power consumption than some of the more dvanced SRAM fabbing processes we have now. The current estimate is another 6 years before DRAM is completely and utterly irrelevant and ECC and all those hacks are too.
00:24:05 <geist> note what you said is more logical than 'ECC ram is actually a fraud'
00:24:16 <geist> if you'd start with something reasonable then i wouldn't think you're just fucking trolling us
00:24:28 <graphitemaster> considering hyenix already has a functioning fab process producing 128GB SRAM modules for less than DDR4 right now
00:24:29 <jjuran> ECC RAM is a sideshow
00:24:30 <geist> i have no idea if you're making this shit up, but at least it has logic to it
00:24:47 <graphitemaster> it's just a research project tho
00:24:56 <graphitemaster> the bigger problems with SRAM is bus requirements
00:25:10 <graphitemaster> SRAM essentially needs a bus lane per bit which is unreasonable
00:25:17 --- quit: hmmmm (Remote host closed the connection)
00:25:20 <graphitemaster> so all the r&d is in multiplexing it right now
00:25:25 <graphitemaster> and that's the significant set back.
00:26:54 <bcos_> ?
00:27:26 <graphitemaster> geist, I'm just in one of those moods where we've had this discussion to death and it's just the same drivel over and over again about how ECC ram is le savior when in reality it's fixing a problem in DRAM (of which DRAM has many...) that doesn't even exist with SRAM and is approaching SRAM parameters as a result.
00:27:50 <graphitemaster> bcos_, multi channel module configurations.
00:28:25 <bcos_> ?
00:28:37 <bcos_> Still a "problem" that was solved about 40 years ago...
00:28:58 <graphitemaster> not solved in the modern scale state tho
00:29:02 <Mutabah> Wait, what problem does dram solve that sram doesn't have?
00:29:07 <doug16k> ever seen an SRAM bigger than 16MB? I haven't
00:29:08 <Mutabah> *ecc dram
00:29:09 <graphitemaster> in terms of performance, power consumption and latency
00:29:49 <doug16k> you're saying they are going to jump from 16MB to gigs ?
00:29:58 <graphitemaster> they already have :P
00:30:05 <doug16k> can you name one?
00:30:15 <doug16k> actual part I mean
00:30:16 * bcos_ thinks it'd be more worthwhile researching "non-binary DRAM" - slap a value from 0 to 15 into each capacitor and get far more RAM in the same space! :-)
00:30:24 <graphitemaster> hyenix has a paper on their sram process
00:30:46 <graphitemaster> nothing that is released yet, just research stuff.
00:31:06 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
00:31:10 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
00:31:15 <graphitemaster> they can produce sram modules up to 128gb densities with near 100% yield
00:31:21 <geist> some thing someone is researching and 'solved 40 years' are are actually kinda different things you know
00:31:38 <doug16k> $483 for 16MB -> https://ca.mouser.com/productdetail/gsi-technology/gs82582qt20ge-450i?qs=sGAEpiMZZMt9mBA6nIyysJQc0%252bdJyBlRpM5Hwr6H%252bi0%3D
00:31:39 <bslsk05> ​ca.mouser.com <no title>
00:32:30 <bcos_> doug16k: Hrm - current prices are a poor estimate due to volume pricing ("more chips = cheaper chips")
00:32:53 <graphitemaster> sram is expensive because less demand, less chips, less people making them and less people needing them
00:33:03 <graphitemaster> if it had the same demand as dram it would be equivlantly priced
00:33:22 <graphitemaster> especially at the quanities people want
00:33:24 <doug16k> yes that is not really the point. the point is, I've never seen any sram even remotely close to 1GB. what I've seen isn't relevant though, just want to see one actual large sram :)
00:33:30 <bcos_> Well, no. If it had the same demand it'd still be harder to manufacture and more expensive than ECC DRAM
00:33:47 <bcos_> ..it just wouldn't be as expensive as it is now
00:34:02 <graphitemaster> but it's no longr hard to manufacture when we have improved fab processes since the last major fab process
00:34:21 <graphitemaster> especially when ecc dram uses more die area and transistors than sram, or is getting close to
00:34:31 <bcos_> ?
00:34:48 <doug16k> intel can't muster much more than 20MB on a $1000 chip, how do you figure we'll have gigs anytime soon?
00:35:01 <bcos_> ECC RAM is a few bits per row, plus "one off" control logic costs
00:35:13 <doug16k> a modern cpu is basically a giant L3 with processor cores in there somewhere
00:35:16 <graphitemaster> intel can, it's just caches get slow when you make them larger
00:35:24 <graphitemaster> so you need many hiearchies
00:35:58 --- quit: caen23 (Ping timeout: 256 seconds)
00:36:21 --- quit: pounce (Quit: WeeChat 2.0.1)
00:36:58 <bcos_> doug16k: Intel did/does manufacture Xeon Phi with 8 GiB of McDram for < $1000
00:37:11 <doug16k> ah, mc >>DRAM<<
00:37:19 <bcos_> ;-)
00:37:43 <doug16k> graphitemaster, I would be so happy for you to be right. dram sucks
00:38:00 <doug16k> refresh sucks. row to row latency sucks
00:38:47 <bcos_> To make SRAM scale you're going to end up with same/similar "row select" latencies
00:38:48 <graphitemaster> doug16k, 6 years bro I promise you you'll see 1GB and 2GB sram for specialized stuff
00:39:26 --- join: macdonag (~macdonag@cpc110673-lewi19-2-0-cust478.2-4.cable.virginm.net) joined #osdev
00:39:52 <bcos_> In 6 years most people will be using 64 GiB+ DRAM, unless Intel's 3D Xpoint works
00:40:56 <bcos_> Actually, some sort of non-volatile RAM is probably more likely than SRAM being more than "exotic"
00:41:10 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
00:41:56 <graphitemaster> SSD speeds are approaching the speed of DDR as well. I think we discussed this earlier
00:42:12 <graphitemaster> some of the newer NVMe stuff beats DDR2 and comes close to DDR3
00:42:37 <graphitemaster> DDR is approaching it's limits due to latency
00:42:52 <graphitemaster> so you may not be wrong about that non-volatile RAM concept
00:42:56 <bcos_> Consistantly, or just for short bursts because of caches?
00:43:07 <graphitemaster> that I never checked.
00:43:41 <bcos_> I'd expect most of the "very fast NVMe" uses small SRAM buffers/caches, and the actual underlying SSD is nowhere near as fast
00:45:48 --- join: xerpi (~xerpi@33.red-88-23-239.staticip.rima-tde.net) joined #osdev
00:46:12 --- quit: caen23 (Ping timeout: 276 seconds)
00:48:05 --- join: Kazinsal_ (~Kazinsal@unaffiliated/blacklightos) joined #osdev
00:50:52 <doug16k> bcos_, my nvme ssd can sustain 3+ GB/sec read continuously
00:50:58 --- quit: Kazinsal (Ping timeout: 246 seconds)
00:51:16 <bcos_> doug16k: DDR4 is around 20 GB/sec
00:51:38 <doug16k> I was addressing your claim that it's caches making them fast
00:52:14 <doug16k> yes, it's pipelined and has concurrency making it possible, but DRAM does that too
00:52:22 <bcos_> I was addressing graphitemaster's "as fast as DRAM" claim (e.g. suggesting "as fast as DRAM for a short burst")
00:52:48 <doug16k> you have to keep a row open for a certain amount of time, you can't just open a row, read a burst, and close it right away
00:53:05 <graphitemaster> my NVMe ssd can sustain 8 GB/s read
00:53:21 <doug16k> graphitemaster, what is it?
00:53:29 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
00:54:27 <graphitemaster> doug16k, samsung 960 pro
00:54:28 <doug16k> because I call bullshit on that one. 4x PCIe can't do over 4GB/sec
00:54:32 <bcos_> Also note that bandwidth != latency. E.g. if you're bored you can probably achieve 8 GB/s with a massive "RAID 0" array of ancient floppy disks
00:54:40 <doug16k> I have a 1TB 960 pro too
00:55:30 <graphitemaster> doug16k, I'm using samsung magicians "over provisoning" where it uses your RAM as an additional cache :P
00:55:51 <doug16k> k well mine actually reads at about 3.2GB/sec
00:56:06 <geist> that's approaching PCIe 3.0 x4 speed
00:56:10 <doug16k> yes
00:56:13 <geist> which is just shy of 4GB/sec
00:56:40 <geist> what the average SSD does is basically stripe across a lot of dies
00:56:42 <doug16k> bcos_, yes I know linear read is not a good measurement, but a SATA SSD can barely maintain 500MB/sec
00:57:03 <graphitemaster> sata ssd is sad
00:57:10 <geist> individually they may only be say 100MB/sec or so, but a SSD may have 64 or 128 or 256 of the dies at once, which is why they're quite good at writing lots of data when the QD>1
00:57:48 <geist> since they can keep a lot of flash dies open at a time to mitigate the individual speed. basically they toss a fairly large amount of DRAM cache, fairly hefty processing, to stripe across tons of individual chips
00:57:52 <SlashLife> graphitemaster: Huh? Isn't overprovisioning where you reserve part of the SSDs capacity to replace dying cells to prolong its lifetime?
00:57:58 <doug16k> yes, they are very concurrent internally. that's why the NVMe spec has that out-of-order completion queue thing. the order of completion is not likely to be the order of issue due to the interleaving
00:58:03 <geist> by way of comparison, the NVME disks driving Optane are almost completely stupid
00:58:23 --- quit: caen23 (Ping timeout: 256 seconds)
00:58:27 <geist> it has very little dram, relatively dumb controller, because xpoint itself doesn't need to be striped and whatnot
00:58:47 <geist> it's almost conceptually like a relatively slow dram array on the other side of an nvme interface
00:59:40 <geist> sata ssd is fairly sad, but really the throughput is only part of the game. sata ssd is still fairly good at getting read/writes back to you ASAP
01:00:08 <geist> which is in most cases the biggest advantage of SSD over disk. it's a few orders of magnitude faster on seek times no matter what interface you put in front of it
01:00:13 <doug16k> yes, it's like a bunch of raid 0 striped ssd's behind the interface
01:00:46 <doug16k> ram has the exact same thing. with a pathological memory access patter that forces all the accesses onto the same bank, you get stuck waiting for min-row-open time
01:00:59 <geist> doug16k: yeah somewhere i was reading about the industry standard NAND interfaces now, and they're not that complex. something like 100Mhz or 200Mhz at 8 bit wide, but then if you have a chip with say 8 dies, and then you stuff 8 or 16 of those on a drive...
01:01:14 <geist> this is also why larger SSDs perform better. more dies more ability to stripe
01:04:50 --- join: Asu (~sdelang@AMarseille-658-1-29-35.w86-219.abo.wanadoo.fr) joined #osdev
01:09:13 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
01:09:39 <doug16k> in qemu my nvme code seems to be pulling somewhere between 60000 and 230000 IOPS across 8 threads doing random 4KB reads. that measurement is fairly meaningless though, since it is going through the qemu emulation and reading from the host disk cache
01:10:17 <doug16k> but I'm happy with it regardless :)
01:12:30 <doug16k> the per-second number jumps erratically around that huge range
01:13:35 <doug16k> probably because my scheduler is not great - it hardly even tries to keep threads on the same cpu
01:13:57 --- quit: caen23 (Ping timeout: 248 seconds)
01:14:09 --- join: harukomoto (~harukomot@93-41-17-101.ip79.fastwebnet.it) joined #osdev
01:14:11 <doug16k> so they are randomly piling up on the same per-cpu nvme queue and randomly spreading out across them
01:16:19 <doug16k> I've already started doing the code that tracks per-cpu load and per cpu usage so it can balance the threads across the cpus, in preparation for properly doing per cpu scheduling
01:16:37 <doug16k> and per thread cpu usage*
01:21:25 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
01:22:30 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-rrskqocskfiauxrh) joined #osdev
01:24:03 --- quit: neakitten (Quit: "What's the word for when it feels inside your heart that everything in the world is all right?")
01:26:30 --- quit: caen23 (Ping timeout: 276 seconds)
01:33:39 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
01:41:06 --- join: c_ (~c@kana.node.kitteninfra.net.nz) joined #osdev
01:41:16 --- nick: c_ -> r3n
01:46:54 --- join: mmu_man (~revol@vaf26-2-82-244-111-82.fbx.proxad.net) joined #osdev
01:55:51 --- quit: kasumi-owari (Ping timeout: 276 seconds)
01:57:51 --- quit: xerpi (Quit: Leaving)
01:58:02 --- join: kasumi-owari (~kasumi-ow@ftth-213-233-237-007.solcon.nl) joined #osdev
02:08:32 --- join: Kimundi_ (~Kimundi@p57A894B0.dip0.t-ipconnect.de) joined #osdev
02:11:18 --- join: caladrius (~quassel@188.25.93.211) joined #osdev
02:15:06 --- quit: daniele_athome (Quit: ZNC - http://znc.in)
02:16:37 --- join: glauxosdever (~alex@athedsl-112599.home.otenet.gr) joined #osdev
02:29:32 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
02:33:03 --- quit: alyptik (Ping timeout: 255 seconds)
02:34:10 --- join: alyptik (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
02:46:27 --- quit: Halofreak1990 (Ping timeout: 276 seconds)
02:49:14 --- join: eivarv (~eivarv@cm-84.215.4.97.getinternet.no) joined #osdev
02:49:35 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
02:50:50 --- quit: Belxjander (Ping timeout: 256 seconds)
02:56:46 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
03:01:14 --- join: m3nt4L (~asvos@2a02:587:a019:8300:3285:a9ff:fe8f:665d) joined #osdev
03:13:41 --- join: Omistaja__ (~fooman@84-253-221-66.bb.dnainternet.fi) joined #osdev
03:16:42 --- quit: ExtremeFMan (Ping timeout: 255 seconds)
03:24:16 --- quit: Belxjander (Ping timeout: 256 seconds)
03:26:45 --- quit: immibis (Ping timeout: 248 seconds)
03:29:21 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
03:33:29 --- join: fujisan (uid4207@gateway/web/irccloud.com/x-xfccohsrywyaqtei) joined #osdev
03:34:13 <graphitemaster> https://techcrunch.com/2018/01/12/intel-tried-desperately-to-change-the-subject-from-spectre-and-meltdown-at-ces/
03:34:14 <bslsk05> ​techcrunch.com: Intel tried desperately to change the subject from Spectre and Meltdown at CES | TechCrunch
03:34:26 <graphitemaster> looks like Intel loves spinning PR and making the problem worse for themselves
03:38:42 --- join: Arcaelyx (~Arcaelyx@2601:646:c200:27a1:f0b1:b3a7:bd52:33c1) joined #osdev
03:39:02 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
03:40:56 --- quit: CheckDavid (Quit: Connection closed for inactivity)
03:41:16 --- quit: mmu_man (Ping timeout: 256 seconds)
03:42:52 --- quit: king_idiot (Remote host closed the connection)
03:43:05 --- join: curiosity_freak (~naveen@157.50.9.125) joined #osdev
03:44:35 <curiosity_freak> during boot time in unreal mode can we access the addresses below RESET VECTOR ? or we can only access the above 16 bytes ?
03:45:09 <Mutabah> curiosity_freak: From what you've read, what do you expect
03:45:10 <Mutabah> ?
03:46:15 <curiosity_freak> https://manybutfinite.com/post/how-computers-boot-up/
03:46:16 <bslsk05> ​manybutfinite.com: How Computers Boot Up | Many But Finite
03:49:16 <curiosity_freak> in the memory map he mentioned that last 16 bytes are addressable via EIP thanks to the power-up hack
03:50:07 <curiosity_freak> that means we can't address the region of memory below the reset vector ?
03:51:21 <sortie> Morning
03:51:28 <Mutabah> no, it doesn't mean that
03:51:48 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-vvrwgnfknnncgarn) joined #osdev
03:52:33 <curiosity_freak> okay! so the last 2MB (can vary deponds on the size of bios rom ) is mapped to BIOS ROM ?
03:52:43 <Mutabah> Implementation defined
03:52:53 <curiosity_freak> okay
03:53:19 <Mutabah> Seriously, as os developers most of us don't know (and don't need to know)
03:54:03 --- nick: Kazinsal_ -> Kazinsal
03:54:10 <Kazinsal> Yeah this is all seriously irrelevant shit that you shouldn't care about
03:54:13 --- part: Kazinsal left #osdev
03:54:16 --- join: Kazinsal (~Kazinsal@unaffiliated/blacklightos) joined #osdev
03:54:19 <curiosity_freak> okay
03:54:20 <Kazinsal> Oops wrong button
03:54:24 <curiosity_freak> leave it
03:58:44 <Lowl3v3l> curiosity_freak: usually, whatever the question is, "unreal mode" is definitely the wrong answer^^
04:00:08 <curiosity_freak> hmm. do you any idea where the bios rom is mapped ? below 1mb or below 4gb ( 32 bit cpu intel )
04:00:15 --- join: quc (~quc@host-89-230-173-123.dynamic.mm.pl) joined #osdev
04:00:39 <Lowl3v3l> curiosity_freak: thats entirely irrelevant to any halfway decent os design^^
04:01:02 <curiosity_freak> fine!!!
04:01:40 <Mutabah> That said, Afaik it's below 1MB.. with memory controller hackery to present it at just below 4GB for reset
04:02:16 <Mutabah> I've worked with a similar setup on an ARM2 machine - as soon as the memory controller sees a certain type of access, it disables the special reset hck
04:03:44 <curiosity_freak> thaks :-)
04:14:23 <Kazinsal> At actual RESET time chances are the DRAM controllers are in a preconfigured state presenting just some ROM, so the BIOS has to do cache-as-RAM stuff and that's just something you don't want to fuck around with
04:19:15 --- quit: Belxjander (Ping timeout: 255 seconds)
04:20:06 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
04:24:27 --- quit: curiosity_freak (Quit: Leaving)
04:25:28 --- join: ircer2 (~ircer2@185.230.125.164) joined #osdev
04:25:36 --- join: m_t (~m_t@p57B3CF49.dip0.t-ipconnect.de) joined #osdev
04:47:26 --- quit: ircer2 (Read error: Connection reset by peer)
04:49:51 --- quit: Belxjander (Ping timeout: 255 seconds)
04:52:38 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
04:59:07 --- quit: m3nt4L (Remote host closed the connection)
05:02:17 --- join: gareppa (~gareppa@unaffiliated/gareppa) joined #osdev
05:04:12 --- quit: gareppa (Client Quit)
05:06:50 --- quit: caen23 (Ping timeout: 256 seconds)
05:10:19 --- quit: latentprion (Ping timeout: 268 seconds)
05:11:09 --- join: freecoder (Elite21018@gateway/shell/elitebnc/x-ouzbwczjwfgwrqky) joined #osdev
05:23:28 --- quit: m_t (Quit: Leaving)
05:24:09 --- quit: sdfgsdfg (Ping timeout: 256 seconds)
05:39:55 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
05:40:37 --- join: dennis95 (~dennis@p50915CF9.dip0.t-ipconnect.de) joined #osdev
05:46:35 --- join: John____ (~John__@79.97.140.214) joined #osdev
05:53:31 <alphawarrior> Why does the TSS have 3 esps?
05:53:58 <Mutabah> One for each ring other than 3
05:54:26 <Mutabah> Unless you're doing rathe strange things, the only one you'll use is TSS0
05:54:31 <alphawarrior> oh I see thanks
05:56:36 <alphawarrior> If you were to use VT-x would that need a proper os inside of it or would it run if you just gave an app?
05:56:57 <Mutabah> You could gie it an "app"
05:57:21 <Mutabah> but VM exits are kinda expensive compared to syscalls
05:59:15 --- nick: Omistaja__ -> FMan
06:00:57 --- quit: CheckDavid (Quit: Connection closed for inactivity)
06:01:47 <alphawarrior> oh I see well it sounded like a good idea to put all app into it's own container for a moment
06:04:33 --- join: navidr (uid112413@gateway/web/irccloud.com/x-qrmtpzahoyxtexjs) joined #osdev
06:06:59 <glauxosdever> http://forum.osdev.org/viewtopic.php?f=2&t=32600&p=281859#p281859 <- Anything to add here?
06:07:00 <bslsk05> ​forum.osdev.org: OSDev.org • View topic - Public Domain C/C++ Compiler
06:13:32 --- quit: sprocklem (Ping timeout: 260 seconds)
06:14:26 --- quit: John____ (Read error: Connection reset by peer)
06:19:34 --- quit: Belxjander (Ping timeout: 248 seconds)
06:20:12 --- join: JusticeEX (~justiceex@pool-108-30-196-198.nycmny.fios.verizon.net) joined #osdev
06:25:00 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
06:30:00 --- quit: quc (Remote host closed the connection)
06:30:15 --- join: quc (~quc@host-89-230-173-123.dynamic.mm.pl) joined #osdev
06:32:07 --- quit: fujisan (Quit: Connection closed for inactivity)
06:32:45 --- join: oaken-source (~oaken-sou@p3E9D2477.dip0.t-ipconnect.de) joined #osdev
06:37:05 --- join: latentprion (~latentpri@vampire.ertos.nicta.com.au) joined #osdev
06:41:54 --- quit: Kimundi_ (Ping timeout: 255 seconds)
06:44:21 --- join: gkbrk (~gkbrk@31.205.132.207) joined #osdev
06:44:37 --- quit: Tobba (Remote host closed the connection)
06:44:55 --- join: Tobba (~Tobba@h-25-170.A159.priv.bahnhof.se) joined #osdev
06:47:18 --- join: Kimundi_ (~Kimundi@p57A894B0.dip0.t-ipconnect.de) joined #osdev
06:53:34 --- join: retpolin_ (~retpoline@90.95.19.47) joined #osdev
06:55:57 --- quit: retpoline (Ping timeout: 256 seconds)
06:56:08 --- nick: retpolin_ -> retpoline
06:58:06 --- quit: Kimundi_ (Ping timeout: 255 seconds)
07:00:30 --- join: svk (~svk@p2003006A651087009DE913D9684E1941.dip0.t-ipconnect.de) joined #osdev
07:05:14 --- join: SwiftMatt (~Objective@2601:282:4300:3e:a9c1:feed:c3bd:176e) joined #osdev
07:12:28 --- join: Pessimist (~Pessimist@unaffiliated/pessimist) joined #osdev
07:12:49 --- nick: Asu -> Asu`afk
07:19:51 --- quit: plonk (Read error: Connection reset by peer)
07:19:58 --- join: plonk (~plonk@rosa.physik-pool.tu-berlin.de) joined #osdev
07:19:58 --- quit: plonk (Changing host)
07:19:58 --- join: plonk (~plonk@unaffiliated/plonk) joined #osdev
07:20:53 --- quit: shikhin (Ping timeout: 248 seconds)
07:20:54 --- quit: blueglass (Ping timeout: 248 seconds)
07:21:08 --- quit: lucebac (Remote host closed the connection)
07:21:26 --- quit: renopt (Ping timeout: 248 seconds)
07:21:41 --- join: renopt (~renopt@172.110.30.143) joined #osdev
07:21:44 --- join: blueglass (~a@104.236.67.153) joined #osdev
07:22:29 --- join: shikhin (shikhin@buttsex.space) joined #osdev
07:25:53 --- quit: gkbrk (Quit: Leaving)
07:33:03 --- quit: Retr0id (Quit: Leaving)
07:34:33 --- quit: latentprion (Ping timeout: 255 seconds)
07:38:54 --- join: hmmmm (~sdfgsf@pool-72-79-165-92.sctnpa.east.verizon.net) joined #osdev
07:47:44 --- quit: ahrs (Remote host closed the connection)
07:49:02 --- join: ahrs (quassel@gateway/vpn/privateinternetaccess/ahrs) joined #osdev
07:51:13 <doug16k> alphawarrior, running a user process is its own container already. it can't access the memory of anything that is mapped in and it can't access kernel memory
07:51:15 * doug16k waves at intel engineer
07:52:35 --- join: user10032 (~Thirteen@2.124.229.123) joined #osdev
07:52:51 <doug16k> that isn't mapped in*
07:54:56 --- join: sinetek (~sinetek@172.110.128.68) joined #osdev
07:59:18 --- quit: Pessimist (Ping timeout: 255 seconds)
08:05:23 --- join: nzoueidi (~nzoueidi@ubuntu/member/na3il) joined #osdev
08:05:31 --- join: bm371613 (~bartek@2a02:a317:603f:9800:391:ed9f:1c09:1285) joined #osdev
08:07:06 --- join: John____ (~John__@79.97.140.214) joined #osdev
08:11:53 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
08:13:34 --- join: latentprion (~latentpri@vampire.ertos.nicta.com.au) joined #osdev
08:20:27 --- join: regreg (~regreg@85.121.54.224) joined #osdev
08:25:47 --- quit: Asu`afk (Quit: Konversation terminated!)
08:29:26 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
08:31:38 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
08:32:17 --- quit: daniele_athome (Ping timeout: 256 seconds)
08:32:39 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
08:38:42 --- join: alphawarrior_ (~alphawarr@netacc-gpn-104-54-44.pool.telenor.hu) joined #osdev
08:39:35 --- quit: alphawarrior_ (Client Quit)
08:40:03 --- quit: Halofreak1990 (Ping timeout: 276 seconds)
08:40:55 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
08:58:37 --- join: pounce (~pounce@c-24-11-27-195.hsd1.ut.comcast.net) joined #osdev
09:03:41 --- quit: Shamar (Quit: Lost terminal)
09:06:25 <alphawarrior> what is __cxa_guard_acquire and __cxa_guard_release?
09:10:18 --- join: m3nt4L (~asvos@2a02:587:a019:8300:3285:a9ff:fe8f:665d) joined #osdev
09:17:09 <Lowl3v3l> alphawarrior: stuff concerning local static variables in c++
09:18:00 <Lowl3v3l> https://manishearth.github.io/blog/2015/06/26/adventures-in-systems-programming-c-plus-plus-local-statics/
09:18:01 <bslsk05> ​manishearth.github.io: Adventures in Systems Programming: C++ Local Statics - In Pursuit of Laziness
09:18:06 <pounce> Should I be using cfi directives in my assembly, and if so are they availible in nasm?
09:18:22 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
09:18:26 --- join: gareppa (~gareppa@unaffiliated/gareppa) joined #osdev
09:19:05 --- quit: gareppa (Remote host closed the connection)
09:19:56 --- join: boinc (~boinc@2001:41d0:8:7534::1) joined #osdev
09:20:00 <boinc> Hi
09:20:03 --- join: dhoelzer (~dhoelzer@ool-4a5940e5.dyn.optonline.net) joined #osdev
09:21:39 --- quit: alyptik (Ping timeout: 276 seconds)
09:23:16 --- join: mmu_man (~revol@vaf26-2-82-244-111-82.fbx.proxad.net) joined #osdev
09:23:21 <boinc> Can someone tells me, what's steps I've to follow to read/write few bytes on usb stick ? :)
09:24:30 --- join: alyptik (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
09:26:31 --- join: gareppa (~gareppa@unaffiliated/gareppa) joined #osdev
09:28:45 <alphawarrior> Well as far as I know you need something similar as to read from a normal hdd but you gotta embed the command to USB packets
09:28:48 --- quit: quc (Read error: No route to host)
09:28:54 <Lowl3v3l> boinc: write a usb driver and read the bytes. You might additionally need a filesystem driver though
09:40:15 --- join: quc (~quc@host-89-230-173-123.dynamic.mm.pl) joined #osdev
09:42:01 <alphawarrior> ok well I have researched bitfields and they are really evil and damn so many osdev projects have them
09:45:55 <variable> alphawarrior: ++
09:46:15 <variable> they are designed to solve a problem, but end up causing more problems
09:46:21 <variable> this is annoyingly common in C :-)
09:47:34 --- quit: _sfiguser (Read error: Connection reset by peer)
09:53:12 --- quit: navidr (Quit: Connection closed for inactivity)
09:56:05 --- quit: Halofreak1990 (Ping timeout: 248 seconds)
09:56:46 --- join: Asu (~sdelang@AMarseille-658-1-29-35.w86-219.abo.wanadoo.fr) joined #osdev
09:57:47 <alphawarrior> if I take an int* from a va_list it'll be the same as if I did (int*)va_arg(va, void*) right?
10:00:53 <sortie> alphawarrior: Technically, no
10:01:03 <sortie> alphawarrior: Pointer types are not required to have the same representation
10:02:04 --- quit: nzoueidi (Ping timeout: 256 seconds)
10:20:30 --- quit: gareppa (Quit: Leaving)
10:21:04 <darklink> oh
10:21:26 <darklink> is it bad that i use bitfields in my VMM code?
10:22:43 <variable> darklink: its less that its "bad" and more that most people don't understand the limitations
10:22:44 <variable> if you're okay with (a) padding (b) endianness problems
10:22:47 <variable> then it isn't a concern
10:23:58 <doug16k> you probably aren't saving much, it may be worse. you may be shrinking the data a bit and greatly expanding the number of instructions used to read/write them
10:26:08 <doug16k> data packing techniques are counterproductive when you don't have a huge array of the thing(s) being packed
10:26:10 --- quit: bm371613 (Quit: Konversation terminated!)
10:27:32 <doug16k> individual one bit flag type things aren't bad, but packing multi-bit things causes much more code to generate
10:34:47 --- join: SwiftMatt (~Objective@2601:282:4300:3e:cda5:d46b:fb77:d75) joined #osdev
10:35:40 <darklink> the padding isn't really a problem when you use latest gcc and __attribute__((packed)) everywhere
10:36:10 <darklink> but yeah i would assume that the code is slow af
10:36:28 <darklink> especially when i'm initializing everything but 3 bits
10:38:29 --- join: dbittman (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
10:43:26 --- quit: awang (Ping timeout: 256 seconds)
10:44:32 --- join: Kimundi_ (~Kimundi@p57A894B0.dip0.t-ipconnect.de) joined #osdev
10:45:30 --- join: dennis95_ (~dennis@p50915BD6.dip0.t-ipconnect.de) joined #osdev
10:46:50 --- quit: dennis95 (Ping timeout: 256 seconds)
10:46:58 --- quit: variable (Quit: Found 1 in /dev/zero)
10:47:02 --- nick: dennis95_ -> dennis95
10:50:09 <doug16k> alphawarrior, if you know it is an int pointer, why lie to va_arg?
10:51:07 --- quit: m3nt4L (Remote host closed the connection)
10:53:39 <doug16k> pounce, cfi directives are useful for improving debugging (by enabling stack traces and debugging to work better), and for exception unwinding.
10:54:57 <doug16k> unless you have stack unwinding, cfi directives have no effect on the program behaviour
10:55:18 --- join: NotSecwitter (~NonSecwit@unaffiliated/nonsecwitter) joined #osdev
10:56:11 <doug16k> I have cfi directives in my kernel so stack traces work right through interrupt frames, and so I can go up the call frames and properly see variable values in callers
10:57:00 <doug16k> for example, in an unhandled page fault, I can go up and look at the variables of the code that faulted
10:58:08 --- quit: boinc (Quit: WeeChat 1.6)
10:58:45 --- quit: NonSecwitter (Ping timeout: 268 seconds)
11:00:57 --- join: nzoueidi (~nzoueidi@ubuntu/member/na3il) joined #osdev
11:03:50 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
11:13:25 --- join: Barrett (~barrett@unaffiliated/barrett) joined #osdev
11:15:10 <pounce> what's a tlb shootdown?
11:16:53 --- quit: behalebabo (Ping timeout: 240 seconds)
11:20:10 --- join: Pessimist (~Pessimist@78-61-54-57.static.zebra.lt) joined #osdev
11:20:10 --- quit: Pessimist (Changing host)
11:20:10 --- join: Pessimist (~Pessimist@unaffiliated/pessimist) joined #osdev
11:20:31 <darklink> it's to synchronize memory mappings between CPUs
11:21:24 <darklink> because each CPU and each core/thread has their own TLB, if you change an entry and invlpg on one cpu/core/thread the other CPUs don't know about this and might still use the old one
11:21:49 <darklink> depending on whether it is a global mapping/shared memory and whether or not the changed pages are in the TLB
11:22:09 <darklink> basically it's a remote invlpg
11:22:20 --- join: behalebabo (~behalebab@unaffiliated/behalebabo) joined #osdev
11:22:28 <pounce> doug16k: in the layout that you were explaining to me, when is the kernel stack changed in the IDT, during `isr_context_t *thread_schedule(isr_context_t *ctx)` ?
11:23:05 <pounce> ok, thank you darklink :)
11:24:49 --- join: lucebac (~lucebac@lucebac.net) joined #osdev
11:24:49 --- quit: lucebac (Changing host)
11:24:49 --- join: lucebac (~lucebac@unaffiliated/lucebac) joined #osdev
11:26:02 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
11:26:12 --- quit: oaken-source (Quit: leaving)
11:29:51 <pounce> I mean the interrupt stack table*
11:31:09 --- join: m_t (~m_t@p57B3CF49.dip0.t-ipconnect.de) joined #osdev
11:36:27 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:38:36 --- quit: clever (Ping timeout: 255 seconds)
11:38:51 --- join: clever (~clever@108.175.83.38) joined #osdev
11:38:51 --- quit: clever (Changing host)
11:38:51 --- join: clever (~clever@unaffiliated/clever) joined #osdev
11:39:31 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
11:50:51 --- quit: babyflakes (Quit: Connection closed for inactivity)
11:55:56 --- join: Darmor (~Tom@198-91-187-5.cpe.distributel.net) joined #osdev
11:57:06 --- quit: sinetek (Ping timeout: 256 seconds)
12:01:37 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
12:07:23 --- quit: Asu (Remote host closed the connection)
12:08:09 --- join: sinetek (~sinetek@172.110.128.134) joined #osdev
12:11:46 --- join: sinetek_ (~sinetek@172.110.128.67) joined #osdev
12:12:19 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
12:14:13 --- quit: sinetek (Ping timeout: 256 seconds)
12:15:56 --- join: regreg_ (~regreg@85.121.54.224) joined #osdev
12:19:12 --- quit: regreg (Ping timeout: 256 seconds)
12:21:47 --- quit: nzoueidi (Ping timeout: 256 seconds)
12:26:46 <alphawarrior> is there a isdigit function in freestanding mode or do I have to write that too?
12:27:46 --- join: immibis (~chatzilla@122-59-200-50.jetstream.xtra.co.nz) joined #osdev
12:36:06 <variable> alphawarrior: IIRC no
12:36:16 <variable> since ctype.h is not in the freestanding headers list
12:37:01 --- join: Asu (~sdelang@AMarseille-658-1-29-35.w86-219.abo.wanadoo.fr) joined #osdev
12:37:13 <variable> also TIL about iso646.h
12:43:22 <geist> is that the one that defines AND and whatnot?
12:43:44 --- join: sinetek__ (~sinetek@64.64.117.80) joined #osdev
12:44:43 <variable> geist: yes
12:44:53 <variable> I am highly inclined to write some code that uses this
12:44:59 <geist> hah
12:45:57 --- quit: sinetek_ (Ping timeout: 255 seconds)
12:46:01 --- join: sinetek (~sinetek@modemcable018.210-57-74.mc.videotron.ca) joined #osdev
12:46:06 <geist> i have never encountered any code in the wild that uses these
12:46:43 --- quit: JusticeEX (Ping timeout: 256 seconds)
12:46:52 --- join: SwiftMatt (~Objective@2601:282:4300:3e:cda5:d46b:fb77:d75) joined #osdev
12:48:12 --- quit: sinetek__ (Ping timeout: 255 seconds)
12:55:01 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
12:55:28 <Lowl3v3l> alphawarrior: nope, ctypes is not in freestanding c
12:57:25 * variable gives Lowl3v3l 100 experience points
12:57:31 <variable> are you highlevel yet?
12:57:41 <Lowl3v3l> variable: sorry, didn't see you wrote the same thing xD
12:57:50 <Lowl3v3l> nope, still a newbie :P
12:57:59 <variable> Lowl3v3l: no sorry needed. I just make nick based jokes all the time
12:58:04 <variable> people need to pick good ones
12:58:23 <Lowl3v3l> well i like mine. it was given to me and somehow stuck :D
12:58:47 <variable> heh.
12:59:00 <variable> time to play games!
12:59:31 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
12:59:42 <Lowl3v3l> actually, i should really go to sleep since i have to work again tomorrow xD
12:59:48 <Lowl3v3l> for the first time this year but still
13:10:00 --- quit: quc (Remote host closed the connection)
13:10:16 --- join: quc (~quc@host-89-230-173-123.dynamic.mm.pl) joined #osdev
13:12:58 --- join: JusticeEX (~justiceex@pool-108-30-196-198.nycmny.fios.verizon.net) joined #osdev
13:15:50 --- join: xerpi (~xerpi@33.red-88-23-239.staticip.rima-tde.net) joined #osdev
13:16:46 --- join: sinetek_ (~sinetek@modemcable018.210-57-74.mc.videotron.ca) joined #osdev
13:18:42 --- quit: sinetek (Ping timeout: 256 seconds)
13:18:56 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:19:01 --- join: sortaddsort (~archer@unaffiliated/remcwo9o) joined #osdev
13:20:36 --- quit: adminseodwn (Ping timeout: 255 seconds)
13:22:09 --- quit: alyptik (Ping timeout: 276 seconds)
13:23:49 --- join: alyptik (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
13:24:39 --- quit: sortaddsort (Ping timeout: 255 seconds)
13:25:37 --- join: adminseodwn (~archer@unaffiliated/remcwo9o) joined #osdev
13:37:27 --- join: SwiftMatt (~Objective@2601:282:4300:3e:cda5:d46b:fb77:d75) joined #osdev
13:37:36 --- join: Asu` (~sdelang@92.184.96.72) joined #osdev
13:37:45 --- quit: Asu (Ping timeout: 276 seconds)
13:40:36 --- quit: m_t (Quit: Leaving)
13:41:07 --- quit: vdamewood (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
13:46:23 --- join: king_idiot (~ahaslett@124.157.115.222) joined #osdev
13:49:02 --- join: regreg__ (~regreg@85.121.54.224) joined #osdev
13:50:33 --- join: sdfgsdfg (~sdfgsdfg@unaffiliated/sdfgsdfg) joined #osdev
13:52:14 --- quit: regreg_ (Ping timeout: 265 seconds)
13:52:41 --- join: freakazoid0223_ (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
13:53:25 --- quit: freakazoid0223 (Ping timeout: 248 seconds)
13:56:15 --- quit: Asu` (Quit: Konversation terminated!)
13:56:36 --- quit: daniele_athome (Ping timeout: 255 seconds)
13:57:09 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
13:58:35 --- nick: alyptik -> because
14:05:58 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
14:08:50 --- quit: sinetek_ (Quit: This computer has gone to sleep)
14:10:35 --- quit: Darmor (Ping timeout: 256 seconds)
14:11:10 --- join: Darmor (~Tom@198-91-187-5.cpe.distributel.net) joined #osdev
14:11:58 --- quit: harukomoto (Ping timeout: 256 seconds)
14:12:16 --- quit: king_idiot (Quit: leaving)
14:14:19 --- join: hppavilion[1] (~dosgmowdo@10-36-178-69.gci.net) joined #osdev
14:14:52 --- quit: glauxosdever (Quit: leaving)
14:15:27 --- quit: Belxjander (Ping timeout: 276 seconds)
14:15:49 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
14:16:10 --- quit: John____ (Read error: Connection reset by peer)
14:17:34 --- nick: because -> people
14:18:36 --- quit: renopt (Changing host)
14:18:37 --- join: renopt (~renopt@unaffiliated/renopt) joined #osdev
14:18:42 --- join: king_idiot (~ahaslett@124.157.115.222) joined #osdev
14:21:57 --- quit: Tazmain (Ping timeout: 276 seconds)
14:22:26 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
14:24:45 --- quit: freakazoid0223_ (Ping timeout: 256 seconds)
14:25:00 --- quit: Belxjander (Ping timeout: 256 seconds)
14:27:59 --- join: freakazoid0223_ (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
14:29:32 --- quit: freakazoid0223 (Ping timeout: 256 seconds)
14:31:43 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
14:33:03 --- quit: daniele_athome (Ping timeout: 255 seconds)
14:33:39 --- join: daniele_athome (~daniele_a@93-40-14-81.ip36.fastwebnet.it) joined #osdev
14:34:39 --- join: Atemu (~atemu@64.137.153.137) joined #osdev
14:35:11 --- quit: variable (Quit: /dev/null is full)
14:39:28 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-nisrvzoqklfjtxvo) joined #osdev
14:41:27 --- quit: jp (Quit: https://ptpb.pw/~docrivers.gif)
14:41:44 --- join: jp (ayy@youlosethega.me) joined #osdev
14:41:58 --- quit: jp (Remote host closed the connection)
14:42:16 --- join: jp (ayy@youlosethega.me) joined #osdev
14:44:02 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
14:47:08 --- quit: Shamar (Quit: Lost terminal)
14:47:20 --- join: tacco\unfoog (~tacco@dslb-088-064-173-052.088.064.pools.vodafone-ip.de) joined #osdev
14:49:10 --- quit: xenos1984 (Quit: Leaving.)
14:56:20 --- quit: macdonag (Quit: macdonag)
15:04:40 --- quit: caladrius (Ping timeout: 256 seconds)
15:09:29 --- join: Retr0id (~Retr0id@unaffiliated/retr0id) joined #osdev
15:09:55 --- quit: dennis95 (Quit: Leaving)
15:16:38 --- quit: Atemu (Quit: Textual IRC Client: www.textualapp.com)
15:17:08 --- quit: eivarv (Quit: Sleep)
15:20:46 --- join: hppavilion[0] (~dosgmowdo@10-36-178-69.gci.net) joined #osdev
15:24:48 --- quit: hppavilion[1] (Ping timeout: 255 seconds)
15:26:18 --- quit: adminseodwn (Ping timeout: 276 seconds)
15:28:12 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
15:29:33 --- quit: hppavilion[0] (Ping timeout: 276 seconds)
15:30:10 --- quit: freakazoid0223_ (Ping timeout: 256 seconds)
15:30:49 --- join: hppavilion[1] (~dosgmowdo@10-36-178-69.gci.net) joined #osdev
15:31:10 --- quit: sortie (Quit: Leaving)
15:31:34 --- quit: user10032 (Quit: Leaving)
15:32:00 --- join: adminseodwn (~archer@unaffiliated/remcwo9o) joined #osdev
15:32:35 --- join: hppavilion[0] (~dosgmowdo@10-36-178-69.gci.net) joined #osdev
15:36:27 --- quit: hppavilion[1] (Ping timeout: 260 seconds)
15:39:29 --- join: hppavilion[1] (~dosgmowdo@10-36-178-69.gci.net) joined #osdev
15:42:52 --- quit: hppavilion[0] (Ping timeout: 260 seconds)
15:43:45 --- join: hppavilion[0] (~dosgmowdo@10-36-178-69.gci.net) joined #osdev
15:45:27 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
15:45:48 --- quit: hppavilion[1] (Ping timeout: 276 seconds)
15:47:26 --- join: freakazoid0223_ (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
15:49:17 --- quit: freakazoid0223 (Ping timeout: 260 seconds)
16:01:28 --- quit: atk (Quit: Well this is unexpected.)
16:01:40 --- join: atk (~Arch-TK@ircpuzzles/staff/Arch-TK) joined #osdev
16:02:36 --- quit: xerpi (Quit: Leaving)
16:02:49 --- join: Pseudonym73 (~Pseudonym@128.250.0.57) joined #osdev
16:04:30 --- quit: hppavilion[0] (Read error: Connection reset by peer)
16:05:40 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
16:10:18 --- quit: variable (Quit: /dev/null is full)
16:16:31 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
16:22:08 --- join: SwiftMatt (~Objective@2601:282:4300:3e:cda5:d46b:fb77:d75) joined #osdev
16:26:50 --- quit: magnificrab (Ping timeout: 256 seconds)
16:29:23 --- quit: Barrett (Quit: exit)
16:30:44 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
16:33:56 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
16:35:42 --- join: sinetek (~sinetek@modemcable018.210-57-74.mc.videotron.ca) joined #osdev
16:37:38 --- quit: john51 (Remote host closed the connection)
16:37:55 --- join: john51 (~john@15255.s.t4vps.eu) joined #osdev
16:38:27 --- quit: caen23 (Ping timeout: 276 seconds)
16:39:03 --- quit: Belxjander (Ping timeout: 256 seconds)
16:45:48 --- join: wcstok (~Me@c-71-197-192-147.hsd1.wa.comcast.net) joined #osdev
16:45:49 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
16:50:28 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
16:54:37 --- quit: tacco\unfoog ()
17:01:03 --- join: sbahra (~circuser-@pool-100-2-212-39.nycmny.fios.verizon.net) joined #osdev
17:05:27 --- join: SwiftMatt (~Objective@2601:282:4300:3e:2d7d:e0f3:f4f8:4e56) joined #osdev
17:06:00 --- join: Kimundi__ (~Kimundi@p57A89BB9.dip0.t-ipconnect.de) joined #osdev
17:07:56 --- quit: SwiftMatt (Client Quit)
17:09:54 --- quit: FreeFull (Ping timeout: 256 seconds)
17:10:18 --- quit: Kimundi_ (Ping timeout: 276 seconds)
17:11:03 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
17:11:42 --- join: FreeFull (~freefull@defocus/sausage-lover) joined #osdev
17:14:31 --- quit: magnificrab (Remote host closed the connection)
17:14:45 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
17:22:51 --- quit: svk (Read error: Connection reset by peer)
17:30:13 --- quit: adam4813 (Quit: Connection closed for inactivity)
17:31:01 --- quit: Kimundi__ (Ping timeout: 248 seconds)
17:31:45 --- quit: Belxjander (Ping timeout: 256 seconds)
17:38:20 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
17:39:02 --- quit: mmu_man (Ping timeout: 248 seconds)
17:51:30 --- quit: regreg__ (Ping timeout: 255 seconds)
17:54:40 --- quit: sprocklem (Ping timeout: 256 seconds)
17:56:00 --- quit: sinetek (Quit: This computer has gone to sleep)
17:56:52 --- join: sprocklem (~sprocklem@unaffiliated/sprocklem) joined #osdev
18:07:13 --- quit: dhoelzer (Remote host closed the connection)
18:15:23 --- quit: kasumi-owari (Ping timeout: 256 seconds)
18:17:54 --- quit: rain1 (Ping timeout: 276 seconds)
18:19:12 --- join: rain1 (~user@unaffiliated/rain1) joined #osdev
18:19:15 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
18:22:46 --- join: kasumi-owari (~kasumi-ow@ftth-213-233-237-007.solcon.nl) joined #osdev
18:27:49 --- quit: Belxjander (Ping timeout: 240 seconds)
18:33:27 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
18:36:18 --- quit: Pseudonym73 (Quit: Leaving...)
18:42:43 --- quit: JusticeEX (Ping timeout: 264 seconds)
18:45:31 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:49:53 --- quit: ahrs (Read error: Connection reset by peer)
18:51:26 --- join: multi_io (~olaf@x4db37e9f.dyn.telefonica.de) joined #osdev
18:52:16 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-vnmexefkqlpoitbq) joined #osdev
18:53:02 --- join: ahrs (quassel@gateway/vpn/privateinternetaccess/ahrs) joined #osdev
18:54:19 --- quit: multi_io_ (Ping timeout: 240 seconds)
18:56:15 --- quit: chao-tic (Ping timeout: 276 seconds)
19:11:33 <Ameisen> How do you prevent gcc/ld from discarding a symbol with gc-sections that's defined in an assembly file
19:13:10 <Ameisen> It seems to be discarding basically everything that the S file is
19:14:36 --- join: uvgroovy (~uvgroovy@c-65-96-163-219.hsd1.ma.comcast.net) joined #osdev
19:16:25 <Ameisen> figured it out
19:16:29 <Ameisen> added KEEP into the linker scripts
19:17:03 --- quit: uvgroovy_ (Ping timeout: 276 seconds)
19:18:39 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
19:21:30 --- quit: epony (Quit: QUIT)
19:23:32 --- join: JusticeEX (~justiceex@pool-108-30-196-198.nycmny.fios.verizon.net) joined #osdev
19:28:12 <promach_> does Direct-Memory-Access need Snoop-Control-Unit ?
19:31:06 --- quit: vdamewood (Quit: Textual IRC Client: www.textualapp.com)
19:32:39 --- join: epony (~nym@77-85-133-5.ip.btc-net.bg) joined #osdev
19:33:51 --- quit: epony (Max SendQ exceeded)
19:34:27 --- join: epony (~nym@77-85-133-5.ip.btc-net.bg) joined #osdev
19:44:35 --- quit: JusticeEX (Ping timeout: 265 seconds)
19:44:49 --- join: adu (~ajr@pool-173-66-242-131.washdc.fios.verizon.net) joined #osdev
19:48:00 --- join: SwiftMatt (~Objective@2601:282:4300:3e:2d7d:e0f3:f4f8:4e56) joined #osdev
19:51:20 <Mutabah> Ameisen: well, gc-sections should discard anything that's actually used.
19:57:00 <Ameisen> this is initialization code called by the CPU
19:57:03 <Ameisen> there's no way for the linker to know it's used.
19:57:29 <Mutabah> Your entrypoint? Should be the file's entrypoint
19:57:49 <Mutabah> other things should be referred to by either code or globals?
19:58:06 <Mutabah> That said, KEEP is useful for some things
20:00:23 <geist> yah. put it in a section and then mark it KEEP
20:00:40 <geist> that way you can put all your entry points and exception vectors there
20:01:45 <geist> plus then you can sort all that stuff at the start of your binary
20:01:53 <geist> which probably doesn't matter, but it feels nicer and more organized
20:03:15 --- quit: epony (Remote host closed the connection)
20:06:59 <pounce> So I was considering at one point page-aligning all of my start up code, and then once the OS starts up, deallocating all of it
20:07:32 <pounce> Is that ever done? or is it more trouble than it's worth
20:07:50 --- quit: chao-tic (Ping timeout: 256 seconds)
20:08:35 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
20:08:46 --- quit: chao-tic (Client Quit)
20:11:23 --- quit: adu (Quit: adu)
20:12:50 --- join: epony (~nym@77-85-133-5.ip.btc-net.bg) joined #osdev
20:14:00 --- quit: epony (Max SendQ exceeded)
20:14:39 --- join: epony (~nym@77-85-133-5.ip.btc-net.bg) joined #osdev
20:20:06 --- quit: Belxjander (Ping timeout: 276 seconds)
20:25:17 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
20:27:27 --- join: freakazoid0223 (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
20:28:48 --- quit: freakazoid0223_ (Ping timeout: 256 seconds)
20:41:16 --- join: oaken-source (~oaken-sou@p3E9D2C5D.dip0.t-ipconnect.de) joined #osdev
20:43:17 --- quit: king_idiot (Ping timeout: 256 seconds)
20:46:06 --- quit: uvgroovy (Quit: uvgroovy)
21:00:17 --- quit: variable (Quit: /dev/null is full)
21:03:50 --- quit: quc (Ping timeout: 248 seconds)
21:04:42 --- quit: Patater (Ping timeout: 255 seconds)
21:06:06 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
21:06:48 --- join: ohnx (~ohnx@unaffiliated/ohnx) joined #osdev
21:06:58 --- quit: variable (Client Quit)
21:07:25 --- quit: Darmor (Quit: Leaving)
21:08:25 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
21:08:32 --- quit: variable (Client Quit)
21:09:01 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
21:09:20 --- quit: variable (Client Quit)
21:10:07 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
21:10:07 --- quit: variable (Client Quit)
21:12:33 --- join: babyflakes (uid171740@gateway/web/irccloud.com/x-vypkvpbvpwddsdef) joined #osdev
21:15:05 --- quit: Lowl3v3l (Remote host closed the connection)
21:17:06 --- join: freakazoid0223_ (~IceChat9@pool-108-52-4-148.phlapa.fios.verizon.net) joined #osdev
21:19:24 --- quit: freakazoid0223 (Ping timeout: 255 seconds)
21:20:15 --- join: quc (~quc@87.116.230.31) joined #osdev
21:35:21 --- join: Humble (~hchiramm@2405:204:53a5:f3fa:ef49:f6d7:748d:4c61) joined #osdev
21:42:30 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
21:53:43 --- join: lowl3v3l (~lowl3v3l@musketeer-7.fusion.uni-jena.de) joined #osdev
22:10:00 --- quit: quc (Remote host closed the connection)
22:10:14 --- join: quc (~quc@87.116.230.31) joined #osdev
22:11:23 --- quit: freakazoid0223_ (Quit: Make it idiot proof and someone will make a better idiot.)
22:14:13 --- quit: thinkpol (Remote host closed the connection)
22:14:40 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
22:16:47 --- quit: lowl3v3l (Quit: Lost terminal)
22:18:43 --- quit: wcstok (Read error: Connection reset by peer)
22:23:27 --- join: SwiftMatt (~Objective@2601:282:4300:3e:2d7d:e0f3:f4f8:4e56) joined #osdev
22:24:17 --- join: Lowl3v3l (~Lowl3v3l@141.35.23.133) joined #osdev
22:26:58 --- join: etXzat[m] (etxzatmatr@gateway/shell/matrix.org/x-iobdplateohkxbxm) joined #osdev
22:27:30 --- quit: vdamewood (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
22:33:40 --- join: silipwn (~silipwn@unaffiliated/silipwn) joined #osdev
22:37:29 --- join: caen23 (~caen23@79.118.94.187) joined #osdev
22:41:09 --- quit: Belxjander (Ping timeout: 276 seconds)
22:41:43 --- join: eremitah_ (~int@unaffiliated/eremitah) joined #osdev
22:42:54 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
22:45:43 --- quit: eremitah (Ping timeout: 264 seconds)
22:45:43 --- nick: eremitah_ -> eremitah
22:49:01 --- quit: pounce (Quit: WeeChat 2.0.1)
22:51:55 --- join: k4m1 (~k4m1@82-181-0-34.bb.dnainternet.fi) joined #osdev
22:53:59 --- quit: k4m1 (Client Quit)
22:54:26 --- quit: Belxjander (Ping timeout: 256 seconds)
22:54:35 --- join: k4m1 (~k4m1@82-181-0-34.bb.dnainternet.fi) joined #osdev
22:55:16 --- join: xenos1984 (~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120) joined #osdev
23:00:39 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:01:40 --- quit: geist (Quit: Lost terminal)
23:02:18 --- join: user10032 (~Thirteen@2.124.229.123) joined #osdev
23:09:55 --- quit: GreaseMonkey (Remote host closed the connection)
23:15:18 --- join: sinetek (~sinetek@modemcable018.210-57-74.mc.videotron.ca) joined #osdev
23:16:22 --- join: bemeurer (~bemeurer@2600:8802:5300:49b0:feec:c9cb:aaaa:7e25) joined #osdev
23:17:41 --- join: Tazmain (~Tazmain@41.189.78.208) joined #osdev
23:17:56 --- quit: Tazmain (Changing host)
23:17:56 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
23:19:26 --- join: greaser|q (quassel@antihype.space) joined #osdev
23:23:35 --- quit: bemeurer (Quit: Leaving)
23:25:23 --- join: bemeurer (~bemeurer@2600:8802:5300:49b0:feec:c9cb:aaaa:7e25) joined #osdev
23:26:03 --- quit: retpoline (Quit: bye)
23:26:07 --- quit: bemeurer (Client Quit)
23:29:54 --- quit: Humble (Ping timeout: 276 seconds)
23:30:01 --- join: geist (~geist@tkgeisel.com) joined #osdev
23:30:10 --- quit: geist (Client Quit)
23:30:23 --- join: geist (~geist@tkgeisel.com) joined #osdev
23:36:05 --- quit: Pessimist (Remote host closed the connection)
23:41:16 --- join: Humble (~hchiramm@2405:204:5786:75e7:5707:436d:2e1d:65b) joined #osdev
23:45:02 --- quit: sbahra (Remote host closed the connection)
23:49:28 --- join: aosfields_ (~aosfields@71.194.3.30) joined #osdev
23:57:11 --- join: Patater (jaeden@2600:3c00::f03c:91ff:fe93:25aa) joined #osdev
23:58:26 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
23:59:59 --- log: ended osdev/18.01.14