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=7&d=7
00:00:00 --- log: started osdev/18.07.07
00:01:17 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
00:02:27 --- quit: cirno_ (Remote host closed the connection)
00:03:07 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
00:03:48 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:08:36 --- quit: Burgundy (Remote host closed the connection)
00:11:00 --- part: robomanisnot left #osdev
00:14:18 --- quit: xenos1984 (Ping timeout: 240 seconds)
00:16:26 --- quit: zeus1 (Ping timeout: 240 seconds)
00:23:05 --- join: Vulcan (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
00:24:27 --- quit: cirno_ (Remote host closed the connection)
00:28:23 --- quit: m3nt4L (Remote host closed the connection)
00:30:08 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
00:32:35 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
00:46:55 --- join: AverageJ0e (~joe@ip72-222-140-99.ph.ph.cox.net) joined #osdev
00:53:09 --- quit: rafaeldelucena (Ping timeout: 265 seconds)
01:00:07 --- quit: AverageJ0e (Ping timeout: 264 seconds)
01:06:13 --- quit: qeos (Ping timeout: 260 seconds)
01:06:17 --- join: qeos|2 (~qeos@ppp91-79-249-247.pppoe.mtu-net.ru) joined #osdev
01:23:18 --- quit: mavhq (Read error: Connection reset by peer)
01:24:28 --- quit: CrystalMath (Ping timeout: 268 seconds)
01:24:33 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
01:25:18 --- quit: Vulcan (Remote host closed the connection)
01:29:26 --- quit: nwm (Ping timeout: 256 seconds)
01:37:37 --- quit: Goplat (Remote host closed the connection)
01:53:11 --- quit: hmmmmm (Remote host closed the connection)
01:55:54 --- join: Asu (~sdelang@239.19.136.77.rev.sfr.net) joined #osdev
02:06:07 --- join: Vulcan (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
02:08:03 --- quit: mavhq (Read error: Connection reset by peer)
02:08:44 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
02:09:20 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
02:12:36 --- quit: [Dragon] (Quit: Doo or doonnot doo.)
02:12:54 --- quit: masoudd (Ping timeout: 248 seconds)
02:13:47 --- join: kimundi (~Kimundi@i577A9079.versanet.de) joined #osdev
02:30:56 --- quit: salek_ (Ping timeout: 240 seconds)
02:31:59 --- quit: bm371613 (Quit: Konversation terminated!)
02:36:00 --- join: ioerror88 (~odn-noc@atl1.osdev.ninja) joined #osdev
02:36:14 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
02:48:51 --- join: raymondq (~raymondq@gateway/tor-sasl/abramovich) joined #osdev
02:56:11 --- join: MarcinWieczorek (~MarcinWie@89-64-31-35.dynamic.chello.pl) joined #osdev
03:06:31 --- join: M1cha (~M1cha@2a02:908:5a3:da80:7a8d:2699:26c0:ba14) joined #osdev
03:12:38 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
03:26:01 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
03:26:50 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
03:29:28 --- join: rawste (~rawste@static-176-182-199-171.ncc.abo.bbox.fr) joined #osdev
03:33:55 --- join: baschdel (~baschdel@2a01:5c0:1c:6201:bb0:858:a281:6ed8) joined #osdev
03:40:42 --- quit: hph^ ()
03:44:55 --- quit: spare (Quit: leaving)
03:47:03 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
03:52:24 --- quit: graphene (Remote host closed the connection)
03:53:56 --- join: graphene (~graphene@46.101.134.251) joined #osdev
03:54:15 --- join: zeus1 (~zeus@62.56.248.65) joined #osdev
04:00:44 --- quit: zeus1 (Ping timeout: 256 seconds)
04:01:56 --- join: DeepIO (~DeepIO@80.228.187.143) joined #osdev
04:02:28 --- quit: DeepIO (Client Quit)
04:18:18 --- join: Kimundi_ (~Kimundi@i577A9598.versanet.de) joined #osdev
04:21:56 --- quit: kimundi (Ping timeout: 240 seconds)
04:24:08 --- quit: ioerror88 (Quit: leaving)
04:25:55 --- join: sdfgsd (~sdfgsdfgs@176.33.238.46) joined #osdev
04:28:28 --- quit: baschdel (Read error: Connection reset by peer)
04:31:43 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
04:31:56 --- quit: MarcinWieczorek (Ping timeout: 268 seconds)
04:45:56 --- join: m_t (~m_t@p5DDA3BA6.dip0.t-ipconnect.de) joined #osdev
04:55:35 --- join: MarcinWieczorek (~MarcinWie@user-94-254-164-92.play-internet.pl) joined #osdev
04:56:19 --- quit: Vulcan (Remote host closed the connection)
04:58:50 --- join: salek_ (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
04:59:12 --- join: Burgundy (~yyomony@5-12-163-132.residential.rdsnet.ro) joined #osdev
05:03:28 --- join: Tobba (~Tobba@h-25-157.A159.priv.bahnhof.se) joined #osdev
05:06:14 --- quit: rawste (Quit: Sleep....)
05:07:47 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
05:12:57 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
05:14:35 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
05:15:08 --- join: S_Gautam (uid286066@gateway/web/irccloud.com/x-dtbvhmdkiuagufmh) joined #osdev
05:16:09 --- join: Vulcan (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
05:21:31 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
05:22:34 --- join: dennis95 (~dennis@i577BCE98.versanet.de) joined #osdev
05:24:43 --- quit: promach_ (Ping timeout: 264 seconds)
05:26:11 --- join: rawste (~rawste@static-176-182-199-171.ncc.abo.bbox.fr) joined #osdev
05:31:54 --- join: promach_ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
05:32:31 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-rcyafonlngolfwdd) joined #osdev
05:44:14 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
05:47:09 --- join: silipwn (~silipwn@unaffiliated/silipwn) joined #osdev
05:49:08 --- quit: Vulcan (Remote host closed the connection)
05:49:54 --- join: Vulcan (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
05:50:46 --- join: Vulcan_ (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
05:53:56 --- quit: Vulcan (Ping timeout: 240 seconds)
05:54:09 --- join: MarcinWieczorek_ (~MarcinWie@2a00:f41:1c08:9b5e:4025:7f4d:fc6b:148c) joined #osdev
05:55:55 --- join: user10032 (~Thirteen@2a02:c7d:314e:b300:41b3:23d:9e5a:468a) joined #osdev
05:56:54 --- quit: MarcinWieczorek (Ping timeout: 256 seconds)
06:02:48 --- quit: salek_ (Ping timeout: 240 seconds)
06:04:44 --- quit: ljc (Quit: ayy)
06:10:26 --- quit: heat (Ping timeout: 240 seconds)
06:15:25 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
06:16:26 --- join: macdonag2 (~macdonag2@cpc110673-lewi19-2-0-cust478.2-4.cable.virginm.net) joined #osdev
06:24:19 --- quit: ratschance (Remote host closed the connection)
06:24:47 --- join: ratschance (~ratschanc@205.175.226.102) joined #osdev
06:27:45 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
06:30:59 --- quit: raymondq (Remote host closed the connection)
06:31:55 --- quit: Tobba (Ping timeout: 264 seconds)
06:37:24 --- join: zeus1 (~zeus@160.242.136.200) joined #osdev
06:38:22 --- quit: Vulcan_ (Remote host closed the connection)
06:38:53 --- join: lordofthekebabs (556b3b44@gateway/web/freenode/ip.85.107.59.68) joined #osdev
06:39:08 --- join: Vulcan (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
06:39:10 <lordofthekebabs> Is there a operating system for tablets that lets the user code on it. I mean I have looked at tizen, plasma mobile but none of them seems to have the full usability like a desktop OS. I want to be able to open up a editor , terminal the whole development enviorement and be able to have full control over the device. This is like a visual representation
06:39:19 <lordofthekebabs> https://pbs.twimg.com/media/Cy4tycmXcAAOMB3.jpg
06:39:27 <lordofthekebabs> I know that it is from a scifi series but you get the idea of what I am looking for
06:42:55 <heat> I don't know what you mean with controlling the whole device
06:43:02 --- quit: macdonag2 (Quit: macdonag2)
06:43:30 <lordofthekebabs> heat what i mean is that I can have full control over a desktop enviireoemnt
06:43:33 <heat> but android can do the job as a development environment considering it supports a terminal thingy with toolchains, etc like linux
06:43:47 <heat> that's still completely vague
06:44:31 --- quit: Vulcan (Ping timeout: 268 seconds)
06:44:35 <lordofthekebabs> asec pls
06:44:37 <lordofthekebabs> brb
06:46:50 <lordofthekebabs> heat so im a complete newbie in terms of harware and operating systems all I did so far with programming is coding full stack with python with django and some wsgi stuff. I am not so advanced in coding but I want to be able to code with the same ease on a tablet
06:47:22 <heat> Codign with ease and conding on a tablet are, in my experience, mutually exclusive
06:47:27 --- join: HZun (~HZun@0x3ec72d49.osd.customer.dk.telia.net) joined #osdev
06:47:51 <heat> Might be a bit easier if you use a separate keyboard, but still, it's nowhere near as good as a PC
06:48:31 <Love4Boobies> lordofthekebabs, you can use Android for that if you tailor it to your needs but the point is people don't invest effort into this because that's not what tablets are useful for. They are the wrong tool for the task.
06:48:31 <lordofthekebabs> heat yes I know I tried doing a little bit on my phone but still I like the idea
06:48:35 <lordofthekebabs> and want to do it
06:48:59 <heat> I still don't get what you're trying to say with the whole "full control over a desktop environment"
06:49:15 <heat> but again, android can at least do something like it
06:49:17 <lordofthekebabs> heat that was a wrong choice of words sorry
06:49:17 <Love4Boobies> Me neither, I just ignored that part.
06:49:34 <heat> (hell, android can even run debian in a chroot)
06:49:57 <lordofthekebabs> well i get that tablets are the wrong choice for the job but https://pbs.twimg.com/media/Cy4tycmXcAAOMB3.jpg if you look att he image i sent I know that it is from a scifi series but
06:50:12 <heat> it certainly can run any choice of compilers/toolchain/interpreter that you wish
06:50:15 <lordofthekebabs> I would love to spend my time building something like that or use something like that
06:50:37 <palk> that's an app, not an operating system
06:50:41 <heat> that's just an IDE/editor though?
06:51:42 <heat> I don't see what's so special about that image
06:51:58 --- quit: m_t (Remote host closed the connection)
06:52:00 <lordofthekebabs> do you have time for like a 2 min ui video about the image
06:52:02 <heat> it's just an IDE with some TV bs for people to think it's very advanced and futuristic
06:52:16 <heat> uh sure
06:52:19 <lordofthekebabs> https://www.youtube.com/watch?v=qvrSUwqt6Mw
06:52:20 <bslsk05> 'Westworld UI A Supercut' by 陳聰敏 (00:02:46)
06:52:49 --- join: m_t (~m_t@p5DDA3BA6.dip0.t-ipconnect.de) joined #osdev
06:52:50 <lordofthekebabs> I get that it is TV bs but I would love to work on something like that even though i cannot accomplish it. At least i would try
06:52:57 --- join: freakazoid0223 (~mattc@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
06:53:11 --- quit: m_t (Max SendQ exceeded)
06:53:29 --- join: [ToyStory] (~while@unaffiliated/awaxx/x-0928682) joined #osdev
06:54:23 <heat> that ad was very very very confusing
06:54:34 <heat> s/ad/video/
06:56:09 <lordofthekebabs> what
06:56:47 <heat> I tried to understand what you're trying to say
06:56:54 <heat> I ended up even more confused
06:57:31 <lordofthekebabs> look at 2.26
06:57:43 <lordofthekebabs> until 2.37
06:58:08 <lordofthekebabs> rest is tv scifi stuff
06:58:12 <heat> What's so special about it?
06:58:19 <heat> it's all tv scifi stuff
06:58:36 <lordofthekebabs> I would abosuletly love to code on something like that
06:58:43 <lordofthekebabs> on bed on train
06:58:50 <lordofthekebabs> idk literally everywhere i go
06:59:29 <heat> I don't see what's so special about that "desktop environment"
07:00:14 <lordofthekebabs> what do you mean "desktop env"
07:00:43 <lordofthekebabs> well I mean I just want to code it if it doesnt exists
07:00:53 <lordofthekebabs> or use it if it exists that was my question :) but thank you tho
07:00:54 <palk> well, it doesn't, so go ahead
07:01:13 <lordofthekebabs> alright i will try :) maybe in 3 or 4 years
07:01:20 <lordofthekebabs> i can accomplish it
07:01:24 <lordofthekebabs> thanks a lot for taking your time
07:01:26 <palk> best of luck to you
07:01:31 <heat> I don't quite get what you're trying to do
07:01:37 <heat> but good luck I guess
07:01:42 <lordofthekebabs> thanks !
07:01:49 <palk> heat: he wants to make an app that behaves like the "app" in the video
07:03:49 --- join: arora (~ashok@92.96.229.64) joined #osdev
07:04:32 --- part: lordofthekebabs left #osdev
07:09:01 <heat> that sounds like an awful idea tbh
07:13:26 <heat> I have a synchronization question
07:13:53 <heat> I have a function called sem_wait, which blocks the thread and puts it in the wait queue if the counter < 1
07:14:05 <heat> (https://gist.github.com/heatd/bbd457ea48df09e0d18fe8a039210235) <- It's this one
07:14:06 <bslsk05> gist.github.com: sem.c · GitHub
07:14:32 <heat> How do I stop the sem_signal from waking up the thread before it even started to sleep?
07:15:46 <heat> In other words, how do i stop the sem_signal from "waking up" the thread between the atomic_load_explicit and the end of thread_set_state?
07:18:48 <heat> Originally I added a semaphore because of this whole "resume before suspend" problem, but now I realise I haven't solved it at all
07:21:43 --- quit: immibis (Ping timeout: 264 seconds)
07:22:18 <doug16k> heat, is it really necessary to stop it from being awakened? won't it just get scheduled to run again sometime after it goes to sleep? why is that scenario different from it being asleep already when it gets awakened?
07:23:03 --- join: [Brain] (~brain@brainwave.brainbox.cc) joined #osdev
07:23:43 <heat> My thread_wake_up does a no-op if thread->state == desired_state
07:23:52 <doug16k> ah
07:26:08 <doug16k> where does the context switch occur in that paste? does thread_set_state(current, THREAD_BLOCKED); context switch and only return when it gets awakened?
07:28:11 <heat> Yes
07:28:25 <heat> thread_set_state checks if thread == get_current_thread, and if so, yields
07:29:40 <heat> Some more context: This code is executing when trying to sync 2 different threads (of different processes) running in 2 different cpus
07:30:22 <heat> and it only happens sometimes, so it's a timing issue for sure
07:31:12 --- quit: MarcinWieczorek_ (Ping timeout: 240 seconds)
07:32:13 <heat> and now it's also firing asserts in the scheduler code
07:32:21 <heat> Wonderful.
07:33:28 --- join: masoudd (~masoudd@5.116.17.229) joined #osdev
07:34:42 <heat> Yeah, sometimes it hangs, other times an assert fires because the tail of the cpu's runnable list is the thread we're trying to insert
07:35:01 <heat> I believe I screwed up big time in my scheduler's locks
07:37:48 --- join: nicht (~nicht@2804:7f1:2080:9420:7b30:7749:da9:70c4) joined #osdev
07:41:31 --- join: tasman1 (~tasman@139.192.234.58) joined #osdev
07:44:04 --- quit: tasman1 (Client Quit)
07:44:46 --- quit: S_Gautam (Quit: Connection closed for inactivity)
07:44:57 --- join: MarcinWieczorek_ (~MarcinWie@2a00:f41:1c08:9b5e:4025:7f4d:fc6b:148c) joined #osdev
07:52:26 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
07:55:19 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
07:56:14 --- quit: arora (Quit: Good bye!)
08:00:02 --- quit: heat (Remote host closed the connection)
08:02:16 --- join: stephen77 (~stephen@142.134.91.153) joined #osdev
08:03:27 --- quit: zeus1 (Ping timeout: 268 seconds)
08:03:38 <stephen77> Okay I'm having trouble just trying to figure out multithreading
08:03:50 <stephen77> How do I switch between tasks even?
08:04:59 --- quit: HZun (Quit: Leaving)
08:05:35 <palk> typically by preempting one and resuming another
08:07:47 <stephen77> Are there any guides anywhere?
08:08:54 <palk> for what?
08:09:23 <stephen77> I just don't understand how to preempt a thread and resume another
08:09:55 <stephen77> I get what's happening behind the scenes I think - push registers to the stack, save the place where the code was being executed, and then load the other code and its registers
08:10:12 <stephen77> I just don't understand what code does that, if that makes sense
08:10:40 <Love4Boobies> stephen77, it depends on whether you're using a preemptive or a cooperative solution.
08:10:43 <palk> typically, you'll configure some kind of timer device to periodically cause an interrupt which passes execution back to the kernel
08:11:02 <Love4Boobies> In cooperative multithreading, code simply yields. In preemptive, you have an interrupt timer that preempts the running thread.
08:11:04 --- join: tacco| (~tacco@i59F4AFD7.versanet.de) joined #osdev
08:11:11 <palk> so the "guide" would be in how to configure the timer device, which is very much architecture-specific
08:11:20 <stephen77> Love4Boobies: Preemptive is what I'm after
08:11:26 <stephen77> I can configure the timer already
08:11:26 <palk> but, for a general overview, you can start here: https://wiki.osdev.org/Multitasking_Systems
08:11:28 <bslsk05> wiki.osdev.org: Multitasking Systems - OSDev Wiki
08:11:39 <stephen77> I just don't know how to pause a thread
08:11:41 <palk> and then move on to: https://wiki.osdev.org/Context_Switching
08:11:42 <bslsk05> wiki.osdev.org: Context Switching - OSDev Wiki
08:11:43 <stephen77> And resume a thread
08:11:52 <Love4Boobies> stephen77, didn't you just describe the process yourself?
08:12:01 <Love4Boobies> That's exactly how you do it.
08:12:02 <stephen77> Yes
08:12:09 <stephen77> But I don't know how that works
08:12:12 <Love4Boobies> You save the current state and restore another thread's sate.
08:12:14 <Love4Boobies> state*
08:12:16 --- join: Asu` (~sdelang@AMarseille-658-1-97-164.w86-219.abo.wanadoo.fr) joined #osdev
08:12:18 <stephen77> Ex: How do I get the position it was executing in?
08:12:33 <stephen77> How do I get the stack in C? Or should I write it in ASM?
08:12:46 <palk> does your OS already have support for interrupts
08:12:57 --- join: alphawarrior (~alphawarr@96.30.69.37) joined #osdev
08:12:58 <stephen77> Yes
08:13:04 <Love4Boobies> You should write it in assembly.
08:13:15 <palk> then, is the instruction pointer not already on the stack after an interrupt is taken?
08:14:07 <Love4Boobies> When you return from the context switch, you simply return to antoher thread because of the stack switch.
08:14:18 --- quit: Asu (Ping timeout: 245 seconds)
08:14:21 --- join: SwiftMatt (~Objective@2601:282:4300:3e:cc8:1161:1ca7:c879) joined #osdev
08:14:35 <doug16k> stephen77, the stack tells you how to return into the code. you save the stack pointer for one thread, and pick another thread, and switch to that stack, and return into that thread
08:14:46 <stephen77> hmm okay
08:15:10 <doug16k> eventually the original thread will get rescheduled, it just switches to its stack and returns into it
08:17:07 <doug16k> when you create a new thread, you prepare a stack with a layout suitable for it being used to "return" into it for the first time, and set that thread's saved stack pointer to point to the appropriate location in the new thread's stack
08:17:28 <stephen77> Okay I think I understand
08:17:31 <stephen77> Thanks everyone
08:20:05 --- join: promach__ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
08:22:01 --- quit: palk ()
08:22:48 --- quit: promach_ (Ping timeout: 240 seconds)
08:23:55 --- quit: vdamewood (Quit: Textual IRC Client: www.textualapp.com)
08:24:43 --- join: Asu (~sdelang@181.19.136.77.rev.sfr.net) joined #osdev
08:25:01 --- quit: Asu` (Ping timeout: 260 seconds)
08:25:05 --- quit: crgimenes (Quit: crgimenes)
08:25:41 <alphawarrior> hello everyone! how can I tell my binutil/gcc's configure to create libgcc as non PIC?
08:26:41 --- join: [X-Scale] (~ARM@46.50.6.244) joined #osdev
08:26:53 --- quit: X-Scale (Ping timeout: 268 seconds)
08:27:12 --- nick: [X-Scale] -> X-Scale
08:27:15 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
08:28:18 --- quit: JusticeEX (Ping timeout: 240 seconds)
08:31:02 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
08:33:11 --- quit: variable (Quit: /dev/null is full)
08:33:42 --- quit: drakonis (Ping timeout: 248 seconds)
08:34:15 --- quit: Beato (Quit: Bye!)
08:34:48 --- quit: silipwn (Ping timeout: 240 seconds)
08:36:11 <doug16k> alphawarrior, do you have a script that builds gcc?
08:36:35 --- join: silipwn (~silipwn@unaffiliated/silipwn) joined #osdev
08:37:50 --- quit: drakonis_ (Ping timeout: 256 seconds)
08:38:02 <doug16k> alphawarrior, you apply a patch. this is the patch I apply which tells the gcc build to build a set of variations of libgcc with all combinations of -mno-red-zone, -m32, -fPIE, -mrtd, -mregparm3 -> https://github.com/doug65536/dgos/blob/master/toolchain/build-crossgcc-gcc.patch
08:38:04 <bslsk05> github.com: dgos/build-crossgcc-gcc.patch at master · doug65536/dgos · GitHub
08:38:34 <alphawarrior> just doing what https://wiki.osdev.org/GCC_Cross-Compiler tells me but objdump -r shows relocations in crosscc/lib/gcc/x86_64-elf/8.1.0/no-red-zone/libgcc.a so I assume it is pic probably
08:38:36 <bslsk05> wiki.osdev.org: GCC Cross-Compiler - OSDev Wiki
08:38:36 <doug16k> the gcc it builds will automatically choose the appropriate version of libgcc based on the compile parameters
08:39:59 --- join: Vulcan (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
08:41:58 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
08:42:04 <doug16k> alphawarrior, object files will always have relocations. it is impossible for there not to be relocations
08:42:19 <doug16k> relocations != PIC
08:42:43 --- join: salek_ (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
08:43:14 <doug16k> any time any source file refers to a symbol that is defined in another source file, the object file will have a relocation for it
08:43:33 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
08:43:41 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
08:43:50 <doug16k> because the compiler isn't clairvoyant and can't divine what address that symbol will end up at after linking
08:44:36 --- quit: Vulcan (Ping timeout: 255 seconds)
08:45:17 <alphawarrior> oh wow
08:45:22 <alphawarrior> thanks for explaining
08:45:33 <alphawarrior> then how can I test if a .a is PIC?
08:45:40 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
08:47:13 <doug16k> look at the disassembly. does it refer to external symbols with with 0(%rip) ?
08:47:50 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
08:47:53 <doug16k> even if it is PIC, what does it matter? x86-64 PIC just works
08:48:19 <alphawarrior> like movl $0x7,0x0(%rip) # 4a3 <__cpu_indicator_init+0x1f3>?
08:48:25 <doug16k> yes
08:48:40 <alphawarrior> then it contains lots of it
08:49:05 <alphawarrior> lib/gcc/x86_64-elf/8.1.0/no-red-zone/libgcc.a to be specific
08:49:09 <alphawarrior> is that normal?
08:49:16 <doug16k> what's wrong with that? rip relative addressing is smaller code for that
08:49:18 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
08:49:36 <doug16k> an absolute reference would be SIB encoded and would make the instruction one byte larger
08:49:45 --- join: Beato (~Beato@unaffiliated/beato) joined #osdev
08:49:54 <doug16k> with zero benefit
08:50:09 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
08:50:41 <doug16k> why are you trying to stop it from using position independent code?
08:51:10 <alphawarrior> well I'm getting some errors with ld https://pastebin.com/UpztrEhn (the truncated against lines) and i've googled that and i've seen an answer on the intel forums where they ended up with PIC being the problem
08:51:11 <bslsk05> pastebin.com: x86_64-elf-g++ -T arch/x86_64/linker.ld -mno-red-zone -ffreestanding -Wall -Wext - Pastebin.com
08:51:41 <alphawarrior> but if libgcc is fpic then shouldn't my kernel also be fpic?
08:52:21 <doug16k> you have problems in your linker script
08:52:37 --- join: jakogut (~jakogut@162.251.69.147) joined #osdev
08:52:40 <doug16k> the relocation would be truncated to fit anyway
08:52:48 --- quit: variable (Ping timeout: 240 seconds)
08:53:05 <doug16k> stopping pic won't magically eliminate relocations being truncated to fit
08:53:18 <doug16k> can you show your linker script?
08:53:18 <alphawarrior> well my linker script is the same as https://github.com/thepowersgang/rust-barebones-kernel/blob/master/Kernel/arch/amd64/link.ld
08:53:20 <bslsk05> github.com: rust-barebones-kernel/link.ld at master · thepowersgang/rust-barebones-kernel · GitHub
08:53:26 <alphawarrior> but wait let me push my code
08:53:30 <doug16k> ok
08:53:32 <alphawarrior> maybe i made mistakes
08:56:28 <alphawarrior> https://gitlab.com/KriszDev/neko/blob/master/arch/x86_64/linker.ld please don't mind the missing kernel_main function i didn't add that yet
08:56:29 <bslsk05> gitlab.com: arch/x86_64/linker.ld · master · Gáncs Krisztián / neko · GitLab
08:57:42 <doug16k> you don't need to repeatedly say AT, only the first one needs it, from there on it will default to advance the same amount as the vaddr
08:57:53 --- join: zeus1 (~zeus@160.242.135.171) joined #osdev
08:58:46 <doug16k> what's happening is, the linker is emitting sections that are light years away from 0xffffffff80000000, much too far away to encode an offset in the problem instructions.
08:59:26 <doug16k> that is what it means when it says the relocation is truncated to fit. it wants to encode 100+TB offset, but the field in the instruction is 32 bits
09:00:15 --- quit: graphene (Remote host closed the connection)
09:00:30 <doug16k> for example, if you put a global variable at 0x10000000000 and your data section is at 0xffffffff80010000 then it needs to encode an offset that is far too big for the 4 byte offset field in the instruction
09:01:08 <doug16k> alphawarrior, add this to your link command line -> -Wl,-Map,kernel.map
09:01:28 <doug16k> it will write a file indicating where things ended up, pastebin kernel.map
09:01:37 <alphawarrior> ok one sec
09:01:46 --- join: graphene (~graphene@46.101.134.251) joined #osdev
09:02:12 --- quit: zeus1 (Ping timeout: 256 seconds)
09:05:25 <alphawarrior> well i added to the final g++ call that links but nothing gets generated but still shows the error messages: https://pastebin.com/5fCTLv0V
09:05:25 <bslsk05> pastebin.com: x86_64-elf-g++ -T arch/x86_64/linker.ld -Wl,-Map,kernel.map -mno-red-zone -ffre - Pastebin.com
09:06:10 <alphawarrior> oh wait my bad
09:06:11 --- quit: silipwn (Ping timeout: 255 seconds)
09:06:48 <doug16k> you should have -mcmodel=kernel in your compile command line if you are linking at 0xffffffff80000000
09:06:55 <alphawarrior> map file https://paste.pound-python.org/show/w5rHbfQ2WO7fkPqSlF2F/
09:06:57 <bslsk05> paste.pound-python.org: Paste #w5rHbfQ2WO7fkPqSlF2F at spacepaste
09:08:04 <doug16k> it tells the compiler to use instructions that will perform sign extension when doing operations on addresses
09:08:21 <alphawarrior> oh wow
09:08:41 <alphawarrior> why wasn't that a problem with i386?
09:09:11 <doug16k> because i386 can represent any address in instructions normally
09:09:19 <alphawarrior> oh wow
09:09:40 <doug16k> amd64 doesn't double the size of everything. it uses an efficient way to represent addresses that are between -2GB and 0
09:09:53 <alphawarrior> should i do the mcmodel on asm too or just the c++ code?
09:10:00 <doug16k> 0xfffffff80000000 is -2GB
09:10:24 <alphawarrior> oh yeah I read that before somewhere but does it represent it like -2GB then?
09:10:26 <doug16k> just the compiled code but it won't hurt if it goes on assembly or link command lines
09:10:49 <doug16k> the 32 bit field 0x80000000 is sign extended, to 0xffffffff80000000
09:10:59 <doug16k> so it can represent a kernel address with a normal 32 bit offset field
09:11:11 <alphawarrior> oh that's pretty clever actually
09:11:36 <doug16k> yes, amd64 extensions are clever. they didn't just double the size of everything, they carefully made sure it wouldn't bloat it up
09:12:02 <alphawarrior> but then how would you address something like in the half of the space? full 64bit address right?
09:12:22 <doug16k> pointers can point anywhere, no problem
09:12:42 --- nick: promach__ -> promach_
09:12:47 <doug16k> it's only an issue when you want to encode the address of a thing right into an instruction, like accessing a global variable directly
09:13:20 <doug16k> you can make gcc produce bloated code that can handle globals being absolutely anywhere, with -mcmodel=large
09:13:33 <doug16k> it causes it to generate significantly larger code
09:14:11 <doug16k> -mcmodel=kernel makes it generate code that represents accesses to global symbols just as compactly as 32 bit code
09:14:14 <alphawarrior> well "as" doesn't know -mcmodel=kernel so i can't add there as cmdline argument
09:14:25 <doug16k> you should use gcc to assemble
09:14:37 <doug16k> gcc/g++
09:14:45 <alphawarrior> what's wrong with gnu as?
09:14:59 <doug16k> why bother with a special case? you can just compile everything uniformly
09:15:36 <doug16k> you can just compile a bunch of .c .cc .s .S files uniformly with no regard to what language they are
09:15:54 <doug16k> it's just a source file. gcc will see the extension and do the right thing
09:16:08 <alphawarrior> oh so if instead of using a cpp file i use an asm one g++ will compile the same way?
09:16:23 <Xal> no, use `gcc -v` to see what gcc is doing
09:16:33 <Xal> gcc will invoke `as` at some point with a bunch of its own flags
09:16:38 <doug16k> yes. you can do g++ -o something.o -c something.s and it will assemble it
09:17:03 <alphawarrior> that's pretty sweet
09:17:11 <doug16k> halves the amount of stuff in your makefile. no need to special case assembly. just throw it in your SOURCES or whatever
09:17:41 <doug16k> if stuff is in your CFLAGS/CXXFLAGS that doesn't apply to asm, no problem, gcc will ignore them
09:19:06 --- join: qeos (~qeos@ppp91-79-249-247.pppoe.mtu-net.ru) joined #osdev
09:19:22 <doug16k> gcc will invoke as for you btw, it isn't replacing gnu as
09:19:49 <doug16k> just as you can use gcc to link, it will run ld for you, you can use it to assemble, it will invoke as for you
09:20:20 <Xal> though be careful linking with gcc because it could link in libraries you don't need
09:20:20 <Xal> if you want gcc to not use any of its own linking scripts/libraries, use `-nostartfiles -nostdlib`
09:20:25 <doug16k> less special cases is always good
09:20:42 --- quit: eremitah (Remote host closed the connection)
09:20:45 --- quit: Mikaku (Remote host closed the connection)
09:20:59 --- quit: brad_d (Quit: No Ping reply in 180 seconds.)
09:21:07 --- quit: shirk (Ping timeout: 264 seconds)
09:21:12 --- quit: tj (Ping timeout: 240 seconds)
09:21:43 --- quit: Ameisen (Ping timeout: 264 seconds)
09:21:47 --- quit: Asu (Remote host closed the connection)
09:21:47 --- quit: silas (Ping timeout: 256 seconds)
09:22:11 --- quit: CheckDavid (Quit: Connection closed for inactivity)
09:22:13 --- join: Asu (~sdelang@181.19.136.77.rev.sfr.net) joined #osdev
09:22:15 --- join: brad_d (~quassel@unaffiliated/brad-d/x-1947915) joined #osdev
09:22:19 --- quit: qeos|2 (Ping timeout: 264 seconds)
09:22:54 --- quit: j00ru (Remote host closed the connection)
09:23:01 --- join: eremitah (~int@unaffiliated/eremitah) joined #osdev
09:23:07 --- join: j00ru (~j00ru@80-219-208-230.dclient.hispeed.ch) joined #osdev
09:23:20 --- join: Mikaku_ (~Mikaku@2on.fibranet.cat) joined #osdev
09:24:27 --- join: silas (~silas@bluebook.xen.prgmr.com) joined #osdev
09:25:39 --- join: shirk (~shirk@bitspin.org) joined #osdev
09:25:52 --- join: nwm (~nwm@d66-183-140-241.bchsia.telus.net) joined #osdev
09:26:04 <doug16k> alphawarrior, oh, another nice thing about using gcc to assemble: if your file extension is .S then it will preprocess it (handle #include #define etc), and will apply any -Dsomething=value in your C(XX)FLAGS and your -I include path. you can use that to refer have constants that are usable in your C(++) or assembly code uniformly
09:26:42 <doug16k> it will #define __ASSEMBLER__ when assembling, so you can #if avoid anything that isn't assembly in a header
09:28:02 <doug16k> in some places I have structure offsets as #define. I #include it in the assembly code. then in the source that declares the structure, I C_ASSERT(offsetof(type, field) == SOME_OFFSET_CONSTANT) to guarantee the assembly is using the correct field offset
09:28:42 <doug16k> the if I absentmindedly change a structure that breaks assembly, it catches it
09:29:32 <doug16k> it's useful for per-cpu state or thread related state that you may be forced to access from assembly
09:30:34 --- join: tj (~tj@strlen.org) joined #osdev
09:31:01 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
09:31:55 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
09:32:38 <alphawarrior> oh good things
09:33:03 <doug16k> plus you can avoid hard coding everything to death in assembly -> https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/entry.S#L65
09:33:04 <bslsk05> github.com: dgos/entry.S at master · doug65536/dgos · GitHub
09:33:22 --- join: manzerbredes (~loic@2a01cb0885e31500cfc30bb534d5bc37.ipv6.abo.wanadoo.fr) joined #osdev
09:33:22 <doug16k> way better than some random 0xC000xxxx constant that checks some mysterious bit constant
09:33:45 <doug16k> make the code say what it's doing instead of having to believe some comment
09:34:00 <alphawarrior> well changing to gcc from as with mcmodel=kernel didn't make the relocation truncated to fit error and ld return 1 during the final linking :(
09:34:30 <doug16k> then a section is ending up at a bad address
09:34:52 --- quit: sortie (Quit: Leaving)
09:35:04 <doug16k> add this to your link command line -> -Wl,--orphan-handling,warn
09:35:12 --- join: SwiftMatt (~Objective@2601:282:4300:3e:cc8:1161:1ca7:c879) joined #osdev
09:35:22 --- quit: Beato (Quit: Bye!)
09:35:38 --- join: Beato (znc@unaffiliated/beato) joined #osdev
09:36:24 <doug16k> it will complain about every input section that you have not placed in an output section
09:37:10 <Xal> avoid hardcoding in assembly by writing not-assembly
09:37:51 <alphawarrior> oh wow https://pastebin.com/kU046UsU so many things
09:37:52 <bslsk05> pastebin.com: x86_64-elf-g++ -T arch/x86_64/linker.ld -mno-red-zone -mcmodel=kernel -ffreestan - Pastebin.com
09:38:47 <doug16k> alphawarrior, line 15 of your linker script places *(.inittext) not .init
09:39:02 <doug16k> try adding *(.init) after *(.inittext)
09:39:24 --- join: silipwn (~silipwn@unaffiliated/silipwn) joined #osdev
09:39:30 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
09:39:37 <alphawarrior> inittext is a section from the rust barebones' start.S file which contains the boot code
09:39:52 <doug16k> and?
09:40:01 <doug16k> what's .init then?
09:40:24 <doug16k> old-style global constructors?
09:40:33 --- join: tadni (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
09:40:49 <alphawarrior> init is from crti
09:41:15 <doug16k> then don't put it where I said
09:41:30 <doug16k> should be in your .text section
09:41:58 <doug16k> or .ctors
09:42:02 <alphawarrior> oh wait
09:42:15 <doug16k> which I assume exists because you have errors mentioning .dtors
09:42:16 <alphawarrior> it looks like that linker script might be overriding the .init section?
09:42:33 <doug16k> input section names and output section names are independent
09:42:46 <doug16k> assuming they are mentioned in the linker script
09:42:47 <alphawarrior> i mean the linker script at https://github.com/thepowersgang/rust-barebones-kernel/blob/master/Kernel/arch/amd64/link.ld define an init section and also crti does too
09:42:56 <alphawarrior> do i even need the crti stuff?
09:43:19 <heat> Those relocation truncated to fit errors exist because your libgcc and crtstuff wasn't compiled with -mcmodel=large or -mcmodel=kernel
09:43:51 <heat> so they are compiled with -mcmodel=small, and generate R_X86_64_32 relocations
09:44:06 --- join: hmmmm (~sdfgsf@pool-72-79-169-12.sctnpa.east.verizon.net) joined #osdev
09:44:37 <doug16k> avoid large. use kernel if you're linking at 0xffffffff80000000
09:44:57 <alphawarrior> oh but isn't the linker script bad too with defining an .init section when it's there in crti?
09:45:02 <heat> I compile libgcc as large so I can link the same library to user-space and kernel space
09:45:32 --- quit: silipwn (Quit: leaving)
09:45:37 <doug16k> heat, it bloats it up significantly though. why not add a multilib to your gcc build?
09:45:40 <alphawarrior> the rust barebones repo doesn't have the crti asm file so i can't check :(
09:46:19 <heat> doug16k: Can you add a multilib for -mcmodel=kernel?
09:46:30 <doug16k> sure, you can add a multilib for anything
09:46:36 <doug16k> https://github.com/doug65536/dgos/blob/master/toolchain/build-crossgcc-gcc.patch
09:46:38 <bslsk05> github.com: dgos/build-crossgcc-gcc.patch at master · doug65536/dgos · GitHub
09:46:51 <alphawarrior> if I change the .init in the linker script to .boot then it doesn't give that many problems
09:46:52 <doug16k> I build a libgcc with mrtd and mregparm=3 for my bootloader
09:46:58 <heat> Oh, that's nice
09:47:14 <doug16k> heat, it builds one with every valid combination of those
09:47:16 <heat> I'll make sure to patch my target too
09:47:39 <heat> Yeah, I had one for -no-red-zone, just didn't know you could do that for mcmodels
09:47:48 <doug16k> so I could have code that just uses mrtd and it will use that libgcc. and another thing with both mrtd and mregparm=3 and it uses that libgcc, etc
09:48:52 <heat> Wait, does libgcc need to be compiled as PIC/PIE?
09:49:03 <heat> (if you're linking to a PIC/PIE elf)
09:49:48 <doug16k> it could need
09:50:08 --- quit: nicht (Ping timeout: 245 seconds)
09:50:11 <heat> Oh, that makes sense
09:50:19 <doug16k> how would it know to use GOT pointer in ebx in 32 bit code without it?
09:50:39 <heat> I had a tiny kernel that I was trying to compile as completely relocatable
09:50:54 <heat> libgcc was being stupid and broken so I just added a few stubs
09:52:12 <alphawarrior> i should give 64 bit up :D i like 32 bit more it doesn't give this many errors
09:52:25 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
09:52:26 <heat> don't run away from the errors
09:53:00 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
09:53:06 --- join: Ameisen (~Ameisen@digitalcarbide.com) joined #osdev
09:53:14 <doug16k> alphawarrior, heat's probably right, you might need to add an mcmodel=kernel variation of libgcc
09:53:42 <heat> I face those errors every time I recompile my toolchain and forget to compile them as mcmodel=kernel
09:53:44 <doug16k> it didn't occur to me because I'm getting away with not doing that. I think the only thing I use libgcc for is 64 bit divide in x86 code though, so it may not have been a problem
09:54:01 --- quit: crgimenes (Quit: crgimenes)
09:54:29 <alphawarrior> oh how can i add a variant like that?
09:54:29 <heat> doug16k: Do you know what options gcc needs for generating rip-relative addressing?
09:54:42 <alphawarrior> is it similar to how i made the mno-red-zone one?
09:54:45 <heat> yes
09:54:46 <doug16k> heat, executable?
09:54:57 <heat> doug16k: yes
09:54:59 <doug16k> you probably want -fPIE
09:55:13 <heat> fPIE generates a bunch of relocations
09:55:18 --- quit: xenos1984 (Ping timeout: 240 seconds)
09:55:34 <doug16k> then fPIC
09:56:58 <heat> I was getting around the whole problem by patching every relocation before entering the normal kernel, but it's just worse than rip-relative addressing
09:57:07 <heat> I'll be sure to test it out
09:57:18 <doug16k> are you trying to implement KASLR?
09:57:18 <alphawarrior> oh lol
09:57:27 <heat> doug16k: I did implement KASLR
09:57:33 <alphawarrior> sounds too painful
09:57:35 <doug16k> this is for user code then?
09:57:51 <heat> No, it's for the kernel
09:58:03 <heat> The kernel generates a lot of relocations
09:58:14 <heat> I would prefer rip-relative addressing
09:58:41 <doug16k> why? pie is faster code
09:59:18 <doug16k> global array accesses will require less instructions in pie
09:59:23 <heat> The difference is negligible
09:59:29 <doug16k> yeah it's a small difference
10:00:19 <heat> That kernel is still really tiny and I have close to 1000 relocations
10:00:28 --- quit: [ToyStory] (Quit: Don't hate my grind.)
10:00:36 <doug16k> heat, you will almost certainly have to do relocations anyway
10:00:40 <heat> Why?
10:00:56 <doug16k> because if you initialize a global variable to the address of something, it must be fixed up
10:01:04 <heat> Right
10:01:11 <doug16k> char buffer[1024]; .... char *something = buffer;
10:01:27 <doug16k> assuming 'something' is also a global
10:02:01 <heat> Still, I could substancially reduce the number of relocations
10:02:13 <doug16k> why bother though? it takes microseconds to do the relocations, right?
10:02:53 <heat> Depends on the size of the kernel
10:02:55 <doug16k> I mean, if you just loaded the kernel, it was bazillions of cycles waiting for I/O. then you blast through 1000 adds
10:03:50 <heat> Maybe you're right
10:04:46 <heat> What if I extended KASLR and remapped the kernel every time a process was loaded?
10:05:26 <heat> Doesn't seem like that bad of an idea
10:06:00 <doug16k> you could have taken the address of things and stored them. how would you mind-read which pointers to fixup in data structures?
10:06:14 --- join: [PathFinder] (~while@unaffiliated/awaxx/x-0928682) joined #osdev
10:06:20 <doug16k> for example, vtables
10:06:37 <heat> Oh, right
10:06:41 <doug16k> that are chosen at runtime
10:07:02 <heat> I was comparing a kernel to a shared object, but they are really different beasts aren't they
10:08:19 <heat> Anyway, back to the blocking/resuming drawing board
10:08:30 <doug16k> you can fork a kernel. I do that for my gdbstub, so it won't infinitely recurse when a breakpoint gets placed in a bad place. the stub runs in its own fork of the kernel code
10:09:28 <doug16k> then if you step-over something in an interrupt handling code path, the breakpoint placed by gdb won't interfere with the stub's exception handling
10:10:04 <doug16k> not exactly what you meant, but related
10:11:16 <heat> doug16k: I should disable preemption when changing scheduler data structures shouldn't I?
10:11:55 <doug16k> I was going to mention that earlier. if you disable interrupts and then yield, remember that the disabling of interrupts is local to the current thread
10:12:11 <doug16k> when it switches to another context that has interrupts enabled, it will enable interrupts
10:12:18 --- nick: Mikaku_ -> Mikaku
10:12:20 <heat> I don't disable interrupts when disabling preemption
10:12:28 --- quit: Mikaku (Changing host)
10:12:28 --- join: Mikaku (~Mikaku@pdpc/supporter/active/mikaku) joined #osdev
10:12:48 <heat> I just set a bool that tells the scheduler to keep running the same thread
10:12:57 <heat> (should change it to a counter)
10:12:57 <doug16k> ok then what I said doesn't apply. you have to manually worry about it
10:13:30 <doug16k> why not disable interrupts and save the time wasted handling the pointless preemption?
10:14:01 <heat> So code that relies on a timer, signals, etc doesn't break
10:14:22 <heat> I believe it's what linux does too
10:14:49 --- join: angel0xff (~zzz@158-58-227-127.sf.ddns.bulsat.com) joined #osdev
10:15:05 <doug16k> so your scheduling interrupt checks the flag and just returns immediately?
10:15:58 <heat> yes
10:16:20 <doug16k> so I could craft malicious code that tricks the kernel into ignoring every preemption
10:16:27 --- quit: bluezinc (Quit: ave atque vale)
10:16:28 <doug16k> theoretically
10:16:32 <heat> Sure, you could
10:16:39 <heat> but you could also disable interrupts
10:16:46 <doug16k> user code can't
10:17:03 <heat> user code can't touch the bool too
10:17:11 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
10:17:16 <doug16k> but it could call something that touches it at just the right time
10:17:55 --- join: bluezinc (~bluezinc@unaffiliated/bluezinc) joined #osdev
10:17:57 --- quit: bluezinc (Client Quit)
10:18:05 <heat> The kernel only touches that when inside a spinlock
10:18:12 <heat> so you'd need pretty sick timing
10:18:26 <doug16k> exploits are pretty sick, by definition :)
10:18:54 <heat> But doing that perfectly, every ms, is a bit too much isn't it?
10:19:29 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
10:19:30 <doug16k> I'm not saying "therefore your approach is crap", just pointing out an avenue of attack that it makes possible
10:20:08 <heat> yeah
10:20:19 <doug16k> your approach has advantages too, like minimizing hardware IRQ latencies
10:20:22 <heat> I mean, if Linux uses it, it must not be bad
10:21:06 --- quit: masoudd (Ping timeout: 260 seconds)
10:21:18 <heat> So, preemptions inside the scheduler should a big no-no?
10:21:31 <heat> Because it definitely seems like it
10:21:48 <doug16k> if they happen part way through a state change, definitely
10:22:32 --- join: Tobba (~Tobba@h-25-157.A159.priv.bahnhof.se) joined #osdev
10:22:37 <doug16k> heat, you leave interrupts disabled while holding a spinlock?
10:22:41 <doug16k> enabled*
10:22:51 <heat> Yeah
10:22:52 --- join: baschdel (~baschdel@2a01:5c0:1c:6201:bb0:858:a281:6ed8) joined #osdev
10:22:58 <heat> interrupts enabled, preemptions disabled
10:25:18 --- quit: quc (Ping timeout: 240 seconds)
10:27:07 <doug16k> if you check that flag early enough in your scheduling IRQ, then it should be okay even if it occurs part way through a state change
10:27:41 <doug16k> is that check absolutely step 1 in your scheduling ISR?
10:29:30 <heat> It's the first thing to happen inside sched_switch_thread() (which is called by the timer's irq handler, after making sure the thread's quantum is over and all that)
10:30:02 <heat> I should change that code a bit though
10:30:35 --- join: rafaeldelucena (~rafaeldel@2804:14d:ba83:2709:e558:1954:5c74:24ee) joined #osdev
10:31:06 --- quit: Beato (Quit: Bye!)
10:31:22 --- join: Beato (zingmars@unaffiliated/beato) joined #osdev
10:31:40 <doug16k> if you do it after checking the quantum, then isn't there a race between updating that and the scheduling ISR?
10:31:41 --- join: masoudd (~masoudd@5.116.17.229) joined #osdev
10:32:02 <heat> then if it's not set, I switch the thread by going through the current cpu's priority lists(starting from the top), acquiring each list's lock so I'm 100% sure that the other cpus aren't modifying the list
10:32:14 <heat> doug16k: Updating what?
10:32:24 <doug16k> updating the data that keeps track of quantums
10:32:54 <heat> How is there a race if that's all per-cpu data?
10:32:59 <doug16k> say, scheduling IRQ occurs half way through updating that data, ISR checks it
10:33:25 --- join: light2yellow (~l2y@217.30.64.102) joined #osdev
10:33:35 <heat> I don't have interrupts enabled inside IRQs
10:33:58 <heat> or the sched_yield ISR, for that matter
10:33:59 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
10:34:41 <doug16k> let's say the foreground execution is in the middle of updating the quantum-tracking data. then part way through, scheduling IRQ occurs. beginning of scheduling ISR checks partially-updated quantum data
10:34:51 <doug16k> it could be a harmless race, but it's there
10:35:22 <heat> Thread quantums are only updated inside each CPU's IRQ handler
10:35:32 <doug16k> oh ok
10:35:38 <doug16k> now I see what you meant
10:35:41 --- quit: Beato (Client Quit)
10:35:54 <heat> It seems like the most practical option
10:35:56 --- join: Beato (zingmars@unaffiliated/beato) joined #osdev
10:37:52 --- quit: Beato (Client Quit)
10:39:03 --- join: Beato (Beato@unaffiliated/beato) joined #osdev
10:39:04 --- quit: user10032 (Quit: Leaving)
10:39:22 --- join: Vulcan (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
10:42:51 --- quit: masoudd (Ping timeout: 260 seconds)
10:43:48 --- quit: Vulcan (Ping timeout: 240 seconds)
10:44:56 <heat> I think I found another nasty bug: I disable preemption after grabbing the lock, not before, so there could be a race condition between grabbing the lock and disabling ints
10:45:12 <heat> s/ints/preemption/
10:46:25 --- join: Deknos (~somenym@unaffiliated/menace) joined #osdev
10:48:09 --- quit: Beato (Quit: Bye!)
10:48:56 --- join: Beato (Beato@unaffiliated/beato) joined #osdev
10:50:28 <doug16k> yes
10:51:24 <doug16k> I had that lock in my AHCI driver. AHCI IRQ occured while holding the port lock on the port that had a completion. ISR deadlocked trying to acquire same port lock
10:51:34 --- part: Deknos left #osdev
10:52:00 <doug16k> had that bug*
10:55:21 --- quit: Goplat (Remote host closed the connection)
10:56:19 --- quit: trout (Quit: /dev/null is full)
10:57:42 --- quit: alphawarrior (Quit: Leaving)
10:59:53 --- join: palk (~palk@unaffiliated/palk) joined #osdev
11:06:14 --- quit: promach_ (Ping timeout: 248 seconds)
11:09:22 --- quit: jakogut (Quit: jakogut)
11:09:33 --- join: jakogut (~jakogut@162.251.69.147) joined #osdev
11:09:39 --- quit: crgimenes (Quit: crgimenes)
11:10:07 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
11:11:39 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
11:14:01 --- quit: jakogut (Client Quit)
11:14:05 --- quit: light2yellow (Quit: light2yellow)
11:14:14 --- join: jakogut (~jakogut@162.251.69.147) joined #osdev
11:15:03 --- quit: crgimenes (Client Quit)
11:18:46 --- join: AverageJ0e (~joe@ip72-222-140-99.ph.ph.cox.net) joined #osdev
11:19:48 --- quit: ingrix (Ping timeout: 240 seconds)
11:22:34 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
11:24:47 --- quit: heat (Ping timeout: 255 seconds)
11:28:29 --- quit: rawste (Quit: Sleep....)
11:29:09 --- join: rawste (~rawste@static-176-182-199-171.ncc.abo.bbox.fr) joined #osdev
11:29:16 --- quit: rawste (Client Quit)
11:40:58 --- quit: tadni (Remote host closed the connection)
11:42:50 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
11:45:48 --- quit: spare (Quit: leaving)
11:46:08 --- quit: variable (Ping timeout: 265 seconds)
11:46:48 --- join: bm371613 (~bartek@2a02:a317:603f:9800:3d21:d4ea:8e13:962a) joined #osdev
11:55:35 <buhman> I'm trying to understand this alias magic https://ptpb.pw/GI9b ; shouldn't gcc let me redefine this function?
11:55:59 --- join: blackandblue (~batdownh@gateway/tor-sasl/blackandblue) joined #osdev
11:57:32 <buhman> ahh; it needs to be a different translation unit
11:57:34 <buhman> compilers are magic
12:01:31 <palk> s/magic/programs/
12:04:42 --- quit: navidr (Quit: Connection closed for inactivity)
12:14:00 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
12:17:07 --- quit: trout (Ping timeout: 260 seconds)
12:18:32 --- quit: SopaXorzTaker (Remote host closed the connection)
12:23:57 --- quit: pie__ (Remote host closed the connection)
12:24:18 --- join: pie__ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
12:29:32 --- join: rawste (~rawste@static-176-182-199-171.ncc.abo.bbox.fr) joined #osdev
12:30:07 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
12:30:53 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
12:34:08 --- quit: blackandblue (Remote host closed the connection)
12:34:57 --- join: quc (~quc@host-89-230-171-185.dynamic.mm.pl) joined #osdev
12:40:02 --- quit: crgimenes (Quit: crgimenes)
12:44:57 --- quit: andrei-n (Read error: Connection reset by peer)
12:45:50 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
12:46:18 --- join: andrei-n (~andrei@208.8-64-87.adsl-dyn.isp.belgacom.be) joined #osdev
12:48:57 --- quit: variable (Ping timeout: 255 seconds)
12:49:18 --- join: masoudd (~masoudd@5.116.17.229) joined #osdev
12:51:39 --- quit: angel0xff (Read error: Connection reset by peer)
12:59:10 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
13:11:12 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
13:14:46 --- quit: andrei-n (Ping timeout: 248 seconds)
13:16:53 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
13:20:07 --- quit: trout (Ping timeout: 260 seconds)
13:21:07 --- quit: banisterfiend (Ping timeout: 264 seconds)
13:23:09 --- quit: graphene (Remote host closed the connection)
13:24:41 --- join: graphene (~graphene@46.101.134.251) joined #osdev
13:28:34 --- join: angel0xff (~anton@158-58-227-127.sf.ddns.bulsat.com) joined #osdev
13:29:40 --- quit: nwm (Ping timeout: 256 seconds)
13:32:38 --- quit: rawste (Quit: Sleep....)
13:37:08 --- join: zeus1 (~zeus@154.225.245.73) joined #osdev
13:39:29 --- quit: angel0xff (Quit: Ex-Chat)
13:41:31 --- join: angel0xff (~quassel@158-58-227-127.sf.ddns.bulsat.com) joined #osdev
13:43:07 --- join: bluezinc (~bluezinc@unaffiliated/bluezinc) joined #osdev
13:45:10 --- quit: bluezinc (Client Quit)
13:45:28 --- join: bluezinc (~bluezinc@unaffiliated/bluezinc) joined #osdev
13:45:42 --- join: gareppa (~gareppa@unaffiliated/gareppa) joined #osdev
13:46:53 --- quit: gareppa (Remote host closed the connection)
13:48:11 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
13:48:36 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
13:49:17 --- quit: jakogut (Quit: jakogut)
13:49:28 --- join: jakogut (~jakogut@162.251.69.147) joined #osdev
13:51:58 --- quit: M1cha (Ping timeout: 256 seconds)
13:52:06 <doug16k> it's fun to watch `sudo perf top` when doing a big build. processor spends more time clearing pages and acpi sleeping than compiling
13:52:23 --- quit: variable (Ping timeout: 276 seconds)
13:53:24 <doug16k> and when it's pegged on all 16 processors, spends more time allocating heap than anything in gcc
13:54:02 --- quit: jakogut (Client Quit)
13:54:14 --- join: jakogut (~jakogut@162.251.69.147) joined #osdev
13:56:16 --- quit: [PathFinder] (Quit: dropping the doubt is unpolite.)
13:57:10 <doug16k> I should look into making gcc use tcmalloc. the time it spends in heap allocations is ridiculous
14:01:20 --- quit: sortie (Quit: Leaving)
14:01:44 --- quit: palk ()
14:04:31 --- quit: zeus1 (Ping timeout: 260 seconds)
14:07:09 --- quit: graphene (Remote host closed the connection)
14:08:38 --- join: graphene (~graphene@46.101.134.251) joined #osdev
14:14:21 --- quit: rafaeldelucena (Ping timeout: 245 seconds)
14:15:16 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
14:15:47 <mischief> doug16k: nahh just switch it to brk
14:18:08 --- quit: graphene (Remote host closed the connection)
14:18:36 --- join: zeus1 (~zeus@154.225.160.250) joined #osdev
14:19:37 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
14:19:38 --- join: graphene (~graphene@46.101.134.251) joined #osdev
14:19:49 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
14:21:23 --- quit: drakonis (Read error: Connection reset by peer)
14:22:38 --- quit: trout (Ping timeout: 245 seconds)
14:30:56 --- join: [Mururoa] (~while@unaffiliated/awaxx/x-0928682) joined #osdev
14:31:24 --- quit: sortie (Quit: Leaving)
14:32:33 --- join: macdonag2 (~macdonag2@cpc110673-lewi19-2-0-cust478.2-4.cable.virginm.net) joined #osdev
14:34:58 --- quit: MarcinWieczorek_ (Read error: Connection reset by peer)
14:35:24 --- join: MarcinWieczorek_ (~MarcinWie@2a00:f41:1c08:9b5e:4025:7f4d:fc6b:148c) joined #osdev
14:38:11 --- join: SwiftMatt (~Objective@2601:282:4300:3e:74c8:6ef3:c940:1afa) joined #osdev
14:42:17 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
14:44:05 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
14:46:26 --- quit: sh3iny (Remote host closed the connection)
14:46:45 --- join: sh3iny (~mike@gateway/tor-sasl/sh3iny) joined #osdev
14:46:55 --- quit: zeus1 (Ping timeout: 264 seconds)
14:50:02 --- quit: macdonag2 (Quit: macdonag2)
14:51:36 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
14:54:09 --- quit: variable (Ping timeout: 265 seconds)
14:54:20 --- quit: bm371613 (Quit: Konversation terminated!)
15:02:54 --- join: nwm (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
15:03:02 --- quit: masoudd (Ping timeout: 255 seconds)
15:03:14 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
15:03:27 --- quit: drakonis (Read error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number)
15:03:55 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
15:04:25 --- quit: dennis95 (Quit: Leaving)
15:05:07 --- quit: baschdel (Ping timeout: 260 seconds)
15:09:08 --- quit: robert_ (Ping timeout: 265 seconds)
15:11:12 --- quit: jakogut (Read error: Connection reset by peer)
15:11:24 --- join: jakogut (~jakogut@162.251.69.147) joined #osdev
15:15:41 --- quit: Kimundi_ (Ping timeout: 260 seconds)
15:17:26 --- quit: jakogut (Ping timeout: 240 seconds)
15:17:27 --- quit: gattuso (Remote host closed the connection)
15:18:31 --- join: gattuso (~gattuso@pompel.me) joined #osdev
15:18:40 --- quit: MarcinWieczorek_ (Quit: WeeChat 2.1)
15:19:32 --- join: Goplat (~goplat@reactos/developer/Goplat) joined #osdev
15:19:48 --- join: Vulcan (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
15:20:42 --- join: epony (~nym@77-85-141-166.ip.btc-net.bg) joined #osdev
15:22:46 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
15:26:26 --- quit: trout (Ping timeout: 255 seconds)
15:27:14 --- join: palk (~palk@unaffiliated/palk) joined #osdev
15:27:34 --- quit: Shamar (Quit: Lost terminal)
15:29:18 --- quit: quc (Ping timeout: 245 seconds)
15:29:30 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
15:30:32 --- quit: alyptik (Quit: https://ptpb.pw/~docrivers.gif)
15:31:55 --- quit: bemeurer (Ping timeout: 264 seconds)
15:33:22 --- quit: Vulcan (Remote host closed the connection)
15:33:50 --- join: alyptik (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
15:34:12 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
15:43:26 --- quit: bemeurer (Ping timeout: 240 seconds)
15:45:53 --- quit: Asu (Quit: Konversation terminated!)
15:46:27 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
15:54:22 --- quit: heat (Read error: Connection reset by peer)
15:54:51 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
15:58:29 --- quit: variable (Ping timeout: 276 seconds)
16:02:13 --- join: dbittman_ (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
16:03:56 --- quit: sortie (Quit: Leaving)
16:05:11 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
16:05:35 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
16:11:51 --- quit: angel0xff (Ping timeout: 268 seconds)
16:17:31 --- quit: korans (Ping timeout: 260 seconds)
16:17:51 --- join: eremitah_ (~int@unaffiliated/eremitah) joined #osdev
16:19:08 --- quit: graphene (Remote host closed the connection)
16:19:21 <doug16k> I got rid of all of the statically sized stuff in my drivers. have 50,000 nvme drives and 18,000 AHCI controllers? no problem
16:20:00 <bcos> ..except maybe IRQ sharing..
16:20:08 <bcos> ;-)
16:20:34 --- join: graphene (~graphene@46.101.134.251) joined #osdev
16:20:34 <doug16k> I support IRQ sharing. it will make the IRQ handler check a lot of interfaces though :)
16:20:36 <jjuran> 655360 drives should be enough for anybody
16:21:26 --- quit: eremitah (Ping timeout: 240 seconds)
16:21:26 --- nick: eremitah_ -> eremitah
16:21:36 <doug16k> bcos, ah thanks. forgot to make IRQ handler list unlimited
16:22:25 <doug16k> jjuran, amen
16:24:06 <doug16k> ah wait. it sort of is unlimited. if you register the same ISR 1000 times it just refcounts the one entry
16:24:41 <doug16k> I could make it handle an unlimited number of unique ISRs though
16:24:47 --- join: immibis (~chatzilla@222-155-163-212-fibre.sparkbb.co.nz) joined #osdev
16:26:33 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
16:28:19 <variable> welp
16:28:23 <variable> my ThreadRipper 1050X died
16:28:38 <doug16k> died?
16:29:13 <variable> yeah
16:29:22 <variable> about a week ago it turned itself off
16:29:27 <variable> and the mobo won't get past POST
16:29:33 <variable> I'm RMAing it
16:29:46 --- quit: trout (Ping timeout: 245 seconds)
16:30:48 <doug16k> it could be lots of things though. did you try lots of things?
16:31:16 <doug16k> the chance of the issue being the CPU is almost nil
16:31:19 <variable> I brought it to a computer repair place
16:31:30 <variable> since my time is more valuable, and I don't have any other parts to test
16:32:15 <variable> they have tools to test grounding, etc.
16:32:22 <variable> doug16k: what's interesting is that the mobo powers on
16:32:26 <variable> it just does *nothing*
16:32:46 <variable> the "Dr Debug" feature shows nothing (replacement for beeps)
16:32:52 <variable> it doesn't post the fans don't spin
16:32:58 <variable> but the lights turn on
16:33:59 <variable> I anyways
16:34:09 <variable> I'm off to waste my highly valuable time playing board games
16:34:51 <NightBlade> i hate no-post situations
16:35:27 <variable> worst case scenario: I RMA the parts, install new ones, it doesn't work, and I'm back to square zero
16:36:02 <NightBlade> were you able to try with a different powersource?
16:36:15 <NightBlade> i find supplies are the quickest components to break
16:36:19 <variable> different PSU? or different wall socket ?
16:36:24 <NightBlade> PSU
16:36:28 <variable> I assume the computer repair people tested the PSU
16:36:37 <variable> if not, I'll poke them
16:36:42 <NightBlade> should be the first thing they do
16:36:50 <variable> yeah, I think they went further
16:36:55 <variable> they have an oscilliiscope
16:37:00 <variable> and voltage meter
16:37:09 <variable> so they actually tested that the mobo was getting the power it was supposed
16:37:20 <NightBlade> yeah, they would have tested the quality of the power then
16:37:31 <variable> sure
16:37:40 <variable> lets see what happens next
16:37:45 <variable> worst case, I have to get a new PSU
16:37:50 <NightBlade> probably a blown zener diode, my money's on that
16:37:52 <variable> (and I now have a brand new mobo and CPU :))
16:38:21 <NightBlade> its not able to hold a pin at a minimal voltage
16:38:34 <NightBlade> that would mess with POST bigtime
16:39:37 <variable> the PSU has a 10 yr Warranty
16:39:44 <NightBlade> wow
16:39:47 <variable> so if the replacement parts don't work, I'll do that next
16:45:00 --- join: quc (~quc@host-89-230-167-225.dynamic.mm.pl) joined #osdev
16:48:01 --- join: iknosis (~iknosis@185.183.104.140) joined #osdev
16:49:54 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
16:58:10 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
17:01:45 --- quit: variable (Ping timeout: 265 seconds)
17:20:29 --- quit: xenos1984 (Quit: Leaving.)
17:30:21 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
17:33:06 --- quit: trout (Ping timeout: 245 seconds)
17:33:51 --- join: klysm (~mdasoh@173-14-238-113-Utah.hfc.comcastbusiness.net) joined #osdev
17:34:11 --- join: Vulcan (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
17:36:11 --- join: promach_ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
17:39:25 --- quit: Vulcan (Ping timeout: 268 seconds)
17:40:20 --- join: hph^ (~hph@ip72-195-187-57.mc.at.cox.net) joined #osdev
17:45:33 --- quit: Goplat ()
17:50:55 --- quit: epony (Quit: QUIT)
17:52:50 --- quit: spare (Quit: leaving)
17:57:01 --- quit: stephen77 (Ping timeout: 256 seconds)
18:01:43 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
18:01:47 --- quit: graphene (Remote host closed the connection)
18:02:46 --- quit: crgimenes (Quit: crgimenes)
18:03:13 --- join: graphene (~graphene@46.101.134.251) joined #osdev
18:04:13 --- join: stephen77 (~stephen@142.134.91.153) joined #osdev
18:04:19 --- quit: variable (Ping timeout: 260 seconds)
18:24:48 --- quit: JusticeEX (Ping timeout: 240 seconds)
18:31:03 --- join: epony (~nym@77-85-141-166.ip.btc-net.bg) joined #osdev
18:32:38 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
18:35:33 --- quit: trout (Ping timeout: 256 seconds)
18:37:54 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
18:42:29 --- quit: graphene (Remote host closed the connection)
18:42:52 --- join: Goplat (~goplat@reactos/developer/Goplat) joined #osdev
18:43:59 --- join: graphene (~graphene@46.101.134.251) joined #osdev
18:50:24 --- quit: miselin (Ping timeout: 256 seconds)
18:53:09 --- quit: graphene (Remote host closed the connection)
18:54:41 --- join: graphene (~graphene@46.101.134.251) joined #osdev
19:02:55 --- quit: mavhq (Read error: Connection reset by peer)
19:04:11 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
19:04:17 --- join: miselin (~miselin@115.0.198.104.bc.googleusercontent.com) joined #osdev
19:04:17 --- quit: miselin (Changing host)
19:04:17 --- join: miselin (~miselin@pdpc/supporter/student/pcmattman) joined #osdev
19:04:18 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
19:06:26 --- quit: nwm (Ping timeout: 240 seconds)
19:07:47 --- quit: variable (Ping timeout: 260 seconds)
19:09:00 --- join: nwm (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
19:17:34 --- quit: stephen77 (Ping timeout: 265 seconds)
19:29:16 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-zpeqrendmlumvufs) joined #osdev
19:33:23 --- quit: tacco| ()
19:34:02 --- join: Vulcan (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
19:35:46 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
19:36:30 --- quit: jjuran (Quit: jjuran)
19:38:46 --- quit: Vulcan (Ping timeout: 260 seconds)
19:39:24 --- quit: trout (Ping timeout: 276 seconds)
19:42:28 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
19:47:51 --- quit: JusticeEX (Ping timeout: 244 seconds)
19:52:10 --- quit: crgimenes (Quit: crgimenes)
19:52:49 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
19:55:57 --- quit: crgimenes (Client Quit)
19:56:18 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
19:57:56 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
19:58:21 --- join: jjuran (~jjuran@172.58.185.240) joined #osdev
20:07:44 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
20:08:57 --- quit: crgimenes (Quit: crgimenes)
20:09:39 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
20:10:37 --- quit: nj0rd (Ping timeout: 256 seconds)
20:11:07 --- quit: vdamewood (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
20:11:13 --- quit: variable (Ping timeout: 265 seconds)
20:15:59 --- join: drakonis_ (~drakonis@unaffiliated/drakonis) joined #osdev
20:16:44 --- quit: crgimenes (Quit: crgimenes)
20:17:09 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
20:24:17 --- join: nj0rd (~nj0rd@200116b845946f000be9b5b217cd0bd6.dip.versatel-1u1.de) joined #osdev
20:25:16 --- quit: zaquest (Remote host closed the connection)
20:26:53 --- quit: crgimenes (Quit: crgimenes)
20:27:21 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
20:29:24 --- quit: jjuran (Quit: jjuran)
20:38:49 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
20:42:03 --- quit: trout (Ping timeout: 260 seconds)
20:43:51 --- quit: graphene (Remote host closed the connection)
20:45:20 --- join: graphene (~graphene@46.101.134.251) joined #osdev
20:48:05 --- join: ekohandel (~ekohandel@S0106f8e903c814df.vc.shawcable.net) joined #osdev
20:48:47 --- part: ekohandel left #osdev
20:50:17 --- quit: crgimenes (Quit: crgimenes)
20:50:48 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
21:00:32 --- join: zeus1 (~zeus@154.225.160.250) joined #osdev
21:06:59 --- join: zaquest (~notzaques@5.128.210.30) joined #osdev
21:08:01 --- quit: bemeurer (Ping timeout: 260 seconds)
21:10:32 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
21:12:13 --- quit: crgimenes (Quit: crgimenes)
21:13:16 --- quit: freakazoid0223 (Ping timeout: 260 seconds)
21:13:38 --- quit: variable (Ping timeout: 276 seconds)
21:20:30 --- join: M1cha (~M1cha@2a02:908:5a3:da80:7a8d:2699:26c0:ba14) joined #osdev
21:23:08 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
21:25:59 --- quit: promach_ (Quit: WeeChat 2.1)
21:41:29 --- join: jjuran (~jjuran@c-73-132-80-121.hsd1.md.comcast.net) joined #osdev
21:41:56 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
21:42:18 --- quit: doug16k (Remote host closed the connection)
21:44:35 --- quit: trout (Ping timeout: 260 seconds)
21:52:47 --- join: doug16k (~dougx@172-97-186-251.cpe.distributel.net) joined #osdev
21:52:56 --- join: andrei-n (~andrei@208.8-64-87.adsl-dyn.isp.belgacom.be) joined #osdev
22:12:13 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
22:12:43 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
22:13:14 --- join: stephen77 (~stephen@142.134.91.153) joined #osdev
22:16:41 --- quit: variable (Ping timeout: 276 seconds)
22:17:21 --- join: robert_ (~hellspawn@173.171.214.167) joined #osdev
22:17:22 --- quit: robert_ (Changing host)
22:17:22 --- join: robert_ (~hellspawn@objectx/robert) joined #osdev
22:17:53 --- quit: NightBlade ()
22:23:31 --- quit: zeus1 (Ping timeout: 264 seconds)
22:36:09 --- join: drakonis__ (~drakonis@unaffiliated/drakonis) joined #osdev
22:36:42 --- quit: behalebabo (Excess Flood)
22:36:42 --- quit: drakonis_ (Remote host closed the connection)
22:36:43 --- quit: drakonis (Read error: Connection reset by peer)
22:37:28 --- join: behalebabo (~behalebab@unaffiliated/behalebabo) joined #osdev
22:39:11 --- quit: mavhq (Read error: Connection reset by peer)
22:40:26 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
22:44:31 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
22:47:26 --- quit: trout (Ping timeout: 255 seconds)
22:48:50 --- quit: graphene (Remote host closed the connection)
22:50:18 --- join: graphene (~graphene@46.101.134.251) joined #osdev
23:08:55 --- join: palk_ (~palk@unaffiliated/palk) joined #osdev
23:09:02 --- quit: palk (Remote host closed the connection)
23:09:10 --- quit: Naergon (Remote host closed the connection)
23:10:35 --- join: palk (~palk@unaffiliated/palk) joined #osdev
23:13:43 --- quit: dbittman_ (Ping timeout: 260 seconds)
23:13:55 --- quit: palk_ (Ping timeout: 264 seconds)
23:15:38 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
23:19:05 --- quit: variable (Ping timeout: 276 seconds)
23:21:17 --- join: antkit (uid256318@gateway/web/irccloud.com/x-ccdvrlimborlbqus) joined #osdev
23:29:08 --- join: angel0xff (~quassel@158-58-227-127.sf.ddns.bulsat.com) joined #osdev
23:35:20 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
23:36:50 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
23:38:22 --- join: Vulcan (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
23:47:01 --- join: NightBlade (~user@ip-173-247-149-50.user.start.ca) joined #osdev
23:47:50 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
23:49:04 --- quit: Goplat ()
23:51:08 --- quit: trout (Ping timeout: 265 seconds)
23:54:04 --- quit: Burgundy (Remote host closed the connection)
23:58:57 --- join: zeus1 (~zeus@197.239.5.110) joined #osdev
23:59:59 --- log: ended osdev/18.07.07