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

Tuesday, 10 July 2018

00:00:00 --- log: started osdev/18.07.10
00:06:00 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
00:06:19 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:08:40 --- quit: tux3 (Changing host)
00:08:40 --- join: tux3 (tux@unaffiliated/tux3) joined #osdev
00:13:22 --- quit: CheckDavid (Quit: Connection closed for inactivity)
00:16:48 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
00:16:56 --- quit: zeus1 (Ping timeout: 244 seconds)
00:18:07 --- quit: NaNkeen (Ping timeout: 264 seconds)
00:19:50 --- quit: nwm- (Ping timeout: 248 seconds)
00:20:20 --- quit: variable (Ping timeout: 276 seconds)
00:23:10 --- join: myvar (~myvar@105.186.208.217) joined #osdev
00:24:59 --- quit: myvar (Remote host closed the connection)
00:25:55 --- join: nwm (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
00:41:36 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
00:44:45 --- quit: Xal (Ping timeout: 268 seconds)
00:44:55 --- join: NaNkeen (~nankeen@61.6.132.35) joined #osdev
00:46:37 --- join: Xal (~Xal@S010664777dabacc3.vw.shawcable.net) joined #osdev
00:47:48 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
00:51:44 --- quit: trout (Ping timeout: 265 seconds)
00:52:01 --- join: X-Scale (~ARM@83.223.224.124) joined #osdev
00:55:02 --- quit: Stary (Ping timeout: 248 seconds)
00:56:28 --- quit: CompanionCube (Ping timeout: 268 seconds)
00:57:26 --- quit: [Nightmare] (Ping timeout: 240 seconds)
00:57:43 --- quit: AverageJ0e (Ping timeout: 264 seconds)
00:57:58 --- join: myvar (~myvar@105.186.208.217) joined #osdev
00:58:06 --- quit: myvar (Remote host closed the connection)
01:03:15 --- quit: karlguy (Ping timeout: 268 seconds)
01:06:42 --- join: quc (~quc@host-89-230-167-225.dynamic.mm.pl) joined #osdev
01:08:36 --- join: Stary (~Stary@osiris.9net.org) joined #osdev
01:10:06 --- join: [Nightmare] (~while@unaffiliated/awaxx/x-0928682) joined #osdev
01:11:48 --- join: Kimundi_ (~Kimundi@i577A9952.versanet.de) joined #osdev
01:16:55 --- nick: zeroSign1l -> zeroSignal
01:16:58 --- join: CompanionCube (~samis@unaffiliated/drmushroom) joined #osdev
01:17:35 --- quit: zeroSignal (Changing host)
01:17:35 --- join: zeroSignal (~ovi@fsf/member/zeroSignal) joined #osdev
01:18:35 --- quit: SopaXorzTaker (Read error: Connection reset by peer)
01:18:48 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
01:20:22 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
01:23:23 --- quit: variable (Ping timeout: 276 seconds)
01:27:12 --- quit: SopaXorzTaker (Ping timeout: 240 seconds)
01:29:58 --- join: Guest4630 (4d3b9548@gateway/web/cgi-irc/kiwiirc.com/ip.77.59.149.72) joined #osdev
01:32:33 --- join: debug (~debug@m90-144-158-55.cust.tele2.se) joined #osdev
01:33:02 --- join: vaibhav (~vnagare@125.16.97.112) joined #osdev
01:33:40 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
01:37:15 --- quit: Kimundi_ (Remote host closed the connection)
01:37:27 --- join: Kimundi_ (~Kimundi@i577A9952.versanet.de) joined #osdev
01:42:18 --- join: myvar (~myvar@105.186.208.217) joined #osdev
01:45:27 --- quit: myvar (Client Quit)
01:46:01 --- join: myvar (~myvar@105.186.208.217) joined #osdev
01:50:22 --- join: SopaXT (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
01:50:45 --- join: S_Gautam (uid286066@gateway/web/irccloud.com/x-ldebgurmxhibdkar) joined #osdev
01:50:49 --- quit: SopaXorzTaker (Disconnected by services)
01:50:51 --- nick: SopaXT -> SopaXorzTaker
01:53:06 --- quit: SopaXorzTaker (Remote host closed the connection)
01:53:19 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
01:54:00 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
01:54:41 --- join: Maxou56800 (~Maxou5680@fightthebadcode.org) joined #osdev
01:54:45 <Maxou56800> o/
01:56:12 --- quit: trout (Ping timeout: 240 seconds)
02:04:55 --- quit: SopaXorzTaker (Ping timeout: 264 seconds)
02:05:10 <myvar> \0/
02:05:16 <klange> ~o~
02:05:22 <klange> /o/
02:05:25 <klange> \o\
02:05:52 <myvar> #o#
02:05:59 <myvar> @o@
02:06:41 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
02:08:31 <izabera> ؟owo?
02:13:05 --- quit: [Nightmare] (Quit: neurosis is yours now... enjoy :))
02:13:13 <myvar> lol, i tink we are getting off topic xD
02:13:18 --- quit: xedniv (Remote host closed the connection)
02:14:01 --- join: xedniv (~xedniv@arms.trafficking.cn) joined #osdev
02:14:01 --- quit: xedniv (Changing host)
02:14:02 --- join: xedniv (~xedniv@unaffiliated/moldenauer) joined #osdev
02:20:38 <renopt> /o\
02:20:50 <klange> alright that's enough fun for now
02:20:55 <klange> back to osdev, everyone
02:21:20 <myvar> im frustraed with my hobby os
02:21:30 <klange> that's the default state of osdev
02:21:34 <_mjg_> :)
02:21:35 <myvar> i have hit a stumble block i dont know what to do next
02:21:41 <_mjg_> #relatable
02:21:44 <myvar> yea
02:21:54 <_mjg_> the standard thing to do is to take a break for few days
02:21:59 <_mjg_> or at least sleep on the problem once
02:22:03 <myvar> i took a break for 7 months
02:22:06 <renopt> or a few months, or years
02:22:07 <_mjg_> ouch
02:22:10 <myvar> yea
02:22:28 <myvar> + im a full time C# develpoer so my C baced os is prety messy
02:22:49 <myvar> can you recomend a next step: https://github.com/Myvar/MyvarOS
02:22:50 <bslsk05> ​Myvar/MyvarOS - An Operating System (4 forks/6 watchers)
02:23:16 <klange> I don't even need to see the repo to know it's time for you to write a GUI.
02:23:22 <klange> It's always time for everyone to write a GUI.
02:23:24 <klange> Trust me, I'm an expert.
02:23:36 <klange> I worked in the GUI department at Apple!
02:24:14 <myvar> i have writen a fully working rendering an rasterization tool kit in c# for Cosmos os dev
02:24:18 <myvar> but never in plain C
02:24:25 <myvar> my plain C skills are terible
02:24:36 <klange> Then obviously your first step is to port dotnet.
02:24:41 <myvar> xD
02:24:45 <klange> Then you can just run your C# stuff :)
02:24:58 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
02:24:59 <myvar> dotnet is extreamly complicated and os dependent
02:25:16 <myvar> i can probably implment .net il runtime i have even managed an experiment with that
02:25:24 <myvar> but then i would have to write my own stdlib
02:25:50 <myvar> the amount of work is so mutch it would beasyer to just make a new lang + compiler + stdlib from scratch
02:28:23 --- quit: variable (Ping timeout: 276 seconds)
02:28:54 --- join: Asu (~sdelang@158.15.136.77.rev.sfr.net) joined #osdev
02:29:05 <myvar> any recomendations for a play/pause media button app for blue tooth(arch linux)
02:32:36 <myvar> klange, any recomendation on setting vesa, in p mode ?
02:34:02 <renopt> have the bootloader do it, really the easiest way
02:34:50 <renopt> multiboot has a section where you can request video modes, and the info block tells you what settings you actually get
02:35:10 <myvar> yea thats the way i do it normaly
02:37:25 --- join: salek_ (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
02:39:26 --- quit: salek__ (Ping timeout: 240 seconds)
02:43:35 <klange> "don't"
02:43:57 --- quit: Goplat (Remote host closed the connection)
02:44:02 <klange> write drivers for things - start with vms - bochs, qemu, virtualbox all support the same virtual framebuffer interface, vmware's isn't too different
02:44:33 <klange> write a driver that assumes a mode was already set and can get info for it and set things up appropriately
02:44:51 <myvar> virtual box and botch both suport the bga vesa vbe driver
02:45:07 <myvar> i use that, but i was talking about real hardwear
02:45:15 <klange> there is no good way to do it in real hardware
02:45:30 <klange> even X11's vesa driver is an abysmal mess that uses an 8086 emulator to run BIOS code
02:45:47 <myvar> indeed
02:45:51 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
02:46:06 <myvar> what is UEFI
02:47:04 <myvar> is it juast an aplication loader ?
02:47:13 <myvar> for boot stages ?
02:47:17 <klange> UEFI is the thing that replaces BIOS.
02:47:32 <klange> It's very different in how you write boot code for it.
02:47:46 <myvar> can you make UEFI calls in pmode ?
02:48:06 <klange> That's a question with a complicated answer.
02:48:23 <klange> Most UEFI services are only available to bootloaders, and once you've "left" EFI they are no longer valid and almost definitely won't work.
02:48:32 <klange> But UEFI does provide some "runtime services".
02:48:34 <myvar> because aperently you can set video modes using UEFI with is a new thing
02:48:52 <klange> Things that sit in reserved memory that, with the right setup, can be called from an OS.
02:48:53 <vdamewood> is 'pmode' protected mode?
02:49:04 <myvar> yes
02:49:15 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
02:49:19 <myvar> pmode = protected mode
02:49:22 <vdamewood> On a 32-bit processor, UEFI will hand off to your boot image in protected mode.
02:49:34 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
02:50:06 <myvar> so it probebly wount work
02:50:12 --- quit: lecx (Ping timeout: 240 seconds)
02:50:15 <myvar> what ever il just use virtual machien divers for now
02:50:47 <klange> UEFI runs in protected or long mode, depending on platform, and runs applications with access to an API that provides many functions.
02:51:15 <klange> It's basically a small OS in its own right - it has filesystem drivers (for FAT, and maybe if you're lucky ISO9660), it has network drivers and even a usable IP stack...
02:51:28 <myvar> o wow
02:51:29 <klange> And unlike BIOS it provides these through a sane method - EFI applications are just PE executables.
02:51:51 <myvar> so is it work spending my time to learn it and move my os over to that ?
02:52:02 <klange> You don't move your OS to it, you write a bootloader for it.
02:52:07 <myvar> ah
02:52:11 <myvar> im with you
02:52:27 <klange> We had a discussion earlier about whether it's feasible to run an actual OS within UEFI, and it's just not something you should think about.
02:52:36 <myvar> ok
02:52:52 <myvar> UEFI gave me a lot of shit when i tried to install arch on my new laptop a month ago
02:53:02 --- quit: Kimundi_ (Quit: quit)
02:53:03 <klange> EFI has too many requirements for how you access hardware - it is very clear in the documentation that once you've brought up an actual OS, you need to leave EFI.
02:53:09 <myvar> that as far as my exsperiance gows with it xD
02:53:13 --- join: kimundi (~Kimundi@i577A9952.versanet.de) joined #osdev
02:53:22 <myvar> i see
02:54:33 <myvar> you know my next step is to make system calls work and use user space
02:55:03 <myvar> but do you think its fesable to not do that and make an os that only runs virtual machiens for Jit laguages
02:55:21 <myvar> that way the jit can invoke the kernel, and access memmory that way
02:55:26 <klange> Yes, but I'm not sure if it's easier or something you should do in a first kernel.
02:55:57 <myvar> that does not bother me i spend most of my time writing compiler for the fun of it
02:56:07 <myvar> os dev is a secondery past time
02:56:18 <myvar> so combining the two can only mean more fun
02:56:21 <myvar> i hope
02:56:23 <myvar> xD
02:56:51 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
02:59:42 --- quit: trout (Ping timeout: 240 seconds)
03:01:16 <myvar> well, what do you think makes the most sence to do, implment a new laguage and jit, or try to implment an existing laguage, C#, java, python or Luajit ?
03:01:36 <myvar> or maby even lisp idk
03:13:18 --- quit: NaNkeen (Ping timeout: 240 seconds)
03:14:49 <klange> I really outta write my own little interpeted bytecode language like Python...
03:14:53 <klange> But I've said that before.
03:15:34 <myvar> lol, ikr
03:15:55 <myvar> "if my job did not keep me so bussy", is my usal excuse lol
03:19:31 <Shockk> if you're job's keeping you bussy, you need to get a wider bus width
03:19:50 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-mhlolpkfeugscuos) joined #osdev
03:22:42 <myvar> lmao
03:22:45 --- join: shymega (~shymega@torbaytechjam/shymega) joined #osdev
03:22:50 --- join: janemba (~janemba@unaffiliated/janemba) joined #osdev
03:23:07 --- quit: ptx (Read error: Connection reset by peer)
03:23:23 --- join: ptx (~ptx@563400ad.rev.stofanet.dk) joined #osdev
03:24:12 <klange> if you're job, you should being bussy is probably the least of your problems
03:27:38 <klange> ... of course I fucked that up...
03:27:48 <klange> s/you should /
03:27:56 <klange> gddi i missed my last /
03:28:04 <klange> ... okay I give up.
03:28:42 --- join: rawste (~rawste@static-176-182-199-171.ncc.abo.bbox.fr) joined #osdev
03:28:55 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
03:29:48 --- join: lecx (lex@yuuh.pw) joined #osdev
03:30:41 --- quit: smeso (Ping timeout: 244 seconds)
03:32:12 --- quit: variable (Ping timeout: 265 seconds)
03:34:06 --- join: m_t (~m_t@p5DDA3824.dip0.t-ipconnect.de) joined #osdev
03:37:33 --- join: apetresc_ (~apetresc@CPEbc4dfb720b93-CMbc4dfb720b90.cpe.net.cable.rogers.com) joined #osdev
03:37:46 <myvar> lol
03:38:31 --- quit: apetresc (Ping timeout: 264 seconds)
03:39:24 <myvar> i have been working a a compiler design for 2 months now(on paper) where ever laguage feture is a plugin and every target platfrom is a plugin, might be time to give it a spin becuase that way i can easly reuse meany peaces of code, to experment easly
03:39:49 --- quit: Guest4630 (Remote host closed the connection)
03:41:46 --- join: smeso (~smeso@unaffiliated/smeso) joined #osdev
03:41:56 --- join: dormito (~dormito@172.58.111.131) joined #osdev
03:42:31 --- quit: dormito (Client Quit)
03:42:53 --- join: dormito (~dormito@172.58.111.131) joined #osdev
03:44:56 --- join: zeus1 (~zeus@197.239.5.7) joined #osdev
04:00:14 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
04:03:57 --- quit: trout (Ping timeout: 276 seconds)
04:08:30 --- quit: zeus1 (Ping timeout: 260 seconds)
04:08:55 --- quit: antkit (Quit: Connection closed for inactivity)
04:09:15 --- join: antkit (uid256318@gateway/web/irccloud.com/x-fougrbucgurbyxiy) joined #osdev
04:18:24 --- join: Kimundi_ (~Kimundi@87.122.155.255) joined #osdev
04:18:36 --- join: epony (~nym@77-85-141-166.ip.btc-net.bg) joined #osdev
04:22:30 --- quit: kimundi (Ping timeout: 260 seconds)
04:24:12 --- quit: stephen77 (Ping timeout: 240 seconds)
04:28:19 --- join: zeus1 (~zeus@62.56.248.65) joined #osdev
04:28:39 --- quit: nwm (Ping timeout: 256 seconds)
04:30:40 --- quit: myvar (Ping timeout: 260 seconds)
04:33:10 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
04:35:42 --- quit: variable (Ping timeout: 240 seconds)
04:38:27 --- join: korans (~korans@93.191.203.83) joined #osdev
04:42:38 --- quit: newnix (Quit: WeeChat 2.1)
04:43:32 --- quit: zeus1 (Ping timeout: 244 seconds)
04:50:14 --- join: prokbird (~shams@103.195.233.168) joined #osdev
04:50:35 --- join: vmlinuz (~vmlinuz@2804:431:f725:8f79:31cd:cbb0:ff74:5f2) joined #osdev
04:50:35 --- quit: vmlinuz (Changing host)
04:50:36 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
04:53:37 --- join: freakazoid0223 (~mattc@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
04:56:25 --- quit: vmlinuz (Ping timeout: 256 seconds)
05:04:32 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
05:07:32 --- join: newnix (~newnix@exile.digital) joined #osdev
05:07:37 --- quit: trout (Ping timeout: 256 seconds)
05:14:35 --- join: vmlinuz (~vmlinuz@187.35.250.145) joined #osdev
05:14:48 --- quit: vmlinuz (Changing host)
05:14:48 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
05:16:19 --- join: bauen1 (~bauen1@x59cc8241.dyn.telefonica.de) joined #osdev
05:25:02 --- join: myvar (~myvar@105.186.208.217) joined #osdev
05:28:46 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
05:29:31 --- quit: myvar (Ping timeout: 244 seconds)
05:29:43 --- quit: CheckDavid (Quit: Connection closed for inactivity)
05:34:53 --- quit: bauen1 (Remote host closed the connection)
05:35:56 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
05:39:29 --- quit: variable (Ping timeout: 276 seconds)
06:02:03 --- join: isaac_ (~isaac@host81-129-159-113.range81-129.btcentralplus.com) joined #osdev
06:02:31 --- nick: isaac_ -> isaacwoods
06:07:21 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
06:09:42 --- quit: trout (Ping timeout: 240 seconds)
06:13:14 --- join: arora (~ashok@92.96.224.138) joined #osdev
06:15:32 --- quit: ybyourmom (Quit: Lost terminal)
06:17:55 --- quit: m_t (Quit: Leaving)
06:20:49 --- quit: rawste (Quit: Sleep....)
06:28:48 --- quit: Kimundi_ (Ping timeout: 240 seconds)
06:30:36 --- join: rawste (~rawste@static-176-182-199-171.ncc.abo.bbox.fr) joined #osdev
06:35:20 --- quit: arora (Quit: leaving)
06:37:34 --- join: myvar (~myvar@105.186.208.217) joined #osdev
06:38:18 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-ubejzgqhmfvkjgby) joined #osdev
06:40:00 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
06:42:06 --- quit: myvar (Ping timeout: 264 seconds)
06:43:11 --- quit: variable (Ping timeout: 276 seconds)
06:47:10 --- join: promach_ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
06:47:50 --- quit: Asu (Remote host closed the connection)
06:49:52 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
06:52:41 --- join: w17t (~w17t@unaffiliated/w17t) joined #osdev
06:53:59 --- quit: w17t (Remote host closed the connection)
06:54:21 --- join: w17t (~w17t@unaffiliated/w17t) joined #osdev
06:56:25 --- join: preference (1f18d883@gateway/web/freenode/ip.31.24.216.131) joined #osdev
06:59:48 --- join: dadabidet (~dadabidet@extranet.adullact.org) joined #osdev
07:00:07 <dadabidet> hello, I have a question regarding font size in OSes
07:00:50 <dadabidet> Since there is a DPI setting, do OS adapt how large a font will look depending on the screen size?
07:01:30 <Mutabah> Depends on the OS - A good one will support a user-specified UI scale and just scale everything up to whatever they want
07:01:51 <dadabidet> so what happens in multi screen setups?
07:02:01 <dadabidet> For example I have 2 different screens
07:02:03 <Mutabah> The DPI reported by the monitor is mostly only useful for feeding to a document viewer/editor so it knows what "100%" is
07:02:13 <Mutabah> A good OS will support different scales on each screen :)
07:02:49 <Mutabah> That said, most modern ones just have a global scale setting which applies to all screens
07:03:47 --- quit: vdamewood (Quit: Textual IRC Client: www.textualapp.com)
07:03:50 --- join: Kimundi_ (~Kimundi@dynip-129-217-076-217.wifi.tu-dortmund.de) joined #osdev
07:04:05 <doug16k> dadabidet, 72 points = 1 inch
07:04:33 <dadabidet> Using ubuntu, I'm moving a window which is overlapping 2 different screens, I start moving the window down, and it's not descending at the same speed
07:04:58 <izabera> this is like
07:05:02 <izabera> the most on topic question
07:05:17 <izabera> we should have a wiki page about this
07:05:53 <dadabidet> But aren't fonts unable to scale at fine scalar values?
07:06:13 <dadabidet> for example I don't think I can set a font at a size of 13.23441
07:06:19 <doug16k> dadabidet, so, if it's a 72 point font, and the screen is 96 dpi, then the font is 96 pixels high
07:06:27 <dadabidet> it's only steps
07:06:29 --- join: glauxosdever (~alex@ppp-2-86-170-147.home.otenet.gr) joined #osdev
07:06:46 <doug16k> it's just a scaling factor to convert actual distance to pixels
07:07:06 <doug16k> and points is just a distance measurement, the height of the font
07:07:09 --- quit: apetresc_ (Quit: ZNC - http://znc.in)
07:07:49 <doug16k> it's not just fonts though. a dialog could be so many points wide and so many points tall
07:08:31 --- quit: jack_rabbit (Ping timeout: 264 seconds)
07:08:41 <dadabidet> Aren't some TTF font optimized to be rendered at certain pixel sizes?
07:09:15 <dadabidet> it seems that at small sizes, they always look the same
07:09:38 <doug16k> pixels = points / 72 * dpi
07:09:56 --- join: [Orchestra] (~while@unaffiliated/awaxx/x-0928682) joined #osdev
07:10:13 <dadabidet> mmmh
07:10:37 <dadabidet> I should try to screenshot example on different monitors to see the difference
07:10:45 <doug16k> or, pixels = inches * dpi
07:11:01 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
07:11:11 --- quit: Philpax (Read error: Connection reset by peer)
07:12:23 <dadabidet> imperial units :/
07:12:40 <doug16k> dadabidet, you know what the i means in dpi right?
07:12:48 <doug16k> dots per inch
07:12:52 <dadabidet> sure
07:13:06 <dadabidet> but still, inches are not SI units
07:13:25 <doug16k> desktops have obfuscated dpi to be some magical BS that mysteriously makes things big or small...
07:13:44 <dadabidet> how so?
07:13:45 <doug16k> what it really means is a way to tell the OS the size of the screen so it can make a 72 point font one inch in the real world
07:14:03 --- quit: trout (Ping timeout: 265 seconds)
07:15:41 <doug16k> or more precisely, it tells the OS the density of the pixels
07:16:06 <doug16k> 4k 17" monitor has extreme density. 60" 1920x1080 monitor has low density
07:16:46 <dadabidet> anyhow, those are the reason I made my own sans serif bitmap font
07:16:47 <doug16k> you need a hell of a lot of pixels on 4K 17" monitor to make 1 inch (72 points), and far fewer on 60" 1920x1080 monitor
07:17:02 <dadabidet> I made one which is very readable, Im quite happy with it
07:17:13 <dadabidet> and it's not pixel ugly
07:17:59 <dadabidet> there also are fonts that are pretty enough without anti aliasing
07:18:18 <dadabidet> but they're arranged and tweak to look good
07:20:09 <dadabidet> So I don't understand the need for density if it's for reading
07:20:43 <dadabidet> high density requires more power
07:21:13 <dadabidet> and you rarely see high definition pictures offline
07:21:50 --- nick: Plazma_ -> Plazma
07:21:57 <doug16k> fonts are mostly represented in points, which is a real world distance measurement, but could be in any measurement, like mm. dpi translates real world distance to pixels
07:22:25 <doug16k> if you represent your font size in pixels to begin with, then it's a tiny font on 17" 4K monitor, and a big font on 60" 1920x1080 monitor
07:23:14 <klange> my hybrid ISO is working~ or at least, it has a valid FAT and my BIOS bootloader can find files on it that are actually stored there...
07:23:16 <doug16k> dpi factors out the density and allows software to draw something on the screen with real-world measurements. you could draw a 4cm by 4cm square on the screen
07:23:23 <dadabidet> 4K will always use TTF fonts... or maybe a 2x scaled version
07:24:24 <dadabidet> what I am saying is that if I would design a system, I would limit the screen size to avoid those issues
07:25:13 <doug16k> how do you limit what dimensions my monitor has?
07:26:26 --- join: myvar (~myvar@105.186.208.217) joined #osdev
07:26:27 <doug16k> you can either ignore the dpi and have tiny output on small-dimension high-resolution monitors, or you can take it into consideration and adapt to the dpi
07:28:06 <dadabidet> by system I mean a device
07:28:23 --- quit: epony (Quit: QUIT)
07:28:53 <dadabidet> android devices have very advanced features, but low battery autonomy
07:29:18 --- quit: myvar (Remote host closed the connection)
07:29:58 --- join: myvar (~myvar@105.186.208.217) joined #osdev
07:30:52 <doug16k> klange, nice!
07:32:18 <dadabidet> I wonder how much power is drawn with the smooth transistions in android
07:32:35 <dadabidet> I would guess it's high, but I wonder if there are optimizations
07:32:53 --- join: apetresc (~apetresc@CPEbc4dfb720b93-CMbc4dfb720b90.cpe.net.cable.rogers.com) joined #osdev
07:34:12 --- quit: myvar (Ping timeout: 240 seconds)
07:34:36 <doug16k> not as bad as it looks. gpus use a lot less power per thread than the main CPU
07:35:31 --- join: Love4Boobies (~L4B@unaffiliated/l4b) joined #osdev
07:35:45 <doug16k> memory writes cost a bit of power, but they constantly require the same write power for refresh anyway
07:36:16 <doug16k> the framebuffer has to be read constantly and sent to the display regardless
07:42:32 <doug16k> gaming gpus make it seem like gpus use a lot of power, and that's because they run the hell out of the transistors to get extremely high clock speeds with high design complexity, but really, each pipeline uses next to nothing, given that there are 1000+ of them and an entire high end card might use 170W
07:42:36 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
07:43:04 <doug16k> if you don't run the hell out of the transistors you can get very low power usage because so much work is done in parallel that you race to sleep almost instantly
07:45:35 --- quit: variable (Ping timeout: 276 seconds)
07:48:10 --- join: hmmmm (~sdfgsf@pool-72-79-169-12.sctnpa.east.verizon.net) joined #osdev
07:59:21 --- quit: preference (Quit: Page closed)
07:59:25 --- quit: S_Gautam (Quit: Connection closed for inactivity)
08:04:37 --- quit: dadabidet (Remote host closed the connection)
08:04:50 --- join: myvar (~myvar@105.186.208.217) joined #osdev
08:06:43 --- join: epony (~nym@77-85-141-166.ip.btc-net.bg) joined #osdev
08:09:41 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
08:10:49 --- join: zeus1 (~zeus@197.239.5.7) joined #osdev
08:13:56 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
08:14:16 --- quit: andrei-n (Read error: Connection reset by peer)
08:14:18 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
08:15:37 --- join: Asu (~sdelang@40.202.154.77.rev.sfr.net) joined #osdev
08:15:38 --- join: andrei-n (~andrei@208.8-64-87.adsl-dyn.isp.belgacom.be) joined #osdev
08:17:42 --- quit: trout (Ping timeout: 240 seconds)
08:18:39 --- join: baschdel (~baschdel@2a01:5c0:1c:6201:bb0:858:a281:6ed8) joined #osdev
08:24:26 --- join: isd (~isd@pool-71-174-32-198.bstnma.east.verizon.net) joined #osdev
08:24:37 --- join: karlguy (~karlguy@ool-4a5a3082.dyn.optonline.net) joined #osdev
08:27:06 --- quit: glauxosdever (Quit: leaving)
08:32:13 --- join: zeus2 (~zeus@197.239.5.7) joined #osdev
08:32:32 --- quit: zeus1 (Read error: Connection reset by peer)
08:36:09 --- quit: zeus2 (Read error: Connection reset by peer)
08:36:52 --- quit: grouse (Quit: Leaving)
08:37:50 --- join: dennis95 (~dennis@i577BCEEF.versanet.de) joined #osdev
08:45:58 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
08:46:31 --- join: ALowther (~Alowther_@107.144.136.35) joined #osdev
08:48:07 --- part: prokbird left #osdev
08:49:16 --- quit: variable (Ping timeout: 265 seconds)
08:49:32 --- quit: CheckDavid (Quit: Connection closed for inactivity)
08:49:33 --- join: hiei (jinzo@gateway/shell/elitebnc/x-zuneoqtjdyvsgaiu) joined #osdev
08:50:09 <isaacwoods> Is it viable to do distance field font rendering without hardware acceleration support?
08:51:48 --- join: zeus2 (~zeus@62.56.248.65) joined #osdev
08:52:40 <Love4Boobies> Sure.
08:54:38 <isaacwoods> Cool, thought it might be too strenuous to do in software
08:59:06 <Love4Boobies> Computers are pretty fast.
09:06:23 <olsner> but if you're doing it in software, why wouldn't you just use a "normal" font renderer?
09:11:20 <isaacwoods> https://github.com/libgdx/libgdx/wiki/images/distance-field-fonts.png
09:14:04 --- quit: ALowther (Remote host closed the connection)
09:14:04 <olsner> should've compared it to the real deal though, rendering the "regular font" at the target resolution instead of scaling
09:15:33 <isaacwoods> Yeah it'd look fine at target resolution, I just liked the idea of getting scaling "for free"
09:15:43 <isaacwoods> But I'm not an expert at all, maybe it's misguided :)
09:18:40 --- quit: SM0TVI (Read error: Connection reset by peer)
09:19:46 --- join: SM0TVI (~sm0tvi@unaffiliated/sm0tvi) joined #osdev
09:20:20 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
09:20:45 --- join: AverageJ0e (~joe@ip72-222-140-99.ph.ph.cox.net) joined #osdev
09:22:48 --- quit: myvar (Ping timeout: 240 seconds)
09:23:12 --- quit: trout (Ping timeout: 240 seconds)
09:25:12 --- quit: zeus2 (Ping timeout: 240 seconds)
09:27:53 --- quit: variable (Quit: /dev/null is full)
09:29:16 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
09:29:25 --- quit: variable (Client Quit)
09:30:05 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
09:30:12 --- quit: variable (Client Quit)
09:32:00 --- join: akasei (~akasei@viscon.wataha.net) joined #osdev
09:32:05 <akasei> hey! how to format partition with ext2 filesystem, but with revision 0? "-r 0" not working :(
09:33:22 --- join: [Brain] (~brain@brainwave.brainbox.cc) joined #osdev
09:34:30 --- join: ALowther (~Alowther_@107.144.136.35) joined #osdev
09:34:49 <Love4Boobies> akasei, you have the wrong channel. This is for developers, not technical support.
09:37:23 --- quit: ALowther (Remote host closed the connection)
09:40:01 --- quit: sdfgsd (Ping timeout: 268 seconds)
09:41:49 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
09:44:25 --- join: Hello71 (Hello71@unaffiliated/hello71) joined #osdev
09:44:29 --- part: Hello71 left #osdev
09:46:24 --- join: sdfgsd (~sdfgsdfgs@176.33.238.46) joined #osdev
09:47:10 --- join: psf (uid164389@gateway/web/irccloud.com/x-aoytzdfigurcsbfs) joined #osdev
09:49:22 --- join: MrOnlineCoder (~MrOnlineC@195.225.231.218) joined #osdev
09:49:39 --- join: graphene (~graphene@46.101.134.251) joined #osdev
09:51:43 --- quit: Maxou56800 (Ping timeout: 264 seconds)
09:52:00 --- quit: rawste (Quit: Sleep....)
09:53:17 --- join: Maxou56800 (~Maxou5680@fightthebadcode.org) joined #osdev
10:02:45 <akasei> Love4Boobies: yea i creating filesystem driver for my os
10:03:31 <akasei> and this will so much simplyfy this driver
10:04:17 <Love4Boobies> So if you didn't know how to turn on your computer or pay the electricity bill to do it but wanted to use the computer in order to write an OS, would that be on-topic? :D
10:04:39 <Love4Boobies> Read the documentation for your tool.
10:05:05 <Love4Boobies> You haven't even mentioned what you're using.
10:05:10 <Love4Boobies> mention*
10:05:30 * Love4Boobies goes away.
10:07:27 <akasei> heh
10:07:30 <akasei> nvm
10:08:50 --- nick: vaibhav -> vaibhav|gone
10:10:32 --- quit: promach_ (Quit: WeeChat 2.1)
10:20:48 --- quit: Kimundi_ (Ping timeout: 240 seconds)
10:22:19 <froggey> akasei: genext2fs produces rev 0 filesystems, or it did the last time I used it
10:22:38 --- join: manzerbredes (~loic@2a01cb0885e31500cfc30bb534d5bc37.ipv6.abo.wanadoo.fr) joined #osdev
10:23:32 --- join: w41 (~w41@unaffiliated/w41) joined #osdev
10:23:37 <akasei> froggey: thx u
10:23:41 --- quit: m3nt4L (Remote host closed the connection)
10:25:31 --- join: zxq2 (D0MeW66din@unaffiliated/zxq2) joined #osdev
10:26:36 <doug16k> I have such a weird issue in early boot. in kvm I get a failure in my paging code, but on tcg it works fine, and at that point it is still just the first CPU running and isn't even switching threads yet, so how can timing be any issue
10:27:25 <doug16k> I'm not setting global bit in any page table mapping, so PML4 global bit reserved thing can't be it
10:27:43 --- quit: MrOnlineCoder (Ping timeout: 264 seconds)
10:28:02 <doug16k> it's a reverse heisenbug. if I debug it works, full speed fails
10:31:36 <doug16k> I'm seriously considering completely reimplementing my page table manipulation code anyway. I recently reimplemented it in my bootloader and I did it far more elegantly, now that I totally know what I'm doing with them
10:31:54 <doug16k> getting rid of recursive paging entirely
10:36:13 <doug16k> oh wait, actually that's a standard heisenbug. :)
10:36:55 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
10:37:39 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
10:40:09 --- quit: w17t (Quit: Leaving)
10:42:07 --- quit: apetresc (Ping timeout: 264 seconds)
10:42:08 --- join: nwm (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
10:43:18 --- join: apetresc (~apetresc@CPEbc4dfb720b93-CMbc4dfb720b90.cpe.net.cable.rogers.com) joined #osdev
10:50:31 --- quit: aalm (Ping timeout: 264 seconds)
10:53:17 --- join: Kimundi_ (~Kimundi@87.122.155.255) joined #osdev
10:53:19 --- quit: jordyd (Quit: Bye!)
10:54:51 --- join: rawste (~rawste@static-176-182-199-171.ncc.abo.bbox.fr) joined #osdev
10:56:42 --- quit: jbgg (Quit: leaving)
10:56:47 --- join: jordyd (~jordyd@pampanic/co-maintainer/jordyd) joined #osdev
10:57:06 --- join: MrOnlineCoder (~MrOnlineC@195.225.231.218) joined #osdev
11:00:55 <booyah> a.k.a the reverse inverted heisenbug
11:02:45 <Kazinsal> schroedinger's heisenbug. it only becomes a heisenbug once you start debugging it
11:02:46 --- quit: nur (Ping timeout: 244 seconds)
11:04:47 --- quit: doug16k (Remote host closed the connection)
11:08:57 --- quit: antkit (Quit: Connection closed for inactivity)
11:09:50 --- join: doug16k (~dougx@172-97-186-251.cpe.distributel.net) joined #osdev
11:14:59 --- quit: rawste (Quit: Sleep....)
11:19:41 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
11:21:34 --- quit: while1 (Quit: Diamonds and government programs are both forever)
11:29:44 --- quit: w41 (Ping timeout: 265 seconds)
11:37:51 --- quit: isaacwoods (Quit: isaacwoods)
11:41:44 --- join: DusXMT (~dusxmt@84.245.121.11) joined #osdev
11:45:37 <DusXMT> I've been wondering recently... since the i386, the x86 platform supported virtual addressing of up to 64TiB of data as 16-thousand 4 gigabyte memory planes when utilizing memory segmentation; I wonder, has there been any known operating system which made use of this mode?
11:45:53 --- join: tacco| (~tacco@i59F5F2E4.versanet.de) joined #osdev
11:48:41 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
11:49:03 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
11:50:51 --- quit: drakonis (Remote host closed the connection)
12:01:44 --- join: angel0xff (~zzz@158-58-227-127.sf.ddns.bulsat.com) joined #osdev
12:07:48 --- quit: pie_ (Ping timeout: 240 seconds)
12:10:34 <doug16k> DusXMT, are you referring to PAE (physical address extensions)? that's not since the i386. more like since pentium pro
12:10:51 --- join: bm371613 (~bartek@89-64-30-31.dynamic.chello.pl) joined #osdev
12:11:37 <doug16k> it's not planes either. each page can be any page up to the maximum supported physical address, which varies depending on the specific CPU. likely to be 36 or more bits of physical address (64GB or more)
12:12:08 <DusXMT> doug16k: No, I mean virtual memory segmentation
12:13:46 <doug16k> virtual memory segmentation sounds like nonsense. can you describe it?
12:16:05 <DusXMT> It's basically an extension of the realmode segmented memory mode, but the segments can now be 4 gigabytes in length instead of just 64K, and the size is variable so a segment can contain individual modules
12:16:17 <doug16k> segmentation occurs before paging. the program has a virtual address, which is translate by paging with an offset (the segment base), giving a linear address. linear address goes through paging translation to give a physical address
12:16:24 <doug16k> sounds like "unreal mode"
12:17:14 <doug16k> unreal mode is not for serious use because it defaults to 16 bit addressing modes, requiring almost every memory access to have operand size and address size prefixes
12:17:23 <doug16k> you might as well just go into protected mode
12:18:11 <doug16k> swapping segments is not even close to as efficient as swapping pages. segments must be contiguous so you run into major issues with memory fragmentation
12:18:29 --- join: antkit (uid256318@gateway/web/irccloud.com/x-xrujciclfahyuslj) joined #osdev
12:18:54 <DusXMT> From the 80386 programmer's manual, "Application programmers view the logical address space of the 80386 as a collection of up to 16,383 one-dimensional subspaces, each with a spedified length. Each of these linear subspaces is a segment. A segment is a unit of contiguous address space. Segment size may range from one byte up to a maximum of 2^32 bytes"
12:19:16 <doug16k> you'd be locking segments and moving them around whenever memory got fragmented. with paging, that would not be necessary, no matter how fragmented physical memory gets
12:19:56 * DusXMT nods
12:20:04 <doug16k> DusXMT, you're proposing making windows 3.1
12:20:20 <doug16k> only a 32 bit version, with just as painful memory management
12:20:50 <doug16k> flat memory model is vastly superior
12:21:30 --- quit: SopaXorzTaker (Remote host closed the connection)
12:21:40 <DusXMT> I am aware of the advantages of a flat memory model, I'm just curious if there've been any mildly successful crazies who attempted to roll with the segmented memory model :)
12:21:51 <doug16k> yes. windows 3.1
12:22:18 --- quit: AverageJ0e (Ping timeout: 264 seconds)
12:22:27 <DusXMT> Then I guess it's time to write some data processing applications for Windows 3.1 that can handle several terabytes of data :)
12:22:49 <doug16k> 3.1 uses 16 bit addressing, but a 32 bit version would only scale up the issues
12:23:10 <jjuran> You could embrace the fragmentation and call it Unreal Mode Tournament
12:23:10 <doug16k> are you going to page out a 32MB entire segment?
12:23:46 <doug16k> are you going to freeze execution and memmove 128MB segments to defragment free space?
12:24:36 <doug16k> one argument might be, oh I'll have paging too! well, have paging then, the segments become redundant
12:24:52 <olsner> you could probably do defragmentation in virtual memory without actually moving data around, until you need to actually swap out data and invalidate segments
12:26:07 <doug16k> anyone that thinks segments are good hasn't experienced far pointers. they suck, big time
12:26:12 <DusXMT> doug16k: indeed; they do provide the ability to extend the virtual address space, but by the time needing more than 4 gigabytes of data for a single task on a PC came by, 64-bit hardware was probably commonplace
12:26:54 --- join: absolute123 (~vodka@185.192.189.222) joined #osdev
12:27:25 <DusXMT> (the only task I can think of on hand is the linking of a debugging version of libxul, that doesn't fit into a 32-bit address space)
12:27:25 <doug16k> DusXMT, you can have far more than 4GB with paging, with or without PAE
12:27:37 <DusXMT> doug16k: Byt that's physical memory, not virtual memory
12:28:06 <DusXMT> Or am I misunderstanding something here?
12:28:24 <doug16k> you can have windowing extensions like windows has, where you can have a window into a virtually unlimited space
12:29:00 <DusXMT> so in a way that's something similar to the segmented model :) (except it's called a window instead)
12:29:03 <doug16k> assuming you reserve the upper 1GB for the kernel, you have 3GB of virtual address space for each process
12:29:39 <doug16k> DusXMT, yes, but without painfully screwing around with a bunch of LDT descriptors and having to have a toolchain that knows how to incessantly load segment registers
12:30:23 <doug16k> there's a reason every OS uses flat model. segments are a pain that are more trouble than they are worth
12:30:27 <DusXMT> Thank you, then that does indeed answer my question: there are more practical ways of extending the address space
12:31:10 <DusXMT> *virtual address space
12:31:11 <doug16k> yes. besides that, 32 bit is ancient. x86_64 allows for 128TB user address space, separate for each process
12:31:29 <doug16k> or more on latest CPUs
12:31:34 <absolute123> i think i am pretty clear on how things function, i still rambled a bit occationally, the theory i presented is okayish
12:32:50 <absolute123> to file a patent which route i may go, later giving it to commons, is slightly complicated, it needs to include innovation detail to get granted, but there are quite many variations of the method
12:34:32 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-qqowjukqnrkhogdl) joined #osdev
12:34:32 <doug16k> DusXMT, there are cpus now that have 57 bit address space. now you can have 64PB of address space for each process, plus 64PB of kernel space
12:34:41 <doug16k> 65536TB ought to be enough for anyone
12:36:00 <absolute123> doug16k: how have you been? i have also couple of friends here, doug16k has talked with me in private too, it would make more sense to tell things to him in private, i think i am ready to pull off an article
12:36:13 <doug16k> good
12:36:47 <DusXMT> doug16k: of course :) But my question wasn't really about what's available today, but about what's been available since 1986; I fully realize that with 64-bit hardware, memory segmentation is fully obsolete
12:37:45 <DusXMT> Not to mention, an OS that would rely on it would have no chance of being portable to different CPUs
12:37:57 <doug16k> good point
12:38:06 <DusXMT> (other than perhaps PowerPC, I think they implement some sort of memory segmentation as well)
12:39:00 <doug16k> a toolchain can emulate segmentation, by reserving a register as a base address. that's essentially what segments are in x86, plus it enforces an offset limit, and can make segments execute only or data only or code/data
12:39:23 <doug16k> paging provides all of those capabilities in a much more flexible way
12:40:03 <absolute123> i head off, but are you suppose to mess around with memory segments in userspace?
12:40:17 <doug16k> a toolchain could spam limit checks and add a base register to all memory references on any cpu
12:40:39 <absolute123> i think only kernel should do this, that is the point, no crazy assembler thingies that mess around with it in userspace should be used
12:40:41 <doug16k> absolute123, not really. you might touch it a bit when you set up TLS
12:40:49 <doug16k> thread local storage
12:41:05 <absolute123> doug16k: yeah i know, but even then actually kernel would perform it
12:41:08 <doug16k> that would probably be part of the system
12:41:39 <doug16k> not necessarily. it is possible to allow a process to set the fs or gs base on x86, capability permitting, for example
12:42:05 <doug16k> but it's not a great idea because then you have to save and restore those bases on context switch
12:42:11 <absolute123> ok, well the ingo molnar way was kernel based actually, so you set up an ioctl or something for it
12:42:25 <absolute123> and let the kernel do that, but yeah of course it can be done in userspace too
12:42:31 <doug16k> yeah a syscall or something is a better approach. always works too, no capability needed
12:42:37 <absolute123> but it should not be done there imo
12:42:52 <absolute123> yeah, off to bed, bye
12:42:56 <doug16k> bye
12:42:59 --- quit: absolute123 (Quit: Leaving)
12:48:55 --- join: geekodour08 (~geekodour@45.115.172.80) joined #osdev
12:51:46 --- quit: janemba (Read error: Connection reset by peer)
12:52:48 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
12:54:42 --- quit: sixand (Ping timeout: 264 seconds)
12:56:29 --- join: zeus2 (~zeus@197.239.7.77) joined #osdev
13:01:12 --- quit: manzerbredes (Ping timeout: 240 seconds)
13:06:25 --- join: w41 (~w41@unaffiliated/w41) joined #osdev
13:07:43 --- quit: JusticeEX (Ping timeout: 256 seconds)
13:15:05 --- quit: baschdel (Ping timeout: 256 seconds)
13:15:25 --- join: Monax (6d585875@gateway/web/freenode/ip.109.88.88.117) joined #osdev
13:16:32 --- quit: Love4Boobies (Remote host closed the connection)
13:18:34 --- join: monax_ (~N.V.Bossu@2a02:2788:634:93c::4) joined #osdev
13:18:48 --- quit: Monax (Client Quit)
13:26:22 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
13:28:02 --- join: aalm (~aalm@37-219-19-84.nat.bb.dnainternet.fi) joined #osdev
13:29:15 --- quit: psf ()
13:45:40 --- quit: mavhq (Read error: Connection reset by peer)
13:46:55 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
13:47:20 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
13:50:26 --- quit: bm371613 (Quit: Konversation terminated!)
13:52:36 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
14:01:14 --- join: macdonag2 (~macdonag2@cpc110673-lewi19-2-0-cust478.2-4.cable.virginm.net) joined #osdev
14:09:34 --- quit: monax_ (Quit: Leaving)
14:13:48 --- quit: NightBlade (Ping timeout: 240 seconds)
14:17:59 --- quit: brosef (Ping timeout: 256 seconds)
14:18:05 --- quit: zeus2 (Ping timeout: 260 seconds)
14:19:23 --- join: sssnap (~feddywhap@lab46.corning-cc.edu) joined #osdev
14:19:59 --- join: zeus2 (~zeus@197.239.7.77) joined #osdev
14:22:06 --- join: Love4Boobies (~L4B@unaffiliated/l4b) joined #osdev
14:23:03 --- quit: dennis95 (Quit: Leaving)
14:26:29 --- join: ALowther (~Alowther_@68.200.224.209) joined #osdev
14:28:55 --- quit: antkit (Quit: Connection closed for inactivity)
14:34:36 --- quit: ALowther (Ping timeout: 244 seconds)
14:41:36 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
14:43:17 --- join: ALowther_ (~Alowther_@mobile-166-172-185-52.mycingular.net) joined #osdev
14:44:56 --- quit: nwm (Ping timeout: 244 seconds)
14:46:39 --- join: nwm (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
14:47:07 --- quit: macdonag2 (Quit: macdonag2)
14:54:55 --- join: janemba (~janemba@unaffiliated/janemba) joined #osdev
14:56:22 --- quit: sortie (Quit: Leaving)
14:58:55 --- quit: ALowther_ (Ping timeout: 264 seconds)
14:59:37 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
15:00:01 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
15:07:21 --- quit: isd (Quit: Leaving.)
15:11:18 --- quit: angel0xff (Ping timeout: 240 seconds)
15:13:55 --- quit: zeus2 (Ping timeout: 264 seconds)
15:14:48 --- quit: Kimundi_ (Ping timeout: 240 seconds)
15:15:07 --- quit: ExtremeFMan (Quit: We share your Personal Data)
15:16:28 <[Orchestra]> :D Personal really?
15:17:11 <Love4Boobies> how i make os run apache http server to have web site? where is tutorial
15:17:46 <Love4Boobies> is there option in c to do it or i have 2 use assembler language?
15:18:10 <Love4Boobies> idk cuz many instructions and what to use
15:18:22 <Love4Boobies> but tutorial help i learn many!
15:18:36 <[Orchestra]> depending you OS api you can write an HTTP ezly
15:19:00 <[Orchestra]> or many other applicative protocols...
15:19:34 <[Orchestra]> Just get a stronky shovel and start excavate grandma!
15:19:43 <Love4Boobies> can i use network driver from windoze?
15:19:49 --- quit: MrOnlineCoder (Quit: Goodbye)
15:19:59 <Love4Boobies> how i run driver?
15:20:41 <[Orchestra]> hinnnnnnn, *ERROR*... unknown thing exception : windoze
15:20:48 <clever> Love4Boobies: https://wiki.debian.org/NdisWrapper
15:20:49 <bslsk05> ​wiki.debian.org: NdisWrapper - Debian Wiki
15:20:52 <Love4Boobies> i try modprobe but totorial didnt civer that part
15:21:03 <[Orchestra]> I have no idea about windows...
15:21:05 <Love4Boobies> so idk how to implement in os the modprobe command
15:21:15 --- join: hmmmmm (~sdfgsf@pool-72-79-166-46.sctnpa.east.verizon.net) joined #osdev
15:21:16 <[Orchestra]> I only have interest in free softwares
15:21:30 <Love4Boobies> load_driver() or something, probably. but idk what it is called in c
15:21:45 <clever> Love4Boobies: its called whatever you named it when writing your kernel
15:22:19 <Love4Boobies> well i did not writing this part yet but i write it now, i just want to know what is the c function to load driver
15:22:30 <clever> Love4Boobies: https://wiki.osdev.org/Modular_Kernel
15:22:31 <bslsk05> ​wiki.osdev.org: Modular Kernel - OSDev Wiki
15:22:45 * DusXMT wonders if that person's NickServ account got hacked
15:22:58 <Love4Boobies> Not really, I'm just a little bored.
15:24:07 --- quit: hmmmm (Ping timeout: 268 seconds)
15:24:49 <Love4Boobies> Also, who calls protocols on the application layer "applicative protocols"? :)
15:26:12 --- quit: hmmmmm (Ping timeout: 240 seconds)
15:26:18 --- join: AndrewBC (~AndrewBC@ip70-187-57-150.pn.at.cox.net) joined #osdev
15:26:20 <[Orchestra]> the author usually
15:26:22 <[Orchestra]> :D
15:26:53 <Love4Boobies> Which author is that?
15:27:27 <[Orchestra]> are you crafting an Animated Immitation with my answers?
15:27:51 <[Orchestra]> cuz I know u kiiding me :D
15:28:16 <Love4Boobies> No, I stopped trolling when I started typing not like an idiot. :)
15:28:29 --- join: hmmmm (~sdfgsf@pool-72-79-166-218.sctnpa.east.verizon.net) joined #osdev
15:28:51 <[Orchestra]> let's assume I'm one then
15:29:26 --- quit: quc (Ping timeout: 240 seconds)
15:29:57 <Love4Boobies> You might expand your audience by using terminology that makes sense. :p
15:30:26 --- quit: w41 (Ping timeout: 240 seconds)
15:30:31 * Love4Boobies needs to uninstall Minecraft. Too much procrastination.
15:30:51 <[Orchestra]> I'm absolutly not looking for audience even glory...
15:30:58 <clever> Love4Boobies: try porting minecraft to your OS!
15:31:09 <clever> Love4Boobies: then you can get 2 birds with 1 stone
15:31:31 <Love4Boobies> Well, I wouldn't be porting Minecraft, I'd be porting the JVM together with a couple of other things.
15:32:08 <Love4Boobies> As for the proper Minecraft (the Bedrock Edition), that's not really possible.
15:32:33 <CompanionCube> proper minecraft?
15:32:35 <CompanionCube> lol nope.
15:33:17 <clever> mods are the only way to play minecraft
15:33:19 <Love4Boobies> It's basically Minecraft except it has more features (both technical and in-game) and doesn't lag as much,
15:33:21 <CompanionCube> actually, upon reading scrollback
15:33:24 <CompanionCube> 10/10 trolling
15:33:34 <Love4Boobies> I'm not trolling at the present time.
15:34:00 <Love4Boobies> Regarding mods, perhaps. But you have mods for either version, if that' what you are looking for.
15:34:17 <clever> bedrock's mod api is far more limited
15:34:21 <CompanionCube> so where can I pick up, say, a computer mod for Bedrock?
15:34:26 --- join: hmmmmm (~sdfgsf@pool-72-79-165-22.sctnpa.east.verizon.net) joined #osdev
15:34:36 <CompanionCube> and then can I run it on this Linux box that's my desktop?
15:34:37 <Love4Boobies> The Java Edition doesn't even have an API, it's mostly a bunch of ugly kludges.
15:34:54 --- quit: hmmmm (Ping timeout: 264 seconds)
15:34:58 --- join: quc (~quc@host-89-230-167-218.dynamic.mm.pl) joined #osdev
15:34:59 <CompanionCube> (are they still censoring your chat? Would like to know.)
15:36:10 <DusXMT> For me, the problem with mods is that they break the balance of the game; sure, if you carefully select mods that are compatible in spirit, you can get some pretty nice results, and the total conversion mods like TerraFirmaCraft or Better than Wolves are really neat, but most of the time, it's all about exploiting things to get things from different mods...
15:36:41 <[Orchestra]> lakka OS is cool to play oldish games
15:37:22 <Love4Boobies> No, mods are terrible. I think their biggest advantage is that they sometimes have good ideas in them that can be further polished (integrated with the rest of the mechanics, take in account the rest of the game to keep it balanced, make it not feel wonky, etc.).
15:37:32 <DusXMT> (or building the "ultimate machine" to get the vast majority of items for free)
15:37:56 <rubenwardy> Minetest ;)
15:38:50 <Love4Boobies> CompanionCube, there are many mods to choose from. No Linux support as of yet (and Wine won't help since it's an UWP application) but they said they're making a business case to bring it to macOS and Linux. But since these are way, way smaller markets, we'll have to wait.
15:39:07 <rubenwardy> open source voxel game engine. Mods don't break every update https://www.minetest.net
15:39:08 <Love4Boobies> I mostly use Linux myself so I would appreciate it.
15:39:08 <bslsk05> ​www.minetest.net: Home - Minetest
15:39:19 <CompanionCube> and the third point?
15:39:31 <Love4Boobies> I have no idea.
15:39:40 <Love4Boobies> At any rate, it does have some cool features:
15:40:11 <CompanionCube> http://minecraft.wikia.com/wiki/Minecraft_Coins_(Money) also this is garbage
15:40:11 <bslsk05> ​minecraft.wikia.com: Minecraft Coins (Money) | Minecraft Wiki | FANDOM powered by Wikia
15:40:12 <Love4Boobies> You can push/pull block entities with pistons: things like hoppers, chests, dispensers, etc. So you can make some pretty nifty contraptions that are just not possible in the Java Edition.
15:40:43 <Love4Boobies> No one forces you to use coins if you don't want to, though.
15:40:54 <Love4Boobies> There's free stuff and non-free stuff. I'm fine with that.
15:41:17 <DusXMT> Love4Boobies: TerraFirmaCraft is definitely worth checking out if you're tired of the same old mining and crafting and if the game is too easy; it's a total conversion mod that's all about survival and somewhat-more realistic cave exploring and material collecting
15:41:27 <clever> Love4Boobies: mods like frames and funky motion also let you move tile-entities in java edition
15:41:36 --- join: hmmmmmm (~sdfgsf@pool-72-79-166-114.sctnpa.east.verizon.net) joined #osdev
15:41:39 <Love4Boobies> Another nice feature is that the rendering distance is higher. And they're adding official 4K and shader support.
15:41:51 <Love4Boobies> Not to mention it's had proper VR support for quite some time.
15:42:32 <Love4Boobies> DusXMT, that's nice. I used to like the idea of survival but I mostly do tech things these days.
15:42:42 --- quit: doug16k (Ping timeout: 240 seconds)
15:42:54 <Love4Boobies> Crazy control blocks or redstone or piston contraptions, use structure blocks in all sorts of ways, etc.
15:43:18 --- quit: hmmmmm (Ping timeout: 240 seconds)
15:43:31 <Love4Boobies> clever, yeah but (a) they're trying to fix something that's broken and (b) they suck.
15:43:48 <Love4Boobies> Push a double chest, it turns into two chests for a bit and then goes back, etc.
15:43:57 --- quit: Asu (Quit: Konversation terminated!)
15:44:02 <Love4Boobies> There's all sorts of timing problems, etc
15:44:25 --- join: hmmmmm (~sdfgsf@pool-72-79-167-91.sctnpa.east.verizon.net) joined #osdev
15:45:00 <Love4Boobies> I wrote a couple of mods too but mostly to help me expose some very obscure mechanics so as to optimize some of my contraptions.
15:45:07 * CompanionCube likes mods so bedrock edition has practically zero chance of being the actual mineccraft....even in the future when it can actually run
15:45:33 <CompanionCube> that said, bedrock edition likely has better code because java edition was never particularly great in that department...
15:45:56 --- quit: hmmmmmm (Ping timeout: 240 seconds)
15:46:46 <Love4Boobies> CompanionCube, https://i.ytimg.com/vi/ycvBivhY07k/maxresdefault.jpg
15:46:52 <Love4Boobies> And what do you suppose this is?
15:46:53 --- quit: xenos1984 (Quit: Leaving.)
15:46:58 <Love4Boobies> As a random example.
15:47:06 <Love4Boobies> It does have plenty of mods.
15:47:31 <clever> Love4Boobies: retextured mobs, and the AI is likely fixed to choosing from an existing mob
15:47:45 <clever> with no way to create a new mob with a truely unique AI
15:47:59 <Love4Boobies> That's almost true.
15:48:01 <CompanionCube> the car's a good 3D model though
15:48:09 <CompanionCube> good job for whoever made it
15:48:18 <Love4Boobies> It's written by Mojang, actually.
15:48:30 <Love4Boobies> Anyway, it's not just retextued mobs.
15:48:46 --- join: palk (~palk@unaffiliated/palk) joined #osdev
15:48:47 <Love4Boobies> However, you are right --- currently no way to have very custom AI and stuff.
15:48:52 <clever> Love4Boobies: can bedrock ever hope to do this? https://www.youtube.com/watch?v=-mtcoRR_APk
15:48:53 <bslsk05> ​'Immersive Railroading Spotlight Alpha 0.2.1' by cam72cam (00:10:39)
15:49:09 <clever> CompanionCube: look at the 3d models in this mod
15:49:15 <Love4Boobies> You have some control over things but not much. However this point needs to be taken seriously:
15:49:18 <CompanionCube> clever: i know
15:49:19 <clever> CompanionCube: the pistons even move correctly as the wheels turn
15:49:23 <CompanionCube> i've seen them in action
15:49:24 <Love4Boobies> Java Edition has no modding support.
15:49:27 <CompanionCube> at betterthanminecon
15:49:33 <CompanionCube> shit was awesome.
15:49:40 <Love4Boobies> For Bedrock, they began working on modding support.
15:49:42 <clever> CompanionCube: yeah
15:49:46 <DusXMT> well, minecraft forge is the de-facto modding framework for the java edition
15:50:04 <CompanionCube> https://imgur.com/a/tnO4r example of said shit being awesome if buggy
15:50:05 <bslsk05> ​imgur.com: Imgur: The magic of the Internet
15:50:08 <rubenwardy> Minetest has modding support for ages. Ignore the name, like most free software the name is terrible
15:50:16 <rubenwardy> but a proper plugin based API
15:50:31 <Love4Boobies> I'm not saying that Java Edition can't be modded. I've modded it too.
15:50:40 <Love4Boobies> I'm saying that it's possible *despite* Mojang.
15:50:55 <Love4Boobies> And with Bedrock, they seem to give a shit about it because Java taught them it's important.
15:50:59 <Love4Boobies> So the future looks brighter.
15:51:11 <Love4Boobies> Currently, it's quite limited. But eh.
15:51:17 <Love4Boobies> Have to start somewhere.
15:51:31 --- quit: Tazmain (Quit: Leaving)
15:51:40 <DusXMT> Mojang were fully intending on writing a modding framework for the java edition, they even hired Dinnerbone for the task, but Forge sort of already fulfilled the purpose of the missing modding framework, and having two would result in a fragmented market
15:52:09 <CompanionCube> there was little point fixing what was no longer broken
15:52:19 <Love4Boobies> Regarding railroads and trains --- if that's all there is, I'm pretty sure that can be done with Bedrock, yes.
15:52:27 <Love4Boobies> I also like that Bedrock has chemistry mechanics.
15:52:55 <CompanionCube> trains are just one example
15:52:58 <Love4Boobies> They're pretty cool. You can fly pigs into the sky with helium baloons and leads, make colored torches, underwater tnt, etc.
15:53:33 <Love4Boobies> Well, give an example that's worth giving. :)
15:53:49 <CompanionCube> let's see, two of the mods i like quite a bit
15:53:54 <Love4Boobies> For instance, I don't think you can currently ave new dimensions in Bedrock.
15:54:01 <Love4Boobies> have*
15:55:00 --- join: doug16k (~dougx@172-97-186-251.cpe.distributel.net) joined #osdev
15:55:11 <CompanionCube> https://www.minecraft-installer.de/Dateien/BilderWeb/OpenComputers.jpg http://www.minecraftmods.com/wp-content/uploads/2013/07/millenaire1.jpg here's two of mods i like the most
15:56:32 <clever> CompanionCube: i dont think bedrock would ever allow a mod as complex as opencomputers
15:56:34 <Love4Boobies> What's the second one?
15:56:42 <clever> too much state and computation
15:56:59 <CompanionCube> 2nd one's milleniare
15:57:05 --- join: hmmmmmm (~sdfgsf@pool-72-79-165-144.sctnpa.east.verizon.net) joined #osdev
15:57:08 <Love4Boobies> clever, that's also an argument for now allowing redstone or pistons.
15:57:13 <Love4Boobies> Yet they do.
15:57:21 --- join: patv (ac61a3ea@gateway/web/freenode/ip.172.97.163.234) joined #osdev
15:57:26 <clever> Love4Boobies: redstone and pistons are far far simpler
15:57:31 <CompanionCube> which are similar to NPC villages but way better (and i think even older?)
15:57:43 <clever> Love4Boobies: they operate almost entirely on block-updates
15:57:49 <Love4Boobies> clever, so are the individual states you are talking about.
15:57:58 --- join: zeus2 (~zeus@197.239.7.77) joined #osdev
15:58:20 <clever> Love4Boobies: OC has to run on every tick, independant of the block and world ticks, and can save the state of an entire LUA vm to the block at chunk unload
15:58:23 <Love4Boobies> CompanionCube, is it just text apeparing above villager heads or do they do interesting things?
15:58:43 <CompanionCube> the text is representing the thing they're currently doing
16:00:12 --- quit: hmmmmm (Ping timeout: 240 seconds)
16:00:49 <CompanionCube> they could also be out building a new thing or getting resources or trading with you
16:03:37 --- join: hmmmmm (~sdfgsf@pool-72-79-168-240.sctnpa.east.verizon.net) joined #osdev
16:06:40 --- quit: hmmmmmm (Ping timeout: 268 seconds)
16:06:49 --- join: hmmmmmm (~sdfgsf@pool-72-79-166-8.sctnpa.east.verizon.net) joined #osdev
16:07:18 --- quit: vmlinuz (Quit: Leaving)
16:09:40 --- quit: hmmmmm (Ping timeout: 244 seconds)
16:10:30 --- join: S_Gautam (uid286066@gateway/web/irccloud.com/x-tkykuulxtqpoiych) joined #osdev
16:14:28 --- quit: qeos (Read error: Connection reset by peer)
16:16:00 --- quit: Shamar (Quit: leaving)
16:18:57 --- join: qeos (~qeos@ppp91-79-249-247.pppoe.mtu-net.ru) joined #osdev
16:19:27 --- join: eremitah_ (~int@unaffiliated/eremitah) joined #osdev
16:20:13 --- quit: eremitah (Ping timeout: 265 seconds)
16:20:13 --- nick: eremitah_ -> eremitah
16:24:42 --- quit: freakazoid0223 (Read error: Connection reset by peer)
16:27:55 --- join: freakazoid0223 (~mattc@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
16:31:48 --- quit: spare (Quit: leaving)
16:32:25 <klange> The process for my ISO-FAT hybrids looks like this: 1) Populate a base directory with the files you want on the FAT - EFI loader, kernel, modules, etc.; 2) Allocate and format an appropriately sized FAT image. 3) Use mtools to copy the files from the base directory onto the actual FAT, and create blank shadow files in a new directory for the ISO base. 4) Place the FAT image and any CD-specific files in the C
16:32:31 <klange> D base directory. 5) Create the base ISO with xorriso using the typical eltorito alt boot efi arguments.
16:33:12 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
16:33:12 <klange> 6) Parse the ISO and the FAT to get the file offsets and sizes and apply them to the extent start and length for the equivalent file in the ISO.
16:34:07 <klange> Because mtools will create contiguous files on a fresh image, and cluster sizes at these partition sizes should be at least 2048 (and are always powers of two), we can ensure contiguous, 2048-byte files are in the FAT, which is exactly what we need to make shadow files in the ISO.
16:36:32 <clever> klange: what if you just had support for the iso9660 FS in the kernel, and skip the entire fat mess?
16:36:48 <doug16k> clever, you have to have fat for efi boot
16:36:56 <doug16k> remember, efi = windows
16:37:05 --- join: jack_rabbit (~jack_rabb@c-73-211-181-224.hsd1.il.comcast.net) joined #osdev
16:37:10 <clever> ah, so you also want efi
16:37:18 <doug16k> efi is gushing microsoftness
16:37:20 <clever> but how does efi normally work on a dvd?
16:37:22 <klange> clever: The problem is the other way around, and the right solution from your perspective would be the opposite - the BIOS bootloader should support FAT.
16:38:03 * DusXMT thought EFI was primarily designed for apple, and then adapted back to the PC world in the form of UEFI
16:39:06 <clever> klange: which part of the firmware/os is forcing a restriction in which way?
16:39:16 <klange> EFI forces us to have a FAT stored within the ISO.
16:39:21 <clever> ah
16:39:31 <clever> let me double-check how nixos handles things
16:39:35 <doug16k> DusXMT, no way. its executable format is PE (windows format) and its calling convention is windows, and the boot partition must be FAT
16:40:04 <klange> I already have an ISO BIOS bootloader that works great, so I wanted it to keep working while also allowing the EFI loader to use the simple filesystem drivers built-in to EFI.
16:40:10 <clever> but uefi is extensible, and apple just added support for HFS+ to their firmware images
16:40:23 <klange> Plus I thought it'd be a neat hack if I could get this particular brand of isohybrid working.
16:40:49 <clever> klange: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/installer/cd-dvd/iso-image.nix is where nixos handles all of the iso images
16:40:51 <doug16k> it is definitely neat
16:40:51 <klange> It's really amazing how Apple was on board with EFI before it was standardized, despite being a Microsoft and Intel invention.
16:40:51 <bslsk05> ​github.com: nixpkgs/iso-image.nix at master · NixOS/nixpkgs · GitHub
16:41:27 <klange> I have a special place in my heart for hybrid files.
16:41:35 <clever> line 80 generates an EFI/boot directory with all of the efi files
16:41:41 <klange> Now I should see if I can make this a valid PDF...
16:41:47 <doug16k> klange, lol
16:42:04 <clever> line 124 then generates an efi image, using mkfs.vfat and mcopy
16:42:11 * CompanionCube thinks EFI is more a modern DOS in ROM than a Windows.
16:42:43 <clever> line 368 then includes that fat disk image as /boot/efi.img on the cdrom
16:43:06 <clever> and line 395 sets the efiBootImage param of make-iso9660-image to "boot/efi.img"
16:43:10 <doug16k> just installed a brand new 6000 BTU of happiness in my window
16:43:38 <doug16k> oh wait, 8000
16:43:45 <clever> https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-iso9660-image.sh#L59
16:43:47 <bslsk05> ​github.com: nixpkgs/make-iso9660-image.sh at master · NixOS/nixpkgs · GitHub
16:43:51 <klange> clever: Their EFI loader likely knows how to get from the EFI partition back to the actual ISO and has an ISO driver built-in to find the rest of the files (syslinux?)
16:44:34 <clever> klange: it looks like nixos is putting a fat32 disk image as a file on the iso9660 FS, and then using xorriso -e boot/efi.img -eltorito-alt-boot -no-emul-boot -isohybrid-gpt-basdat
16:44:46 <klange> clever: yes, that is how you make an EFI loadable ISO.
16:44:48 <doug16k> clever, that's how efi expects it
16:44:59 <doug16k> the "boot program" is actually a fat partition image
16:45:27 <doug16k> an alternate one. the non-efi one is the first one, which is a normal eltorito one
16:45:37 <doug16k> that loads somewhere and it jumps into it
16:46:05 <klys> were it not for flash storage, fat would be deprecated by now
16:46:23 <CompanionCube> to be replaced by what?
16:46:36 <klys> something ms built
16:47:08 <doug16k> replaced preferably by a filesystem not based on singly linked lists
16:47:15 <CompanionCube> nothing's yet bested it in the niche of 'basic lowest-common-denominator' filesystem
16:49:55 <CompanionCube> FAT's simplicity and wide-ranged usage is what's allowed it to last this long despite being a rather bad filesystem overall. None of the modern filesystems has managed to make a serious dent in that specific use case
16:50:20 --- quit: zeus2 (Ping timeout: 260 seconds)
16:50:35 <klys> does ext2 use singly linked lists?
16:50:56 <clever> klange: i believe ext uses a fairly complex tree system
16:50:56 <doug16k> it uses a radix tree doesn't it?
16:51:12 <klys> there, thanks
16:51:43 <clever> klys: each tier of the tree has a longer depth of indirect pages, so short files lack indirect pages, and load faster
16:52:53 <klange> I have an ext2 driver in my OS. Mostly use it for ramdisk, though.
16:53:07 <klys> is it too complex for say a five sector bootloader?
16:53:54 <klange> It wouldn't serve any purpose in this setup.
16:57:54 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
17:03:27 <klange> I think I gain some things from this approach. I don't need to write an actual FAT driver (the parser tool I wrote is in Python and can make assumptions about contiguous files), and my EFI loader doesn't need to care that it's on a CD - so it would work on any EFI system partition as long as that system partition had the necessary boot files for the OS. Wins on both sides.
17:06:14 <klange> Plus if I want to mount the disc in the OS, I can just mount the disc as ISO9660 - again, no FAT driver, and no chain mounting or having to parse a GPT on a CD to get to the files.
17:07:17 <clever> klange: what if this image is written to a usb stick, and somebody modifies files on the fat image?
17:07:41 <klange> You can't do that.
17:07:51 <clever> what stops you?
17:08:00 <klange> The fact that it would break everything ;)
17:08:06 <clever> other then things breaking horribly because your using iso9660 for the offsets
17:08:35 <klange> Also the embedded FAT isn't set up in a way that allows easily editing it even if you did put the image on a USB stick - you still have to jump through hoops to mess with the FAT.
17:08:46 <clever> ah
17:08:55 <clever> so its not visible in the partition table
17:09:06 <clever> probably only in special records that a cdrom uses to boot
17:09:40 <klange> It's an ISO, it doesn't have a partition table in a standard location - there's a shadow GPT that EFI knows about, but if you plopped the image on a USB stick it wouldn't have a functional partition table.
17:09:53 <pikhq> Honestly, I think FAT is gonna be hard to replace even if you design something vaguely suitable for purpose but simpler, just because FAT is ubiquitously supported.
17:10:10 <clever> klange: the nixos image i looked at above, also includes a proper MBR header, so it also works on a usb stick
17:10:17 --- quit: geordi (Remote host closed the connection)
17:10:28 <pikhq> That factor alone means replacing it will end up like replacing GIF.
17:11:12 <clever> klange: the -isohybrid-mbr flag
17:11:19 <klange> Even in the MBR case, the EFI file system is not marked as FAT, it's marked as EFI System Partition, and Windows at least tryies to make those difficult to write to. Ultimately, though, the answer is "don't fucking do that."
17:11:33 <klange> The other answer is "if you do that, run the ISO extent update tool again"
17:12:38 <klange> Additionally my BIOS loader wouldn't work on a USB stick anyway.
17:13:01 <klange> It uses a native ATAPI driver. Part of why I'm building an EFI loader in the first place.
17:13:42 <clever> ah, and the usb<->hdd emulation in legacy bios for usb boot, likely just does it via the legacy bios api for hdd's
17:15:13 <clever> which reminds me of a bit of a kludge i discovered while trying to boot nvme a few months ago
17:15:18 <clever> grub technically has zero nvme support
17:15:31 <clever> it relies on the motherboard firmware to provide drivers via uefi
17:15:37 <klange> Yeah, would need to stay down in real mode to do the BIOS disk reads. Possible, but annoying. Could assume a large amount of memory and just copy the entire disk (I use all the files on it anyway) to memory first and then jump to protected to do the ISO parsing, but that seems silly. Ultimately, not interested in building a full-featured BIOS loader.
17:15:57 --- quit: patv (Quit: Page closed)
17:19:42 <clever> klange: i also just remembered the fun setup i made to iscsi boot nixos
17:20:02 <clever> klange: i had a non-netboot build of grub in the MBR of an iscsi image, using the legacy bios hooks in ipxe to make it netboot
17:24:18 --- quit: epony (Ping timeout: 240 seconds)
17:29:09 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
17:30:26 <doug16k> clever, my motherboard has bios support for nvme
17:30:36 <doug16k> and efi for that matter
17:31:27 <doug16k> anything reasonably new should handle nvme
17:31:49 <palk> "reasonably new"
17:32:14 --- quit: variable (Ping timeout: 265 seconds)
17:33:25 <doug16k> developers get new dev boxes like every year right? :)
17:33:32 <palk> if your definition of "reasonably new" is "handles nvme," then that is a tautology; otherwise, the statement is false
17:33:53 --- quit: Tobba (Ping timeout: 244 seconds)
17:33:58 --- join: zeus2 (~zeus@197.239.7.77) joined #osdev
17:34:26 <palk> once a decade is more likely
17:35:16 <doug16k> you sure you know what a tautology is? a machine several years old can boot nvme
17:35:21 <clever> doug16k: in my case, i was helping a friend boot from nvme with a pcie adapter card, so the firmware didnt officially support it
17:35:47 <clever> no clue how old the motherboard was
17:35:59 --- quit: mavhq (Read error: Connection reset by peer)
17:36:03 <clever> my primary desktop also has an adapter, but /boot is on sata, and linux dont care
17:36:42 <clever> the windows installer somehow detects if the bios supports nvme, and refuses to even install to an nvme drive, even if you could just shove the efi sys partition onto a sata one to kludge your way thru it
17:37:14 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
17:37:37 <palk> just because a "several years old" system can boot nvme does not mean that every "several years old" system can, nor that it is "unreasonably" new
17:37:59 <clever> palk: the main rule i would go by, is if the motherboard has an nvme slot on it
17:38:15 <clever> if the hardware physically supports nvme, the firmware it ships with better support it :P
17:38:27 <palk> that doesn't mean the bios supports the interface APIs to it
17:39:05 <palk> "real" OSs don't use BIOS interface APIs to it
17:39:58 <clever> but the bios itself still needs to support nvme, to load the efi binaries from it, if you choose to boot from nvme
17:40:36 <geist> but you need to be more careful than that: not all m.2 slots are pci-e
17:40:51 <clever> yeah, some can be sata
17:41:03 <geist> though in general they were msata before that
17:41:13 <geist> which is definitively not pcie, and a dead end now
17:41:55 <doug16k> clever, I have the opposite anecdote. a friend of mine with a seven year old fx-990 motherboard and fx-8150 cpu booted off a pcie nvme
17:41:59 <geist> what is unclear is if there were any nvme pci card based drives (either a direct card, or a m.2 on a carrier board) that has a BIOS rom that allows it to still work
17:42:21 <clever> model name : AMD FX(tm)-8350 Eight-Core Processor
17:42:22 <geist> if so, then that would generally make things work for at least classic bios bits. and possible uefi if it had firmware for that
17:42:26 <clever> doug16k: almost identical cpu to mine
17:42:32 --- quit: chao-tic (Quit: WeeChat 1.0.1)
17:42:44 <clever> doug16k: ive never actually tested to see if my desktop supports nvme, its a fairly high end board
17:42:56 <clever> crosshair v formula-z
17:43:16 <geist> if it's uefi based, and fairly recent (last 4 or 5 years) should be
17:44:12 <clever> the bios shows a copywrite date of 03/23/2015
17:44:20 <geist> but honestly my gaming rig is SATA SSD based, and i'm not gonna dumb a load of money just to switch it to nvme. it'll probably be a tiny bit quicker, and i'll feel a little more superior, but it's really not worth the cash. for gaming at least
17:44:35 <doug16k> in my friend's case he had to update his bios to whatever is the latest, so it probably wasn't using pci rom. can't be very recent though for such an old motherboard
17:44:39 <geist> but any new ssd i get if i can do it nvme, absolutely
17:44:49 <doug16k> it's more than a tiny bit though
17:45:05 <sysfault> All you need to do is find a board with a PCI-Express 3.0 x4 intertface m2 slot. Some older boards only support NVME disks that are PCIE 2.0 x2 and SATA, which are no faster than a regular SATA III SSD.
17:45:13 <doug16k> more like 6x faster
17:45:23 <clever> i got my laptop shipped with only nvme, and it had zero trouble booting
17:45:23 <geist> eeeh. maybe. depends a bit
17:45:37 <geist> clearly at the wire it'll be faster, but a lot of times stuff is cpu bound anyway, for games.
17:45:55 <geist> compressed bits on disk, decoding the bundles, loading textures, etc
17:46:08 <clever> geist: that reminds me, i discovered one day that WoW saves mod state to the disk 1 byte at a time, with a complete flush between every byte
17:46:12 <geist> i dont see it saturating the SATA link almost ever, so i dont have a lot of evidence that it'll be a massive win
17:46:15 <doug16k> my game loading screens are silly. it zips past the actual loading part and the only delay is the server communication stuff
17:46:22 <geist> and then 32GB ram is great for caching bits
17:46:32 <clever> geist: i discovered this when putting the game on a samba share, and that 1 byte flush turned into a 50ms round-trip over the LAN, per byte
17:46:34 <geist> yah and they're basically silly on my rig too, for games i play
17:46:43 <clever> geist: it took 15 minutes just to exit the game, lol
17:46:48 <chrisf> lots of PC game IO is just crap
17:46:53 <geist> right
17:46:59 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
17:47:05 <geist> compressed, unoptimized, etc
17:47:19 <geist> best thing you can do is be patient and throw lots of ram at it
17:47:22 <clever> i use ZFS on sata ssd's with my desktop, with zfs compression enabled
17:47:33 <clever> just installing a game in steam saturates the cpu so hard that the entire system lags
17:47:51 <clever> steam is the only thing to do it, i think they are doing multi-threaded disk writes to fully max out the hardware
17:48:00 <chrisf> read+decompress isnt necessarily a loss if they've chosen sensibly
17:48:01 <doug16k> when I play old games like elder scrolls oblivion, I can't read the little tip that comes up when loading :)
17:48:10 <clever> doug16k: lol
17:48:13 <doug16k> it's fun to see if I can catch a couple of words
17:49:42 <geist> and a fast SSD actually makes the elevators in mass effect 2 bearable
17:50:03 <geist> i was actually actively playing that game when i bought my first SSD drive. it was night and day
17:50:59 <geist> ah mass effect 1 actually: https://www.penny-arcade.com/comic/2007/11/16
17:51:01 <bslsk05> ​www.penny-arcade.com: Penny Arcade - Comic - Nitpicking: Mass Effect, Part Two
17:52:01 <clever> something ive been wondering about, does the osdev wiki have any specs on the usb debug ports?
17:52:15 <clever> both the old ones, and the newer 3.0 ones
17:52:20 --- join: geordi (~geordi@ns510081.ip-192-99-4.net) joined #osdev
17:52:35 <geist> the xhci based ones? we actually did some amount of work on them for fuchsia. got it kind of working
17:52:51 <geist> i think it's just specced in xhci as an optional feature. but you need the magic usb debug cables
17:52:55 <geist> think they're about $20 a pop
17:53:19 <clever> geist: i'm interested in the protocol those magic cables speak, and if i can just implement it with open-source firmware on a microcontroller
17:53:20 --- quit: zeus2 (Ping timeout: 260 seconds)
17:53:21 <geist> i seemed to remember that it's kind of fiddly
17:53:53 <geist> wouldn't be surprised. iirc it just negotiates a particular device connection with a pair of bulk endpoints or something
17:54:09 <clever> i remember 1.0/2.0 having a dumb debug port, that is basically just serial, without the device-under-test having to run a usb stack
17:54:11 <geist> i think you can just connect to it from a host using libusb or whatnot
17:54:12 <doug16k> clever, it's documented in the main xhci spec document for the 3.0
17:54:28 <clever> and 3.0 having something more powerful that can inspect cpu registers, without the OS having to be responding
17:54:38 <geist> the magic is all on the 'device' side, and in this case xhci offloads all of the logic
17:55:12 <doug16k> clever, what? xhci doesn't jtag into the machine, it's just a data transport
17:55:14 <geist> *that* i believe is some sort of proprietary nonsense. i heard someone talking about it at the last intel dev conference i went to (2016 i believe)
17:55:23 <clever> doug16k: let me find the source i was reading...
17:55:32 <geist> doug16k: iirc, there's some sort of other proprietary extension that requires a magic box
17:55:36 <geist> and of course is intel specific
17:56:01 <geist> i think it comes in via a usb-c connector and actually negotiates another alternate wire format
17:56:35 <geist> but it sort of kind of accomplishes a lot of the same thing as a jtag. provided the motherboard manufacturer actually wires it up
17:56:39 <geist> which (hopefully) they dont
17:56:48 <doug16k> on cpus where the usb controller is integrated into the cpu?
17:56:58 <doug16k> I can see that being feasible then
17:57:15 <geist> yah and i think there's at least one xhci on every intel soc nowadays
17:57:17 <clever> cant find the link about the jtag level stuff
17:57:37 <geist> i think it's somewhat magic, i seriously doubt you can figur eit out
17:58:04 <geist> the other one that doug is talking about is an open spec. i think only intel implements it in their xhci controllers. haven't checked to see if ryzen added the feature
17:58:10 --- join: epony (~nym@77-85-141-166.ip.btc-net.bg) joined #osdev
17:58:29 <geist> iirc you can tell if your controller supports it since it shows up as a pci-e option
17:58:44 <clever> 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller (prog-if 20 [EHCI])
17:58:47 <clever> Capabilities: [e4] Debug port: BAR=1 offset=00e0
17:58:53 <clever> 00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller (prog-if 20 [EHCI])
17:59:00 <clever> 00:16.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller (prog-if 20 [EHCI])
17:59:00 <geist> yeah but that's EHCI, that's some other thing
17:59:06 <geist> usb 3. XHCI
17:59:16 <clever> 3 of my usb controllers support the EHCI debug port
18:00:19 <doug16k> yeah I thought clever meant the normal usb debug port standard thing
18:00:23 <geist> or at least i have a strong reason to believe that the xhci based debug stuff has nothing at all to do with the ehci stuff
18:00:33 <clever> ah, and my laptop doesnt have any debug ports
18:00:47 <geist> since if anything the register interface would be different for setting it up at least
18:01:00 <geist> though i suppose they could negotiate the same looking device interface
18:01:04 <doug16k> I can't find Debug in my lspci -vvv
18:01:25 <clever> 00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31)
18:01:35 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
18:01:44 <geist> all of my machines are powered off at home so i cant check
18:01:46 <clever> and the laptop only has a single usb controller, xhci, none of that ohci + ehci mess
18:02:30 <clever> geist: do you think the EHCI debug port stuff would also be in the spec?
18:03:50 <doug16k> I think it is
18:04:02 <doug16k> I didn't look at ehci a lot but I remember it being there
18:04:12 --- quit: trout (Ping timeout: 240 seconds)
18:04:28 <doug16k> yes, appendix c
18:05:06 --- quit: graphene (Remote host closed the connection)
18:06:01 <clever> doug16k: ah, perfect
18:06:16 <geist> note you still may need a magic cable
18:06:32 --- join: graphene (~graphene@46.101.134.251) joined #osdev
18:06:37 <geist> the ones i have look like a single cable with two USB-A ends, both orange
18:07:02 <clever> my motherboard has a cable almost exactly like that
18:07:18 <clever> if you hit a special button on the motherboard, i believe it turns one of the ports into usb-slave mode
18:07:26 <clever> it then advertises itself as a USB HID device
18:07:35 <geist> for what purpose?
18:07:46 <clever> and with the right (windows only) software, you can view the cpu temps, voltages, fan speeds, and change the clock speed/ratio/voltage
18:07:57 <clever> you can even read the cpu temp/voltage while the machine is "off"
18:08:20 <clever> and it has GUI buttons to do an acpi shutdown, hard poweroff, hard reset, and bios reset
18:08:24 <geist> an then that's something completely different
18:08:28 <clever> along with reading diagnostic codes
18:08:30 <geist> thats talking to some little microcontroller
18:08:30 --- quit: hmmmmmm (Ping timeout: 244 seconds)
18:08:40 <geist> cute, but i'm sure that's outside of the chipset
18:09:06 <clever> yeah, i strongly suspect its acting in usb slave mode, i dont know what debug port does yet, reading appendix c
18:09:42 --- quit: CompanionCube (Ping timeout: 240 seconds)
18:10:07 <doug16k> typically when you have the debug debug port enabled, it isolates it from the debugged OS, that port simply doesn't exist to it
18:10:28 <clever> yeah, i believe its the same with this special port on the motherboard
18:10:32 --- join: promach_ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
18:10:42 --- join: CompanionCube (~samis@unaffiliated/drmushroom) joined #osdev
18:12:33 <clever> section C.4, it mentions that in mode 1 (the usb drivers are off), that the EHCI controller has to generate its own keepalive packets
18:12:38 --- join: ybyourmom (~ybintell@vampire.ertos.nicta.com.au) joined #osdev
18:12:43 <clever> that implies that the debug port is in host mode
18:13:25 <clever> so the magic cable, needs to have 2 usb controllers, both acting as usb slaves
18:13:58 <clever> but you could possibly cheat, and just use 1 slave controller for the debug port, plus a TTL serial going into an FTDI...
18:15:13 <doug16k> note that specs like that say things with the intended audience being people implementing the hardware. the spec mentions sync packets being sent over the link, utterly irrelevant to an os developer implementing remote debug
18:15:52 <clever> but my goal is to make my own debug cable
18:16:12 <doug16k> ah so you are implementing the hardware then. ok it's totally relevant to you :)
18:17:00 <clever> i want to turn https://www.sparkfun.com/products/retired/12765 into a debug device
18:17:02 <bslsk05> ​www.sparkfun.com: Teensy 2.0 - DEV-12765 - SparkFun Electronics
18:17:10 <clever> and then debug why my desktop is hanging hard
18:19:08 <doug16k> I can tell you why it is hanging hard: something's wrong with it
18:19:09 <geist> clever: the usb 3 debug cable isn't that complicated
18:19:27 <clever> i see no mention of vid/pid, usb descriptors, or anything related
18:19:33 <geist> one side does act in host mode, the cable just has special wiring that instructs the device side to automatically decide to be a device
18:19:44 <geist> so it's really got a magic pullup or something on one end
18:19:54 <clever> doug16k: i suspect its multiple cores stalling on the same spinlock, but when that kind of thing goes south, its hard to get any core to respond for a backtrace
18:20:49 --- quit: geekodour08 (Remote host closed the connection)
18:21:11 <clever> geist: that sounds very similar to USB-OTG
18:21:15 <doug16k> why not rs-232 serial printfs?
18:21:30 <clever> doug16k: no hardware serial port on the system
18:21:43 <clever> and a usb stack is likely to hang
18:21:54 <geist> yes, it is, the trick is that the xhci controller then switches over into this magic debug mode with no cpu intervention
18:22:15 <geist> does the entire device side negotiation in hardware
18:22:18 <Love4Boobies> MAGIC DEBUG MODE
18:22:53 <geist> MAGIC!
18:23:00 <geist> like EL TORITO
18:24:11 <doug16k> you might be able to write logs to a buffer in ram, then when it hangs, press reset and read the logs from the buffer and write them to disk
18:24:42 <clever> doug16k: oh yeah, and doesnt uefi allow doing just that via nvram?
18:24:49 <klange> and now my efi loader is loading files over the EFI file system APIs, yay
18:24:58 <doug16k> perhaps, by preparing a little bootloader that is made specifically for that
18:25:13 <doug16k> on a flash drive or something
18:25:28 <clever> the tricky part, is getting it to detect when it has hung, and to save the logs on its own
18:25:39 <geist> doug16k: that's where we write kernel logs to to recover the crash on next boot in zircon
18:25:42 <geist> pretty easy
18:26:12 <geist> most platforms have some sort of mechanism like that, up to an including just squirrling shit away and hoping the bootloader doesn't overwrite it
18:26:42 <clever> theres also the crash kernel in linux
18:30:23 <doug16k> clever, you could setup a perf counter as a watchdog timer that is close to overflowing. periodically keep resetting it to a value, and if/when it hangs, it will overflow. set up the LAPIC to NMI when the perf counter overflows, NMI handler captures context
18:31:18 --- quit: JusticeEX (Ping timeout: 240 seconds)
18:31:42 <doug16k> you could send a series of NMI IPIs to the other cpus to coerce them into doing a backtrace/context dump
18:32:53 <doug16k> or just configure each cpu to do its own watchdog timer
18:32:56 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
18:33:53 <doug16k> the problem is that you don't know what it was doing at the point it deadlocks, right?
18:33:55 <clever> doug16k: i have gotten backtraces out of the spinlocked cores before with `echo l > /proc/sysrq-trigger`
18:34:15 <doug16k> oh this isn't your own OS? it's linux?
18:34:17 <clever> but i'm not entirely sure that was the same fault, sometimes one core survives by chance and it limps along enough to respond to ssh
18:34:21 <clever> yeah, normal linux
18:34:25 <doug16k> oh
18:34:28 <doug16k> nevermind then
18:35:02 <clever> i have also recently confirmed issues with a sata drive simply dropping a request, and the kernel hangs forever waiting for a reply that wont come
18:35:12 <clever> that went away after removing a sata dock from the path
18:35:42 <clever> but it still had a total deadlock after fixing that
18:35:53 --- join: zeus2 (~zeus@197.239.7.77) joined #osdev
18:36:14 --- quit: variable (Ping timeout: 276 seconds)
18:36:23 <clever> and then the summer weather kicked in, and lately its been going into thermal shutdown
18:36:34 <clever> ive had to turn off half the cpu cores just to stop it from overheating
18:36:55 --- quit: graphene (Remote host closed the connection)
18:37:04 <doug16k> yeah? then the cpu's switching regulator probably has cooked capacitors and the cpu voltage is rippling up and down in a triangle wave
18:37:25 --- quit: promach_ (Quit: WeeChat 2.1)
18:37:27 <clever> i can actually graph the cpu voltage, using the special port i mentioned previously
18:37:52 <clever> doug16k: https://i.imgur.com/uXLYuMx.png
18:37:59 <doug16k> yeah, at what sampling rate? definitely not enough
18:38:09 <doug16k> I'm talking hundreds of kHz
18:38:10 <clever> maybe half a second?
18:38:23 --- join: graphene (~graphene@46.101.134.251) joined #osdev
18:38:43 <clever> prior to disabling 4 cores, the current graph literally went off the scale
18:38:47 <clever> the software wont let me zoom out enough to see how many amps its pulling, lol
18:39:00 <clever> and past ~80c, it just shuts off hard
18:39:06 <clever> no trace of thermal throttling
18:40:34 <clever> would you happen to know if the FX8350 lacks thermal throttling?
18:41:13 <doug16k> afaik everything post head-spreader era has throttling
18:41:51 <clever> that makes things pretty strange
18:42:21 <doug16k> switching regulators can have stability issues with fried capacitors
18:42:42 <clever> ive had 3 models of laptops with dynamic speed, which have refused to leave the lowest speed when overheating
18:42:52 <clever> and 1 of those laptops has also gone into thermal shutdown when the fan got stuck
18:43:18 --- quit: zeus2 (Ping timeout: 268 seconds)
18:43:19 <clever> though the 8350 lacks any dynamic clocking, so i can see how it would be harder to even see if its throttling
18:44:47 <doug16k> you redid the thermal interface material, right?
18:45:08 <clever> after the first thermal shutdown i cracked open the case to discover the fan was clogged with dust
18:45:23 <clever> heatsink*
18:45:34 <clever> and then when trying to remove the heatsink, i wound up ripping the entire cpu out of the socket, lol
18:45:34 <doug16k> took off the heatsink, removed the old crap, put new high quality thermal paste on, and reinstalled the heatsink?
18:45:58 <doug16k> don't pull up. rotate it back and forth and only use light upward force
18:46:25 <doug16k> you want to shear off the material, not yank it off vertically
18:46:27 <clever> yeah, i made the mistake of trying to work it side to side at an angle
18:46:50 <clever> once i did shear it off with a hammer and screwdriver, i scrubbed both sides clean with acetone and paperdown
18:46:55 <buhman> how does lk's thread_resched() not require an infinitely large call stack?
18:46:59 <clever> and re-applied new paste
18:47:07 <clever> papertowl*
18:47:40 --- quit: graphene (Remote host closed the connection)
18:47:43 <clever> doug16k: it only suffered minor damage in the bottom right: https://i.imgur.com/Rlpe5Ky.jpg
18:48:34 <doug16k> I don't see any ESD precaution in that pic :)
18:48:45 --- quit: nwm (Ping timeout: 260 seconds)
18:48:50 <clever> doug16k: https://imgur.com/XVBf94R may frighten you then
18:48:51 <bslsk05> ​imgur.com: Imgur: The magic of the Internet
18:49:12 <clever> i'm surprised that i didnt bend a single pin
18:49:50 --- join: nwm (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
18:50:14 --- join: hmmmm (~sdfgsf@pool-72-79-160-252.sctnpa.east.verizon.net) joined #osdev
18:51:57 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-ibirbycyvlroeckk) joined #osdev
18:53:54 --- join: isd (~isd@209.6.64.199) joined #osdev
18:54:26 <doug16k> clever, you're joking about the hammer and screwdriver, right?
18:54:43 <clever> doug16k: nope
18:55:08 <klys> zero insertion force
18:55:11 <doug16k> as soon as you pick up a hammer when working on a computer, you're doing it wrong :D
18:55:16 <clever> doug16k: i placed a flat bladed screwdriver on the side of a corner (note the ding in the first image), and lightly hit it with a hammer until the cpu came free
18:55:47 <clever> doug16k: a hammer is also how i got the sata drive bay into my NAS
18:56:08 <clever> doug16k: the dumb case has tabs for the cdrom drives to sit on, which stops you from putting in any 5.25" drives that take up 3 bays
18:56:35 <doug16k> you realize that the machine is full of brittle ceramic capacitors, right?
18:56:49 <klange> oops I put my efi\boot\bootia32.efi in my ISO as well and virtualbox wasn't able to load some files (and apparently can only see 32 files in a directory in its ISO driver, fun stuff!)
18:56:51 <clever> the cpu was not in the motherboard when i was using the hammer
18:57:01 <clever> i had already ripped it out of the ZIF by accident at that point
18:57:30 <clever> and being a ZIF, i did not want to shove it back in with the arm in the locked position
18:57:41 <klange> vbox looking for efi\boot\bootia32.efi on the ISO filesystem first sounds non-compliant
18:57:50 <chrisf> nick checks out
18:58:04 <chrisf> this whole story is a bit clownshoes
19:01:38 <klange> Now I should write some long-to-protected jump code and build this as a 64-bit EFI app...
19:02:50 <clever> doug16k: hmmm, checking some images online of people deliding an 8350, i do see that the cpu has its own ceramic caps...
19:04:29 <doug16k> yes. that deformation of the heatspreader in the corner could be holding the headspreader away from the heatsink, drastically reducing contact area
19:04:47 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
19:05:12 --- quit: froggey (Ping timeout: 240 seconds)
19:05:24 <clever> doug16k: i believe its deformed away from the heatsink, i was careful with the angle i kept the screwdriver at
19:07:20 <klange> doug16k: btw, you may want to use the loaded image's DeviceHandle to find the SIMPLE_FILE_SYSTEM for the partition that loaded you, rather than the first handle that responds to the simple fs GUID.
19:07:50 <doug16k> klange, I do don't I?
19:07:56 --- quit: trout (Ping timeout: 265 seconds)
19:08:21 <klange> no, looks like you query for all simple file system handles and take the first one https://github.com/doug65536/dgos/blob/master/boot/bootefi.cc#L157
19:08:23 <bslsk05> ​github.com: dgos/bootefi.cc at master · doug65536/dgos · GitHub
19:08:34 <doug16k> all one of them
19:08:41 <klange> I was trying the same and vbox kept giving me the ISO
19:09:03 <klange> have you tried this on a system with more EFI-readable partitions?
19:09:31 <klange> It's possible it's just an issue with VirtualBox, but it was giving me the ISO as the first handle even when I ran the app directly from the FAT.
19:09:59 <klange> (I get two handles in vbox - which is also visible in the shell which shows fs0 and fs1)
19:10:07 <doug16k> it should be querying it from the executable handle, that was the intent
19:10:13 <doug16k> it isn't?
19:10:30 <klange> You use LocateHandleBuffer so you're not referencing the image anywhere.
19:11:10 <doug16k> oh right, I thought I was querying it from the image_handle
19:11:40 <doug16k> wow so it's just a fluke and it would fail if there were others
19:12:16 <doug16k> at one point it was querying it from the image_handle, I guess I broke it at some point. thanks
19:12:31 <klange> <3
19:13:12 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
19:19:24 --- quit: CheckDavid (Quit: Connection closed for inactivity)
19:20:55 <geist> buhman: it switches stacks at the bottom
19:21:06 <geist> inside the arch context switch routine
19:22:32 <buhman> ah
19:23:37 <buhman> arch_context_switch looks like complete black magic
19:24:07 <geist> i assure you it isnt, but different arches make it easier or difficult
19:24:15 <geist> the cortex-m version of it is unforunately black magic
19:24:24 <buhman> yeah that's what I'm reading :)
19:24:57 <geist> yah, sadly cortex-m has a very specific way of doing context switches that aren't exactly how LK is written, so there's a bit of black magic to line up the two styles of context switch efficiently
19:27:18 --- join: zeus2 (~zeus@197.239.7.77) joined #osdev
19:27:48 <klange> oh right I neglected to implement the EFI memory map support... need to do that.
19:27:50 <geist> also as you can see the FPU stuff adds a lot of complexity
19:27:55 <klange> then my efi loader willb e complete
19:28:53 --- quit: tacco| ()
19:30:41 <doug16k> there we go, now I HandleProtocol efi_loaded_image_protocol_guid from efi_image_handle into efi_loaded_image then I HandleProtocol efi_simple_file_system_protocol_guid on the efi_loaded_image->DeviceHandle
19:30:49 <klange> yay
19:31:24 <klange> i love that my boot is basically instantaneous in virtualbox
19:31:39 <klange> it doesn't bother emulating anything related to read times for disks
19:31:42 --- quit: JusticeEX (Ping timeout: 240 seconds)
19:31:42 --- quit: freakazoid0223 (Ping timeout: 240 seconds)
19:32:03 <klange> (because why would you want that in a desktop user-oriented virtual machine meant to provide maximum guest performance)
19:32:07 <doug16k> neither does qemu though
19:32:17 <klange> QEMU still manages to be super slow loading ATAPI.
19:32:56 <doug16k> yeah? I haven't noticed
19:33:10 <doug16k> on IDE though? I hardly touch IDE
19:33:28 <klange> Yeah, IDE gets some delay or read slowness emulated
19:34:15 <geist> dunno so much about that but i think i have observed that the bios implementation on qemu is incredibly unoptimized for disk access
19:34:19 <doug16k> most of the time I'm using nvme, but for iso boot, obviously not possible so I typically use ahci, but I can run qemu with ide though, I do support ide so I have a helper to launch qemu with the boot drive on ide
19:34:35 <geist> we have some patch against the bios for zircon to make -kernel <something larger than a few MB> actually bearable
19:34:51 <geist> if you load like 100MB with it it was previously taking like 45 seconds
19:35:05 <klange> Even OVMF is slow, and that's supposed to have actual drivers - takes 4 seconds to load my ramdisk.
19:35:29 <geist> and apparently it was because it was using some sort of internal bios int for copying every single sector between buffers
19:35:38 <geist> and it just eventually adds up
19:35:49 --- quit: jakogut (Quit: jakogut)
19:36:37 <geist> the OVMF implementation is also very slow for some reason. i think it does a full memory scrub or something
19:38:17 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
19:39:30 <doug16k> klange, it's likely that the IDE insw that transfers the sector is implemented as 256 calls to the port read handler in the IDE emulation. ahci would just do async I/O on the host and blast it into a memory as DMA
19:39:59 <geist> word
19:40:42 --- quit: variable (Ping timeout: 240 seconds)
19:41:08 <klange> doug16k: yeah, that sounds like a reasonable theory
19:50:48 --- quit: zeus2 (Ping timeout: 244 seconds)
19:54:56 --- quit: Love4Boobies (Ping timeout: 244 seconds)
20:06:46 --- join: Love4Boobies (~L4B@unaffiliated/l4b) joined #osdev
20:07:52 --- quit: nj0rd (Ping timeout: 265 seconds)
20:09:21 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
20:10:48 --- quit: Love4Boobies (Ping timeout: 240 seconds)
20:11:13 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
20:12:13 --- quit: trout (Ping timeout: 265 seconds)
20:20:46 --- join: nj0rd (~nj0rd@200116b8459e8600e7f3471da2d3b900.dip.versatel-1u1.de) joined #osdev
20:32:44 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
20:34:29 --- join: zeus2 (~zeus@197.239.7.77) joined #osdev
20:34:46 --- quit: epony (Quit: QUIT)
20:40:28 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
20:43:12 --- quit: variable (Ping timeout: 240 seconds)
20:44:05 <doug16k> I just realized that EFI PXE is trivial. since the boot program is the whole EFI partition I just need to point the PXE DHCP responder at the boot partition image
20:44:37 <klange> neat
20:44:38 <doug16k> the code doesn't need one line relating to PXE
20:45:07 <doug16k> now, time to prove that :)
20:46:36 <doug16k> yep, works!
20:48:50 <doug16k> uh oh... maybe not
20:49:02 <doug16k> it was false positive, it actually booted from disk
20:49:28 <klange> oops
20:52:06 <doug16k> says "downloading NBP file" ... delay while downloading 41MB ... NBP downloaded successfully ... drops back to boot menu
20:52:58 <doug16k> just OVMF being its fun self that just drops back to a prompt when something fails
20:57:48 <doug16k> nope, you have to point the DHCP boot file at the actual EFI executable on the TFTP server
20:59:42 --- join: graphene (~graphene@46.101.134.251) joined #osdev
21:01:48 --- quit: zeus2 (Ping timeout: 240 seconds)
21:04:51 <doug16k> I had a glimmer of hope that when I queried the simple_filesystem_protocol from the image handle it would give me an interface to a magically abstracted TFTP filesystem. nope
21:06:10 <doug16k> if TFTP had the capability to download N bytes and offset X, there would be a chance in hell that it would have
21:06:26 <klange> only a handful of pointer size warnings to fix to get my efi loader building for x86-64, and it appears to be doing what it needs to up until the jump to kernel where I need to jump down to protected m ode
21:06:30 <klange> excellent
21:07:34 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
21:11:12 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
21:14:50 --- quit: trout (Ping timeout: 276 seconds)
21:17:19 --- join: epony (~nym@77-85-141-166.ip.btc-net.bg) joined #osdev
21:25:19 --- quit: spare (Ping timeout: 264 seconds)
21:35:44 --- join: NightBlade (~user@ip-173-247-149-50.user.start.ca) joined #osdev
21:36:25 <qoxncyha> are there any methods of IPC other than networking and domain sockets?
21:37:16 <Mutabah> shared memory?
21:37:31 <qoxncyha> how can you share memory across process boundaries?
21:37:35 <Mutabah> TLB sidechannels? :)
21:38:09 <Mutabah> OS-specific, but somehow a pair of processes end up with the same physical page shared between them
21:38:12 <Mutabah> s/OS/kernel/
21:38:29 <Mutabah> maybe a shared file?
21:39:56 --- quit: brynet (Quit: leaving)
21:42:53 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
21:43:12 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
21:43:31 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
21:45:42 --- quit: variable (Ping timeout: 240 seconds)
21:45:52 --- join: zeus2 (~zeus@197.239.7.77) joined #osdev
21:46:46 --- join: brynet (~brynet@brynet6.biz.tm) joined #osdev
21:57:27 <klange> Has anyone done the backtrack to protected from long mode?
21:59:48 --- quit: bauen1 (Ping timeout: 240 seconds)
22:02:26 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
22:02:42 --- join: Kazinsal_ (~Kazinsal@unaffiliated/kazinsal) joined #osdev
22:05:19 --- join: angel0xff (~zzz@158-58-227-127.sf.ddns.bulsat.com) joined #osdev
22:06:29 --- quit: Kazinsal (Ping timeout: 255 seconds)
22:09:05 <ybyourmom> Nope, not me
22:09:15 <ybyourmom> I don't text my exes
22:11:07 --- quit: bauen1 (Remote host closed the connection)
22:12:32 --- quit: chao-tic (Quit: WeeChat 1.0.1)
22:13:35 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
22:15:15 --- quit: apetresc (Ping timeout: 260 seconds)
22:17:10 --- join: apetresc (~apetresc@CPEbc4dfb720b93-CMbc4dfb720b90.cpe.net.cable.rogers.com) joined #osdev
22:17:14 --- quit: trout (Ping timeout: 276 seconds)
22:19:54 <jjuran> qoxncyha: mmap() with MAP_SHARED
22:20:40 <klange> posix has a dedicated shared memory mechanism as well
22:20:50 <klange> lots of options
22:23:27 --- quit: zeus2 (Ping timeout: 268 seconds)
22:24:42 <doug16k> klange, I have
22:24:53 <doug16k> you mean long to protected don't you?
22:25:36 <klange> yeah
22:25:45 <klange> so I can make a 64-bit EFI app that loads my 32-bit kernel.
22:25:52 <doug16k> you 1) turn off paging, 2) clear LME in EFER
22:26:21 <doug16k> then next time you turn paging on, it won't kick into long mode
22:27:51 <doug16k> you need to be executing code from an identity mapped address before turning off paging (of course)
22:28:23 <doug16k> it's likely to be identity mapped in your scenario, EFI generally identity maps everything
22:28:52 <klange> yeah, I think I'm good on that - haven't checked, but the virtual addresses look promising
22:29:03 <doug16k> you might need a step 0 as well, far jump to a cs that doesn't have L bit set
22:29:54 <doug16k> let me check what I do. my earlier bootloader went all the way from real mode up to long mode and all the way back to real mode for each block it loaded :)
22:30:01 <doug16k> I still have that piece of code there
22:31:49 <doug16k> yeah, in my case it does a retf from long mode back to protected mode (step 0), then it does step 1 and 2 I mentioned above
22:32:07 <doug16k> the cs selecting a descriptor that doesn't have L bit set
22:32:13 <doug16k> the retf cs I mean
22:32:31 --- quit: angel0xff (Ping timeout: 244 seconds)
22:33:39 <doug16k> so technically, after the retf it would be what we call compatibility mode, which is sort of protected-mode-in-long-mode execution mode. clearing CR0.PG is when it really leaves long mode and you are really in protected mode. clearing EFER.LME prevents the next setting of CR0.PG to 1 going back into compatibility mode
22:35:21 <doug16k> LME = Long Mode Enabled. when CR0.PG transitions from 0 to 1 when EFER.LME is 1, LMA transitions to 1 and you are in compatibility mode
22:35:57 <doug16k> when CR0.PG transistions from 1 to 0 when EFER.LMA is 1, it transitions to protected mode and EFER.LMA transitions to 0
22:36:28 <doug16k> LMA = long mode active
22:38:22 <doug16k> did that make sense?
22:40:14 <klange> gotcha
22:40:22 <doug16k> so yeah it'd be push protected mode cs, push label_after_the_retf, retf, label_after_the_retf:, clear CR0.PG, clear EFER.LME
22:40:49 <doug16k> and .code32 before clear CR0.PG
22:41:57 <doug16k> oops, push $label_after_the_retf
22:42:01 <doug16k> you knew that though :)
22:42:24 <klange> ;)
22:42:34 --- quit: MDude (Ping timeout: 268 seconds)
22:43:48 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
22:45:56 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
22:46:33 --- quit: port8443 (Quit: Candlejack has no power he)
22:46:34 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
22:47:12 --- join: port443 (~wizardmin@mtndewcode.red) joined #osdev
22:48:35 --- quit: isd (Quit: Leaving.)
22:48:42 --- quit: variable (Ping timeout: 240 seconds)
22:52:48 --- quit: nwm (Ping timeout: 240 seconds)
22:53:34 --- join: nwm (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
22:55:10 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
23:01:03 --- join: myvar (~myvar@105.186.208.217) joined #osdev
23:02:06 --- quit: myvar (Remote host closed the connection)
23:03:42 --- join: myvar (~myvar@105.186.208.217) joined #osdev
23:07:08 --- join: zeus2 (~zeus@197.239.7.77) joined #osdev
23:15:21 --- join: sixand (~Thunderbi@222.84.223.232) joined #osdev
23:15:52 <CrystalMath> does anyone know a way to detect the maximum number of addressable bits on an x86? assuming 386+
23:15:59 <CrystalMath> i suppose no PAE automatically means 32
23:16:04 <CrystalMath> PAE means at least 36
23:16:25 <doug16k> do you mean maximum physical address bits?
23:16:30 <CrystalMath> yes
23:16:35 <CrystalMath> physical address
23:16:56 <doug16k> cpuid leaf 0x80000008
23:17:03 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
23:17:09 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
23:17:28 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
23:18:00 <doug16k> eax[7:0] is the maximum linear address size (typically 48, maybe 57)
23:18:15 <doug16k> eax[15:8] is the maximum physical address size (definitely <= 52)
23:20:02 <doug16k> if that leaf isn't supported, and PAE is supported, then you can assume max physical address size is 36
23:20:14 <doug16k> in 32 bit, max linear address size is obviously 32
23:20:17 --- quit: trout (Ping timeout: 276 seconds)
23:20:29 <doug16k> PAE can support more than 36, if that leaf exists
23:20:55 <doug16k> to know if that leaf exists, read cpuid leaf 0x80000000 and make sure eax >= 8
23:22:29 <CrystalMath> doug16k: thanks :)
23:27:39 <klange> well i jumped to my kernel, and early boot log is showing stuff, but looks like my info struct is bad... hm
23:28:40 --- join: grouse (~grouse@83-233-9-2.cust.bredband2.com) joined #osdev
23:29:39 <doug16k> klange, was the info a global variable in your efi executable or on its stack? I don't think it is safe to rely on that after exitbootservices
23:29:58 <doug16k> to be completely safe you should allocate memory for it from efi and copy it there
23:30:58 <klange> actually bad struct definition had some pointer references that should have been fixed sized integers
23:31:05 <doug16k> I did notice funny stuff happening to some of my data after exitbootservices, when I put it in an allocated block, no problem
23:31:17 <doug16k> ah, that :)
23:31:31 <doug16k> yeah I explicitly force everything to be 64 bit in my kernel parameters struct
23:31:40 <klange> now I'm GPFing when trying to set up page directories in my kernel, but I've got all my module references :)
23:32:54 <klange> https://gist.github.com/klange/34c45f7cc589897b1aec626085a3ad32
23:32:56 <bslsk05> ​gist.github.com: kernel.log · GitHub
23:32:58 --- quit: banisterfiend (Ping timeout: 244 seconds)
23:33:41 <doug16k> klange, you might want to toggle global pages off and on somewhere soon to flush global mappings from the TLB
23:33:53 <klange> good call
23:38:37 <[Orchestra]> like 2 years ago I did try that OS
23:39:02 <[Orchestra]> It's mind blowing
23:39:09 <[Orchestra]> sincerely
23:40:15 <doug16k> also note that no-execute isn't enabled by OVMF. that broke my code early on, because I always have it enabled if possible in my BIOS bootloader, and forgot in my EFI kernel entry code. if you use that, make sure you turn it on. might not be an issue for your code if it originally expected to take control from multiboot
23:41:16 <doug16k> my bootloader enters my kernel fully in long mode with the paging fully set up
23:42:04 --- join: w41 (~w41@unaffiliated/w41) joined #osdev
23:43:48 --- join: manzerbredes (~loic@myriads-lg.irisa.fr) joined #osdev
23:46:03 <[Orchestra]> ls -al /home/john/github/toaruos/
23:46:04 <[Orchestra]> total 80
23:46:06 <[Orchestra]> drwxr-xr-x 9 root root 4096 Nov 9 2016 .
23:46:17 <[Orchestra]> that's it ~
23:47:48 --- quit: w41 (Ping timeout: 240 seconds)
23:52:18 --- quit: zeus2 (Ping timeout: 264 seconds)
23:52:46 <[Orchestra]> it booted on a dedicated machine (old amd sempron, that I still have!) if i'm correct.
23:52:51 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
23:53:21 <[Orchestra]> but it's not gud for everyday use unless I throw the MB into a bath of oil :D
23:53:42 <[Orchestra]> too noisy fan's....
23:55:12 --- quit: variable (Ping timeout: 240 seconds)
23:55:18 <[Orchestra]> noway the power consumption resulting that oldish HW is a waste... :D
23:56:27 --- quit: nortega (Remote host closed the connection)
23:56:59 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
23:59:28 --- join: w41 (~w41@unaffiliated/w41) joined #osdev
23:59:59 --- log: ended osdev/18.07.10