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=3

Tuesday, 3 July 2018

00:00:00 --- log: started osdev/18.07.03
00:02:19 --- quit: cirno_ (Remote host closed the connection)
00:03:02 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
00:06:48 --- quit: manzerbredes (Quit: WeeChat 2.1)
00:07:16 --- join: manzerbredes (~loic@myriads-lg.irisa.fr) joined #osdev
00:07:44 --- quit: zeus1 (Ping timeout: 268 seconds)
00:11:16 --- quit: manzerbredes (Client Quit)
00:12:37 --- join: manzerbredes (~loic@myriads-lg.irisa.fr) joined #osdev
00:12:54 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
00:13:49 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
00:15:12 --- quit: variable (Ping timeout: 255 seconds)
00:16:57 --- quit: manzerbredes (Client Quit)
00:17:17 --- join: manzerbredes (~loic@myriads-lg.irisa.fr) joined #osdev
00:20:12 --- quit: manzerbredes (Client Quit)
00:22:11 --- join: manzerbredes (~loic@myriads-lg.irisa.fr) joined #osdev
00:22:48 --- join: sixand1 (~Thunderbi@39.130.66.242) joined #osdev
00:24:18 --- quit: sixand (Ping timeout: 245 seconds)
00:24:18 --- nick: sixand1 -> sixand
00:28:20 --- join: tmk (~shams@117.205.143.90) joined #osdev
00:30:01 --- quit: tmk (Client Quit)
00:31:02 --- quit: prokbird (Ping timeout: 265 seconds)
00:32:18 --- quit: cirno_ (Remote host closed the connection)
00:32:40 --- quit: Avinash (Quit: Textual IRC Client: www.textualapp.com)
00:33:20 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
00:36:56 --- quit: bemeurer (Quit: WeeChat 2.1)
00:39:43 --- join: Love4Boobies (~L4B@unaffiliated/l4b) joined #osdev
00:41:06 --- quit: sixand (Quit: sixand)
00:44:20 --- join: Asu (~sdelang@9.202.154.77.rev.sfr.net) joined #osdev
00:44:55 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
00:47:28 --- quit: trout (Ping timeout: 265 seconds)
00:56:59 --- quit: celadon (Quit: ZNC 1.7.0+deb1+b1 - https://znc.in)
01:01:34 --- join: celadon (~celadon@66.157-14-84.ripe.coltfrance.com) joined #osdev
01:02:17 --- quit: cirno_ (Remote host closed the connection)
01:03:07 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
01:05:44 --- quit: Sjors (Ping timeout: 276 seconds)
01:06:02 --- quit: celadon (Ping timeout: 256 seconds)
01:13:20 --- join: Sjors (~quassel@bulbasaur.sjorsgielen.nl) joined #osdev
01:13:23 --- quit: Peetz0r (Ping timeout: 260 seconds)
01:13:57 --- join: msh3iny (~mike@gateway/tor-sasl/sh3iny) joined #osdev
01:14:52 --- quit: sh3iny (Ping timeout: 250 seconds)
01:15:07 --- quit: lucebac (Ping timeout: 264 seconds)
01:15:08 --- quit: AnyTimeTraveler (Ping timeout: 264 seconds)
01:15:08 --- quit: mfrsn (Ping timeout: 264 seconds)
01:15:17 --- join: lucebac (~lucebac@lucebac.net) joined #osdev
01:15:19 --- quit: lucebac (Changing host)
01:15:19 --- join: lucebac (~lucebac@unaffiliated/lucebac) joined #osdev
01:16:16 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
01:16:40 --- join: mfrsn (~mfrsn@unaffiliated/mfrsn) joined #osdev
01:16:56 --- join: AnyTimeTraveler (~quassel@titan-systems.net) joined #osdev
01:19:06 --- quit: variable (Ping timeout: 255 seconds)
01:19:29 --- join: Peetz0r (~Peetz0r@217-19-26-76.dsl.cambrium.nl) joined #osdev
01:21:54 --- quit: mavhq (Read error: Connection reset by peer)
01:22:58 --- quit: _mjg_ (Ping timeout: 268 seconds)
01:23:08 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
01:23:36 --- quit: NaNkeen (Ping timeout: 256 seconds)
01:24:19 --- join: NaNkeen (~nankeen@61.6.126.158) joined #osdev
01:26:40 --- quit: dhoelzer (Ping timeout: 268 seconds)
01:32:19 --- quit: cirno_ (Remote host closed the connection)
01:32:59 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
01:37:49 --- quit: NaNkeen (Ping timeout: 240 seconds)
01:38:26 --- quit: Goplat (Remote host closed the connection)
01:42:45 --- join: kimundi (~Kimundi@i577A96B4.versanet.de) joined #osdev
01:43:31 --- quit: hmmmmmm (Remote host closed the connection)
01:43:55 --- join: NaNkeen (~nankeen@61.6.126.158) joined #osdev
01:44:00 --- nick: vaibhav|gone -> vaibhav
01:44:34 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
01:44:53 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
01:47:54 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
01:50:35 --- quit: trout (Ping timeout: 276 seconds)
02:02:23 --- quit: cirno_ (Remote host closed the connection)
02:02:33 <doug16k> function trace now indicating nesting with indentation :) -> https://gist.github.com/doug65536/53321611c78a1abf279964d332b1a337
02:02:34 <bslsk05> ​gist.github.com: gist:53321611c78a1abf279964d332b1a337 · GitHub
02:02:49 --- quit: manzerbredes (Quit: WeeChat 2.1)
02:02:56 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
02:03:14 --- join: manzerbredes (~loic@myriads-lg.irisa.fr) joined #osdev
02:03:51 <klange> doug16k: neat
02:04:54 --- join: celadon (~celadon@66.157-14-84.ripe.coltfrance.com) joined #osdev
02:05:04 --- quit: manzerbredes (Client Quit)
02:05:29 --- join: manzerbredes (~loic@myriads-lg.irisa.fr) joined #osdev
02:07:42 --- join: Guest4630 (4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72) joined #osdev
02:10:08 <doug16k> c: t: and I: indicate the cpu number, thread id, and EFLAGS.IF at that moment
02:10:42 <doug16k> I want to do an ncurses UI so I can cursor left to collapse a call, cursor right to expand, ctrl-left/ctrl-right to expand/collapse that function everywhere
02:15:52 <doug16k> I manged to squeeze it down to 8 bytes per record, but later realized if I stop the trace-log tool and restart it, it won't necessarily start reading at the beginning of a packet, so I expanded it to 9 bytes and added a sync field. it throws away 1 byte from the start until the first record's sync field is 0x55
02:16:40 --- join: elevated (~elevated@gateway/tor-sasl/elevated) joined #osdev
02:19:03 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
02:22:03 --- quit: variable (Ping timeout: 260 seconds)
02:22:27 --- quit: cirno_ (Quit: WeeChat 2.1)
02:40:41 --- join: abramovich (~abramovic@gateway/tor-sasl/abramovich) joined #osdev
02:48:49 --- quit: Guest4630 (Ping timeout: 240 seconds)
02:50:42 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
02:54:12 --- quit: trout (Ping timeout: 276 seconds)
03:01:30 --- join: prokbird (~shams@103.195.234.115) joined #osdev
03:02:48 --- join: glauxosdever (~alex@athedsl-4564586.home.otenet.gr) joined #osdev
03:03:44 <promach> For https://kristerw.blogspot.com/2017/03/the-cost-of-conditional-moves-and.html , why the conditional move code example take twice the time to execute compared to the version using a branch ?
03:03:45 <bslsk05> ​kristerw.blogspot.com: Krister Walfridsson’s blog: The cost of conditional moves and branches
03:08:55 <doug16k> promach, code that is doing almost nothing will exaggerate minute differences in decode and dispatch
03:09:58 <doug16k> the branch in the trivial test case is 100% predictable so it totally hides how much time would have been saved by conditional moves
03:10:31 <doug16k> the conditional move version is issuing an additional operation, and doesn't benefit from microop fusion of compare and branch
03:11:12 --- quit: Sjors (Ping timeout: 240 seconds)
03:11:47 <doug16k> microbenchmarks are misleading. something that is true in a microbenchmark is likely to be completely false in real cases
03:11:52 <promach> additional operation ? you mean movl and cmovg ?
03:12:21 <doug16k> the cmovg. movl is basically free
03:12:46 <promach> why only cmovg ?
03:12:58 --- quit: void_sec3301 (Ping timeout: 256 seconds)
03:13:12 <promach> I suppose both also implies some sort of memory relocation ?
03:13:19 <doug16k> it's the only additional operation that actually has to go through an integer pipeline. movl is done earlier in the pipeline, by renaming
03:13:48 <promach> register renaming
03:13:52 <doug16k> yes
03:14:31 <doug16k> movl reg,reg I mean
03:14:44 <promach> why can't cmovg use register renaming mechanism as well ?
03:14:55 <doug16k> it does, but it isn't ONLY a rename
03:15:05 <promach> huh?
03:15:41 <doug16k> cmov actually executes in an integer pipeline. mov reg,reg doesn't
03:16:17 <promach> cmovg -> move if greater than
03:16:22 <promach> so it needs the ALU
03:16:28 <promach> I get it now
03:16:28 <doug16k> not exactly
03:16:32 <promach> doug16k: thanks
03:16:36 <promach> huh ?
03:17:06 <doug16k> cmovg %edx, %eax <-- means, if the flags say it is greater, copy eax to edx, otherwise, copy edx to edx
03:17:25 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
03:17:41 <promach> which flag ?
03:17:42 --- quit: Mikaku (Ping timeout: 240 seconds)
03:17:42 --- quit: lecx (Ping timeout: 240 seconds)
03:17:47 <doug16k> basically it's a mux that selects the source or destination, the mux is controlled by the flag comparison. the output of the mux is the result
03:18:02 <promach> flag comparison still needs ALU, right ?
03:18:31 --- quit: goncalo (Ping timeout: 260 seconds)
03:18:52 <doug16k> intel didn't send me the source code, can't tell you
03:18:54 <doug16k> but probably
03:18:59 --- quit: yrlf (Ping timeout: 276 seconds)
03:19:04 <promach> ok
03:19:14 <promach> but movl does not need ALU
03:19:33 <glauxosdever> Elronnd: I am making my own bootloader currently. What do you need help with?
03:19:37 <doug16k> right, movl reg reg will just rename the destination to point to the same register as the source
03:21:00 --- join: Sjors (~quassel@bulbasaur.sjorsgielen.nl) joined #osdev
03:21:19 --- quit: NaNkeen (Ping timeout: 260 seconds)
03:21:37 <doug16k> promach, every time you store a result to a register, it allocates a new (internal) register for it, and renames the destination register name to point to the newly allocated (internal) register
03:21:49 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
03:23:38 <promach> yes
03:23:40 <doug16k> promach, 1) movl eax,42 2) mov ebx,eax 3) add eax,2 <-- allocates a new register (r17), initializes it with 42, points eax to r17. points ebx to r17. reads eax, adds 2, allocates a new register (r18), stores 44 to r18, points eax to r18
03:24:10 --- quit: emerson (*.net *.split)
03:24:11 --- quit: islandsparky_ (*.net *.split)
03:24:11 --- quit: kingoffrance (*.net *.split)
03:24:57 <doug16k> s/movl/mov (I'm using intel syntax above)
03:25:03 --- quit: variable (Ping timeout: 260 seconds)
03:25:40 --- join: shymega (~shymega@torbaytechjam/shymega) joined #osdev
03:26:05 <promach> ok
03:26:33 <promach> so, add eax,2 also uses register renaming to point to a different register than eax ?
03:26:38 <doug16k> right
03:26:45 <promach> what if we want to add 2 to eax itself ?
03:26:55 <doug16k> there is no "eax itself"
03:27:00 <promach> ??
03:27:08 <promach> I see
03:27:12 <doug16k> at any point in the program, the programmer visible registers are strewn across the internal registers
03:27:44 <doug16k> when it has to flush/restart, it puts the names back to what they were at the last retired instruction, instantly undoing all the speculated wrong stuff
03:28:28 <promach> pipeline flush
03:28:41 <doug16k> yes. typically a mispredict but it can be an exception
03:29:01 <doug16k> it might not notice that something was a page fault until way later
03:29:08 <doug16k> for example
03:29:24 <doug16k> or a floating point exception. won't be noticed until far later
03:31:22 <doug16k> let's say it misses the TLB, it is continuing to rampage ahead and execute stuff after the memory access instruction. when it misses the TLB, it might miss the cache when it tries to read the page tables. it will get miles ahead and speculate tons of stuff. eventually it sees it was not present. boom, pipeline flush, everything it did after the memory access didn't happen
03:31:44 <doug16k> so it puts all the names back to what they were before the memory access that page faulted, instantly putting everything back
03:32:37 <promach> speculation ....
03:32:53 <doug16k> yes
03:33:21 <promach> a lot of cache coherency issues involved during speculation
03:34:06 <doug16k> the way x86 does it is very hard to implement, yes. it protects the programmer from a lot of crazy stuff
03:34:18 --- join: Asu` (~sdelang@249.204.136.77.rev.sfr.net) joined #osdev
03:34:32 <doug16k> there were/are architectures with "imperfect" exceptions, which don't flawlessly put it all back like I described.
03:34:35 <doug16k> they are a huge pain
03:35:53 <doug16k> basically forces you to insert barriers that wait until everything is done up to the barrier, so you don't have a disaster to clean up
03:36:24 <doug16k> and they obviously kill performance
03:37:20 <doug16k> x86 has a barrier like that: lfence
03:37:32 <doug16k> you rarely need it though. mostly useful for perf measurements
03:37:34 <promach> memory barrier ?
03:37:42 --- quit: Asu (Ping timeout: 248 seconds)
03:37:58 <doug16k> it sounds like a memory barrier but it is really a "wait until all previous instructions have produced their result" instruction
03:38:37 <promach> ok
03:39:10 --- join: emerson (emerson@freenode/staff/emerson) joined #osdev
03:40:14 <doug16k> so if you rdtsc after lfence, you can be sure it really executed everything before the lfence
03:40:27 <doug16k> and it didn't issue rdtsc miles ahead of time
03:41:55 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
03:43:23 <promach> ok
03:44:02 --- quit: prokbird (Quit: Leaving)
03:49:24 <glauxosdever> Anyone concerned about the future of the Internet in the EU?
03:49:51 <doug16k> promach, have you watched these? they are *really* good -> https://www.youtube.com/playlist?list=PL5PHm2jkkXmi5CxxI7b3JCL1TWybTDtKq
03:50:12 <doug16k> if you're into this stuff, that professor is amazing
03:56:36 --- quit: trout (Ping timeout: 276 seconds)
03:58:11 --- quit: emerson (*.net *.split)
03:58:26 --- quit: aalm (Ping timeout: 240 seconds)
03:58:52 --- join: lecx (lex@yuuh.pw) joined #osdev
04:04:17 --- join: emerson (emerson@freenode/staff/emerson) joined #osdev
04:05:10 --- quit: DeepIO_ (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/)
04:05:38 --- quit: abramovich (Quit: Leaving)
04:10:14 --- quit: Sjors (Ping timeout: 248 seconds)
04:11:32 --- quit: crgimenes (Quit: crgimenes)
04:11:48 --- join: nastaki (~nastaki@pdf840f25.tokynt01.ap.so-net.ne.jp) joined #osdev
04:12:22 --- join: Mikaku (~Mikaku@pdpc/supporter/active/mikaku) joined #osdev
04:14:20 <nastaki> hi men, well the regfile flop in gpu hw, is three state because of two +one primarly alternating values, persistent, private and cont assignment tested change, and due to the delay line, array operations can be either whole array or single element, they correspond to private or global/persistent pool in the flop
04:15:19 <nastaki> in the other way to put it, lsu flops are private pooled when wr_en signal is not there, and alu reg flops are global pool
04:17:47 --- join: Kimundi_ (~Kimundi@i577A91DE.versanet.de) joined #osdev
04:18:01 --- quit: xerpi (Quit: Leaving)
04:18:43 --- join: bauen1 (~bauen1@x59cc873b.dyn.telefonica.de) joined #osdev
04:21:21 --- quit: kimundi (Ping timeout: 255 seconds)
04:24:28 --- join: zeus1 (~zeus@62.56.248.65) joined #osdev
04:28:01 <Vercas> https://cdn.discordapp.com/attachments/152162730244177920/463657312272252930/unknown.png
04:28:58 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
04:29:50 <Mutabah> Vercas: *snerk*
04:30:08 <Mutabah> Vercas: Do you have stats for .rs files?
04:30:21 <Vercas> I don't.
04:30:31 <Vercas> Got this off a Discord channel, as the URL suggests. :P
04:31:05 <Mutabah> Oh, yeah
04:31:14 <Mutabah> I use a discord-irc bridge so I'm used to seeing those links
04:31:53 <Vercas> https://anvaka.github.io/common-words/#?lang=cpp
04:31:53 <bslsk05> ​anvaka.github.io: Most used words in programming languages
04:31:58 <Vercas> Check this out.
04:32:02 <Vercas> This is... mildly interesting.
04:32:52 <nastaki> this is why i suggested basically that only full fifo pipelining and regfile understanding is how this hack can be understood, which i talk about. I provided a link there, can someone still need this pipelining introduction?
04:33:11 <nastaki> https://www.scss.tcd.ie/jeremy.jones/vivio/dlx/dlxtutorial.htm
04:33:12 <bslsk05> ​www.scss.tcd.ie: Introduction to the MIPS Processor
04:33:16 <Asu`> `require` in 54th in js
04:33:34 <Asu`> would have been funny if it was in the top 10
04:34:32 <Vercas> Mutabah: To respond to your curiosity about Rust files: self, let, fn, the, pub, mut, a, use, if, ...
04:35:42 --- quit: zeus1 (Ping timeout: 256 seconds)
04:37:10 --- join: yrlf (~yrlf@core.recodex.at) joined #osdev
04:38:05 <doug16k> Vercas, 0x00000000? really?
04:38:16 <Vercas> What?
04:38:32 <Mutabah> Vercas: Quite a nice spread of keywords
04:38:39 <doug16k> it's in that link you posted. it's fairly big considering
04:39:06 <Mutabah> Asu`: Heh
04:39:59 <Asu`> well, `import` is 5th for react
04:40:01 <Asu`> lol
04:41:30 --- join: goncalo (~goncalog@blacksand.promisc.org) joined #osdev
04:44:49 <nastaki> how it all works, is first RD stage goes over a mux in parallel some stuff happens there, and readbacks of fifo are done in parallel if possible, then fsm put's 1/5th of cycle later things to execute stage, that one allready accesses regfile directly, if there had been a change in the register value, alu executes, if not then not
04:46:17 <nastaki> when either alu or lsu completes of the two enable signals alternations, then in first case, writebacks to earlier instructions will be disallowed
04:46:36 <nastaki> and in lsu case retire_pc that of lsu is programmed as new program counter
04:47:06 --- join: bender (uid106562@gateway/web/irccloud.com/x-syxljjakhhhimema) joined #osdev
04:47:29 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-fhattztghngbjlme) joined #osdev
04:47:55 <nastaki> the delay entry is there, because, when per warp there are more regs that changed , it will run things as whole-array
04:48:11 --- join: vmlinuz (~vmlinuz@32.104.18.203) joined #osdev
04:48:11 --- quit: vmlinuz (Changing host)
04:48:11 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
04:48:51 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
04:49:28 <SopaXorzTaker> I wonder, are there any operating systems where the kernel is written in bytecode and interpreted?
04:49:31 <promach> doug16k: thanks for the youtube link
04:49:32 <nastaki> in other words, it detects the delay and if it is there, it will enable rd_addr0/1/2 from the select input, and flip the whole array of lsu
04:49:38 --- join: S_Gautam (uid286066@gateway/web/irccloud.com/x-tyibhmnhafzohwaa) joined #osdev
04:49:57 <SopaXorzTaker> I know, there were some OSes where the kernel could execute bytecode
04:50:10 <SopaXorzTaker> but I'm asking about one where the kernel and the drivers are interpreted too
04:50:32 <doug16k> SopaXorzTaker, EFI applications and drivers can be bytecode
04:50:48 <SopaXorzTaker> Like, the kernel would be wrapped in a layer that would execute the bytecode and allow it to interface with the periphernals on a low-level
04:50:54 <promach> lsu flops are private pooled when wr_en signal is not there, and alu reg flops are global pool ?
04:50:59 <SopaXorzTaker> the drivers would still be a part of the kernel, though
04:51:00 <promach> doug16k
04:52:35 --- join: aalm (~aalm@37-219-19-50.nat.bb.dnainternet.fi) joined #osdev
04:52:35 <nastaki> if you want to access the global registers from an array..you need to broadcast them from one element
04:52:44 --- join: NaNkeen (~nankeen@61.6.61.196) joined #osdev
04:53:00 --- join: eremitah_ (~int@unaffiliated/eremitah) joined #osdev
04:53:06 <nastaki> in that case the delay line won't go in, neither lsu_select, and stuff can be broadcasted element by element
04:53:10 --- quit: eremitah (Ping timeout: 256 seconds)
04:53:22 --- nick: eremitah_ -> eremitah
04:58:15 <Vercas> SopaXorzTaker: That sounds like quite the waste. However, I know one thing that's close: COSMOS.
04:58:28 <Vercas> The "interpretation" is done ahead-of-time, not just-in-time, though.
04:58:42 --- quit: crgimenes (Quit: crgimenes)
04:59:06 <SopaXorzTaker> Vercas, eww, C#
04:59:19 <SopaXorzTaker> Is there something alike, but without the M$ crap?
04:59:49 <Vercas> I think an attitude adjustment would help you greatly towards achieving your goals.
05:00:55 <SopaXorzTaker> Vercas, I refuse to touch anything related to this evil, evil company. What's wrong with my attitude
05:00:57 <SopaXorzTaker> ?
05:01:02 <Vercas> Funny enough, the only other project is the Miranda research kernel. Microsoft research.
05:01:04 <SopaXorzTaker> (also, please don't use a LART to readjust it)
05:01:33 <Vercas> Yes yes, I know Bill Gates chases little black kids with his insane vaccines, etc. etc.
05:01:54 <SopaXorzTaker> Vercas, no
05:01:56 <Vercas> Paralyzing Africans left and right. XD
05:02:00 <SopaXorzTaker> That's Barack Obama
05:02:12 <Vercas> Sorry, got my conspiracies mixed up.
05:02:21 <SopaXorzTaker> I'm talking about oppression of INNCOENT PLAES.. oh, wrong channel - opression of FOSS, I mean
05:02:36 <SopaXorzTaker> oppression*
05:02:37 <Vercas> Really... Like what?
05:02:48 <nastaki> the relevant hunks happen in reg_256x32b_3r_1w.v, it selects lsu to do the access according to lsu wfid/base, but it accesses regfile from simx alu flops for the write to happen, it is wrapping stuff
05:03:22 <Mutabah> SopaXorzTaker: There's a project to write an OS that executes wasm natively...
05:03:24 <SopaXorzTaker> Vercas, using the corrupt Linux Foundation
05:03:29 <SopaXorzTaker> Acquiring GitHub
05:03:47 <SopaXorzTaker> Being a patent troll after those "we love FOSS" campaigns
05:03:51 <Vercas> Dunno what you're on about the Linux Foundation, and acquiring GitHub is bad why?
05:04:03 <Mutabah> Afaik, most of these bytecode OSes involve a small natively compiled kernel combined with potentially bytecode drivers
05:04:06 <Vercas> And what patents have they sued FOSS devs/users for?
05:04:16 <SopaXorzTaker> Vercas, because they just got a bunch of young stupid developers to support them
05:04:23 <Vercas> Mutabah: They're basically two or even three kernels written in different languages.
05:04:35 <Mutabah> Yeah, interesting concept really
05:04:37 <Asu`> MS and open source lol
05:04:39 <Vercas> SopaXorzTaker: So you're, what, 50-year-old graybeard who knows best?
05:04:42 <Asu`> what significant do they have open sourced?
05:04:51 <Asu`> aside of a text editor and two minor things
05:04:51 <SopaXorzTaker> Vercas, http://techrights.org/2016/03/08/microsoft-extorting-wistron/
05:04:53 <Vercas> Asu`: Check their GitHub shiz.
05:04:53 <bslsk05> ​techrights.org: Microsoft Hates Linux: Patent Extortion Continues With New Software Patents Deal (Wistron) | Techrights
05:04:58 --- join: quc (~quc@87.116.228.115) joined #osdev
05:05:09 <SopaXorzTaker> Vercas, no, I'm a 15-year-old idiot amazed at the ignorance of the FOSS community
05:05:21 <Vercas> There we go.
05:05:46 <Vercas> I used to care about who liked and didn't like Justin Bieber at your age, lmao.
05:06:51 <Vercas> Also, that article smells like refined bullshit.
05:06:58 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
05:07:01 <Vercas> So there's exactly one company paying Microsoft.
05:07:10 <Vercas> Out of dozens of Android OEMs.
05:07:12 <Asu`> Vercas: they might have open sourced some projects related to dotnet and js, but really nothing worthwhile as for native projects
05:07:20 <SopaXorzTaker> Vercas, well, Roy Schestowitz is obsessed with FOSS, so there might be some exaggeration
05:07:41 <SopaXorzTaker> Vercas, they've also pushed Xiaomi into partnership
05:07:43 <Asu`> i.e. zero part of windows, visual studio, directx (aside of the hlsl shader compiler, which isn't even useful for projects like wined3d)
05:07:47 <SopaXorzTaker> Oh, and don't forget exFAT
05:08:04 <SopaXorzTaker> it used to be a highly successful patent trolling tactic
05:08:12 <Vercas> Asu`: They don't owe their source code to anyone.
05:08:24 <Asu`> so what?
05:08:47 <Vercas> So take what you've got: .NET Core, ASP.NET, some database, etc.
05:09:09 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
05:09:11 <Vercas> And not only did they open-source these, they're cross-platform.
05:10:07 <Vercas> Open-sourcing parts of Windows is far less useful to us as a development community than, say, open source drivers.
05:10:18 <Vercas> Especially GPU drivers.
05:10:32 <Asu`> asp.net is fairly dead, and though .net core is great to have cross platform, it's just still far enough to justify the bigotry of some calling it the "biggest open source company" etc
05:10:35 <Vercas> Y'all got an entirely independent computer running parallel to your OS doing whatever it wants.
05:10:44 <SopaXorzTaker> Vercas, the M$ ecosystem has strong lock-in
05:11:03 <Vercas> Maybe for newbies.
05:11:19 <Vercas> There's virtually nothing stopping you from porting and developing cross-platform stuff these days.
05:11:25 <Vercas> Only exception is drivers.
05:11:32 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
05:11:40 <Asu`> Vercas: a good example is directx
05:11:41 <SopaXorzTaker> Vercas, eww, proprietary drivers
05:11:50 <Vercas> Asu`: Part of the GPU stack, which I mentioned before.
05:12:03 <Asu`> i'm not talking about the driver part
05:12:14 <Asu`> direct3d, unlike opengl, is partly a library from MS
05:12:14 <Vercas> I know, userland part needs to be open source too.
05:13:30 <Vercas> Asu`: Also, even if Microsoft wanted to open-source it, AMD and nVidia have contributed to it and they're major cunts.
05:13:51 <Vercas> Surely we all 'member Linus Torvalds flipping off nVidia.
05:14:00 <Mutabah> Heh :)
05:14:15 <Asu`> AMD is pretty good on the open source side... for linux
05:14:31 <Asu`> opengl on windows is still a pile of hot garbage, and their drivers are closed
05:14:33 <Vercas> Intel's shit is entirely open source. And their GPU documentation is solid.
05:14:45 <Asu`> Vercas: AMD wants to kill the proprietary driver on linux
05:14:49 <Vercas> Well, the Windows driver is not open source AFAIK.
05:14:58 <Asu`> yes, it's closed
05:15:05 <Asu`> all drivers on windows are closed
05:15:22 <Asu`> graphic drivers* from the big names
05:15:34 <Vercas> Must be because they work with Microsoft devs and lots of crap they do is under NDA. :l
05:15:47 <Asu`> that might be part of the reason
05:15:56 <Mutabah> Or because parts of the driver interfaces are hard to release
05:15:57 <Asu`> but unlike on linux, AMD has no interest into open sourcing the windows driver, for example.
05:16:06 <Mutabah> Or maybe just becuase they have a hack list for games/programs :)
05:16:12 <Mutabah> And they don't want to name and shame
05:16:25 <Vercas> Yeah. AMD stands to gain from open-sourcing the Linux driver: other people can do the maintenance for them.
05:16:32 <Mutabah> Yup
05:16:38 <Asu`> one of the lead AMD devs said that he means to deprecate the proprietary driver, and has contributed to get mesa to support newer opengl versions under compatibility profiles
05:16:51 <Vercas> Right now they have two different platforms to worry about. They do this and every white knight driver/kernel dev on Linux can start fixing their own bugs.
05:16:56 <Asu`> intel didn't have to care about it, because... who would use intel hardware for professional 3D?
05:17:16 <Vercas> Yet Intel's driver is fully open source, including shaders for crap like video codecs.
05:17:22 <Asu`> mesa is a great project. might be one of my favourite OSS projects
05:17:36 <Mutabah> Great for us here :)
05:17:45 <glauxosdever> I'm more worried about the future of the Internet because of EU copyright directive now..
05:17:50 <Asu`> huh, i guess some of you use it for OSMesa?
05:17:51 <Mutabah> mesa software rendering is nice for making your hobby os look flashy
05:17:58 <Asu`> glauxosdever: yes, that's pretty shit
05:18:13 <Asu`> wikipedia italia has actually blocked their website to protest
05:18:15 <Vercas> glauxosdever: Don't worry, I'm working on Internet 2.0
05:18:45 <glauxosdever> Vercas: Are you? Not sure it won't be illegal after this..
05:18:50 <Vercas> So, unless my memory fails, MESA is just a rendering library, isn't it..?
05:19:02 <glauxosdever> But, yes, I learned from wikipedia it's on 5th July
05:19:11 <glauxosdever> Already^
05:19:12 <Vercas> With a choice of back ends.
05:19:32 <Vercas> glauxosdever: Wireless mesh networking is my goal.
05:19:34 <Asu`> Vercas: it's a big chunk of userland for 3d graphics
05:19:41 <Prf_Jakob> Pretty much :)
05:20:13 <Vercas> Is it a client/server architecture, or just a library you drop into your app?
05:20:36 <Prf_Jakob> There is something called OSMesa that you can drop in your app.
05:20:49 <Asu`> so basically, radeonsi is the opengl implementation for AMD GPUs, it depends on AMDGPU/radeon (the kernel driver), it uses some code in common with other graphics drivers (think intel's, nouveau for nvidia) and can provide opengl, d3d9, vulkan, etc
05:20:51 <Prf_Jakob> But the biggest part is a full featured driver stack.
05:20:57 <Asu`> ^
05:21:18 <Asu`> i don't know enough to provide details on how it's operating internally though
05:21:38 <Vercas> So wait. Full-featured driver stack?
05:21:50 <Vercas> You're telling me that the codebase of MESA includes drivers for GPUs?
05:21:57 <Prf_Jakob> Yeah
05:22:00 <Asu`> Vercas: yes, the userland part of it
05:22:02 <Prf_Jakob> A fair bit of them
05:22:06 <Vercas> Which I could duct-tape onto my OS?
05:22:24 <Vercas> Asu`: Userland part? So not full drivers? :|
05:22:38 <Prf_Jakob> Only the userland part of them, but not the kernel drivers.
05:22:40 <Asu`> ^
05:22:49 <Vercas> Right..
05:22:53 <Asu`> mesa has a few opengl renderers: https://mesamatrix.net/
05:22:56 <bslsk05> ​mesamatrix.net: The OpenGL vs Mesa matrix
05:23:48 <Asu`> software* renderers
05:24:15 <Prf_Jakob> virgl isn't really a software renderer, its a virtual driver.
05:24:17 <Vercas> So I need to write my own drivers, or port some other driver, in order to get proper support for a GPU...
05:24:26 <Prf_Jakob> Yes
05:24:28 <Asu`> yes
05:24:40 <Prf_Jakob> Or you could port some from FreeBSD or Linux.
05:24:42 <Vercas> And MESA just tells me what interface it wants to work with?
05:24:48 <Prf_Jakob> Yupp
05:25:06 <Vercas> I suppose porting an Intel driver isn't going to be rocket science.
05:25:18 <Vercas> Especially since my drivers will be in userland, where I can sandbox the fuck out of them.
05:26:09 <Asu`> Vercas: you can try to wire in the linux intel kernel module in your kernel :D
05:26:21 <Asu`> i think freeBSD has a linux graphics module compatibility layer?
05:26:26 <Vercas> Nah, not kernel, directly into userland.
05:26:35 <Asu`> ah, microkernel?
05:26:39 <Vercas> Yeah.
05:26:52 --- join: SwiftMatt (~Objective@2601:282:4300:3e:48bd:2fcb:f706:3ed8) joined #osdev
05:27:05 <Asu`> Vercas: https://en.wikipedia.org/wiki/Mesa_(computer_graphics)#/media/File:Gallium3D_example_matrix.svg
05:27:06 <bslsk05> ​en.wikipedia.org: Mesa (computer graphics) - Wikipedia
05:27:11 --- quit: Tazmain (Quit: Leaving)
05:27:26 <Asu`> though, i don't think vulkan mesa drivers work through gallium3D
05:27:41 <Vercas> Hm.
05:27:49 <Prf_Jakob> The vulkan drivers are so small so they basically have very little shared code.
05:28:53 <Vercas> Vulkan is pretty bare-metal, yeah.
05:28:56 <Prf_Jakob> Btw, virgl is a virtual driver for the virgl3d protocol. It should be fairly easy to get up and running (easy here is relative to writing graphics drivers).
05:29:09 <Vercas> I personally don't even actually care about OpenGL that much, Vulkan is the API I'm interested in.
05:29:18 <Vercas> Buuuuuut it's nice to have.
05:29:58 <Prf_Jakob> Virgl is OpenGL only, at least for now and for some time, but there are plans for a vulkan renderer.
05:30:34 <Vercas> Prf_Jakob: So that's a *kernel* driver?
05:30:49 <Vercas> Or a userland part of it, that handles all the rendering instead?
05:31:04 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
05:31:29 <Asu`> Prf_Jakob: Vercas: https://www.phoronix.com/scan.php?page=news_item&px=QEMU-Possible-Vulkan
05:31:32 <bslsk05> ​www.phoronix.com: QEMU Is Interested In Vulkan Guest Support "Vulkan-ize Virgl" - Phoronix
05:31:36 --- quit: graphene (Remote host closed the connection)
05:32:09 <Vercas> Wait... So VirGL is not a software renderer, but a virtualized renderer?
05:32:46 <Prf_Jakob> Vercas: Yeah :)
05:32:55 <Prf_Jakob> I dunno why it is in the software group
05:32:58 <Asu`> https://virgil3d.github.io/
05:32:58 <bslsk05> ​virgil3d.github.io: Virgil 3D GPU project by virgil3d
05:33:15 --- join: graphene (~graphene@46.101.134.251) joined #osdev
05:33:26 --- quit: bauen1 (Remote host closed the connection)
05:33:26 <Asu`> "The implementation of rendering for the card is done in the host system as part of qemu and is implemented purely on OpenGL so you can accelerated rendering on any sufficiently capable card/driver combination."
05:33:33 <Asu`> "The project also consists of a complete Linux guest stack, composed of a Linux kernel KMS driver, X.org 2D DDX driver and Mesa 3D driver."
05:35:30 <Vercas> Hm.
05:35:55 <Vercas> I wonder if VMWare has got support for this.
05:36:02 <Asu`> doubt it
05:36:23 <Vercas> So the only supported host right now is literally Qemu?
05:36:44 <Vercas> `QEMU 2.5 contains 3D support only with the GTK3 frontend with GL enabled.`
05:37:03 <Asu`> sounds like it
05:37:06 <nastaki> and i looked how it happens that this wrapping stuff, it appears that verilog when merging compilation units, can backdrive inputs from other wires/inputs
05:37:53 <Prf_Jakob> Vercas: VMware has it's own similar stack called SVGA3D.
05:38:05 <Vercas> Ahhhh I 'member now.
05:38:12 <Vercas> Full DirectX 9 virtualization.
05:38:17 <Prf_Jakob> Pretty much
05:38:19 --- quit: immibis (Ping timeout: 240 seconds)
05:38:53 <Vercas> https://www.mesa3d.org/vmware-guest.html
05:38:53 * Prf_Jakob worked for VMware on said stack, and now is a maintainer for virgl3d :p
05:38:54 <bslsk05> ​www.mesa3d.org: VMware guest GL driver
05:39:06 <Vercas> Prf_Jakob: Nice! :D
05:39:31 --- join: jbgg (~jbgg@20.51.222.87.dynamic.jazztel.es) joined #osdev
05:39:35 <Asu`> huh cool :)
05:40:01 <Prf_Jakob> Well a maintainer for the part that qemu uses.
05:40:07 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
05:40:10 <Vercas> So the kernel driver part seems to be open source.
05:40:18 <Vercas> And MESA supports it...
05:40:26 <Prf_Jakob> For VMware? Yes
05:40:28 <Vercas> Means a port is theorethically possible.
05:42:14 <Prf_Jakob> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/svga/svga_winsys.h
05:42:15 <bslsk05> ​gitlab.freedesktop.org: src/gallium/drivers/svga/svga_winsys.h · master · Mesa / mesa · GitLab
05:42:37 <Prf_Jakob> Vercas: ^ that interface is an abstraction of the kernel interface, basically what you will need to implement.
05:43:08 <nastaki> it asks from that file i referenced if rdX_addr is satisfied, and backdrives the regfile in alu mode in the default label
05:43:09 <Prf_Jakob> The OpenGL SVGA3D is used on both Linux and Windows, but only the Linux below that interface is open.
05:43:12 --- quit: variable (Ping timeout: 276 seconds)
05:43:19 <Asu`> i've always wondered, why does each driver need specific implementations for opengl and vulkan? can't it be entirely abstracted by gallium?
05:43:42 <Prf_Jakob> Vulkan is on basically the same level (if not lower) then Gallium.
05:44:01 <Vercas> Prf_Jakob: Wait, why do I need the Windows interface?
05:44:02 <Prf_Jakob> So Gallium is used for OpenGL and some other video interfaces.
05:44:07 <nastaki> well virtual machine based rendering would go also very fast, is the SVGA3D still only dx9 and ogl2.1 though?
05:44:17 <Prf_Jakob> Vercas: You don't, I'm just giving context :p
05:44:23 <Vercas> Ah.
05:44:59 <Prf_Jakob> What I mean is, that interface is what you probably need to implement yourself.
05:45:02 <Asu`> nastaki: according to mesamatrix virgl is 4.1
05:45:05 <Prf_Jakob> Or port
05:45:20 <Asu`> oh wait you're talking about svga3d
05:45:27 <nastaki> Asu`: i know that, exactly
05:46:19 <Prf_Jakob> Asu`: Yeah, he seemed more interested in something on VMware so I pointed him in that direction :)
05:46:44 <nastaki> with the pace that developers have gone, i mean no critisism released, but i do not have time to make dx11 front-end to the precompiler at the moment
05:47:45 <Vercas> Can't wait to develop my actual drivers.
05:48:20 <nastaki> some are not as me hired programmers, i can't belive they can not find time for dx11
05:48:38 <Asu`> i wish i had time to do some osdev too, but i'm already spending that time on learning HDLs :P
05:48:44 --- join: pochito (~pochito@181.95.226.71) joined #osdev
05:49:03 <nastaki> cause i am at the moment finally entirely broke, i need to go to work too
05:49:23 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
05:49:24 <nastaki> and hence currently for bigger precompiler project i do not have time
05:50:35 --- part: debug left #osdev
05:52:22 <nastaki> cause dealing with nextGL is entire crap, when one only needs the command buffer methods, it has been waste of time to do newIR and all those other calls
05:58:50 <nastaki> to be fair i am more like linux based c-groups or alike containers guy, not a virtual machine guy myself, for windows since no one uploads stable code, there are many virtual machine users indeed
05:59:49 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
06:00:26 <nastaki> i looked how my friend booted virtual machines on skylake low-voltage processor, and in fact they ran very well there but ... anyhow
06:04:56 --- quit: smeso (Ping timeout: 240 seconds)
06:08:04 <nastaki> in fact on friday i have my first day at some random work, so...i can also recap tomorrow my ideas about how to do the precompiler framework with LLVM kit
06:08:12 <nastaki> however at the moment i have to go.
06:08:18 --- quit: nastaki (Quit: Leaving)
06:08:23 --- quit: NaNkeen (Ping timeout: 260 seconds)
06:11:05 <Vercas> Question. What on Earth has nastaki been blabbering about all this time?
06:11:57 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
06:12:03 <Vercas> It looks like a Markov chain was given OCR and set off on r/iamverysmart
06:14:38 --- quit: ybyourmom (Quit: Lost terminal)
06:15:12 --- quit: trout (Ping timeout: 240 seconds)
06:17:04 <Mutabah> Vercas: It's mardinator
06:17:25 <Vercas> Y he here? :C
06:18:51 <Asu`> oh, it's mardinator
06:19:13 <Asu`> i felt like there were too much commas but i didn't realize
06:19:37 <Asu`> seriously, if you want to make a heuristic to detect him, just count the amount of ',' in average per message
06:20:37 --- join: prokbird (~shams@117.205.128.49) joined #osdev
06:27:54 --- quit: aalm (Ping timeout: 256 seconds)
06:28:47 --- quit: Kimundi_ (Ping timeout: 256 seconds)
06:30:09 --- quit: graphene (Remote host closed the connection)
06:30:45 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
06:38:29 --- join: Sjors (~quassel@bulbasaur.sjorsgielen.nl) joined #osdev
06:43:05 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
06:46:15 --- quit: variable (Ping timeout: 276 seconds)
06:46:39 --- join: NaNkeen (~nankeen@61.6.61.196) joined #osdev
06:50:26 --- join: promach_ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
06:51:24 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
06:57:24 <doug16k> Asu`, lol
06:57:38 --- quit: barbershopper (Remote host closed the connection)
07:00:41 --- quit: stoopkid (Quit: Connection closed for inactivity)
07:01:07 --- quit: samathy (Quit: ZNC 1.6.5+deb1 - http://znc.in)
07:01:20 --- join: samathy (~samathy@samathy.space) joined #osdev
07:01:29 --- quit: samathy (Remote host closed the connection)
07:02:27 --- join: samathy (~samathy@samathy.space) joined #osdev
07:03:03 --- join: _mjg (mjg@fook.org) joined #osdev
07:04:55 --- quit: jack_rabbit (Ping timeout: 264 seconds)
07:06:51 --- quit: snowball (Quit: Communi 3.5.0 - http://communi.github.com)
07:07:22 --- quit: manzerbredes (Quit: WeeChat 2.1)
07:09:09 --- join: kimundi (~Kimundi@dynip-129-217-105-124.wifi.tu-dortmund.de) joined #osdev
07:15:20 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
07:18:14 --- quit: trout (Ping timeout: 256 seconds)
07:18:32 --- join: zeus1 (~zeus@62.56.248.65) joined #osdev
07:24:07 --- quit: NaNkeen (Ping timeout: 264 seconds)
07:28:23 --- join: NaNkeen (~nankeen@61.6.183.145) joined #osdev
07:32:56 --- join: hmmmm (~sdfgsf@pool-72-79-167-4.sctnpa.east.verizon.net) joined #osdev
07:36:02 --- join: nastaki (~nastaki@pdf840f25.tokynt01.ap.so-net.ne.jp) joined #osdev
07:36:31 <nastaki> Vercas: you have a fags name, please keep your fingers away from my name!
07:37:09 --- join: manzerbredes (~loic@LFbn-1-1235-47.w86-253.abo.wanadoo.fr) joined #osdev
07:37:28 <nastaki> do your porn, don't interact with my signals, much appreciated, thank you have a nice day idiot!
07:37:32 --- quit: nastaki (Client Quit)
07:37:40 --- join: tadni (~tadni@71-11-142-172.dhcp.stls.mo.charter.com) joined #osdev
07:37:59 --- join: tadni_ (~tadni@71-11-142-172.dhcp.stls.mo.charter.com) joined #osdev
07:38:22 <brynet> o_O
07:44:23 --- quit: CheckDavid (Quit: Connection closed for inactivity)
07:45:53 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
07:46:08 --- quit: banisterfiend (Ping timeout: 276 seconds)
07:49:57 --- quit: variable (Ping timeout: 276 seconds)
07:52:21 --- quit: elevated (Quit: bye)
07:54:07 --- quit: salek_ (Ping timeout: 264 seconds)
07:54:39 --- join: millerti (~millerti@cpe-66-24-91-119.stny.res.rr.com) joined #osdev
07:56:29 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
08:01:26 --- quit: NaNkeen (Ping timeout: 240 seconds)
08:03:06 --- quit: zeus1 (Ping timeout: 256 seconds)
08:07:15 --- quit: bender (Quit: Connection closed for inactivity)
08:09:41 --- quit: tadni (Quit: Leaving)
08:11:05 --- quit: crgimenes (Quit: crgimenes)
08:11:29 --- quit: jakogut (Quit: Ping timeout (120 seconds))
08:14:50 --- join: freakazoid0223 (~mattc@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
08:15:31 --- quit: Love4Boobies (Ping timeout: 268 seconds)
08:15:48 --- join: grouse_ (~grouse@83-233-9-2.cust.bredband2.com) joined #osdev
08:16:49 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
08:17:32 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
08:19:17 --- quit: grouse (Ping timeout: 276 seconds)
08:20:36 --- quit: trout (Ping timeout: 245 seconds)
08:26:24 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
08:28:11 --- quit: crgimenes (Quit: crgimenes)
08:30:28 --- join: stoopkid (uid137696@gateway/web/irccloud.com/x-vzafmzinwafeqstu) joined #osdev
08:31:52 --- quit: grouse_ (Quit: Leaving)
08:32:19 --- quit: cirno_ (Remote host closed the connection)
08:32:59 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
08:35:17 --- join: BartAdv (uid90451@gateway/web/irccloud.com/x-ogjuptrjbywayvuk) joined #osdev
08:35:45 --- join: SwiftMatt (~Objective@2601:282:4300:3e:210e:d4e9:6154:3e91) joined #osdev
08:35:58 --- quit: SwiftMatt (Client Quit)
08:36:14 --- quit: cirno_ (Client Quit)
08:42:15 --- part: prokbird left #osdev
08:44:57 --- join: crgimenes (~crgimenes@179.208.113.73) joined #osdev
08:45:43 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
08:48:39 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
08:52:11 --- quit: variable (Ping timeout: 260 seconds)
08:53:32 --- quit: crgimenes (Ping timeout: 256 seconds)
08:55:07 --- quit: jjuran (Quit: jjuran)
09:05:48 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
09:08:20 --- join: NaNkeen (~nankeen@61.6.183.145) joined #osdev
09:13:09 --- quit: tadni_ (Remote host closed the connection)
09:13:26 --- quit: plonk (Quit: ZNC - 1.6.0 - http://znc.in)
09:16:35 --- join: zeus1 (~zeus@197.239.32.35) joined #osdev
09:17:03 --- join: andrei-n (~andrei@208.8-64-87.adsl-dyn.isp.belgacom.be) joined #osdev
09:17:57 --- quit: nortega (Remote host closed the connection)
09:18:02 --- join: naortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
09:19:08 --- quit: stee3 (Quit: stee3)
09:25:49 --- join: bemeurer (~bemeurer@stdcognition.static.monkeybrains.net) joined #osdev
09:26:23 --- quit: bauen1 (Ping timeout: 245 seconds)
09:27:11 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
09:28:06 --- quit: NaNkeen (Ping timeout: 256 seconds)
09:28:24 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
09:29:26 --- quit: zeus1 (Ping timeout: 240 seconds)
09:30:47 --- quit: trout (Ping timeout: 276 seconds)
09:31:38 --- join: [X-Scale] (~ARM@83.223.227.205) joined #osdev
09:32:19 --- quit: cirno_ (Remote host closed the connection)
09:33:03 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
09:33:50 --- quit: X-Scale (Ping timeout: 268 seconds)
09:33:51 --- nick: [X-Scale] -> X-Scale
09:34:31 --- join: plonk (~plonk@rosa.physik-pool.tu-berlin.de) joined #osdev
09:34:32 --- quit: plonk (Changing host)
09:34:32 --- join: plonk (~plonk@unaffiliated/plonk) joined #osdev
09:34:50 --- join: Asu (~sdelang@161.19.136.77.rev.sfr.net) joined #osdev
09:38:06 --- quit: Asu` (Ping timeout: 260 seconds)
09:46:15 --- join: NaNkeen (~nankeen@61.6.183.145) joined #osdev
09:51:20 --- join: NaNkeen_ (~nankeen@61.6.183.145) joined #osdev
09:52:38 --- quit: NaNkeen (Ping timeout: 245 seconds)
09:53:50 --- join: jjuran (~jjuran@c-73-132-80-121.hsd1.md.comcast.net) joined #osdev
09:54:07 --- quit: millerti (Ping timeout: 264 seconds)
09:54:12 --- quit: bauen1 (Ping timeout: 240 seconds)
09:54:19 --- quit: jbgg (Quit: leaving)
09:54:53 --- join: jbgg (~jbgg@20.51.222.87.dynamic.jazztel.es) joined #osdev
09:56:19 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
09:57:07 --- join: aalm (~aalm@37-219-19-50.nat.bb.dnainternet.fi) joined #osdev
09:58:51 --- quit: pochito (Ping timeout: 255 seconds)
09:59:05 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
09:59:59 --- join: dennis95 (~dennis@i577BCEAC.versanet.de) joined #osdev
10:00:47 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
10:02:19 --- quit: cirno_ (Remote host closed the connection)
10:02:20 --- quit: variable (Ping timeout: 265 seconds)
10:02:26 --- quit: aalm (Ping timeout: 240 seconds)
10:02:49 --- quit: FManTropyx (Ping timeout: 240 seconds)
10:02:59 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
10:03:27 --- join: aalm (~aalm@37-219-19-50.nat.bb.dnainternet.fi) joined #osdev
10:04:42 --- quit: kimundi (Ping timeout: 255 seconds)
10:09:47 --- quit: NaNkeen_ (Ping timeout: 256 seconds)
10:10:12 --- join: Jack_ (485df870@gateway/web/freenode/ip.72.93.248.112) joined #osdev
10:10:20 <Jack_> Hello
10:13:27 --- join: zeus1 (~zeus@197.239.32.35) joined #osdev
10:14:30 --- join: user10032 (~Thirteen@2a02:c7d:314e:b300:4948:171a:1647:37ec) joined #osdev
10:14:59 <klys> hi
10:15:22 * klys was just working on the 2nd part of his malloc routines
10:15:43 --- join: FManTropyx (~fooman@82-203-172-156.bb.dnainternet.fi) joined #osdev
10:17:56 --- quit: promach_ (Quit: WeeChat 2.1)
10:21:45 <Jack_> Does anyone have any tips about getting qemu to dump better debugging information? I am using gdb to step through and the -d option on qemu to dump the registers, but it is reseting on a single instruction.
10:25:15 <klys> are interrupts enabled?
10:25:54 <klys> also if you're doing pc code, bochs has a nice debugger
10:27:47 <Jack_> Interrupts are disabled and everything works except trying to change the cs register
10:28:03 <klys> are you in protected mode?
10:28:05 <Jack_> Also I am using uefi which I don't think Bochs supports yet
10:28:08 <Jack_> Yes
10:28:17 <klys> are you setting cs to 8 ?
10:28:25 <Jack_> Trying too haha
10:28:30 <klys> :.)
10:28:47 <Jack_> Since I am using x64 I have to set it using a far return but it keeps breaking
10:28:56 <klys> push dword 8; push dword label; retf
10:29:00 <Jack_> I am like almost positive that the stack is correct and everything
10:29:14 <klys> oh it's 64-bit
10:29:20 <Jack_> Ya
10:29:50 <klys> push dword 8; push qword label; retq // not sure if cs should be a qword or a dword here.
10:29:50 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
10:30:16 <Jack_> I have tried both pushw and pushq for the cs
10:30:19 <Jack_> neither seem to work
10:30:27 <Jack_> also retf and retfq
10:30:32 <klys> and pushl ?
10:31:04 <klys> well I just know in 32-bit pmode it's push dword
10:31:10 <Jack_> Pretty sure I tested that too but I am going to check to be sure
10:31:10 <klys> sry
10:31:37 <klys> did you lidt or lgdt first?
10:31:55 <Jack_> lgdt because technically a idt is already loaded by uefi (technically a gdt is loaded as well)
10:32:02 <klys> k
10:32:19 --- quit: cirno_ (Remote host closed the connection)
10:32:20 <Jack_> The OS actually continues to work if I don't try to set the cs register and build the gdt around its current value so its really strange
10:32:26 <klys> you know it's lgdt [gdtr] not lgdt [gdt] right?
10:33:03 <klys> yeah sounds right
10:33:04 <Jack_> Ya I am passing a 10 byte GDT pointer
10:33:04 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
10:33:26 --- quit: cirno_ (Client Quit)
10:33:45 --- quit: trout (Ping timeout: 276 seconds)
10:34:44 <klys> gdtr[0] is the limit field
10:34:59 <Jack_> Yup I am using a packed struct and passing the address
10:35:17 <Jack_> When the cpu resets and dumps all the registers and the gdtr looks valid to me
10:35:55 <klys> what does gdt[ 8 ] look like?
10:36:16 <Jack_> What do you mean?
10:36:31 <klys> the cs descriptor
10:37:12 <klys> also note that idt can't modufy cs if you have a new gdt.
10:37:51 <klys> modify*
10:37:59 <Jack_> Ya I am pushing off worrying about the idt until I get to that point haha
10:38:12 <Jack_> The CS Descriptor is in C so I have to piece it together give me a moment
10:38:22 <klys> well perhaps now is the time
10:39:01 <Jack_> Do you think that would cause a cpu reset on a return? Because if so then maybe I should start working on that
10:39:09 <klys> yes
10:39:24 <klys> triple fault easy
10:39:42 <Jack_> But I have disabled interrupts using cli
10:39:48 <Jack_> I thought this would prevent the triple fault
10:40:19 <klys> perhaps i am mistaken, just as soon as you sti...
10:40:36 <Jack_> Hmm let me test this and insert a sti before the return and see if that crashes the program
10:40:46 <Jack_> because i think the idt that uefi loads is still valid
10:40:59 <klys> it can't be used though
10:41:10 <Jack_> Why not?
10:42:52 <klys> struct IDTDescr { uint16_t selector; ... }; // what does this point to? https://wiki.osdev.org/IDT
10:42:53 <bslsk05> ​wiki.osdev.org: Interrupt Descriptor Table - OSDev Wiki
10:44:30 <klys> the answer is that it points to your gdt.
10:44:38 --- nick: vaibhav -> vaibhav|gone
10:45:00 <Jack_> Hmmm I am confused by this
10:45:43 <klys> if gdt is invalid then idt is invalid.
10:46:04 <Jack_> Oh okay I understand what you are saying
10:46:30 --- quit: alyptik (Ping timeout: 248 seconds)
10:46:36 <Jack_> I still am confused why a far return would reset but I am going to delay that thought and setup an idt
10:47:18 <Jack_> Thank you klys I will be back with results
10:48:02 --- quit: BartAdv (Quit: Connection closed for inactivity)
10:48:19 <klys> k
10:49:17 --- join: alyptik (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
10:49:42 --- quit: zeus1 (Ping timeout: 256 seconds)
10:57:38 --- join: zaquest (~notzaques@5.128.210.30) joined #osdev
10:58:26 --- quit: clever (Quit: leaving)
10:58:49 --- join: bender (uid106562@gateway/web/irccloud.com/x-fixbxspulkobrhue) joined #osdev
11:01:39 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
11:05:00 --- quit: variable (Ping timeout: 255 seconds)
11:17:27 --- join: stee (~junk@66.252.139.92) joined #osdev
11:18:34 --- join: pochito (~pochito@gw.dc.uba.ar) joined #osdev
11:19:37 --- join: kimundi (~Kimundi@i577A91DE.versanet.de) joined #osdev
11:24:15 --- join: elevated (~elevated@gateway/tor-sasl/elevated) joined #osdev
11:25:11 --- quit: FManTropyx (Ping timeout: 276 seconds)
11:27:40 --- quit: spare (Ping timeout: 256 seconds)
11:31:05 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
11:31:11 --- quit: andrei-n (Quit: Leaving)
11:33:35 --- join: zeus1 (~zeus@197.239.32.35) joined #osdev
11:34:46 --- quit: bauen1 (Ping timeout: 260 seconds)
11:34:46 --- quit: X-Scale (Ping timeout: 260 seconds)
11:34:52 <doug16k> Jack_, cli only masks IRQs, interrupts caused by hardware. it has nothing to do with exceptions or software interrupts
11:35:44 --- join: islandsparky (1816e74b@gateway/web/freenode/ip.24.22.231.75) joined #osdev
11:36:10 <doug16k> obviously, right? what do you expect it to do if exceptions are blocked, just pretend the exception didn't happen?
11:36:27 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
11:36:27 --- join: SwiftMatt (~Objective@2601:282:4300:3e:210e:d4e9:6154:3e91) joined #osdev
11:36:58 <doug16k> you can't block exceptions
11:37:24 --- join: FManTropyx (~fooman@82-203-190-213.bb.dnainternet.fi) joined #osdev
11:37:58 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
11:38:49 <doug16k> correction: only floating point exceptions can be blocked
11:39:58 --- quit: SwiftMatt (Client Quit)
11:40:39 --- quit: trout (Ping timeout: 260 seconds)
11:41:05 <doug16k> in that case, it makes some sense to pretend the exception didn't happen, it will use NaN or infinity or just round off the result, etc and let it continue
11:46:57 --- join: lordofthekebabs (55617ef0@gateway/web/freenode/ip.85.97.126.240) joined #osdev
11:47:25 <lordofthekebabs> how hard would it be to create a OS for tablets ? ( For background: I have been learning programming for atleast a year now and the only thing I am doing is backend. Even though it is fun I dont get the same joy of even thinking about what I could be building if I had the knowledge to build Operating systems. And of course I will learn computer arhitecture, data structs, mathemtacis before starting operating systems
11:47:34 <lordofthekebabs> I am willing to devote time but I am just unsure of how much knowledge of prerequisite for commiting something like this
11:48:02 <lordofthekebabs> How long would it take for a beginner like me to build a atleast functionaing os
11:48:40 <lordofthekebabs> for visual representation https://qph.fs.quoracdn.net/main-qimg-ef2097fa379c529596978cc218407234 this is the thing I want to build not the same but I want to build a tablet for developers
11:48:53 <doug16k> lordofthekebabs, the feasibility will be determined by the availability of hardware documentation for the target tablet
11:48:54 --- join: X-Scale (~ARM@31.22.200.14) joined #osdev
11:49:51 <lordofthekebabs> doug16k well I dont have any knowledge about the docs about hardware but i am willing to go with the one that has the best docs if it is the right fit
11:50:34 <lordofthekebabs> how long would it take me to build something remote to the picture i sent maybe 3 yeras ? 4 years
11:51:19 --- join: snowball (~user_name@91.135.83.174) joined #osdev
11:51:49 <doug16k> something like that
11:52:04 --- quit: elevated (Quit: bye)
11:52:44 <lordofthekebabs> doug16k which language would you recommend rust or c ?
11:52:58 <doug16k> start with, "can I even get a toolchain set up to compile for it", and "can I even deploy a build to it", and "can I even set one pixel before it locks up" :D
11:54:04 <doug16k> me? I'd say C because I don't know rust and I have decades of C experience :)
11:54:32 <booyah> C is gaaaayt
11:54:33 <booyah> C is gaaaay
11:54:33 <doug16k> I use C++ for my project
11:54:53 <booyah> it's like using a small pocket knife, to build a marine port
11:55:00 <booyah> yeah C++ is more like it
11:55:14 <lordofthekebabs> well everyone is seeming to say that rust is better but I dont know which one to go with
11:55:32 <booyah> rust seems to be more secure language
11:55:34 <doug16k> do you know rust or C or C++ at all?
11:55:43 <booyah> but C++ is the one that is reaaaly well established
11:55:53 --- quit: jjuran (Quit: jjuran)
11:56:08 <booyah> if you dont know either, then rust might be the future. if you know one, use the one you know
11:56:22 <booyah> just remember C++ is a mine field. but we're in osdev so anyway everything is :)
11:56:26 <lordofthekebabs> doug16k well I have been learning backend dev with python and java but never touched c other than hello world and some printing to the console
11:56:45 <doug16k> lordofthekebabs, some assembly language will help a lot, even if it is for another CPU
11:56:45 <lordofthekebabs> booyah :) alright thanks for the heads up
11:57:11 <dbittman> rust's learning curve is steep, and osdev's learning curve is steep. I would recommend against mixing the two
11:57:41 <lordofthekebabs> alright c yeah I am gonna search and see rust but
11:57:58 <lordofthekebabs> I am probably gonna go with c
11:58:05 <lordofthekebabs> thanks a lot for the tips
11:59:56 <booyah> lordofthekebabs: imo better C++, it's imporved C
12:00:11 <booyah> thre's not much reason to use C over C++
12:00:43 <lordofthekebabs> booyah well I will of course compare the two I have long way untill I choose the language
12:01:03 <lordofthekebabs> I need to leanr architecture , mathematics , algorithms and so on
12:01:24 --- quit: pochito (Remote host closed the connection)
12:01:51 --- join: pochito (~pochito@gw.dc.uba.ar) joined #osdev
12:02:43 <doug16k> lordofthekebabs, a tablet is very likely to have an arm processor. learn a bit about arm while you're at it
12:03:33 <lordofthekebabs> doug16k alright noted thanks
12:03:35 <doug16k> you'll need to have a clue about that when you first set up a toolchain to compile for it
12:04:41 <lordofthekebabs> doug16k well I will say okay but right know I dont know what a toolchain is but once I start learning I will be back :) with more questions
12:05:29 <snowball> in a vfs, is a file node supposed to track any kind of read/write offset? or is that somebody else's job
12:06:24 <doug16k> snowball, the file descriptor tracks the offset. the descriptor points to an inode
12:06:49 <doug16k> you could dup the file descriptor, and it would make a new one, with its own offset, but refers to the same underlying file
12:07:30 <snowball> in that case, i'm throughly confused about the entities involved in a vfs: virtual node, inode, descriptor
12:07:54 <doug16k> same as if you open() a file again. points to the same inode, but the different descriptor has its own offset and can be closed independently
12:08:28 --- quit: lordofthekebabs (Quit: Page closed)
12:11:57 <doug16k> snowball, there are two levels. the actual file is the node, it has no seek position, only a refcount. it knows things like where to find the blocks on disk and can read or write arbitrary offsets. each file descriptor using the node increments the refcount of the node. if you open the same file 100x you have 100 file descriptors, and the node has a refcount of 100 but there is one node.
12:12:11 --- join: zenix_2k2 (~zenix_2k2@42.113.186.163) joined #osdev
12:12:40 <doug16k> if you close all 100 file descriptors, the node's refcount gets down to zero and you deallocate the node
12:12:42 <zenix_2k2> one question is there any book or good resource that i can use to learn about building drivers that interact with hardware ?
12:12:57 <zenix_2k2> like webcams and such, btw.. it is Windows
12:13:18 <doug16k> zenix_2k2, look at the DDK on MSDN
12:14:10 <doug16k> zenix_2k2, you'll need detailed datasheets and documentation for the target device
12:14:43 <zenix_2k2> well it will be my very own device anyway when i have done with hardware researching
12:14:52 <zenix_2k2> and i think that after building that i do also need to build a driver
12:15:10 <zenix_2k2> not "have done" opps, but still in researches :P
12:15:54 <doug16k> zenix_2k2, in that case, yes, the DDK is what you need. DDK = Driver Development Kit
12:16:59 <zenix_2k2> and is MSDN a microsoft thing ?
12:17:00 --- quit: variable (Ping timeout: 255 seconds)
12:17:09 <snowball> are vfs's aware of file descriptors at all?
12:17:10 <doug16k> yes. it's their documentation site
12:17:42 <doug16k> snowball, only aware of how many fds are using a given node
12:17:57 --- join: tacco| (~tacco@i59F4D0BF.versanet.de) joined #osdev
12:18:58 <zenix_2k2> and by DDK you mean this one --> https://docs.microsoft.com/en-us/windows-hardware/drivers/ ?
12:18:59 <bslsk05> ​docs.microsoft.com: Windows Driver Kit documentation | Microsoft Docs
12:19:00 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
12:19:10 <zenix_2k2> cause there are lots of sources i have found
12:19:13 <zenix_2k2> and not sure which is which
12:19:26 <doug16k> zenix_2k2, yes, that
12:20:41 --- quit: stoopkid (Quit: Connection closed for inactivity)
12:21:01 --- quit: nur (Ping timeout: 245 seconds)
12:21:27 --- join: salek_ (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
12:21:42 <zenix_2k2> but that is gonna help but what i meant was is there any source that can help me understanding how OS interact with hardware ? like kernel and low level stuffs ?
12:22:12 --- join: nur (~hussein@175.141.139.171) joined #osdev
12:22:37 <zenix_2k2> beside of my hardware i am also curious about things like "special memory address" that i heard somewhere and how the CPU process data and send it the the users
12:22:39 <zenix_2k2> things like that
12:22:45 --- quit: nur (Remote host closed the connection)
12:23:21 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
12:23:45 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
12:24:06 --- join: Vulcan_ (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
12:24:33 <doug16k> snowball, when you open a file, you create a new file descriptor and as the filesystem implementation to open it. if the filesystem sees it has a node for that file already, it will increment its reference count and return a pointer to it, otherwise it will create a new node with a refcount of 1 and return a pointer to it
12:25:03 <doug16k> snowball, you then store the node pointer in the file descriptor and return the fd number from the open syscall
12:25:17 <zenix_2k2> so ehm, any suggestion ?
12:25:52 <doug16k> now, when they do a read syscall, they pass you the fd. you lookup the fd and get the node pointer. you call into the filesystem and pass the node pointer, passing the offset from the file descriptor.
12:26:32 <doug16k> zenix_2k2, the question is too broad. it depends on whether it is PCI or USB or something else
12:27:07 --- quit: bauen1 (Ping timeout: 264 seconds)
12:27:19 --- quit: grumble (Ping timeout: 600 seconds)
12:27:36 --- join: bauen1 (~bauen1@188.193.140.119) joined #osdev
12:27:44 --- quit: Belxjander (Client Quit)
12:27:46 --- join: kingoffrance (180b7a03@gateway/web/freenode/ip.24.11.122.3) joined #osdev
12:27:50 --- join: grumble (~grumble@freenode/staff/grumble) joined #osdev
12:28:17 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
12:29:43 <doug16k> zenix_2k2, to get started I can suggest some search terms. look up DMA, bus mastering, IRQ, Interrupt handler, PCI, USB endpoints
12:29:57 <doug16k> MMIO, port I/O
12:30:10 <zenix_2k2> those are hardware stuffs right ?
12:30:14 <doug16k> yes
12:30:20 <zenix_2k2> and after that ?
12:30:29 <zenix_2k2> do i need to read something about OSes ?
12:30:37 <doug16k> those are the primary mechanism that you use to access hardware and handle I/O
12:30:42 --- quit: bemeurer (Remote host closed the connection)
12:31:09 --- join: bemeurer (~bemeurer@stdcognition.static.monkeybrains.net) joined #osdev
12:31:35 <doug16k> I don't have a book recommendation list, but I know of one -> https://wiki.osdev.org/Books
12:31:37 <bslsk05> ​wiki.osdev.org: Books - OSDev Wiki
12:31:51 <doug16k> look around on that site
12:32:29 <zenix_2k2> those look like... algorithms, what do they have anything to do with OSes ?
12:32:37 <zenix_2k2> i mean the knowledge of how OSes work
12:32:39 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
12:32:51 --- quit: SopaXorzTaker (Remote host closed the connection)
12:33:04 <doug16k> if you know of an OS implementation that has no algorithms, let me know, I want to see it
12:33:41 <kingoffrance> i am biased, but suppose your entire "OS" or bootloader is "hello world". how does this differ from a "userland" program? at the HW level, code is code, 1s and 0s.
12:33:42 <zenix_2k2> no no i mean how can the OS talk to the hardware, you know, the kernel
12:34:01 <zenix_2k2> like understanding how the kernel was made and how it works
12:34:25 <kingoffrance> all the "Security" "memory mapping" "Access to drivers" is effectively "made up" i.e. we call that a kernel, but there is much in common between a "kernel" and any other code.
12:34:53 <kingoffrance> IMO a "kernel" is just another program, one with full access to do anything. all the "Separation" is in peoples heads
12:35:56 <kingoffrance> it is good we have such "Separation" nowadays, we have somewhat defined what an "OS" is, but it is entirely arbitrary.
12:36:13 <zenix_2k2> well yes everything which isn't touchable are software but i mean how as it made
12:36:43 <zenix_2k2> i think that there has to be someone or something that has those information behind the scenes of an OS
12:37:06 <zenix_2k2> not just clicking button and then see the magic
12:38:59 --- quit: snowball (Quit: Communi 3.5.0 - http://communi.github.com)
12:39:30 <doug16k> zenix_2k2, what you are asking is too broad. operating systems are software. there's code, there's data. it accesses devices, manages memory, accesses filesystems, creates processes, handles system calls. what do you expect as an answer to that?
12:40:03 <doug16k> you'll need to take some time and read up on it and ask something more specific and less vague
12:40:22 <renopt> tbh kernels are a lot less magic than they were in the past, the hardware is generally well documented, the build process is pretty much the same as for userland programs, lots of quality, open-source bootloaders
12:41:17 --- join: smeso (~smeso@unaffiliated/smeso) joined #osdev
12:42:17 <zenix_2k2> so how do they build hardware and how to make the OS interact with it is documented somewhere ?
12:42:47 <doug16k> there is hardware documentation, yes. that is what you read when you make a driver for something
12:43:35 <doug16k> sometimes it is some proprietary thing that only applies to one specific device. sometimes it is a standard that many devices follow, and one driver can work with a wide variety of devices implementing that standard
12:43:36 <zenix_2k2> but the DDK which you advised me doesn't seem to be it, it is still... too general on what is going on behind the scene
12:43:55 <doug16k> you asked how to make a windows driver. DDK is the answer
12:44:30 <zenix_2k2> well yea, actually my first question was meant to be longer than that but i am too suck at expressing :P
12:44:44 <zenix_2k2> but building driver is still a part of it
12:44:56 <doug16k> the whole point is not knowing everything down to the metal. operating systems provide abstractions so you can write one piece of code that works on a variety of hardware
12:45:20 --- quit: bemeurer (Remote host closed the connection)
12:45:37 <zenix_2k2> but to build one you need to know it down to the metal right ? and i mean not using it to write code but building one like it
12:45:40 <doug16k> the OS developers suffer with the machine-specifics, so application developers don't need to reinvent everywheel
12:45:43 --- join: bemeurer (~bemeurer@stdcognition.static.monkeybrains.net) joined #osdev
12:46:37 <aalm> you need to write something before building..
12:46:59 <doug16k> same thing applies to drivers. drivers use OS facilities to provide assistance with things. a driver shouldn't need to know how to program the interrupt controller. it asks something else in the OS to do that, something else that knows all about this specific architecture's interrupt controller
12:47:01 <zenix_2k2> well i did
12:47:06 <kingoffrance> i guess zenix is more into electrical side of things, what does 1 and 0 "physically" mean?
12:47:11 <zenix_2k2> i do know C, Python and a bit Assembly
12:47:15 --- quit: variable (Quit: Found 1 in /dev/zero)
12:47:30 <zenix_2k2> electricial signals ? 1 represents a stronger signal
12:48:20 <kingoffrance> thats the only way i can interpret "how do they build hardware"
12:48:27 --- join: blackandblue (~batdownh@gateway/tor-sasl/blackandblue) joined #osdev
12:49:06 <zenix_2k2> but still how can a "virtual thing" which isn't touchable can send those 1 and 0 signals to the hardware ?
12:50:03 <zenix_2k2> and actually i do want to build an OS of my own, just a simple one... maybe that will make things clearer
12:50:16 <zenix_2k2> so i am just wondering if anyone here has any suggestion on building one ?
12:50:28 <zenix_2k2> i mean suggestion on which books or course
12:51:52 --- quit: Vulcan_ (Remote host closed the connection)
12:52:15 --- join: Vulcan_ (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
12:52:43 --- quit: Vulcan_ (Remote host closed the connection)
12:52:56 --- quit: aalm (Ping timeout: 240 seconds)
12:53:09 <kingoffrance> well, the "Virtual thing" itself is likely 1s and 0s effectively. this punched hole is 1 and non-punched hole is 0 :)
12:53:36 <kingoffrance> err, non-hole
12:54:26 <doug16k> zenix_2k2, I gave you lots of suggestions for what to read
12:54:46 <doug16k> you loaded up the book page and didn't even scroll it, just came back asking what algorithms have to do with anything
12:55:14 <zenix_2k2> well i did scroll it that is how i know it was algorithms
12:55:18 --- join: aalm (~aalm@37-219-32-75.nat.bb.dnainternet.fi) joined #osdev
12:55:43 <doug16k> ah, well that book shows on my screen on initial load
12:57:01 <zenix_2k2> Hm, weird... but it took me a few scrolls to see it
12:57:38 <zenix_2k2> but yea, i will just first research those 8 things before going any further
12:57:40 <zenix_2k2> thk anyway
12:58:04 --- join: cdzeno (~cdzeno@host15-225-dynamic.15-87-r.retail.telecomitalia.it) joined #osdev
12:58:43 <kingoffrance> at the very broad level, i would say hw and sw converge. you can simulate hw in sw, or you can simulate sw in hw (e.g. add a floating point unit/instructions)
12:58:57 <doug16k> zenix_2k2, you probably want to look at the ones about computer architecture and operating system internals
12:59:24 --- quit: blackandblue (Remote host closed the connection)
12:59:53 <doug16k> really though, the trick with OS dev is not overwhelming yourself to a halt with unstable code. it's all you in a kernel, if it's unstable the results are disastrous resets and lockups
12:59:58 --- join: blackandblue (~batdownh@gateway/tor-sasl/blackandblue) joined #osdev
13:01:30 <zenix_2k2> well ok then
13:02:10 <kingoffrance> if you drag a magnet across a hard drive and toggle the bits...is that a hw magnet or sw? it toggles the bits just like "software" would :)
13:02:25 <kingoffrance> you just did it "manually"
13:03:09 <kingoffrance> likewise, whether you punch a card by hand or a computer does it, the CPU doesnt really know nor care
13:03:34 <kingoffrance> perhaps over the years with "integrated" things, we see a separation that originally was less there.
13:06:24 <zenix_2k2> yea i think this is more like electrical stuffs, more than OSes that i am wondering
13:08:06 --- quit: bender (Quit: Connection closed for inactivity)
13:11:08 <kingoffrance> it gets even funnier, look up "computer" in an old dictionary. just a person who computes
13:11:20 <kingoffrance> in reality, our hardware, we are just simulating humans i suppose :)
13:11:26 <kingoffrance> just faster more precise people...
13:12:11 <kingoffrance> in truth, the first "computer" was some dude unless we want to say "this bird counts how many worrms to feed to its children"
13:12:46 --- join: hmmmmm (~sdfgsf@pool-72-79-164-24.sctnpa.east.verizon.net) joined #osdev
13:15:50 --- quit: hmmmm (Ping timeout: 248 seconds)
13:17:43 <zenix_2k2> yea talking about it, so what do you call a person who computes nowadays ?
13:19:46 --- quit: user10032 (Quit: Leaving)
13:20:44 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
13:21:10 <renopt> a wageslave :P
13:22:16 --- quit: manzerbredes (Ping timeout: 245 seconds)
13:22:33 <S_Gautam> kingoffrance: eventually we will be hardware as well
13:23:45 <doug16k> zenix_2k2, you call them a person that needs to buy a computer
13:25:01 <zenix_2k2> nya, that is what we call a customer
13:26:31 --- quit: zeus1 (Ping timeout: 264 seconds)
13:29:45 --- part: zenix_2k2 left #osdev
13:46:03 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
13:46:22 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
13:53:33 --- quit: vmlinuz (Quit: Leaving)
14:02:50 --- join: jjuran (~jjuran@c-73-250-47-193.hsd1.md.comcast.net) joined #osdev
14:08:23 --- join: elevated (~elevated@gateway/tor-sasl/elevated) joined #osdev
14:09:46 --- join: Vulcan_ (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
14:09:48 --- quit: sortie (Quit: Leaving)
14:10:06 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
14:13:48 --- quit: cdzeno (Quit: Leaving)
14:15:21 --- quit: glauxosdever (Quit: leaving)
14:19:57 --- quit: dennis95 (Quit: Leaving)
14:20:19 --- quit: aalm (Ping timeout: 240 seconds)
14:20:54 --- join: aalm (~aalm@37-219-19-84.nat.bb.dnainternet.fi) joined #osdev
14:22:11 --- nick: pie_ -> ^pie_^
14:23:14 --- join: sdfgsd (~root@213.74.82.169) joined #osdev
14:26:09 --- join: Naergon (~Naergon@unaffiliated/naergon) joined #osdev
14:29:01 --- join: SwiftMatt (~Objective@2601:282:4300:3e:210e:d4e9:6154:3e91) joined #osdev
14:32:28 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
14:38:07 --- join: immibis (~chatzilla@222-155-163-212-fibre.sparkbb.co.nz) joined #osdev
14:38:42 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
14:39:14 --- join: jack_rabbit (~jack_rabb@c-73-211-181-224.hsd1.il.comcast.net) joined #osdev
14:42:06 --- join: zeus1 (~zeus@197.239.32.35) joined #osdev
14:43:45 --- join: nur (~hussein@175.141.139.171) joined #osdev
14:44:23 --- quit: Asu (Remote host closed the connection)
14:44:35 --- quit: [MisbehavingOS] (Quit: Je t'emmerde! si je veux changer de pseudo je le change! :))
14:45:05 --- join: mra90 (~Martin@host-85-202-159-241.sta.tvknaszapraca.pl) joined #osdev
14:48:07 --- join: graphene (~graphene@46.101.134.251) joined #osdev
14:49:36 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
14:51:27 --- quit: graphene (Read error: Connection reset by peer)
14:51:34 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
14:53:04 --- join: graphene (~graphene@46.101.134.251) joined #osdev
14:56:38 --- quit: zeus1 (Ping timeout: 248 seconds)
14:57:44 --- quit: naortega (Quit: Vivu lante, vivu feliĉe!)
15:03:43 --- quit: immibis (Ping timeout: 264 seconds)
15:07:37 --- join: [MisbehavingOS] (~while@unaffiliated/awaxx/x-0928682) joined #osdev
15:11:29 --- quit: kimundi (Read error: Connection reset by peer)
15:11:40 --- join: kimundi (~Kimundi@i577A91DE.versanet.de) joined #osdev
15:25:20 <graphitemaster> wow, SUSE sold for 2.5 bn
15:26:43 --- quit: Shamar (Quit: leaving)
15:35:04 --- quit: sortie (Read error: Connection reset by peer)
15:35:04 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
15:37:46 --- nick: ^pie_^ -> pie_
15:39:07 <booyah> wut?
15:40:41 --- join: zeus1 (~zeus@154.225.219.161) joined #osdev
15:45:47 --- quit: Vulcan_ (Remote host closed the connection)
15:46:12 --- join: Vulcan (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
15:46:39 --- quit: Vulcan (Remote host closed the connection)
15:52:13 --- quit: freakazoid0223 (Remote host closed the connection)
15:53:26 --- join: freakazoid0223 (~mattc@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
16:02:30 --- quit: jjuran (Quit: jjuran)
16:06:22 --- quit: FManTropyx (Quit: sinclair.z80.guru)
16:07:40 <palk> booyah: https://www.suse.com/c/news/suse-partners-with-growth-investor-eqt-to-continue-momentum-strategy-execution-and-product-expansion/
16:07:43 <bslsk05> ​www.suse.com: SUSE Partners with Growth Investor EQT to Continue Momentum, Strategy Execution and Product Expansion - SUSE Communities
16:08:12 --- quit: booyah (Read error: Connection reset by peer)
16:09:21 --- join: booyah (~bb@193.25.1.157) joined #osdev
16:12:53 --- quit: booyah (Read error: Connection reset by peer)
16:14:05 --- join: booyah (~bb@193.25.1.157) joined #osdev
16:17:08 --- quit: Naergon (Ping timeout: 268 seconds)
16:18:50 --- quit: zeus1 (Ping timeout: 256 seconds)
16:19:17 <kingoffrance> well, the word "Computer" is lost, but if you asked for the king to show you his computer, he wouldnt wheel out an abacus, hed wheel out his astrologer who did the "reckoning". the abacus was just a secondary peripheral device, had to be driven by the actual "computer".
16:20:33 --- join: elderK (uid205007@pdpc/supporter/active/elderk) joined #osdev
16:26:31 --- quit: pochito (Ping timeout: 264 seconds)
16:29:52 --- join: booyah_ (~bb@193.25.1.157) joined #osdev
16:30:05 --- quit: booyah (Read error: Connection reset by peer)
16:32:05 --- join: nastaki (~nastaki@d75-154-180-31.bchsia.telus.net) joined #osdev
16:32:54 <nastaki> im my eyes those cranks that do not have any achievement which means either national team membership or something similar to show
16:33:07 <nastaki> i count them to be as abortion leftovers
16:34:17 <klys> abort abort
16:34:24 <nastaki> and we have quite a lot of those noisy leftovers
16:34:48 <klys> your religious opinions are off-topic.
16:35:10 <nastaki> they should not be eligible to talk to be but they go over their shadow and looking to be humiliating me even
16:35:28 <nastaki> not facing the fact, that when i through a punch their dead
16:35:29 <klys> your political opinions are also off-topic.
16:35:47 <nastaki> throw
16:36:07 <klys> your metaphysical idea is off-topic as well.
16:37:06 <nastaki> i hate abortionleftovers who have something to say to me, and i damn well have enough of resources to order a murder to them
16:38:00 <klys> your religious opinion is off-topic. your political opinion, while off-topic, is also ujust, and I have to ask you how you can harm others while remaining sane?
16:38:47 --- mode: ChanServ set +o klange
16:38:50 <nastaki> they harmed me, i just finish them
16:38:51 --- kick: nastaki was kicked by klange (nastaki)
16:40:25 <chrisf> klys: dont engage :(
16:40:33 <klys> :(
16:41:38 --- mode: Mutabah set -o Mutabah
16:41:41 <Mutabah> 'morning everyone
16:41:47 <klys> hi
16:41:52 <klys> what's new
16:42:11 <Mutabah> Morning blues mostly :)
16:42:36 <klange> All of my friends are in LA this week.
16:42:49 <klange> And I'm just sitting here at work.
16:43:22 --- quit: xenos1984 (Quit: Leaving.)
16:45:24 <klys> I had a shot at using memory structures to cover 64 KiB, since the smaller allocator is working; it needs a number of extra variables though. then I took a nap.
16:47:00 <klys> i'm writing this all in assembly with nasm.
16:50:41 --- join: nicht (~nicht@2804:7f1:2080:1b7b:a117:a53e:8a3f:653) joined #osdev
16:51:27 <klys> the memory leaf structure is { byte* start[ 16 ]; byte* end[ 16 ]; leaf* prev,* next; };
16:51:27 --- quit: nicht (Remote host closed the connection)
16:51:51 --- join: nicht (~nicht@2804:7f1:2080:1b7b:a117:a53e:8a3f:653) joined #osdev
16:53:05 <klys> upon completion i'll work on twig, branch, limb, and trunk structures to cover 4 GiB.
16:53:53 <klys> the leaf structure is the only one with end pointers.
16:55:35 <klys> the other structures just point to their subordinates.
16:55:41 --- join: jjuran (~jjuran@c-73-132-80-121.hsd1.md.comcast.net) joined #osdev
16:56:39 --- quit: nicht (Remote host closed the connection)
16:57:03 --- join: nicht (~nicht@2804:7f1:2080:1b7b:a117:a53e:8a3f:653) joined #osdev
16:57:05 --- quit: nicht (Max SendQ exceeded)
16:57:08 --- quit: graphene (Remote host closed the connection)
16:57:32 --- join: nicht (~nicht@2804:7f1:2080:1b7b:a117:a53e:8a3f:653) joined #osdev
16:57:50 <klys> my first complete allocation routines will likely use a first-fit strategy.
16:58:46 --- join: graphene (~graphene@46.101.134.251) joined #osdev
17:00:47 <klange> you're putting a lot of thought into this allocator
17:01:09 <klys> yeah, all of the structures refer to 16 subordinate units.
17:02:20 --- join: zeus1 (~zeus@154.225.219.161) joined #osdev
17:03:02 <chrisf> im not sure there's any way other than upfront thought if you're doing it in assembly.
17:04:25 <chrisf> klys: is this for page frames, or address space, or what?
17:04:27 <klys> I mostly start with somewhat of a pseudocode routine and then plug it into nasm. the next goal after memory allocation is debugging.
17:04:47 <klys> chrisf, paging is turned off.
17:05:04 <chrisf> ick, ok.
17:05:59 <klys> by debugging I mean, calculation and then emulation
17:06:56 <klys> I intend to preserve the calculator for a later user interface goal.
17:07:42 <klys> so yeah, it'll work like the allocators did in 16-bit dos, except smarter and with a tree structure.
17:07:58 <klys> and it's all 32-bit for now.
17:09:27 <klys> preserving the registers on the trampoline for user interaction ought to be fun when I get to it
17:11:02 --- quit: chao-tic (Ping timeout: 248 seconds)
17:12:46 <klys> and it will emulate protected mode this way, with either qemu or libx86 code.
17:16:23 <klys> this program has a multiboot2 version and a dos version
17:16:41 --- join: palk_ (~palk@unaffiliated/palk) joined #osdev
17:17:21 <klys> the dos version works with the emx extender for vcpi, and I intend to modify vcpi to actually support multiple control programs with a standardized interface that looks like vcpi did originally.
17:18:18 <klys> the multiboot2 version is what i'm working with recently, even though the dos version is fairly compatible and work.
17:18:21 --- quit: palk (Ping timeout: 260 seconds)
17:18:32 <klys> works*.
17:19:41 <klys> so it will look like coo-erative kernels in 32-bit real mode interacting loosley and emulating protected mode.
17:20:37 <klys> basically all that ill be needed to add a kernel to the mix will be some scheduler code and everything else is optional.
17:21:11 <chrisf> this is pmode, just with paging disabled, correct?
17:21:21 <klys> yes
17:21:25 <klys> no
17:21:35 <klys> this is real-mode programming
17:23:08 <klys> as soon as multiboot2 loads the kernel it switches to real-mode with a helper routine in low memory.
17:23:24 --- quit: pie_ (Remote host closed the connection)
17:23:52 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
17:25:16 --- nick: jack_rabbit -> knusbaum
17:25:20 <klys> there are also helper routines in low memory for conditional branching. that'll surely sour you, though possibly the best thing will be porting everything to riscv at some stage.
17:26:45 <klys> as of today, riscv has no video, so I can't see working with it yet.
17:26:54 <klange> agreed
17:27:03 <klange> gimme a framebuffer and we can talk
17:27:09 <chrisf> this is a curious collection of bizarre decisions
17:27:14 <chrisf> but good luck to you :)
17:27:58 --- quit: pie_ (Remote host closed the connection)
17:28:23 <klys> well, I'm not turing off support for x86_32 ever, so there may be room to discuss what is advisable.
17:29:03 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
17:29:05 --- join: pie__ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
17:29:37 --- quit: pie__ (Remote host closed the connection)
17:30:48 <geist> hello
17:30:53 <geist> i am here
17:30:54 <klys> h-hi
17:31:11 <geist> and thus the party can commence
17:31:22 <klange> woo
17:31:28 <klys> w00t
17:31:28 <klange> oh and happy murica day
17:31:36 <geist> that's tomorrow
17:31:41 <klange> not here in not-america
17:31:52 <geist> i'm heading to canada the day after though
17:32:04 <geist> not forever (unfortunately), but for a week
17:32:06 <klange> i have this weird habit of not being in the US for muricah day.
17:32:09 <klys> on the east coast, it's 10:30pm
17:32:19 <klange> it's less weird now that I'm permanently not in the U S
17:32:26 <klange> but before that it was a bit weird
17:32:28 <geist> word
17:32:30 --- mode: ChanServ set -o klange
17:32:51 <geist> spent the last few days with fam at Lake Chelan. nice lake in eastern washington state
17:33:15 <klys> on the east coast, it's 8:30pm, rather.
17:33:26 <geist> recommended. also 3rd deepest lake in the US
17:33:45 <klys> what does the beach look like? sand?
17:34:38 <geist> mostly rock, it's a narrow very deep (1400ft) glacial lake
17:34:42 <klange> old uni friend of mine is hiking into the wilderness for a few weeks, good luck to him
17:34:46 --- quit: S_Gautam (Quit: Connection closed for inactivity)
17:35:13 <geist> went to a water park for a day, first time in a while. lots of fun. you can never be too old to have fun at a good water park
17:35:55 <klys> happy summertime
17:36:33 <geist> lots of wineries too: https://photos.app.goo.gl/Z1wJmZ79LDiw9US47
17:37:52 --- nick: knusbaum -> jack_rabbit
17:38:05 --- join: SwiftMatt (~Objective@2601:282:4300:3e:210e:d4e9:6154:3e91) joined #osdev
17:39:09 --- quit: graphene (Remote host closed the connection)
17:40:42 --- join: graphene (~graphene@46.101.134.251) joined #osdev
17:46:42 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
17:47:06 --- join: Vulcan (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
17:49:34 --- join: NaNkeen (~nankeen@61.6.126.158) joined #osdev
17:50:27 --- join: SwiftMatt (~Objective@2601:282:4300:3e:210e:d4e9:6154:3e91) joined #osdev
17:51:26 --- quit: Vulcan (Ping timeout: 240 seconds)
17:52:15 --- quit: brynet (Ping timeout: 255 seconds)
17:54:14 --- quit: kimundi (Ping timeout: 248 seconds)
18:03:15 --- quit: spare (Quit: leaving)
18:10:05 --- join: promach_ (~promach@219.74.174.136) joined #osdev
18:11:20 --- quit: quc (Ping timeout: 256 seconds)
18:19:04 --- quit: zeus1 (Ping timeout: 256 seconds)
18:36:32 --- quit: bemeurer (Quit: WeeChat 2.1)
18:37:44 --- quit: tacco| ()
18:38:57 --- quit: palk_ ()
18:39:16 --- quit: promach_ (Quit: WeeChat 2.1)
18:42:27 --- quit: booyah_ (Read error: Connection reset by peer)
18:43:37 --- join: booyah_ (~bb@193.25.1.157) joined #osdev
18:45:24 --- join: ybyourmom (~ybintell@vampire.ertos.nicta.com.au) joined #osdev
18:55:35 --- quit: JusticeEX (Ping timeout: 260 seconds)
18:56:51 --- quit: graphene (Remote host closed the connection)
18:58:23 --- join: graphene (~graphene@46.101.134.251) joined #osdev
19:02:04 --- join: zeus1 (~zeus@154.225.219.161) joined #osdev
19:05:17 --- quit: nicht (Ping timeout: 256 seconds)
19:07:09 --- quit: graphene (Remote host closed the connection)
19:07:27 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
19:08:19 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
19:08:45 --- join: graphene (~graphene@46.101.134.251) joined #osdev
19:09:24 --- quit: Tazmain (Quit: Leaving)
19:12:13 --- quit: rafaeldelucena (Ping timeout: 245 seconds)
19:12:49 --- quit: chao-tic (Ping timeout: 240 seconds)
19:13:10 --- quit: zeus1 (Ping timeout: 248 seconds)
19:13:19 --- join: brynet (~brynet@brynet6.biz.tm) joined #osdev
19:14:39 --- quit: ratschance (Remote host closed the connection)
19:15:02 --- join: ratschance (~ratschanc@205.175.226.96) joined #osdev
19:15:12 --- quit: booyah_ (Read error: Connection reset by peer)
19:16:22 --- join: booyah_ (~bb@193.25.1.157) joined #osdev
19:17:11 --- quit: booyah_ (Read error: Connection reset by peer)
19:18:51 --- join: booyah_ (~bb@193.25.1.157) joined #osdev
19:20:14 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
19:23:31 --- quit: booyah_ (Read error: Connection reset by peer)
19:23:46 --- join: rafaeldelucena (~rafaeldel@2804:14d:ba83:2709:1db9:fe9:9bb:d45f) joined #osdev
19:24:41 --- join: booyah_ (~bb@193.25.1.157) joined #osdev
19:24:48 --- join: stoopkid (uid137696@gateway/web/irccloud.com/x-bdsfhqlauwpymemx) joined #osdev
19:25:57 --- quit: JusticeEX (Quit: Lost terminal)
19:30:31 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
19:36:43 --- quit: MDude (Ping timeout: 264 seconds)
19:41:31 --- quit: NaNkeen (Ping timeout: 264 seconds)
19:47:27 --- join: Vulcan (~Vulcan@rc137-3-88-172-220-120.fbx.proxad.net) joined #osdev
19:52:00 --- quit: Vulcan (Ping timeout: 256 seconds)
19:55:12 --- quit: booyah_ (Read error: Connection reset by peer)
19:56:54 --- join: zeus1 (~zeus@154.225.219.161) joined #osdev
19:58:36 --- join: booyah_ (~bb@193.25.1.157) joined #osdev
20:08:44 --- quit: booyah_ (Read error: Connection reset by peer)
20:09:12 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
20:09:58 --- join: booyah_ (~bb@193.25.1.157) joined #osdev
20:10:22 --- quit: zeus1 (Ping timeout: 265 seconds)
20:11:09 --- join: pochito (~pochito@190.179.33.162) joined #osdev
20:14:06 --- quit: chao-tic (Ping timeout: 256 seconds)
20:15:30 --- quit: nj0rd (Ping timeout: 276 seconds)
20:22:03 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
20:28:05 <Jack_> Can anyone take a look at this little Gist I made of me trying to use the iretq instruction to load a new cs segment register value and see if anything seems obviously off?
20:28:06 <Jack_> https://gist.github.com/TheCynosure/ced2352e1671e2d2a9f55e3b38afd94b
20:28:07 <bslsk05> ​gist.github.com: Trying to do an IRETQ but for some reason it is failing in qemu. · GitHub
20:28:48 --- join: nj0rd (~nj0rd@200116b845c77c0013e5fb0dabe6c5f4.dip.versatel-1u1.de) joined #osdev
20:29:03 <Jack_> The code continuously crashes on the iretq instruction. I am almost positive the stack is correct but maybe something else is obvious to others?
20:29:48 <Jack_> I cant load the label directly onto the stack because I get a relocation linking error as it is an absolute address, this might be a problem but I can't tell because I am a noob :P
20:36:18 --- quit: blackandblue (Remote host closed the connection)
20:37:56 <Mutabah> Why are you changing CS?
20:38:26 <Mutabah> Also - iretq pops SS/RSP too
20:39:58 <Mutabah> Jack_: If you're using qemu - try single-stepping with gdb, and/or use the interrupt tracing support to determine exactly where the crash happens and why
20:41:29 <geist> yah the key is what are you doing it for? to enter user space or just to refresh cs with another priviledged cs?
20:41:43 <geist> and what modes are you in and what modes are you intending to switch to
20:42:26 <geist> well, looks like they're just trying to load an address for the next line i guess, so probably just refreshing the cs
20:43:40 <geist> if you just want to reload cs you can probably do it with a lret as well, which then doesn't involve flags and reloading ss and whatnot
20:46:08 --- quit: graphene (Remote host closed the connection)
20:47:41 --- join: graphene (~graphene@46.101.134.251) joined #osdev
20:49:15 --- quit: pochito (Quit: Leaving)
20:54:14 --- join: zeus1 (~zeus@154.225.219.161) joined #osdev
20:57:08 --- quit: graphene (Remote host closed the connection)
20:58:42 --- join: graphene (~graphene@46.101.134.251) joined #osdev
20:58:49 --- quit: zeus1 (Ping timeout: 240 seconds)
20:59:41 --- quit: drakonis (Remote host closed the connection)
21:00:32 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
21:04:49 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
21:11:06 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
21:13:05 --- join: SwiftMatt (~Objective@2601:282:4300:3e:210e:d4e9:6154:3e91) joined #osdev
21:22:36 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
21:23:11 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
21:23:34 <Jack_> Sorry guys, went afk for a bit
21:23:49 <Jack_> But I am trying to reload the cs because I am loading a new gdt
21:24:00 --- join: navidr (uid112413@gateway/web/irccloud.com/x-cjpvouhuwadhknjv) joined #osdev
21:24:03 <Jack_> But since this is 64 bit I can't use a far jump
21:24:18 <Jack_> And I tried a retfq but that also didn't work at all
21:24:26 <Jack_> Its been a real pain in the butt
21:26:19 --- quit: freakazoid0223 (Ping timeout: 240 seconds)
21:26:34 <Jack_> Also, I have been single stepping with GDB and know that it is crashing exactly at the retq or iretq line
21:26:37 <Jack_> instruction
21:32:08 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
21:32:20 --- quit: cirno_ (Remote host closed the connection)
21:32:27 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
21:32:57 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
21:34:17 --- join: NaNkeen (~nankeen@61.6.126.158) joined #osdev
21:34:26 <Mutabah> Jack_: As said, it also pops ss/rsp - so add those
21:34:43 <Mutabah> Jack_: Also, stop at the iretq and inspect the stack - just to be sure
21:36:23 <Jack_> Okay will do
21:37:03 <Jack_> In the documentation it doesn't say that it pops a ss
21:37:28 <Jack_> Do you think I should just switch back to a far return as it says that IRETQ will just do a far return if the EFLAGS register is cleared anyway
21:39:35 --- join: manzerbredes (~loic@2a01cb0885e31500cfc30bb534d5bc37.ipv6.abo.wanadoo.fr) joined #osdev
21:40:34 <Mutabah> Which documentation doesn't say that it pops ss? The instruction docs do say that iirc (in the pseudocode for 64-bit mode)
21:41:38 --- quit: cirno_ (Ping timeout: 250 seconds)
21:41:38 <Jack_> I was looking at the 32 bit documentation sadly I just realized, doubt it is different but I don't trust it anymore
21:42:09 <Mutabah> Instruction behaviors can change quite a bit between PMode and LMode
21:42:17 <Jack_> Ya
21:43:21 <klys> you still haven't said what your cs: descriptor looks like
21:47:00 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
21:47:17 <Jack_> 0x9a 0xef 0x00 0xff
21:47:28 <Jack_> That is my code descriptor that I just printed off using gdb
21:48:04 <Mutabah> They're 8 bytes long for starters
21:48:21 <Jack_> Wait no sorry I mispoke its this
21:48:43 <Jack_> 0xff 0x00 0x00 0x00 0x9a 0xef 0x00 0x00
21:49:02 --- join: kimundi (~Kimundi@i577A91DE.versanet.de) joined #osdev
21:50:48 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
21:54:02 <Jack_> Alright a problem was definetly just found, I had aligned the struct instead of packing it
21:54:09 <Jack_> With the packing the value changes
21:54:29 <Jack_> Into this: 0xff 0xff 0x00 0x00 0x00 0x9a 0xef 0x00
21:54:33 <Jack_> That makes more sense
21:55:19 <Jack_> And checking the value against my struct that is what I intended it too look like
21:59:03 <Jack_> And my stack before calling retfq is the following: 0x00000000068f76b4 0x0000000000000008
21:59:26 <Jack_> And the first qword on the stack is a valid memory address in my program using gdb
22:01:37 --- quit: Kazinsal (Read error: Connection reset by peer)
22:02:19 --- quit: cirno_ (Remote host closed the connection)
22:02:37 --- join: zeus1 (~zeus@81.199.19.241) joined #osdev
22:03:08 --- join: Kazinsal (~Kazinsal@unaffiliated/kazinsal) joined #osdev
22:03:10 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
22:06:38 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
22:08:49 --- quit: ybyourmom (Ping timeout: 240 seconds)
22:10:01 <Mutabah> Jack_: And the third, fourth, and fifth?
22:10:06 --- join: ybyourmom (~ybintell@vampire.ertos.nicta.com.au) joined #osdev
22:11:52 <Jack_> My stack before retf: 0x00000000068f76b4 0x0000000000000008 0x0000000000000180 0x0000000000000200 0x0000000007f949d0
22:12:01 <Jack_> But retfq also only pops two arguments
22:12:07 <Jack_> cs and rip
22:12:08 <Mutabah> Oh, retf
22:12:14 <Mutabah> I thought you were still using iret
22:12:23 <Jack_> Yes I switched over, sorry if thats a shakeup
22:12:37 <Jack_> I just thought it would be easier to deal with
22:12:38 <Mutabah> Check your GDT
22:12:47 <Mutabah> and the GDTR
22:12:54 <Jack_> Okay I will check again but heres the thing
22:12:55 <Mutabah> and turn on interrupt tracing in qemu `-d int`
22:13:13 <Mutabah> If that doesn't give you more of a hint, then maybe see if you can get bochs working
22:13:26 <Mutabah> (bochs provides a very detailed log of crashes)
22:13:30 --- quit: chao-tic (Quit: WeeChat 1.0.1)
22:13:40 <Jack_> UEFI sets up the GDT for you and sets cs to index 5, I setup a gdt with a code descritpor at gdt[4] and if I dont change the cs register than the kernel continues to work fine
22:14:08 --- quit: graphene (Remote host closed the connection)
22:14:09 <Jack_> Because I am using UEFI I don't think I can use bochs to debug and I have the -d int option active
22:14:10 <Mutabah> Where is your code descriptor when you're running this `retf`?
22:14:26 <Jack_> My code descriptor is a static array of c structs inside my code
22:14:37 <Jack_> MY code descriptor is an element in this array*
22:15:29 --- join: SwiftMatt (~Objective@2601:282:4300:3e:210e:d4e9:6154:3e91) joined #osdev
22:15:39 --- join: graphene (~graphene@46.101.134.251) joined #osdev
22:15:40 <Mutabah> I meant what index
22:15:59 <Jack_> Technically speaking 1 and 5
22:16:11 <Mutabah> Zero based?
22:16:28 <Jack_> I have the one at 1 that I am trying to switch too and the one at 5 that I know works if I don't change the cs
22:16:31 <Jack_> Yes its zero based
22:16:37 <Jack_> 0 would be the null descriptor
22:16:55 <Mutabah> The one at 5 won't ever get loaded
22:17:04 <Mutabah> Well, assuming that you don't try to reload cs
22:17:41 <Jack_> Why wouldn't the one at 5 be loaded? I thought when you reload the gdt it would reload that little hidden part of each segment register
22:17:51 <Jack_> But I guess if it didn't then that would make sense
22:19:12 <Mutabah> `lgdt` just sets where the CPU will look for GDT descriptors
22:19:21 <Mutabah> it only reads when reloading a segment register
22:19:45 <Jack_> Oh ok that makes sense then why the program continues working when I don't try and reload the cs segment register
22:20:29 <Jack_> This definetly makes me think it is my gdt then that is screwed up
22:20:36 <Jack_> I'm going to check that now
22:21:45 <Mutabah> if you don't reload it, it just keeps using the cached values
22:23:04 --- quit: bauen1 (Remote host closed the connection)
22:24:04 --- quit: manzerbredes (Ping timeout: 256 seconds)
22:24:34 <Jack_> Welp this is very embarrassing but thank you for sticking with me Mutabah
22:24:50 <Jack_> I was able to get it working because I had set the D bit and the L bit
22:25:00 <Jack_> But the AMD64 Documentation clearly states that this is illegal
22:25:07 <Jack_> Thank you so much
22:25:39 --- quit: SwiftMatt (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
22:29:35 --- quit: elderK (Quit: Connection closed for inactivity)
22:29:40 --- join: clever (~clever@unaffiliated/clever) joined #osdev
22:31:11 --- quit: Jack_ (Quit: Page closed)
22:32:20 --- quit: cirno_ (Remote host closed the connection)
22:32:55 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
22:52:07 --- quit: nur (Quit: Leaving)
22:57:07 --- join: snowball (~communi@159.148.172.3) joined #osdev
22:57:38 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
23:00:42 --- quit: NaNkeen (Ping timeout: 240 seconds)
23:02:20 --- quit: cirno_ (Remote host closed the connection)
23:03:01 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
23:07:17 --- join: immibis (~chatzilla@222-155-163-212-fibre.sparkbb.co.nz) joined #osdev
23:07:20 --- quit: stoopkid (Quit: Connection closed for inactivity)
23:08:34 --- join: manzerbredes (~loic@myriads-lg.irisa.fr) joined #osdev
23:08:42 --- join: xerpi (~xerpi@0.red-83-45-194.dynamicip.rima-tde.net) joined #osdev
23:10:28 --- quit: xerpi (Remote host closed the connection)
23:10:41 --- quit: kimundi (Ping timeout: 260 seconds)
23:10:53 --- join: xerpi (~xerpi@0.red-83-45-194.dynamicip.rima-tde.net) joined #osdev
23:16:18 --- quit: vdamewood (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
23:21:56 --- join: NaNkeen (~nankeen@61.6.126.158) joined #osdev
23:23:44 --- join: nur (~hussein@175.141.139.171) joined #osdev
23:29:28 --- join: dbittman_ (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
23:30:35 --- quit: NaNkeen (Ping timeout: 276 seconds)
23:32:20 --- quit: cirno_ (Remote host closed the connection)
23:33:02 --- join: cirno_ (~cirno_@gateway/tor-sasl/cirno/x-25801483) joined #osdev
23:34:57 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
23:35:17 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:35:48 --- join: Avinash (~Avinash@unaffiliated/avinash) joined #osdev
23:42:08 --- quit: xerpi (Remote host closed the connection)
23:43:13 --- join: xerpi (~xerpi@0.red-83-45-194.dynamicip.rima-tde.net) joined #osdev
23:43:15 --- quit: dbittman_ (Ping timeout: 255 seconds)
23:53:40 --- join: nastaki (~nastaki@ip98-164-227-11.oc.oc.cox.net) joined #osdev
23:54:05 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
23:55:29 <nastaki> such a guy who does not have any sport acheivement to show, to understand and back up their words, is considered a terrorist in my life right away! It's a fact that any average or above sportsman does not bully the shit out of others or make prankscams to happen
23:57:09 --- mode: ChanServ set +o Mutabah
23:57:15 --- kick: nastaki was kicked by Mutabah (Goodbye.)
23:59:59 --- log: ended osdev/18.07.03