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

Tuesday, 17 July 2018

00:00:00 --- log: started osdev/18.07.17
00:00:47 <geist> https://fuchsia.googlesource.com/third_party/qemu/+/6c17729ff7b17575efbe5ef518371550f691461d is our change actualy
00:00:48 <bslsk05> ​fuchsia.googlesource.com: 6c17729ff7b17575efbe5ef518371550f691461d - third_party/qemu - Git at Google
00:01:18 <geist> seems that it does precisely that, it matches multiboot.S to use the dma interface to read from fw_cfg
00:01:34 <geist> reminds me, we should clean this up and get it upstreamed
00:03:07 --- quit: zeus1 (Ping timeout: 264 seconds)
00:03:59 <geist> anyway, i sleep now
00:04:25 --- quit: sixand (Quit: sixand)
00:04:43 --- join: sixand (~Thunderbi@119.123.34.73) joined #osdev
00:05:20 --- quit: sixand (Client Quit)
00:10:12 --- join: sixand (~Thunderbi@119.123.34.73) joined #osdev
00:12:07 --- quit: aalm (Ping timeout: 268 seconds)
00:12:18 --- join: m3nt4L (~asvos@2a02:587:a01d:4100:3285:a9ff:fe8f:665d) joined #osdev
00:20:26 --- quit: iknosis (Ping timeout: 260 seconds)
00:21:11 --- join: iknosis (~iknosis@185.183.104.140) joined #osdev
00:24:36 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
00:26:07 --- quit: iknosis (Ping timeout: 256 seconds)
00:26:16 --- join: iknosis (~iknosis@185.183.104.140) joined #osdev
00:31:38 <klange> https://gist.githubusercontent.com/klange/d462ba5111d592f84e113816f3701527/raw/722eefe73998e5b6860c7f6a621d925591d8539b/gistfile1.txt
00:35:49 --- quit: flacks (Ping timeout: 240 seconds)
00:36:37 --- join: myvar (~myvar@105.186.208.217) joined #osdev
00:37:58 --- join: flacks (flacks@184.91.69.131) joined #osdev
00:38:28 --- quit: magnificrab (Ping timeout: 256 seconds)
00:39:40 <Ameisen> ccYsITfx.s:18848: Error: invalid register for .seh_savexmm
00:39:42 --- join: magnificrab (~pi@189.171.148.122.sta.dodo.net.au) joined #osdev
00:39:48 <Ameisen> I find that odd. Only happens on mingw builds
00:47:44 --- join: xerpi (~xerpi@210.red-83-45-194.dynamicip.rima-tde.net) joined #osdev
00:48:43 --- quit: bemeurer (Ping timeout: 240 seconds)
00:50:19 --- join: asymptotically (~asymptoti@gateway/tor-sasl/asymptotically) joined #osdev
00:58:22 <klange> and in investigating geist's question I just sort of implemented support for > and >> in my shell and wrote a small xxd clone and fixed a bug in my kernel where O_APPEND wasn't working...
01:05:16 <Sjors> doug16k: I wonder if it's the right approach to set shadow bits on store, and check them on load, re asan
01:05:33 <Sjors> doug16k: I think this way, if you store something in the wrong place, it will allow it
01:05:46 <Sjors> doug16k: or am I misreading your code?
01:13:56 --- join: Avinash (~Avinash@unaffiliated/avinash) joined #osdev
01:15:07 --- quit: [Awaxx] (Quit: Power cut... again...)
01:15:13 <klange> so that all appears to be working okay... https://i.imgur.com/mUNDGGO.png
01:15:35 <klange> it's just as shoddy as my pipe implementation but it works well enough to at least look like it's a unix shell
01:19:21 --- join: [Chorus] (~while@unaffiliated/awaxx/x-0928682) joined #osdev
01:23:52 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
01:23:53 --- join: Avinash_ (~Avinash@unaffiliated/avinash) joined #osdev
01:26:12 --- join: chao-tic (~chao@122.62.26.54) joined #osdev
01:26:31 --- quit: Avinash (Ping timeout: 264 seconds)
01:35:05 --- join: vaibhav (~vnagare@125.16.97.123) joined #osdev
01:37:05 <Avinash_> klange: hi, how long you have been working on your os? https://www.youtube.com/watch?v=9mTwWIW7G8g it just blowed my mind
01:37:06 <bslsk05> ​'ToaruOS 1.2.1 demo reel' by K Lange (00:10:38)
01:38:28 <klange> I started working on my OS early in 2011 / late in 2010 if you include book reading.
01:40:02 --- quit: xerpi (Quit: Leaving)
01:43:17 <Avinash_> oh my god, that took a while
01:43:24 <Avinash_> but you did great
01:44:19 --- quit: vaibhav (Ping timeout: 256 seconds)
01:44:37 --- join: glauxosdever (~alex@ppp-94-66-203-124.home.otenet.gr) joined #osdev
01:44:41 <Avinash_> klange, how did you managed to build gui
01:44:49 <Avinash_> could you please teach me
01:44:51 <klange> ToaruOS's GUI has an interesting history.
01:44:59 <Avinash_> please tell me
01:45:23 <klange> I came from working on Compiz, so I really wanted to do my own windowing system in my OS, so it was a goal from the beginning.
01:45:58 <klange> First ToaruOS UI was a really shoddy and slow compositor, the shared memory subsystem for it was hacked together in a few weeks with so me help from a friend/classmate.
01:46:31 <Avinash_> thats so cool
01:46:34 <klange> The first compositor used shared memory for a lot more than it should have, including communicating initial handshakes with applications (it would then use a pipe to send events / receive commands)
01:47:03 <klange> Learned a lot building that - mostly a lot about what I really needed from an IPC mechanism to do it right.
01:47:41 <klange> The second iteration of ToaruOS's compositor, which is still around, was a lot better architected.
01:48:00 <klange> The UI in that video you linked uses a lot of third-party stuff for drawing - Cairo, freetype, libpng.
01:49:05 <Avinash_> oh, but it looks awesome, great work
01:49:28 <klange> I've been working on ditching all the third-party stuff for core parts of the OS, starting with the C library. That project has been going really well, but don't quite have all the apps (or even the libraries) ported over yet to really replace the original OS.
01:49:58 <ybyourmom> You want to write your own libc?
01:50:18 <klange> I've done enough of it to port Python again.
01:50:36 <ybyourmom> Sounds like not my kind of thing
01:50:36 <klange> It's not exactly my idea of a fun time, but a got a lot of derision over the years for using newlib :P
01:50:37 <ybyourmom> gl
01:51:08 <ybyourmom> Writing a compat layer from posix to my OS just to port a libc will be hard enough
01:51:25 --- join: navidr (uid112413@gateway/web/irccloud.com/x-bbppxyqphaawxrep) joined #osdev
01:51:36 <klange> The harder parts of libc are all in stdio.
01:51:56 --- quit: hmmmm (Remote host closed the connection)
01:53:39 <klange> I miss Cairo. It was so fast at blitting...
01:54:09 --- quit: Humble (Ping timeout: 276 seconds)
01:54:27 <klange> I want to patch up my compositor so it can take different rendering libraries, so that when I get cairo ported again the compositor will be able to use it if installed...
01:54:53 <klange> I want to do something similar for the system text rendering and freetype, so if freetype is installed it will be used instead of the sdf renderer.
01:55:41 --- join: vaibhav (~vnagare@125.16.97.125) joined #osdev
01:56:20 <klange> Those three libraries are the only ones that really got used heavily by the core OS.
01:56:26 <klange> Er, those two and libpng*
01:56:44 <m712> they're all really good libraries
01:56:54 <m712> klange: ever gonna support GTK+?
01:57:06 <klange> I don't know if that's more or less likely with my own C lib.
01:57:27 <klange> I will say a lot of the problems I had with porting GLib on the path to maybe porting GTK+ were because newlib was getting in the way.
01:57:41 <klange> It would be /awesome/ to have a GTK+ backend for my windowing system.
01:57:55 --- quit: bemeurer (Ping timeout: 256 seconds)
01:58:01 <klange> I want to sortie even managed to port the libraries (with no backends) at some point to Sortix.
01:58:34 <klange> GTK+ is apparently not *that* much of a porting nightmare, it's mostly getting glib happy with your system as that's where all the real fun is.
01:58:44 <klange> Ah, time to go home.
01:58:56 <m712> i'm still in the process of hooking the language i'm gonna write my operating system to LLVM :/
01:58:58 <m712> climbing mount everest is tough
01:59:00 <m712> klange: have a nice trip
02:00:51 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
02:03:09 --- join: ljc (~ljc@unaffiliated/ljc) joined #osdev
02:04:09 --- quit: Avinash_ (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:07:19 --- join: light2yellow (~l2y@185.220.70.162) joined #osdev
02:08:54 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
02:10:57 --- quit: nwm (Ping timeout: 240 seconds)
02:13:19 --- quit: bemeurer (Ping timeout: 240 seconds)
02:14:35 --- join: Avinash (~Avinash@unaffiliated/avinash) joined #osdev
02:18:45 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
02:30:46 --- quit: S_Gautam (Quit: Connection closed for inactivity)
02:31:35 <klange> Right now my biggest stumbling block with porting stuff is libm crap.
02:31:47 <klange> Considering whether I should just take the dive on that one and use a BSD libm like sortie.
02:31:54 <sortie> Hello klange
02:31:59 <sortie> I recommend using musl's libm
02:31:59 <klange> Hello person I keep pinging.
02:32:10 <sortie> Ah I was about to hello you before you pinged me
02:32:15 <sortie> Predictive ping. That's what the world has come to.
02:32:22 <sortie> musl's libm is better than the BSD ones
02:32:39 <sortie> My libm isn't overall that great, part of it is my fault, part of it is what I imported
02:33:03 --- join: Asu (~sdelang@95.82.136.77.rev.sfr.net) joined #osdev
02:33:06 <sortie> musl seems to have cared a bit more and is more complete, I found my libm didn't do everything it was supposed to
02:34:50 <klange> I've been writing stubs as needed and have implemented a handful of things that needed to be implemented, but as my only real consumer of libm at the moment is either myself or Python, it's spotty.
02:42:26 <m712> isn't libm math.h?
02:44:52 <sortie> Yes
02:48:10 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
02:48:24 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
02:49:37 --- quit: SopaXorzTaker (Remote host closed the connection)
02:52:36 <m712> i can't let neovim go. i tried spacemacs but it has too many little weirdnesses that using it becomes a pain
02:54:09 <m712> dir-locals fails with terse output, everytime you open a file emacs will cd into the file's folder, slow as molasses to boot, completion engine won't understand system headers, ...
02:55:15 <m712> i'm banned from #emacs so i can't ask about any of it
02:57:15 --- quit: Lucretia (Quit: Konversation terminated!)
02:57:21 --- quit: Goplat (Remote host closed the connection)
02:58:51 --- quit: chao-tic (Quit: WeeChat 1.0.1)
03:00:27 --- join: Lucretia (~Luke@pdpc/supporter/active/lucretia) joined #osdev
03:01:36 --- join: Humble (~hchiramm@106.208.52.95) joined #osdev
03:12:19 --- quit: shakesoda (Quit: Connection closed for inactivity)
03:18:20 --- quit: Avinash (Quit: Textual IRC Client: www.textualapp.com)
03:18:49 <Lowl3v3l> m712: hummm for me spacemacs works fine, but i just run it in the console
03:18:58 <m712> yeah me too
03:19:10 <m712> maybe it's just not the one
03:19:22 <m712> nvim sucks but it works
03:20:06 <m712> i'd love to learn all the ins and outs of emacs and be blessed by saint iGNUcius but on't have the time atm
03:21:19 --- quit: bemeurer (Ping timeout: 240 seconds)
03:44:14 <Lowl3v3l> m712: i feel you xD though i do most my development in IDE's by now so i rarely even start a plain text editor
03:44:25 <m712> shame on you
03:44:48 <m712> torturing your poor ram with GTK+ windows
03:45:12 <m712> nvim can pretty much become an IDE with few plugins
03:45:18 <Lowl3v3l> not my fault i have to use VS and do java at work.
03:45:28 <Lowl3v3l> i have no option there, none at all^^
03:46:00 <m712> eclim (code completion -> vim omnicomplete) + YCM (omnicomplete -> better format + async) + nerdtree (project tree)
03:46:26 <Lowl3v3l> and i have done my private stuff( even osdev) in VS as well to learn it. and it's working surprisingly well
03:46:36 <m712> heathens
03:46:39 <m712> heathens everywhere
03:46:58 <m712> eclim runs a headless eclipse to do code completion
03:46:58 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
03:47:19 <m712> for java only iirc tho, YCM's C/C++ support is stellar
03:48:12 <Lowl3v3l> i know all the important vim and emacs plugins. but i just do not have any option to use them at work. So i dont. And in general, i am of the fraction "use the best tool available", and as long as intellij is unmatched for java and VS is a good c++ ide i will use those. My "got to use command line vim to jerk off on how leet i am"-times are over ;)
03:48:29 <m712> sure sure
03:48:38 <m712> i don't disagree
03:48:44 <m712> use whatever's available
03:48:52 <m712> but vs still sux xD
03:49:32 <Lowl3v3l> does it? it has some features that i have never found in any other c++ ide by now. I am waiting for the day when finally there is a good c++ ide.
03:49:41 <m712> Lowl3v3l: tell me about them
03:50:07 <m712> i mainly dislike it because microsoftware
03:50:56 --- join: Kimundi_ (~Kimundi@i577A99E4.versanet.de) joined #osdev
03:51:07 <Lowl3v3l> the llvm-toolchain integration is really good and the remote-building as well. e.g. my os atm is built using this remote-building function which connects to the linux subsystem and does all the compilation and stuff there.
03:53:49 <asymptotically> Lowl3v3l: if you like intellij, have you tried CLion?
03:54:04 <Lowl3v3l> asymptotically: nope, haven't got the money^^
04:01:09 --- join: aalm (~aalm@37-219-73-181.nat.bb.dnainternet.fi) joined #osdev
04:08:42 --- join: SopaXT (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
04:09:50 --- quit: SopaXorzTaker (Ping timeout: 256 seconds)
04:11:10 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
04:17:20 <Lowl3v3l> asymptotically: their RC really does look neat. to sad they want money for the whole thing
04:18:57 --- join: Kimundi__ (~Kimundi@i577A952E.versanet.de) joined #osdev
04:22:19 <m712> Lowl3v3l: instead of connecting to the linuz subsystem, you use linux itself :)
04:22:31 --- quit: Kimundi_ (Ping timeout: 248 seconds)
04:24:15 --- quit: Amaan (Quit: Connection closed for inactivity)
04:24:22 <m712> i'm not a FOSS absolutist but I try to use and develop it as much as I can
04:27:33 <ybyourmom> I follow the GPL thing up to GPLv2, but not as far as the anti-TiVo-ization clause in GPLv3
04:27:51 <m712> ybyourmom: why?
04:29:32 <ybyourmom> I can understand the argument that if you create IP, you have the right to license it as you see fit, and in fact you can't actually sell software: you actually sell licenses to software, and not software itself
04:29:57 <ybyourmom> As the creator and owner, you have a natural right to control that property and to sell it on your terms
04:30:22 <m712> but you sell the hardware, not a license to the hardware
04:30:26 <ybyourmom> I don't see an argument however, for you being able to control someone else's product (hardware) based on your ownership of some software running on it
04:30:42 <ybyourmom> Hardware is the result of physical labour and not intellectual labour
04:31:06 <m712> okay, so what
04:31:12 <m712> 's your gripe with it?
04:31:16 <m712> I don't get it
04:31:55 <ybyourmom> I don't see the argument for you being able to control the property of another party (hardware assets) based on your ownership of another piece of property (IP)
04:32:47 <m712> are you saying that you don't own the hardware you're sold?
04:32:56 <m712> otherwise as far as I can tell you should be for anti-tivo then
04:33:09 <Lowl3v3l> m712: oh my main pc runs on linux. But for a large part the tools i use are not up for debate ;)
04:33:22 <m712> Lowl3v3l: fite me
04:33:42 <ybyourmom> m712: I purchased the product which TiVo sold me on the terms that they sold it to me under
04:33:50 <Lowl3v3l> m712: discuss with the people dictating my work tools ^^
04:34:04 <m712> Lowl3v3l: give me their number
04:34:08 <Lowl3v3l> ;)
04:34:20 <m712> :^)
04:34:21 <bcos_> ybyourmom: Did you? Usually those sorts of things are rented/leased/licenced and the company still technically owns the hardware
04:34:43 <m712> bcos_: really? ewwwwww
04:34:54 <bcos_> ..and because the company owns the hardware, they should be free to do what they want with their hardware
04:35:01 <ybyourmom> bcos_: No, most rental agreements are explicit
04:35:13 <m712> also gotta love git submodule hells
04:36:09 <m712> bcos_: really reminds you to read the fine print
04:38:19 <bcos_> Hrm
04:40:11 <bcos_> For Tivo specifically; I'm not sure how it works - it looks like in some countries (e.g. USA) it was a subscription service (where you own nothing and their hardware is theirs)
04:40:26 <bcos_> ..but not in some other countries
04:44:41 --- quit: bemeurer (Ping timeout: 260 seconds)
04:50:34 <m712> my set-top box is an SBC running XBMC
04:50:37 <m712> i'm Free
04:51:25 --- join: hchiramm_ (~hchiramm@2405:204:d48c:6030:fae2:e05d:f9d3:2f1b) joined #osdev
04:55:46 --- quit: Humble (Ping timeout: 260 seconds)
04:56:08 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
04:57:30 --- join: S_Gautam (uid286066@gateway/web/irccloud.com/x-rulnkpbsttnbgqqu) joined #osdev
04:58:14 --- quit: SopaXT (Quit: Leaving)
04:58:43 --- join: m_t (~m_t@p5DDA3CFD.dip0.t-ipconnect.de) joined #osdev
05:00:06 <asymptotically> Lowl3v3l: they offer free licenses to students and people developing open source projects. although of course it would be better if it was FOSS :)
05:00:49 --- quit: bemeurer (Ping timeout: 240 seconds)
05:05:38 --- join: Amaan (uid4967@gateway/web/irccloud.com/x-kvzuaqgyhupyxjpa) joined #osdev
05:08:47 --- quit: myvar (Remote host closed the connection)
05:16:42 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
05:18:33 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
05:30:20 --- join: MrOnlineCoder (~MrOnlineC@195.225.231.218) joined #osdev
05:31:41 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
05:33:50 --- quit: D4rk (Ping timeout: 244 seconds)
05:35:47 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
05:37:13 --- join: bauen1 (~bauen1@x59cc82b0.dyn.telefonica.de) joined #osdev
05:38:24 --- join: D4rk (~D4rk@unaffiliated/d4rk) joined #osdev
05:38:42 --- join: graphene (~graphene@46.101.134.251) joined #osdev
05:42:16 --- quit: bauen1 (Remote host closed the connection)
05:43:03 --- quit: X-Scale (Ping timeout: 248 seconds)
05:44:32 <klange> My shell is still exceptionally bad, but I've added some additional functionality, such as... the ability to run script files.
05:44:44 <klange> Yeah, kinda amazing it took so long to actually bother with that one.
05:44:58 <klange> I even have shebang support in my kernel, but I can't remember what I tested it with...
05:45:09 <klange> (I did eventually use it to run Python scripts, but that was way after implementing it?)
05:49:49 --- quit: Kimundi__ (Ping timeout: 240 seconds)
05:51:34 <rain1> cool!
05:52:19 <MrOnlineCoder> Are there any guidelines/checklists, what is required to be in my os to be able to compile gcc? like what syscalls, parts of libc it should support?
05:52:43 <klange> to compile gcc to run on the OS?
05:53:02 <klange> modern gcc is a bit more complicated, since it's C++
05:53:26 <MrOnlineCoder> i know that toaruos can run a bunch of software, including sdl and gcc
05:53:32 <MrOnlineCoder> what have you done to achieve it?
05:54:03 <klange> Mainline ToaruOS manages to run gcc mostly because it uses newlib, though there was a good bit of functionality in the kernel and newlib glue necessary to make that happen.
05:54:47 <klange> The good news about gcc is that the old C versions really only need basic C standard library functionality and the streams-based file access - and I don't even think they need it to be particularly good.
05:55:21 <klange> That said, I haven't tried the newer C++ ones, and I haven't tried building gcc/binutils against my own C library, so... not sure where the bar is set.
05:55:43 <klange> My suggestion is you just try to run the configure script to start with and see what happens.
05:55:43 <MrOnlineCoder> what is the latest gcc verison in `old c`?
05:56:20 <klange> I believe 6 was the last release series written in C, and 6.4 is the latest in that series.
05:56:26 <MrOnlineCoder> ty
05:57:03 --- quit: stoopkid (Quit: Connection closed for inactivity)
05:57:17 <klange> I might be wrong about that?
05:59:53 <klange> gcc built as C++ since 2012, but I don't think it was actually required until much later and/or they're still building with a small enough subset that it's stuff that gcc supports natively?
06:00:04 <klange> but then why do I have it in my head that 6 is some magical number in this...
06:00:30 <klange> I have a port of gcc 6.3 for toaruos-mainline, but I don't actually know...
06:01:04 <MrOnlineCoder> how did you port sdl? doesn't it require opengl implementation?
06:01:39 <klange> SDL 1.x does not require OpenGL - it's an entirely separate library/project to have OpenGL on SDL 1.x
06:01:51 <klange> I think even 2.x you can build without it.
06:02:14 <klange> What you do "need" is a backend that can create windows and draw to them in your OS's graphics API.
06:02:51 <sortie> <MrOnlineCoder> Are there any guidelines/checklists, what is required to be in my os to be able to compile gcc? like what syscalls, parts of libc it should support?
06:03:03 <klange> this repo has all the work I did to port SDL https://github.com/klange/SDL
06:03:04 <bslsk05> ​klange/SDL - MIRROR of SDL (1.2) with additional とあるOS bits (1 forks/1 watchers)
06:03:12 <sortie> MrOnlineCoder: I don't think I made a list, but actually it's not that much. A lot of core C plus a little bit of POSIX (fork, exec, mkstemp, etc.)
06:03:47 <sortie> MrOnlineCoder: But overall it's not too bad compared to a lot of other ports.
06:04:02 <sortie> Oh and you need C++ support of course
06:04:46 <sortie> MrOnlineCoder: https://wiki.osdev.org/Porting_GCC_to_your_OS is the stub about this
06:04:48 <klange> I'll have to build libstdc++ against my libc eventually I guess...
06:04:48 <bslsk05> ​wiki.osdev.org: Porting GCC to your OS - OSDev Wiki
06:04:49 --- quit: MindlessDrone (Ping timeout: 240 seconds)
06:05:22 --- join: vmlinuz (~vmlinuz@32.104.18.203) joined #osdev
06:05:23 --- quit: vmlinuz (Changing host)
06:05:23 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
06:05:26 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
06:07:01 <MrOnlineCoder> klange, so all your apps that require sdl do software-rendering?
06:07:03 --- join: MindlessDrone (~MindlessD@unaffiliated/mindlessdrone) joined #osdev
06:07:28 <klange> Uh, yes, that's normal for SDL.
06:07:56 --- quit: bemeurer (Ping timeout: 268 seconds)
06:07:57 <MrOnlineCoder> sortie, ah, thanks!
06:08:06 <klange> SDL is just a generic framebuffer API.
06:08:40 <klange> (+ a generic input API, + (if you build for it) a standard audio API)
06:08:57 <MrOnlineCoder> ((+ font api haha))
06:09:27 <klange> I sit?
06:09:34 <klange> Pretty sure that's an extension.
06:09:38 <klange> SDL_TTF or something
06:09:40 <MrOnlineCoder> yea
06:09:45 <klange> aka not part of SDL
06:09:54 --- join: FManTropyx (~fooman@82-203-174-167.bb.dnainternet.fi) joined #osdev
06:10:03 <MrOnlineCoder> it is just usually used in sdl projects
06:10:07 <MrOnlineCoder> as SDL image
06:11:12 <klange> I never ported any of those, core SDL was all that I needed for the handful of other stuff - bochs, the snes emulator, etc.
06:11:21 <klange> quake and doom are both SDL ports
06:11:54 <MrOnlineCoder> can you say that if you can compile sdl, you can compile bochs, snes, doom, etc?
06:16:04 <klange> Maybe? Bochs required some additional work.
06:18:04 <klange> The best way to find out what you're missing is to just try.
06:18:51 <klange> I thought it'd be months before my C library would be capable of building Python again, but then I tried it and it only a dozen functions were missing - two days later I had a graphical application written in Python running.
06:20:51 --- join: Kimundi__ (~Kimundi@dhl1116.cs.uni-dortmund.de) joined #osdev
06:23:41 --- quit: ljc (Quit: ayy)
06:28:30 --- quit: graphene (Remote host closed the connection)
06:31:39 --- join: baschdel (~baschdel@2a01:5c0:1c:6201:bb0:858:a281:6ed8) joined #osdev
06:36:17 --- join: Raybih (Raybih@49.125.56.155) joined #osdev
06:40:44 --- quit: Lowl3v3l (Remote host closed the connection)
06:44:56 --- quit: tuxillo (Ping timeout: 268 seconds)
06:48:51 --- quit: MrOnlineCoder (Ping timeout: 265 seconds)
06:55:49 --- quit: sixand (Ping timeout: 240 seconds)
06:57:41 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
07:04:24 --- join: promach_ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
07:09:47 --- quit: sysfault (Remote host closed the connection)
07:10:15 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
07:12:39 --- quit: NightBlade (Ping timeout: 248 seconds)
07:14:20 --- quit: MDude (Remote host closed the connection)
07:16:47 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
07:19:47 --- quit: sysfault (Remote host closed the connection)
07:20:09 --- quit: SopaXorzTaker (Remote host closed the connection)
07:20:19 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
07:20:39 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
07:20:44 --- quit: sysfault (Max SendQ exceeded)
07:21:38 --- quit: Raybih ()
07:31:48 --- quit: bemeurer (Ping timeout: 268 seconds)
07:31:58 <klange> Hm, should I do something inexplicably evil and convert my init process to run a bunch of shell scripts?
07:33:14 --- join: hmmmm (~sdfgsf@pool-72-79-166-36.sctnpa.east.verizon.net) joined #osdev
07:36:35 --- join: hmmmmm (~sdfgsf@pool-72-79-166-45.sctnpa.east.verizon.net) joined #osdev
07:39:41 --- quit: hmmmm (Ping timeout: 260 seconds)
07:44:46 --- join: jakogut_ (~jakogut@162.251.69.147) joined #osdev
07:45:05 --- join: gareppa (~gareppa@unaffiliated/gareppa) joined #osdev
07:46:47 --- join: hmmmmmm (~sdfgsf@pool-72-79-168-31.sctnpa.east.verizon.net) joined #osdev
07:49:42 --- quit: hmmmmm (Ping timeout: 276 seconds)
07:50:51 --- quit: gareppa (Remote host closed the connection)
07:52:35 --- quit: grouse (Quit: Leaving)
07:53:04 --- join: hmmmmm (~sdfgsf@pool-72-79-160-162.sctnpa.east.verizon.net) joined #osdev
07:55:25 --- quit: Tobba (Remote host closed the connection)
07:55:27 --- quit: hmmmmmm (Ping timeout: 240 seconds)
07:55:49 --- join: Tobba (~Tobba@h-25-157.A159.priv.bahnhof.se) joined #osdev
07:55:53 --- quit: hmmmmm (Read error: Connection reset by peer)
07:56:41 --- join: hmmmmm (~sdfgsf@pool-72-79-166-18.sctnpa.east.verizon.net) joined #osdev
07:58:27 --- join: hmmmmmm (~sdfgsf@pool-72-79-166-6.sctnpa.east.verizon.net) joined #osdev
08:01:51 --- quit: hmmmmm (Ping timeout: 260 seconds)
08:02:01 --- join: hmmmmm (~sdfgsf@pool-72-79-165-161.sctnpa.east.verizon.net) joined #osdev
08:04:44 --- quit: hmmmmmm (Ping timeout: 265 seconds)
08:07:33 --- quit: navidr (Quit: Connection closed for inactivity)
08:07:38 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
08:07:45 --- quit: SopaXorzTaker (Read error: Connection reset by peer)
08:08:31 --- quit: hmmmmm (Ping timeout: 264 seconds)
08:08:57 --- join: MrOnlineCoder (~MrOnlineC@195.225.231.218) joined #osdev
08:09:15 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
08:11:01 --- quit: nemo235 (Ping timeout: 265 seconds)
08:12:35 --- join: nemo235 (~nemo@213-225-33-145.nat.highway.a1.net) joined #osdev
08:16:12 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
08:19:45 <geist> klange: that's some crazy progressive stuff
08:19:54 <geist> if you made all of them shell scripts that would be like super flexible
08:19:55 <geist> neat!
08:20:55 --- quit: bemeurer (Ping timeout: 248 seconds)
08:21:09 <heat> P R O G R E S S I V E
08:21:53 <heat> Has anyone tried to do test driven development in the kernel?
08:22:02 --- join: freakazoid0223 (~frkazoid@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
08:23:29 --- join: grzesiek (~grzesiek@PC-77-46-101-67.euro-net.pl) joined #osdev
08:24:51 --- quit: grzesiek (Remote host closed the connection)
08:25:09 --- join: grzesiek (~grzesiek@PC-77-46-101-67.euro-net.pl) joined #osdev
08:25:49 <geist> we've been thinking about it a bit in zircon. here and there we do some
08:25:59 <geist> helps to be using C++ so you can build mock classes and whatnot
08:27:42 <heat> obviously you couldn't really do it for complex hardware
08:27:47 --- quit: manzerbredes (Quit: WeeChat 2.1)
08:27:59 <heat> but it's not a bad idea for kernel features
08:31:48 <geist> indeed
08:33:06 <heat> Do you do kernel tests in the userspace or the kernel?
08:34:06 <geist> well, both really. user space kernel tests are a necessity
08:34:19 <geist> ie, stress testing the kernel, trying to break it. and of course regression tests on behavior
08:39:10 <graphitemaster> have any fuzz tests
08:39:21 <graphitemaster> e.g making every system call with random values
08:39:22 <geist> actually yes. we just got syzkiller running
08:39:33 <geist> https://github.com/google/syzkaller actualy
08:39:33 <bslsk05> ​google/syzkaller - syzkaller is an unsupervised, coverage-guided kernel fuzzer (357 forks/1700 watchers)
08:39:42 <geist> and sure enough it is finding stuff as expected
08:40:08 <geist> we have a whole bug tag for things found because of that, so we're going to start needing to triage these against regular development
08:40:46 <graphitemaster> the engine at work, all our interface functions are small basic wrapper functions that are exported to Lua (and soon other scripting languages) and we have a fuzzer that tests the functions themselves, which is the same as fuzzing from Lua or any other scripting language
08:41:00 <graphitemaster> and the idea is nothing from scripting side should beable to bring the engine down
08:41:25 <graphitemaster> after writing the fuzzer, I found a lot of really weird issues, as expected
08:41:41 <geist> yah
08:41:48 <graphitemaster> they're more or less all fixed except the ones where the fuzzer decides to generate a 1TB string to pass to a function
08:41:52 <clever> ever heard of https://github.com/nccgroup/TriforceAFL ?
08:41:52 <bslsk05> ​nccgroup/TriforceAFL - AFL/QEMU fuzzing with full-system emulation. (78 forks/367 watchers)
08:42:07 <geist> no but sounds neat
08:42:31 <geist> note that these fuzzers usually require a fair amount of effort to run, i think we have a farm of machines to get good coverage
08:42:36 <clever> basically, it will run fork() inside qemu, to dup the entire state of the VM, then do kernel level fuzzing in the copy
08:42:37 <geist> but that's precisely what google is good at
08:42:43 <clever> then destroy the copy, and fork() another one out
08:42:54 <graphitemaster> generic fuzzers are always so much more complicated to setup and run
08:43:14 <geist> indeed
08:43:21 <clever> geist: so you can fuzz a kernel that takes 30 seconds to boot, without paying that 30 second time every test
08:43:57 <geist> indeed. thankfully fuchsia takes less than 2 seconds to boot :)
08:43:58 <graphitemaster> dude works at google, they have farms of systems designed to run workloads to which no one cares how long it takes and if the result is ever used
08:44:14 <geist> graphitemaster: it's actually a very real problem of how do you deal with the firehose of output
08:44:45 <geist> if you file a bug for everything you see you'll get swamped. you probably want to pick out low hanging fruit, fix them, then rerun a new batch, seeing that many are probably dups, etc
08:45:22 <geist> then the other problem i have is making sure you get good coverage on ARM
08:45:31 <graphitemaster> sea of output sucks
08:45:36 <graphitemaster> android logcat
08:45:48 <geist> since a) running qemu on x86 hosts is slow because it's TCG and b) real arm machines to run on are hard to automate
08:46:06 <geist> oh also update: the ThunderX2 machines are on tap for late july now. me want so bad
08:46:11 <clever> geist: what about kvm+qemu on arm?
08:46:20 <geist> clever: you need an arm host for that, which are hard to come by
08:46:31 <geist> we have a pair of cavium thunderx1 machines, but they're currently used for build testing
08:46:35 <clever> yeah, but its easier to automate then running tests on baremetal arm
08:46:36 <geist> we have some thunderx2 machines on order
08:46:49 <geist> sure, but you have to actually *get* a host arm machine to run things on
08:47:00 <clever> i have 4 or 5 rpi's
08:47:06 <geist> they dont do KVM
08:47:19 <geist> because broadcomm is a piece of crap and implemented a nonstandard interrupt controller and timer
08:47:22 --- join: stoopkid (uid137696@gateway/web/irccloud.com/x-yiuxswauzwdukexq) joined #osdev
08:47:38 <geist> best cheapo host i've used is an odroid-c2, which is okayish
08:47:56 <geist> main problem there is not a lot of ram (2GB) and then i noticed the timer resolution is awful. like 1ms
08:48:01 <geist> but so it goes.
08:48:19 <graphitemaster> just use a bunch of chrome books
08:48:40 <graphitemaster> can prolly fit quite a few in a 4U :P
08:48:42 <geist> i dont know of one that's arm64
08:48:51 <geist> most of the early arm chromebooks were cortex-a15s, which is arm32
08:49:04 <geist> dunno about later ones, but at that point you're buying some random machine off amazon
08:49:04 <graphitemaster> samsung ones
08:49:15 <geist> which one? the early samsungs were arm32
08:49:33 <graphitemaster> the plus iirc
08:49:37 <jjuran> The RPi's timer resolution seems to be 10ms.
08:50:04 <geist> jjuran: yeah that's a problem when running qemu+kvm. i found that some tests ran terribad on the odroidc2 when hosting qemu
08:50:06 <graphitemaster> pretty pricy because they have touch screens
08:50:11 <graphitemaster> when you'll never use the sceen
08:50:16 <graphitemaster> oh lol, nintendo switch
08:50:17 <geist> debugged it and it turns out qemu is susceptable to the resolution of the host timer
08:50:29 <graphitemaster> tegra x1 dev boards
08:50:36 <geist> oh fuck anything with tegra in it
08:50:42 <geist> never touching that crap with any length of pole
08:50:46 <graphitemaster> :(
08:50:52 <heat> why?
08:51:01 <graphitemaster> nvidia dinked some shit
08:51:02 <geist> they tend to be like broadcomm. *highly* irregular
08:51:15 <geist> hell, they even had their own core, Denver. transmeta style shit
08:51:21 <heat> what do you mean with irregular?
08:51:27 <geist> wouldn't be suprirsed if that doesn't implement the hypervisor extensions anyway
08:52:10 <geist> basically since there are so many options in the ARM world, cores and SoCs that are good for running hypervisors need to have a series of features checked off
08:52:53 <geist> need a) a core that implements EL3-EL0 b) a boot rom that starts linux in EL2 (some dont) c) needs a standard interrupt controller (GICv2 or GICv3) d) needs a standard arm timer (built in, but some socs prefer a custom timer)
08:53:23 <geist> a is generally okay, b is all over the place. qualcomm cores have wonky boot roms that usually nerf starting the core in EL2 because they tend to run their own hypervisor
08:53:39 <geist> c is mostly cool, except broadcomm in rpi because they used their own custom interrupt controller
08:53:55 <geist> and d i've seen various vendors hack the linux kernel to use their own timer: amlogic, broadcomm
08:54:30 <geist> *all* server class arm cores are totally fine, because arm mandates all of these features in their server spec. SBC? server base something spec
08:55:20 <geist> oh also samsung tends to fail on b as well. the bigger arm soc vendors that are big in android space tend to have more complex boot loader stacks that like to 'occupy' EL2
08:55:40 <geist> your best bet is asically a random chinese soc maker, because they usually dont leave anything in rom and just implement a standard design
08:55:51 <geist> amlogic, rockchip, etc
08:56:21 <geist> <end of info dump>
08:56:35 <geist> now you know, go forth and prosper
08:56:55 <heat> huh
08:57:06 <Asu> i saw a twitter thread about tegra cpus
08:57:18 <Asu> it was about a bug caused by a on-chip recompiler
08:57:22 <geist> i think the newer tegra cores are more standard, they moved away from Denver
08:57:23 <heat> what was EL* again?
08:57:26 <geist> not sure they're going to do it again
08:57:31 <Asu> and also they had 8 cores in hardware but 4 of them were literally unusable
08:57:50 <geist> Asu: yeah i hope to never have to deal with it. i heard android kernel folks at work grumbling about those pieces of crap
08:58:02 <geist> heat: in ARM64 there are 4 run levels, not unlike 'rings' in x86
08:58:06 <geist> EL0 = user space
08:58:12 <geist> EL1 = standard kernel supervisor mode
08:58:15 <geist> EL2 = hypervisor
08:58:23 <heat> ah I see
08:58:27 <geist> EL3 = monitor (for power management. like SMM)
08:58:39 <heat> so the bootloaders like to act like hypervisors?
08:59:03 <geist> sometimes. usually the boot rom leaves around a monitor in EL3, but some of them also leave behind their own hypervisor in EL2
08:59:07 <Asu> found it
08:59:09 <Asu> https://twitter.com/FioraAeterna/status/855445075341398017
08:59:10 <bslsk05> ​twitter: <FioraAeterna> small brain: bug in your code ␤ big brain: bug in the compiler ␤ cosmic brain: bug in the cpu's on-chip recompiler <github.com/golang/go/issu… https://t.co/JZc9ndx6Pt> https://pbs.twimg.com/media/C98mpVuVoAAE4_N.jpg
08:59:20 <geist> most of them dont. linux automatically leaves behind a little hypervisor stub if the kernel was started in EL2
08:59:30 <geist> then uses it later if KVM is activated
09:00:18 <geist> it's sort of complicated but way more straightforward than VMX and SVM in x86 world
09:00:24 <geist> you simply run another kernel above your kernel
09:00:29 <geist> it's kernels all the way down
09:00:49 <heat> kernel-ception
09:03:36 <geist> anyway, so its quite possible to run qemu+kvm on an arm linux machine, you just need the right arm linux machine
09:04:00 <geist> and like in many cases the bargain bin, cheapest thing you can find (rpi) is not a good one
09:04:13 <geist> someties you gotta spend a few more bucks to get the right thing
09:04:34 <heat> wouldn't the EL2 occupation thing exist for security reasons
09:04:52 <geist> it could
09:05:03 <heat> so even if you get a compromised kernel you can't really flash the rom or whatever
09:05:24 <geist> sure, that's *sort* of whats going on in he qualcomm world
09:05:55 <geist> they leave a little monitor kernel like thing behind in EL2 that facilitates communication between the EL1 kernel (linux, android) and the other processors on the soc (radio, media DSP, etc)
09:06:06 <geist> that way linux kernel doesn't really have direct access to any of that
09:06:30 <geist> of course then the qualcomm thing is likely to be full of security holes, so if you root that you own the whole soc
09:06:37 <heat> that's stupid right?
09:06:45 <heat> you're just slowing things down
09:07:06 <geist> preaching to the choir
09:07:28 <heat> so why do they do that?
09:07:32 <geist> i think it's also because they're afraid of GPL, so they can run whatever secret code they want in EL2 and then hide it behind an IPC mechanism to the linux kernel
09:08:08 <geist> and then just treat the linux kernel that's running android as another client in a sea of cpus
09:08:26 <geist> last i checked on a snapdragon 835 for example there were something like 13 different cores running different operating systems
09:08:43 <geist> so the idea is to have one central arbiter running somewhere to manage all of the buffers and whatnot
09:08:44 <heat> I thought vendors didn't need to merge their changes back to the mainline tree?
09:09:11 <geist> yeah but they dont even have to open source it if it isn't in the kernel at all
09:09:51 <heat> I didn't know they had to open source it
09:09:59 <heat> anyway, couldn't they just use a module
09:10:10 <geist> dont think android does modules. anyway, that's their problem
09:10:19 <geist> i'm not here to try to dissect what qualcomm thinks.
09:10:42 <geist> they're basically an IP company run by lawyers, so they almost always err on the side of keeping it secret and not releasing the source if they can find a way to do it
09:11:15 <geist> as a software person i hate dealing with their stuff, it's always layers and layers of black boxes with minimal documentation
09:11:41 <geist> and usually there's some okayish reasoning for all the black boxes. they like to keep things modular, even within their own company, so that product group A doesn't have to know what B does, etc
09:11:47 <geist> but it's really frusterating as an end user
09:12:04 <heat> TIL nvidia doesn't have the best black boxes
09:12:20 <geist> yah
09:12:32 <geist> to be fair nvidia is a bit nicer to deal with now than they were 5 or 10 years ago
09:12:38 <heat> nvidia needs to learn how to IPC
09:12:48 <heat> have they released gpu docs yet?
09:12:52 <geist> 8 years ago when i had to last deal with them they were outright hostile, it was baffling
09:13:08 <geist> gpu wise i think they're just as tight as always
09:13:38 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
09:13:44 <geist> anyway, off to work
09:13:46 --- mode: geist set -o geist
09:16:02 --- join: bemeurer (~bemeurer@148.64.103.131) joined #osdev
09:17:13 --- quit: Amaan (Quit: Connection closed for inactivity)
09:19:57 --- quit: m_t (Quit: Leaving)
09:29:02 --- join: [Brain] (~brain@brainwave.brainbox.cc) joined #osdev
09:43:06 --- join: MDude (~MDude@pa-67-234-83-197.dhcp.embarqhsd.net) joined #osdev
09:51:08 --- join: MarchHare (~Starwulf@72-172-219-73.fidnet.com) joined #osdev
09:56:49 --- quit: opios (Ping timeout: 244 seconds)
10:00:09 --- join: isaac_ (~isaac@host81-129-159-113.range81-129.btcentralplus.com) joined #osdev
10:01:14 <heat> http://renderingpipeline.com/graphics-literature/low-level-gpu-documentation/
10:01:17 <bslsk05> ​renderingpipeline.com: Low-Level GPU Documentation | RenderingPipeline
10:01:23 <heat> I just found this and it might be useful for someone
10:04:55 --- join: manzerbredes (~loic@ARennes-650-1-33-137.w86-215.abo.wanadoo.fr) joined #osdev
10:06:17 --- join: hmmmm (~sdfgsf@pool-72-79-166-208.sctnpa.east.verizon.net) joined #osdev
10:10:39 --- join: Icefoz (~Icefoz@roc.alopex.li) joined #osdev
10:10:51 <Icefoz> Hello once again, all
10:10:57 --- quit: MrOnlineCoder (Read error: Connection reset by peer)
10:11:03 --- nick: isaac_ -> isaacwoods
10:11:18 <heat> hi
10:13:19 --- quit: pie_ (Ping timeout: 240 seconds)
10:25:28 --- quit: MDude (Quit: Going offline, see ya! (www.adiirc.com))
10:25:51 --- join: MDude (~MDude@pa-67-234-83-197.dhcp.embarqhsd.net) joined #osdev
10:28:49 --- quit: promach_ (Quit: WeeChat 2.2)
10:28:50 --- quit: MDude (Client Quit)
10:29:24 --- join: MDude (~MDude@pa-67-234-83-197.dhcp.embarqhsd.net) joined #osdev
10:38:49 --- quit: newnix (Ping timeout: 240 seconds)
10:41:26 --- nick: vaibhav -> vaibhav|geone
10:41:30 --- nick: vaibhav|geone -> vaibhav|gone
10:43:58 --- join: tuxillo (~antonioh@89.128.97.235) joined #osdev
10:46:25 --- quit: aalm (Ping timeout: 244 seconds)
10:54:27 --- join: newnix (~newnix@exile.digital) joined #osdev
10:56:38 --- quit: S_Gautam (Quit: Connection closed for inactivity)
11:00:04 --- quit: Burgundy (Remote host closed the connection)
11:02:43 --- quit: silas (Ping timeout: 240 seconds)
11:05:18 --- quit: newnix (Quit: WeeChat 2.1)
11:07:05 --- join: nwm (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
11:12:12 --- join: MarcinWieczorek (~MarcinWie@2a00:f41:1cef:64fd:dcf3:94c4:b1c8:7e32) joined #osdev
11:14:19 --- quit: Kimundi__ (Ping timeout: 244 seconds)
11:16:40 --- join: X-Scale (~ARM@83.223.242.141) joined #osdev
11:17:10 --- quit: SopaXorzTaker (Remote host closed the connection)
11:17:36 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
11:20:44 --- quit: SopaXorzTaker (Read error: Connection reset by peer)
11:22:10 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
11:24:56 --- join: zeus1 (~zeus@197.239.32.38) joined #osdev
11:31:51 --- quit: MarchHare (Ping timeout: 248 seconds)
11:32:29 --- join: newnix (~newnix@exile.digital) joined #osdev
11:39:38 --- quit: grzesiek (Quit: Ex-Chat)
11:43:03 --- quit: vmlinuz (Ping timeout: 248 seconds)
11:45:30 --- quit: debug (Quit: "planned" power outage)
11:46:31 --- join: Burgundy (~yomon@86.121.70.166) joined #osdev
11:49:06 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-znenhmaesuvurvkv) joined #osdev
11:49:18 --- join: Kimundi__ (~Kimundi@i577A952E.versanet.de) joined #osdev
11:49:59 --- quit: nur (Quit: Leaving)
11:57:24 --- quit: thithib (Quit: leaving)
11:57:48 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
11:58:44 --- join: thithib (~thithib@219.ip-193-70-1.eu) joined #osdev
11:59:00 --- quit: MarcinWieczorek (Read error: Connection reset by peer)
12:01:30 --- join: MarcinWieczorek (~MarcinWie@public-gprs366302.centertel.pl) joined #osdev
12:02:33 --- join: nur (~hussein@175.145.129.119) joined #osdev
12:06:23 --- quit: SopaXorzTaker (Quit: Leaving)
12:06:40 <glauxosdever> I had this curious thought yesterday. What if I have a superior OS/compiler/language design if users can't use the programs they like?
12:07:49 <heat> it's useless
12:08:23 <glauxosdever> That's why I'm reverting to UNIX-like and I'll try to make it better from there as a base
12:08:53 <heat> UNIX-like is better but not enough
12:08:57 <sortie> Curious thought?
12:09:02 <glauxosdever> Yeah
12:09:04 <sortie> This is like osdev 101.
12:09:05 <heat> NT-like is the best option for usability
12:09:12 <sortie> I'm pretty sure it's mentioned in beginner mistakes.
12:09:39 <glauxosdever> Is it?
12:09:41 <sortie> glauxosdever: Port the program. Have a compatibility layer. Use virtual machines. Write a better program.
12:10:03 <heat> or
12:10:28 <heat> Work like linux/NT/whatever and don't bother porting
12:11:01 <heat> and accept that you can't port everything
12:11:08 <sortie> glauxosdever: But now you're unclear about your goals
12:11:13 <glauxosdever> If I were to work like Linux, I wouldn't be here
12:11:17 <sortie> Is your goal to make something novel and good, or have lots of users?
12:11:18 <heat> and if you want your OS to grow a lot(unlikely) you won't port everything
12:11:20 <glauxosdever> Linux is too complex
12:11:27 <sortie> glauxosdever: You're too ignorant.
12:11:32 <glauxosdever> I know
12:11:33 <heat> Linux is as complex as it needs to be
12:11:41 <sortie> heat: Now, now.
12:11:42 <heat> to ensure lots of features, speed and portability
12:11:48 <heat> err
12:11:57 <heat> not portability, backwards compatibility
12:12:05 <sortie> heat: I'm sure there's plenty of silliness in Linux
12:12:11 <heat> exactly
12:12:17 <sortie> But there's way more intentional stuff in Linux that glauxosdever knows about
12:12:20 <sortie> *than
12:12:22 <heat> that's just kept for backwards compat
12:12:38 <heat> they *don't* break userspace
12:12:53 <pikhq> Userspace just likes to break itself on Linux.
12:13:45 --- join: pat_ (a6303193@gateway/web/freenode/ip.166.48.49.147) joined #osdev
12:13:54 --- nick: pat_ -> patv
12:16:08 <heat> jokes aside, linux is very stable
12:16:15 <glauxosdever> Indeed
12:16:21 <heat> mostly because the old things everything relies on are stably shit
12:16:29 <heat> shit APIs, but they work
12:17:04 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
12:17:04 <heat> the newer linux APIs are mostly good though
12:17:26 --- quit: sysfault (Max SendQ exceeded)
12:17:56 --- join: aalm (~aalm@37-219-73-181.nat.bb.dnainternet.fi) joined #osdev
12:18:02 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
12:18:54 <heat> I suggest you learn from both windows, linux, and the interwebz
12:19:10 <heat> they're all really good
12:19:44 --- quit: light2yellow (Quit: light2yellow)
12:20:42 --- join: bm371613 (~bartek@2a02:a317:603f:9800:3d21:d4ea:8e13:962a) joined #osdev
12:20:51 --- quit: manzerbredes (Ping timeout: 260 seconds)
12:20:59 <glauxosdever> And then derive a design that will be better but no one will want to use because they want their usual programs. Sure, I'd actually prefer going the custom route.
12:23:06 <heat> no
12:23:08 <heat> that's not what I meant
12:25:31 <glauxosdever> What did you mean?
12:26:38 <heat> learn from linux/unix and/or windows, use their APIs in non-trivial things
12:26:52 <heat> s/use/learn from and improve/
12:27:45 <glauxosdever> So better designs but with compatibility? THat's what I'm aiming for now
12:27:49 <klys> monolithic is "too complex" I see what you mean
12:27:56 <glauxosdever> klys gets the point
12:28:35 <heat> not entirely
12:28:41 <heat> 1) monolithic is not too complex
12:28:43 <klys> linking everything with everything else?
12:29:17 <klys> pile of drivers
12:29:43 <klys> only one software interrupt
12:30:28 <glauxosdever> Monolithic is conceptually simpler (no need for additional kernel-driver interfaces), but then you have to maintain that and sometimes the drivers have security holes, etc
12:30:30 <heat> 2) I meant that you should use either the unix/nt api in the basic API every program uses, and then use your own in the more kernel-specific APIs
12:30:43 <klys> I think of having sofware interrupts to multiplex and demultiplex modular kernel functionalith.
12:30:49 <klys> y*
12:31:00 <heat> it's very easy to screw up a microkernel
12:31:10 <heat> it's not that easy to screw up a monolithic one
12:31:42 <klys> I am not pro-microkernel, as the abstractions are entirely agnostic there.
12:32:06 <glauxosdever> heat: Design-wise? Security-wise?
12:32:20 <heat> glauxosdever: both
12:32:25 <heat> + performance wise
12:32:48 <heat> you need to be good and know what you're doing
12:33:47 <glauxosdever> I agree. But how is it bad for security?
12:34:18 <heat> I didn't say it's bad
12:34:30 <heat> I said that it's easy to screw up
12:34:35 <glauxosdever> Right
12:34:47 <heat> for security maybe not so much
12:35:26 <klys> the part where kernel-driver interfaces are nice is when you replace the driver with something necessary or different
12:36:00 <glauxosdever> Or you add an inofficial driver
12:36:28 <heat> kernel-driver interfaces exist in monolithic kernels...
12:37:39 <klys> and who has a unix/nt api?
12:37:54 <heat> that / meant or
12:38:04 <klys> ok
12:38:16 <heat> you can do both but it's not a good idea
12:38:29 <heat> because 1) Why?; 2) Good luck
12:42:05 --- join: MrOnlineCoder (~MrOnlineC@195.225.231.218) joined #osdev
12:46:47 <klys> mischief, would you recommend turning off -Werror in /root/src/sys/efivim/edk2/BaseTools/Source/C/Common ?
12:48:04 <klys> also, I tried gnu-efi 3.0.8, 3.0.6, and 3.0.4-with debian patches.
12:55:27 --- quit: flacks (Ping timeout: 240 seconds)
12:57:47 --- join: flacks (flacks@184.91.69.131) joined #osdev
12:59:59 --- join: tacco| (~tacco@i59F52B2A.versanet.de) joined #osdev
13:03:20 --- quit: xenos1984 (Ping timeout: 244 seconds)
13:04:05 --- quit: sysfault (Remote host closed the connection)
13:04:09 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
13:04:34 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
13:06:57 --- quit: MarcinWieczorek (Quit: WeeChat 2.1)
13:09:32 --- quit: X-Scale (Ping timeout: 244 seconds)
13:11:04 --- quit: Tobba (Read error: Connection reset by peer)
13:12:02 --- join: X-Scale (~ARM@83.223.227.30) joined #osdev
13:12:24 --- quit: spare (Quit: leaving)
13:12:31 --- quit: drakonis (Remote host closed the connection)
13:16:27 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
13:16:40 --- join: vmlinuz (~vmlinuz@32.104.18.202) joined #osdev
13:16:40 --- quit: vmlinuz (Changing host)
13:16:40 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
13:18:35 --- quit: sysfault (Remote host closed the connection)
13:19:06 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
13:20:56 --- quit: Belxjander (Ping timeout: 260 seconds)
13:22:02 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
13:22:27 --- quit: zeus1 (Ping timeout: 240 seconds)
13:23:23 --- join: zeitue (~zeitue@137.119.92.151) joined #osdev
13:31:49 --- quit: MindlessDrone (Ping timeout: 240 seconds)
13:39:57 --- quit: gattuso (Ping timeout: 240 seconds)
13:40:44 --- part: nemo235 left #osdev
13:42:15 --- quit: vmlinuz (Quit: Leaving)
13:43:56 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
13:51:38 --- join: JonRob (~jon@194.168.25.101) joined #osdev
13:52:38 --- quit: m3nt4L (Remote host closed the connection)
13:58:35 --- join: MindlessDrone (~MindlessD@unaffiliated/mindlessdrone) joined #osdev
14:03:23 --- quit: MindlessDrone (Ping timeout: 268 seconds)
14:05:19 --- quit: amj (Quit: WeeChat 2.1)
14:05:33 --- join: amj (amj@linuxfromscratch/translator/amj) joined #osdev
14:05:58 --- quit: baschdel (Ping timeout: 256 seconds)
14:06:49 --- join: zeus1 (~zeus@197.239.32.38) joined #osdev
14:08:35 --- quit: bm371613 (Quit: Konversation terminated!)
14:09:46 --- quit: Asu (Remote host closed the connection)
14:10:10 --- join: Asu (~sdelang@95.82.136.77.rev.sfr.net) joined #osdev
14:11:21 --- join: hmmmmm (~sdfgsf@pool-72-79-168-239.sctnpa.east.verizon.net) joined #osdev
14:14:36 --- quit: hmmmm (Ping timeout: 260 seconds)
14:16:35 --- quit: sysfault (Remote host closed the connection)
14:17:04 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
14:17:44 --- quit: sysfault (Max SendQ exceeded)
14:18:14 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
14:22:41 --- join: gattuso (~gattuso@pompel.me) joined #osdev
14:25:39 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
14:25:49 --- quit: glauxosdever (Quit: leaving)
14:35:19 --- quit: zeus1 (Ping timeout: 240 seconds)
14:41:19 --- quit: jakogut (Quit: jakogut)
14:41:44 --- join: jakogut (~jakogut_@162.251.69.147) joined #osdev
14:42:18 --- quit: asymptotically (Remote host closed the connection)
14:44:15 <klys> latest error is on: /root/src/sys/efivim/edk2/StdLib/LibC/String/Concatenation.c
14:44:54 --- quit: isaacwoods (Quit: isaacwoods)
14:45:50 --- quit: jakogut (Client Quit)
14:46:15 --- join: jakogut (~jakogut_@162.251.69.147) joined #osdev
14:54:05 --- quit: sysfault (Remote host closed the connection)
14:54:45 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
14:55:01 --- quit: sysfault (Max SendQ exceeded)
14:55:36 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
14:55:52 --- quit: MrOnlineCoder (Read error: Connection reset by peer)
15:08:19 --- quit: JonRob (Ping timeout: 240 seconds)
15:08:53 --- quit: nwm (Ping timeout: 244 seconds)
15:14:27 --- quit: Kimundi__ (Ping timeout: 240 seconds)
15:16:36 --- quit: sysfault (Remote host closed the connection)
15:17:07 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
15:22:16 --- join: Tobba (~Tobba@h-25-157.A159.priv.bahnhof.se) joined #osdev
15:24:27 <graphitemaster> attention osdevers, do you like compiling gcc for your OS
15:24:33 <graphitemaster> if so, you may want to vote against this https://www.phoronix.com/scan.php?page=news_item&px=Python-GCC-Awk-Proposal
15:24:35 <bslsk05> ​www.phoronix.com: A Proposal To Allow Python Scripting Within The GCC Compiler, Replacing AWK - Phoronix
15:24:42 <graphitemaster> since it'll make python a requirement for building
15:24:49 <graphitemaster> which makes compilign gcc on your os really painful
15:25:22 <drakonis> https://gcc.gnu.org/ml/gcc/2018-07/msg00233.html
15:25:24 <bslsk05> ​gcc.gnu.org: Martin Liška - [RFC] Adding Python as a possible language and it's usage
15:25:25 <heat> is it really?
15:25:27 <drakonis> its a proposal
15:25:35 <heat> python's just python
15:25:36 <drakonis> it has to be accepted first
15:26:42 <graphitemaster> hence why I said vote against it
15:26:46 <graphitemaster> the discussion is open
15:26:50 <graphitemaster> just giving a heads up
15:26:55 <drakonis> what's the score right now
15:26:57 <graphitemaster> if there's enough push back it won't happen
15:27:09 <heat> but why push back
15:27:36 <drakonis> there's pretty much no traction on it right now
15:27:41 <drakonis> its also an RFC
15:28:26 <drakonis> there's already some push back on it
15:28:31 --- join: hmmmmmm (~sdfgsf@pool-72-79-166-155.sctnpa.east.verizon.net) joined #osdev
15:30:19 --- quit: palk ()
15:31:55 --- quit: hmmmmm (Ping timeout: 264 seconds)
15:32:57 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
15:33:16 --- join: absolute123 (~vodka@nthrsm081170.hrsm.nt.ngn.ppp.infoweb.ne.jp) joined #osdev
15:35:45 <rain1> why thE FUCK
15:35:59 <absolute123> i smoked some weed today, you're off the hook, but the miaow, this thing ins reg_256blabla it has the flop for write pool, it is like persisent pool now it comes across that three read operands are the multiplexors of this, the flop is with enable signal, either this or that, and the multiplexor fetches it's output
15:36:04 <rain1> make a python script that invokes gcc
15:36:14 <rain1> not gcc has somehow got python built into it internally
15:36:22 <absolute123> and basically it markes the last value of the clock
15:36:24 <rain1> how is everybody so terrible at softare design
15:36:57 <absolute123> whicn in that case means whatever the writeback reg was it can fetch it
15:38:39 <absolute123> i never know how to explain this all, it's complex set of operations
15:38:48 <heat> k
15:38:52 <heat> rain1: idk
15:39:46 --- quit: sortie (Quit: Leaving)
15:40:11 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
15:40:12 --- quit: Asu (Remote host closed the connection)
15:40:22 <heat> rain1: I don't think they want to put python inside gdb
15:40:25 <heat> *gcc
15:40:31 --- quit: sortie (Remote host closed the connection)
15:40:37 <heat> they just want to invoke the scripts using a python interpreter
15:45:03 --- quit: hmmmmmm (Read error: Connection reset by peer)
15:45:16 --- join: hmmmmmm (~sdfgsf@pool-72-79-168-72.sctnpa.east.verizon.net) joined #osdev
15:46:22 --- join: MarchHare (~Starwulf@mo-184-5-202-5.dhcp.embarqhsd.net) joined #osdev
15:47:23 --- join: hmmmmm (~sdfgsf@pool-72-79-167-56.sctnpa.east.verizon.net) joined #osdev
15:48:10 --- quit: heat (Remote host closed the connection)
15:50:19 --- quit: hmmmmmm (Ping timeout: 240 seconds)
15:50:43 --- join: palk (~palk@unaffiliated/palk) joined #osdev
15:51:01 --- join: nwm (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
15:52:37 --- join: Jari-- (~vai@mobile-access-6df088-169.dhcp.inet.fi) joined #osdev
15:52:46 <Jari--> still looking for a working copy of ld
15:52:52 <Jari--> the runtime linker of Linux
15:52:56 <Jari--> where can I find a source code?
15:53:14 <Jari--> or do you have a home made compact one?
15:53:15 <palk> https://sourceware.org/binutils/
15:53:16 <bslsk05> ​sourceware.org: GNU Binutils
15:53:26 <Jari--> palk: is that portable :( ?
15:53:27 <palk> ld is part of the binutils package
15:54:16 <palk> that obviously depends
15:54:34 <Jari--> I mean is it restricted to Linux only?
15:54:39 <Jari--> known anyone used it?
15:54:46 --- join: graphene (~graphene@46.101.134.251) joined #osdev
15:54:55 <Jari--> guys, this is a top seller
15:55:00 <Jari--> if you have a runtime linker
15:55:07 <palk> it is not Linux only
15:55:18 <Jari--> really
15:56:51 <palk> when you say runtime linker, what specifically are you trying to accomplish?
15:56:59 --- nick: puckipedia -> puck
16:01:17 <Jari--> http://menuetos.net/0983.png
16:01:17 <bslsk05> ​menuetos.net: 406 - Client browser does not accept the MIME type of the requested page.
16:04:20 --- quit: Lucretia (Quit: Konversation terminated!)
16:11:48 --- join: Lucretia (~Luke@pdpc/supporter/active/lucretia) joined #osdev
16:14:04 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
16:14:23 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
16:19:51 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
16:20:12 --- quit: Shikadi (Read error: Connection reset by peer)
16:20:21 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
16:20:36 --- quit: tacco| (Ping timeout: 260 seconds)
16:21:05 <absolute123> all the writebacks go over reset value, so hence the underlying value alternates between 0 and X
16:21:49 <absolute123> it is either private or persistent pool that is written
16:22:20 <absolute123> in both of the cases the value gets registered as a last value
16:24:29 --- join: tacco| (~tacco@i59F60F18.versanet.de) joined #osdev
16:25:26 <klys> absolute123, why do you use so many different buzzwords in one sentence, and fail to explain what you mean by using the same buzzwords in your following sentence(s)?
16:26:56 <Jari--> malloc actually calls some system call to extend the memory region of the runtime application?
16:27:03 <Jari--> if I recall right
16:27:25 <klys> malloc uses page faults on the heap, iirc. there is sometimes a system call.
16:27:43 <Jari--> yes
16:28:03 <clever> for linux, malloc either uses brk() to change the end of the heap, or mmap() to allocate a new chunk of memory
16:28:10 <doug16k> Jari--, the idea of malloc is for it to subdivide larger allocations from the system into smaller blocks. usually the system provides allocation of relatively large chunks, like pages which are multiple KB
16:28:35 --- quit: sysfault (Remote host closed the connection)
16:29:03 <doug16k> it is relatively expensive to go all the way into the kernel for every allocation too. malloc gets decent sized chunks from the underlying OS, then it can rapidly make smaller allocations without going all the way into the kernel every time
16:29:04 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
16:29:08 <Jari--> Sections:
16:29:09 <Jari--> Idx Name Size VMA LMA File off Algn
16:29:09 <Jari--> 0 .text 00000333 00000000 00000000 00000040 2**4
16:29:09 <Jari--> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
16:29:09 <Jari--> 1 .data 00000050 00000000 00000000 00000380 2**5
16:29:11 <Jari--> CONTENTS, ALLOC, LOAD, DATA
16:29:19 <Jari--> https://wiki.osdev.org/ELF
16:29:21 <bslsk05> ​wiki.osdev.org: ELF - OSDev Wiki
16:29:25 <Jari--> it is actually sensible format
16:29:32 <Jari--> I will overcome this obstacle it seems
16:30:38 <doug16k> typically malloc will handle it up to some threshold, and beyond that it makes a system call to do large allocations
16:30:59 <doug16k> handle sizes*
16:32:05 --- quit: sysfault (Remote host closed the connection)
16:32:39 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
16:33:06 --- quit: tacco| (Ping timeout: 244 seconds)
16:33:15 <palk> any of you ever had your assembler mark your functions as data instead of text?
16:33:43 <Jari--> I am used to flat binaries
16:33:48 <Jari--> on Commodore 64
16:33:58 <doug16k> if that happens you forgot to put a .section directive in the code
16:34:36 <doug16k> or the shorthand equivalent, .text, .data, .bss etc
16:34:41 <palk> doug16k: no, it's there, but it's a custom section (.text.phys), so I'm thinking that has something to do with it
16:35:05 <doug16k> the section directive takes a 2nd argument. you might want .section .text, "ax"
16:35:27 <palk> what's wrong with .text.phys?
16:35:42 <doug16k> oh I meant .section .text.phys, "ax"
16:36:11 <doug16k> but you can eliminate the need for that by explicitly placing the .text.phys input section in your linker script's .text output section
16:36:42 <doug16k> .text : { ... *(.text.phys) ... }
16:38:30 <palk> it's explicitly in the linker script, but purposefully separate from the .text group
16:38:57 <doug16k> so your problem is the things like " CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE" are not what you wanted?
16:39:35 --- quit: sysfault (Remote host closed the connection)
16:40:10 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
16:40:22 <doug16k> you can use an explicit PHDRS directive in the linker script to take control of those (for example, making one called "code"), and specify specific PHDR types of output sections with :code
16:40:58 <doug16k> if not forced like that, the linker will try to infer it from the input section flags
16:41:09 <doug16k> which come from that 2nd parameter I mentioned in .section directives
16:41:35 --- quit: sysfault (Remote host closed the connection)
16:41:57 <doug16k> you can force certain sections to be readable/writable/executable that way too
16:42:07 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
16:42:25 <doug16k> "ax" means ALLOC, EXECUTABLE
16:42:34 <doug16k> IIRC
16:42:57 --- join: tacco| (~tacco@i59F4F2CA.versanet.de) joined #osdev
16:43:13 --- join: elevated (~elevated@gateway/tor-sasl/elevated) joined #osdev
16:45:07 <palk> even after adding "ax", `nm` still reports them as 'd'.
16:45:30 <doug16k> nm on the object file?
16:45:34 <palk> ya
16:45:48 <ybyourmom> nm wants the D
16:47:45 <palk> adding `.type foo, @function` doesn't seem to fix it either
16:48:14 <Jari--> how do you actually parse elf .text field?
16:48:22 <doug16k> is it on github or something so I can look? I just nm'd some of my stuff and it has the expected types
16:52:36 <doug16k> palk, you put the , "ax" on the first mention of that section in the source file?
16:53:01 <doug16k> not that that matters, just noticed I did
16:53:17 <palk> oh bollocks. The .section, .globl, and .type were correct but the actual label declaration was in a (masked out) preprocessor block, so I guess it was defaulting to data
16:53:29 <palk> sorry to bother
16:55:16 <doug16k> TIL that initializer_list doesn't work at all unless it is exactly std::initializer_list and it is totally special cased D:
16:56:20 <doug16k> I mean the implementation MUST be in std namespace, or the compiler won't do the magic
16:56:55 <klange> "disappointed, but unsurprised"
16:56:55 <palk> that sounds rather horrible, but then again we're talking about C++...
16:57:11 <Ameisen> sigh
16:57:18 <Ameisen> building binutils... ld.gold apperasw to have built right
16:57:22 <Ameisen> ld.bfd appears to be a broken binary
16:57:26 <Ameisen> very small, doesn't run
16:57:53 <klange> odd
16:57:59 <Ameisen> quite
16:58:08 <klange> what's `file` think it is?
16:59:01 <Ameisen> it thinks it's a binary
16:59:04 <Ameisen> it's just... like an empty binary
16:59:08 <Ameisen> I'm wondering if LTO broke it.
16:59:09 <klange> Interesting.
16:59:14 <Ameisen> maybe they had some UB near the beginning that never got picked up
16:59:16 <Ameisen> with LTO, it did.
16:59:22 <doug16k> Ameisen, are you writing a script that compiles it? if so, are you redirecting the output?
16:59:29 <Ameisen> I can't use ld.gold for this particular project I'm afraid
16:59:34 <Ameisen> might be able to use ld.lld though
16:59:49 <Ameisen> doug16k - the script that kicks off the compile passes the output through and also writes it to a log
16:59:49 --- quit: Jari-- (Ping timeout: 240 seconds)
17:00:09 <Ameisen> I didn't notice anything particularly concerning though there were some UB warnings
17:00:15 <Ameisen> which I want to look at
17:00:33 <doug16k> did you say dostuff... 2>&1 > logfile or did you say dostuff > logfile 2>&1
17:00:49 <Ameisen> script -c "./build" build.log
17:00:53 <doug16k> 1st one won't redirect stderr to the file
17:01:02 <Ameisen> script should redirect _all_ output
17:01:15 <Ameisen> also it maintains colors and formatting :)
17:01:15 <doug16k> that bit me for a while. once I forehead slapped that bug, suddenly my log was useful and led me to issues
17:01:29 --- quit: xenos1984 (Quit: Leaving.)
17:04:52 <doug16k> `something 2>&1 > log` means, take stderr and redirect it to wherever stdout is right now (which is the terminal), then > log means redirect only stdout to the file. no stderr goes to the file
17:05:26 <doug16k> `something > log 2>&1` means, redirect stdout to the file, then redirect stderr to wherever stdout is going, which is also the file
17:07:33 <doug16k> I had the 1st one in my compiler build script and the log was damn near useless. changed it to 2nd one and suddenly the log told me exactly what was wrong
17:14:05 --- quit: sysfault (Remote host closed the connection)
17:14:15 --- quit: epony (Quit: upgrades)
17:21:09 --- quit: graphene (Remote host closed the connection)
17:21:58 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
17:22:35 <geist> doug16k: yeah the fact that you have to do them backwards like that is always confusing
17:23:15 <geist> i always remember it as being exactly backwards from what you'd expect, and that seems to generally get me through life
17:23:27 <doug16k> :D
17:23:32 <klys> can you do something like: cat file | app 2&>1 | grep Error; ? I mean, I know you can't really though.
17:23:53 <doug16k> pipes are funny, they happen earlier than left to right
17:24:32 <doug16k> I haven't nailed down the exact semantics of pipes yet in my bash adventures
17:24:49 <doug16k> but they are not what you expect if you know the rule I mentioned earlier
17:25:03 <klys> there isn't a &| afaik.
17:26:19 <klys> although you can do app &> errlog & and then tail -f errlog | grep Error
17:27:10 <palk> klys: if memory serves, that isn't posix standard
17:27:20 <palk> but is supported by (at least) bash
17:31:11 --- quit: JusticeEX (Ping timeout: 260 seconds)
17:31:24 <Ameisen> Doing a rebuild with a few more configure options to see if it helps, since I was missing a few that I should have had
17:32:23 --- quit: chao-tic (Ping timeout: 248 seconds)
17:32:40 <Ameisen> "checking for memmove... no"
17:32:41 <Ameisen> err
17:32:50 <doug16k> lol
17:33:01 <Ameisen> wat
17:33:08 <doug16k> I'm always amused by what it checks for. as if memmove isn't declared
17:33:18 <Ameisen> but... somehow it apparently isn't
17:33:43 --- quit: [Brain] (Ping timeout: 240 seconds)
17:33:57 <doug16k> more likely the test compile simply broke
17:34:13 <doug16k> for a more catastrophic reason, like crt0 problem or something
17:35:36 --- join: sixand (~Thunderbi@119.123.34.73) joined #osdev
17:36:06 <Ameisen> yeah
17:36:12 <Ameisen> annoying when it's unclear why things fail.
17:37:08 <doug16k> I've generally had to dig down to the appropriate directory in gcc's recursive make and look at that specific config.log
17:38:31 <doug16k> gcc/binutils/whatever
17:38:31 --- quit: absolute123 (Ping timeout: 264 seconds)
17:38:39 <Ameisen> warning: conflicting types for built-in function 'memmove' [-Wbuiltin-declaration-mismatch]
17:42:10 --- quit: hunterlabs (Quit: EliteBNC 1.6.5 - http://elitebnc.org)
17:42:50 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
17:45:25 --- quit: rubenwardy (Quit: Bye!)
17:45:45 --- join: rubenwardy (~rw@minetest/dev/rubenwardy) joined #osdev
17:47:29 --- quit: hiei (Quit: ...)
17:48:50 --- join: hunterlabs (Elite20801@gateway/shell/elitebnc/x-ztuqkcfbrlophynn) joined #osdev
17:51:07 --- join: sixand1 (~Thunderbi@119.123.34.73) joined #osdev
17:51:49 --- quit: sixand (Ping timeout: 240 seconds)
17:51:50 --- nick: sixand1 -> sixand
17:52:21 --- quit: bitch (Quit: The bitch has left the building.)
17:53:11 <doug16k> lookahead/lookbehind assertions make life worth living :D
17:53:57 <doug16k> -> (?<!std::)vector(?=<)
17:54:00 --- join: hiei (jinzo@gateway/shell/elitebnc/x-zpajpbpxwzusrhhb) joined #osdev
17:55:44 --- join: graphene (~graphene@46.101.134.251) joined #osdev
17:56:02 <doug16k> 242 occurrences replaced = win
17:56:05 <palk> negative look-behind for "std::", right?
17:56:15 <doug16k> right. and must be followed by <
17:56:20 <doug16k> and not match the <
17:57:01 <palk> I for one find the look-ahead / look-behind very reasonable, especially if you are used to (?: ... ) grouping
17:58:47 --- quit: graphene (Remote host closed the connection)
17:59:47 <palk> geist: you around?
18:00:21 --- join: graphene (~graphene@46.101.134.251) joined #osdev
18:01:02 * klys still needs a working uefix64 build tree.
18:02:34 --- join: bitch (hctib@gateway/shell/elitebnc/x-hwazxbyexdgtwdrv) joined #osdev
18:03:18 <geist> palk: sup
18:07:28 <klys> geist what's new
18:07:50 <palk> geist: https://pastebin.com/iCXDSLjB
18:07:51 <bslsk05> ​pastebin.com: VIA Nano X2 CPUID - Pastebin.com
18:08:00 <klys> o ok
18:12:34 --- join: heat (~heat@sortix/contributor/heat) joined #osdev
18:12:38 <palk> I don't recall who else was looking for that, but that's `cpuid -1` on a via chip
18:12:55 <klys> kpalk, is intel atom compatible with pc bios?
18:13:04 <klys> palk*
18:13:13 <palk> your question makes no sense
18:13:23 <klys> well I though it wasn't
18:13:52 <palk> atom conforms to the x86 ISA if that is what you are asking
18:14:01 <klys> o thanks palk
18:14:05 <heat> every x86 cpu is compatible with pc bios until 2019 I think
18:14:06 <palk> there are atom derivatives that do not, for instance the quark
18:14:22 <palk> but that was not the question
18:14:32 <heat> intel will drop support for the BIOS in 2019 or 2020, I forgot
18:15:06 <heat> but I assume that's only because of the chipset itself
18:15:18 <heat> since the CPU itself has nothing to do with the firmware it's running
18:15:27 <klys> yeah my question is more about the cheap intel atom laptops for sale via ebay and buya.com among other places.
18:15:28 <CompanionCube> wait what
18:15:29 <CompanionCube> really?
18:15:30 <CompanionCube> huh.
18:16:24 <heat> CompanionCube: https://www.guru3d.com/news-story/intel-halts-certain-uefi-bios-class-level-2-compatibility-modes-in-2020.html
18:16:25 <bslsk05> ​www.guru3d.com: Intel Halts Certain UEFI BIOS Class Level 2 Compatibility Modes In 2020
18:16:28 <klys> so by that time someone wil need a uefi implementation of csm which is at least compatible with ovmf.
18:16:57 <heat> no
18:17:02 <heat> CSM is also off-limits
18:17:08 <CompanionCube> O.o
18:17:22 <klys> everyone knows what it does
18:17:33 <klys> those specs have been around for ages
18:17:47 <heat> only UEFI class 3 machines will work
18:17:48 <klys> or so i hear
18:18:27 <heat> klys: I dunno what you mean with csm for ovmf, but tianocore has it for ages
18:18:39 <CompanionCube> ditching the CSM entirely seems a bit much....
18:18:44 <heat> so it wouldn't surprise me that it's already included in the ovmf tree
18:18:51 <klys> csm for ovmf according to my research this week is not yet implemented.
18:18:53 <heat> CompanionCube: But is it?
18:19:10 <CompanionCube> imo yes
18:19:21 <heat> klys: It's also entirely useless since you control how you're booting with virtual machines
18:19:48 <klys> useless?
18:19:57 <heat> BIOS are legacy trash, don't work well with modern PCs, and are a security problem
18:19:57 <CompanionCube> it'd likely be smoother to drop class 0/1 first, then 2 some time after that.
18:20:26 <heat> the vast majority of consumers already run full class 3 with secure boot
18:20:31 <klys> you can cuss and refer to trash all you want. I will continue to want what I feel I need.
18:20:55 <CompanionCube> the BIOS is trash though
18:21:01 <klys> you too.
18:21:14 <CompanionCube> it's a pile of hacks that have accreted over decades...and UEFI, for it's faults, is superior.
18:21:50 <heat> portal 2 boi 1 - 0 BIOS boi
18:22:00 <klys> I'll put you on notice. Let me know when you want me to stop rollin my eyes at you.
18:22:52 <palk> heat: that is patently false; do you realize how large of a group "the majority of consumers" is?
18:22:57 <klys> heat, UEFI bare bones doesn't work. how does that make you feel?
18:23:15 <heat> klys: Makes me feel like osdevers don't care about uefi
18:23:25 <klys> mm.
18:23:45 <heat> because I have a fully functional uefi bootloader that works both in OVMF and real hardware
18:24:45 <heat> palk: I meant the target group of consumers who just use a normal laptop and/or desktop pc, not power users
18:24:53 <palk> it might very well be that "the majority of computers sold in the past month" <<might>> "run full class 3 with secure boot," but that's about all I will concede.
18:24:56 <heat> but maybe the vast part is a bit too much
18:25:28 <palk> you misunderstood me; power users I consider insignificant
18:26:02 <palk> I'm thinking more of the Chinese and Indian markets (that together account for roughly half of the entire world population).
18:26:57 <palk> I can guarantee you that they're not selling state-of-the-art machines with UEFI on them
18:27:28 <heat> I'm not being able to find some numbers, but I can tell you that every machine sold with windows 8/8.1/10 has UEFI with secure boot
18:27:35 <CompanionCube> indeed
18:27:38 <CompanionCube> but are they class 3
18:27:39 <heat> that's a lot of machines
18:27:43 <heat> yes
18:27:45 <heat> secure boot
18:27:54 <heat> and class 3
18:28:19 <CompanionCube> I don't doubt the first one, but the second.
18:28:24 <heat> pretty much the required firmware features by microsoft iirc
18:28:25 <palk> I'm telling you that windows 8+ is likely not running on the majority of the computers being sold right now
18:28:43 <CompanionCube> I'd imagine a good chunk are class 2
18:28:45 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
18:29:08 <heat> http://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide
18:29:10 <bslsk05> ​gs.statcounter.com: Desktop Windows Version Market Share Worldwide | StatCounter Global Stats
18:29:13 <heat> it is
18:29:37 <doug16k> heat, the seabios build has configure options to build it as an EFI CSM
18:29:44 * CompanionCube points to the 40% running win7
18:30:14 * heat points to the 46.75 + 7.7 + 2.23
18:30:15 <doug16k> haven't tried it though, but presumably you load it as an EFI module
18:30:46 <heat> oh, and don't forget mac
18:30:49 <palk> lol, you think a majority of computer sales are first party (and therefore tracked by microsoft)?
18:31:19 <heat> pretty sure these are not sales figures
18:32:11 <palk> were we not talking about sales?
18:32:17 <heat> no
18:32:27 <heat> we were talking about market shares
18:32:37 <heat> at least that was what I was talking about
18:32:58 --- quit: chao-tic (Ping timeout: 244 seconds)
18:37:20 <palk> the data I'm presented with regularly looks more like this: https://filestore.community.support.microsoft.com/api/images/9f99901b-79ec-46ad-8fc0-059d06f766c7
18:37:22 --- quit: patv (Ping timeout: 252 seconds)
18:37:25 <klys> struggling to find a reference to EFI in the Onyx tree
18:37:41 <palk> that's an old picture, but it was the first one that came up in a google search
18:38:21 <heat> klys: It's not there
18:38:27 <klys> orly
18:38:34 <heat> yeah
18:38:38 <klys> k
18:38:43 <heat> i didn't merge it to the main OS yet
18:38:46 <heat> here it is
18:38:46 <heat> https://github.com/heatd/Carbon/tree/master
18:38:48 <bslsk05> ​github.com: GitHub - heatd/Carbon
18:39:08 <klys> thx bro
18:39:23 <heat> np
18:39:38 <heat> tell me if you need any help
18:43:08 <klys> heat, I'm looking for some build scripts, kernel.config?
18:43:49 <klys> I was invoking: make -f ../Makefile
18:43:55 <heat> for the uefi bootloader?
18:44:12 <klys> oh it's Carbon I figured had an overall makefile
18:44:58 <klys> like this: git clone git://github.com/heatd/Carbon.git
18:45:27 <heat> right, you would need an onyx cross compiler for it
18:45:44 <heat> you might be able to build it using a bare metal x86_64-elf
18:45:55 <klys> and that's clang sources?
18:46:08 <heat> what?
18:46:25 <heat> the efibootldr is compiled using clang, if that's what you mean
18:46:26 <klys> it's asking for clang in efibootldr/Makefile
18:46:42 <klys> yeah, does it need a clang cross?
18:46:46 <heat> no
18:46:49 <klys> k
18:47:12 <heat> I used clang so I wouldn't need a mingw64 cross compiler
18:47:55 <klys> will clang-6.0:i386 work?
18:47:57 <heat> (else I would have to use uefi_call_wrapper() which looks ugly)
18:48:05 <heat> you'll need x86_64
18:48:52 <heat> the bootloader was only tested with x86_64, and uefi implementations usually only load x86_64 apps
18:49:53 <doug16k> you can annotate the functions with __attribute__((__ms_abi__)) and structs with __attribute__((__ms_struct__)) and not have to go through a thunk, the compiler will use the appropriate calling convention and layout
18:50:17 <klys> yeah so does clang cross-compile without a rebuild of clang itself?
18:50:42 <doug16k> heat, I don't use clang for my EFI bootloader, I use my kernel cross compiler
18:50:49 <doug16k> er, I don't use mingw I mean
18:52:00 <heat> I've seen lots of weird uefi setups
18:52:04 <klys> doug16k, and that's gcc right
18:52:08 <doug16k> yes, gcc
18:52:40 <heat> klys: Can't tell you if it does, I'm not a clang expert
18:52:49 <klange> just made a bunch of my syscalls and libc functions set errno more correctly, and in the process broke Python because of a bug in my readdir...
18:52:57 <klange> that was fun to track down
18:53:01 <klys> I just remember last time I asked doug16k for a kernel, you didn't have a working release.
18:53:15 <klange> lots of git stashing and checkout -p'ing to find the culprit
18:53:20 <heat> I also don't have working releases
18:53:29 <klange> does anyone want a working release of my OS?
18:53:32 <heat> just broken releases and things that don't work for other people
18:53:56 <klys> klange, when I get past this uefi mash-up that might be cool
18:54:22 <klys> I noticed ponyos was mentioned in #gnu today
18:54:32 <heat> oh actually I could fixup the gcc port with the libgcc thingy and upload it
18:54:34 <klange> I occasionally update https://toaruos.org/nih.iso with latest builds.
18:56:09 <palk> what does "nih" stand for there?
18:56:30 <heat> not invented here, I believe
18:56:34 <doug16k> not invented here
18:56:48 <doug16k> he's implementing it all in that one, if I'm not mistaken
18:56:51 <palk> I didn't ask what it stood for usually
18:57:02 --- quit: sha-2 (Quit: EliteBNC 1.6.5 - http://elitebnc.org)
18:57:31 --- join: nicht (~nicht@177.205.29.113.dynamic.adsl.gvt.net.br) joined #osdev
18:58:11 <klange> palk: that's also what it stands for there
18:58:24 <palk> cheeky
18:58:29 <klange> toaruos-nih is my "fuck it, I'm bored of building an OS where half the userspace is third-party libraries"
18:58:54 <klange> "also some people said mean things to me because of it and I want to show them what's what"
18:59:17 <heat> dab on the mean people
18:59:27 <heat> absolute mad man
18:59:47 <palk> klange: I thought that's what your april fools anime release was for
18:59:58 <palk> (showing them "what's what.")
19:01:03 <heat> klange: offtopic, have you tried porting yutani to use opengl?
19:01:12 <klange> I have not.
19:01:38 <palk> klange: what did you call your "april fools" joke again?
19:01:50 <heat> I was thinking about writing my compositor using gl calls, I thought I would ask you since you know a lot about compositors
19:01:56 <palk> I know it has been a few years, but
19:02:06 <heat> palk: you mean ponyos?
19:02:08 <klange> The april fools joke is PonyOS, which is based on My Little Pony, which is an American cartoon series based on a Hasbro toy line, not an anime.
19:02:13 <palk> ah, yes, that's it
19:02:39 <palk> forgive me, I'm not particularly keen on animated pop culture
19:02:52 <klys> heat: carbon/bootprotocol.h ?
19:03:11 <heat> klys: it's the boot protocol used by the kernel
19:03:20 <klange> heat: Most of my experience is under X11, where the key thing with making OpenGL compositors was good ol' GL_EXT_texture_from_pixmap
19:03:25 <klys> the Onyx kernel?
19:03:58 <heat> klys: Oh, right, my .gitignore is broken right there, let me fix it real quick
19:04:24 <heat> there should be a kernel/include/carbon/bootprotocol.h
19:04:26 <klange> Ultimately, it's going to be the same process as writing a compositor with anything else: map your window textures to something you can use in your graphics engine, blit them with appropriately clipping so you only render what you need to, and... that's about it.
19:04:29 <klys> k
19:04:37 <klange> Compositors are, from a high level, very simple.
19:04:58 <klange> Much simpler than some older GUIs where you were managing client-driven rendering directly to a screen.
19:05:22 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
19:07:56 <heat> screw it i'll just gist the header
19:08:05 <klys> :)
19:08:15 <heat> my kernel executable is also named carbon
19:08:24 <heat> so it screws up the .gitignore
19:09:14 <heat> klys, https://gist.github.com/heatd/715279fb445c7ef2991ed604ab068718
19:09:15 <bslsk05> ​gist.github.com: bootprotocol.h · GitHub
19:09:22 <klys> k
19:10:33 <heat> klange: yeah, I was thinking of an good design where I could draw fancy effects and use any possibly available hardware acceleration/video memory without changing things too much
19:10:39 <heat> opengl came to mind
19:11:12 <klange> heat: you should look up the syntax for gitignore - if ignore /carbon to exclude your kernel binary it shouldn't chatch the carbon directory further down
19:12:35 <heat> ah yes, I figured it out
19:14:36 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
19:15:56 <klys> my installed headers are from gnu-efi 3.0.4-2 and it doesn't know an EFI_FILE_PROTOCOL
19:16:15 <klange> klys: EFI_FILE
19:16:17 <klys> perhaps I'll redirect to a newer gnu-efi
19:16:25 <klys> o
19:16:35 <heat> yes, thats a known issue
19:16:52 <heat> you'll need the newer gnu-efi's
19:16:55 --- quit: nicht (Ping timeout: 248 seconds)
19:17:36 <heat> I'm using gnu-efi 3.0.8-1
19:17:51 <geist> iirc we fairly quickly dumped it and just hand wrote the EFI interface
19:17:54 <klange> They changed/fixed that in a minor point release?
19:18:00 <geist> gnu-efi doesn't hav ea lot of value add in the long ruin
19:18:12 <klange> geist: It is like... 99% headers from Intel and HP anyway.
19:18:21 <klange> I guess they *do* have a library of convenience functions.
19:18:34 <geist> isn't the library GPL or whatnot thought?
19:19:28 --- quit: huaw (Quit: folded)
19:19:47 <klange> I think the whole lot of it is actually a BSD license.
19:19:50 <klange> Including the library.
19:20:31 <klange> Lots of leading comments with copyright years of 1998
19:20:34 <doug16k> I did the same, just declared all the vtbls and constants that I needed and didn't touch gnu-efi
19:22:45 <klange> I think I'll go through and do that at some point.
19:22:54 <klange> Maybe on a slow weekend.
19:22:58 <doug16k> and used my kernel crosscompiler, as I mentioned, and not mingw
19:23:42 <klange> I use my kernel crosscompiler for ia32 and the system gcc for x86_64 (yeah, just sort of... assuming it's x86_64)
19:25:11 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
19:25:48 --- join: huaw (xexexepi@gateway/shell/elitebnc/x-zcsndihqgqlelspk) joined #osdev
19:30:22 * klys now has heat's bootx64.efi
19:30:25 --- join: sha-2 (Sha2@gateway/shell/elitebnc/x-xbbrwgrvuaglsbwt) joined #osdev
19:30:46 <doug16k> there's a bug in the tianocore headers too. the EFI_PXE_BASE_CODE_MODE structure is wrong, the StationIp field begins one byte later than the declaration implies
19:31:08 <heat> if you want it to boot your kernel just change the name in the code
19:31:09 <doug16k> not to mention that there are several "const" missing on pointers that are obviously const
19:31:28 <heat> I could add actual grub-like features, maybe one day
19:32:40 <heat> doug16k: better than the absolute classic SetVirtualAddressMap() Tianocore bug
19:32:42 --- quit: tacco| ()
19:33:16 --- join: nicht (~nicht@2804:7f1:2080:1ba5:915a:cf45:6d36:37bf) joined #osdev
19:33:28 <klange> I separated out my bootloader config / menu stuff so it's easy to change to do other things: https://git.toaruos.org/klange/toaru-nih/src/master/boot/cstuff.c
19:33:30 <bslsk05> ​git.toaruos.org: klange/toaru-nih: A completely-from-scratch hobby operating system: bootloader, kernel, drivers, C library, and userspace. - ToaruOS Git
19:33:39 <klange> (works with the EFI loaders as well as the shoddy BIOS loader)
19:34:27 <doug16k> heat, what's the bug?
19:34:36 <klys> upon booting, qemu appears halted. the screen has the "TianoCore" logo.
19:34:57 <heat> SetVirtualAddressMap access boot services mem
19:35:03 <heat> klys: check the serial output
19:35:13 <klys> k
19:36:11 <heat> doug16k: ^^, so you can't discard boot services memory before setting the virtual address map
19:36:19 <klys> I am not sure, I have -monitro stdio so far
19:36:20 <heat> it's pretty funny, linux devs found it out
19:36:23 --- quit: JusticeEX (Ping timeout: 268 seconds)
19:36:24 <doug16k> ah
19:36:39 <klys> s/ro/or/
19:36:45 --- quit: dude12312414 (Quit: Segmentation fault: 11)
19:37:03 <heat> klys: try ctrl+alt+2
19:37:17 <heat> I don't think -monitor stdio changes the serial output
19:37:43 <geist> -serial stdio does though
19:37:46 <heat> Anyway, I've seen OVMF halt a few times because of a bad FAT image
19:37:48 <doug16k> klys, you want -serial stdio, not -monitor stdio
19:38:01 <klange> -serial mon:stdio
19:38:08 <klange> or gtfo
19:38:47 <klange> `ctrl-a c` to switch to the monitor, ^C goes to the serial properly.
19:38:49 <doug16k> I prefer to be more masochistic and explicitly create chardevs and bind thing to those :)
19:39:16 <klys> heat, https://paste.debian.net/1034174/
19:39:17 <bslsk05> ​paste.debian.net: debian Pastezone
19:39:26 <doug16k> ...because -d int floods stdout, hard
19:40:49 <klys> perhaps this means I didn't specify something on the efi command line or so
19:41:08 <heat> klys: Could you give me the bootx64.efi?
19:41:13 <klys> k
19:41:29 <heat> The only difference is that you're missing the kernel and the initrd
19:41:34 <heat> maybe that's it
19:42:10 --- join: GRD (~GRD@180.250.7.179) joined #osdev
19:43:49 --- quit: jakogut_ (Quit: jakogut_)
19:43:53 <klys> I thought so
19:44:34 <klys> http://45.55.20.239/uefi0002.tar.gz or http://show.ing.me/uefi0002.tar.gz
19:46:36 <heat> klys: are you using the BOOTX64.EFI or bootx64.efi?
19:46:46 <heat> because you have two bootx64s
19:46:59 <klys> the lowercase one is yours.
19:48:54 <doug16k> it's odd that the virtio docs say "The driver performs suitable a memory barrier to ensure the device sees the updated descriptor table..." - could that be because the hypervisor might try to read the memory from another CPU, and could see weakly ordered memory updates happening out of order?
19:49:23 <geist> probably so, yes
19:49:55 <geist> though the trap when you hit the dorbell register is probably a memory barrier
19:50:01 <geist> but that's an architectural detail
19:50:24 <doug16k> yeah, I had the same thought. I guess they are trying to be completely architecture agnostic
19:51:05 <geist> also it's possible that the host is reading ahead and sees the next transfer as it's queued before the doorbell is hit, i guess
19:52:39 --- join: dude12312414 (None@gateway/shell/elitebnc/x-upzqjlecvwqagnhc) joined #osdev
19:52:43 <heat> klys: I think something's wrong with your bootx64
19:52:58 <heat> since the RIP it faults on technically doesn't exist
19:53:03 --- quit: nwm (Ping timeout: 244 seconds)
19:55:02 <geist> so there's probably a good reason to memory barrier after filling out the transfer descriptors, before adding it to the queue head
19:55:07 <geist> even before hitting the dorbell
19:56:11 <doug16k> I think they want to guarantee that the writes to the descriptor array are globally visible before you write the value to the available ring, to ensure that it won't peek ahead in the available ring and find the index to a not-globally-visible descriptor, like you mentioned
19:56:20 <geist> yah
19:56:28 <geist> and this remidns me, we should probably do that in ours. i doubt we do
19:57:45 <heat> klys: https://ahti.space/~heat/bootx64.efi
19:57:46 <heat> try that
19:57:49 <klys> k
19:59:29 <klys> that seems to be working like it was written, heat.
19:59:47 <heat> so it's working?
19:59:56 <klys> yeah that binary worked
20:00:05 <klys> where do I put initrd?
20:00:10 <heat> what command line did you use to compile it
20:00:16 <klys> wget
20:00:20 <klys> :)
20:00:23 <heat> :D
20:00:44 <heat> klys: it's not needed, we're just trying to get the image compiled
20:01:07 <heat> if you add an initrd.tar and a carbon(?) to the root directory you'll have a bootable image
20:01:14 <heat> but you can change that if you want
20:01:20 <klys> ok
20:01:40 <klys> what's the file format of carbon, since I'm curious
20:01:44 <heat> klys: anyway, what compile options?
20:01:48 <heat> ELF64
20:02:20 <klys> you're asking me about something that I did?
20:02:30 <heat> yeah
20:02:30 <klys> I did nothing working, just test yours
20:02:51 <heat> I know, I'm asking for the options for your broken image
20:03:02 --- quit: GRD (Read error: Connection reset by peer)
20:03:23 <klys> they're in the makefile I sent you, in uefibarebones/heatd/Carbon/...
20:03:58 <heat> Right, are you running cygwin?
20:04:09 <heat> or mingw
20:04:12 <klys> I have linux-amd64 with debian and gcc-8
20:04:28 <klys> I used clang from apt
20:04:37 <klys> it's amd64
20:04:46 <heat> hmm
20:05:04 <heat> did it spit any warnings besides the clang ones?
20:05:14 --- quit: nicht (Ping timeout: 256 seconds)
20:05:16 <klys> well there were warnings
20:05:22 <heat> yes, I know that
20:05:30 <klys> lessee
20:06:49 <klys> heat: https://paste.debian.net/1034178/
20:06:51 <bslsk05> ​paste.debian.net: debian Pastezone
20:08:33 --- quit: alyptik (Ping timeout: 244 seconds)
20:09:46 <heat> klys: https://gist.github.com/heatd/aae1ec079b8e9ec6c030d2469f0c1595
20:09:48 <bslsk05> ​gist.github.com: elf_x86_64_efi.lds · GitHub
20:09:50 <heat> check if they are the same
20:11:55 --- join: alyptik (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
20:12:06 <klys> cmp paste.lds /usr/lib/elf_x86_64_efi.lds they are the same
20:14:00 <heat> klys: https://www.archlinux.org/packages/extra/x86_64/gnu-efi-libs/ + Download from mirror and compare all the files with the ones you built maybe?
20:14:01 <bslsk05> ​www.archlinux.org: Arch Linux - gnu-efi-libs 3.0.8-1 (x86_64)
20:14:12 <heat> that would say it's a toolchain problem for sure
20:17:10 --- quit: graphene (Read error: Connection reset by peer)
20:18:44 --- join: graphene (~graphene@46.101.134.251) joined #osdev
20:19:14 <klys> this gnu-efi_3.0.8 is substantially different from upstream.
20:19:44 <heat> the arch linux one?
20:20:10 <klys> yes
20:20:27 <heat> *shrug* try building that one then
20:20:58 <klys> I want the source too...
20:21:00 <heat> wait
20:21:01 <heat> it's not
20:21:14 <heat> it's the same thing
20:21:22 <heat> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gnu-efi-libs
20:21:22 <bslsk05> ​git.archlinux.org: PKGBUILD\trunk - svntogit/packages.git - Git clone of the 'packages' repository
20:21:39 <heat> it should be the same
20:24:42 <klys> ok it compiled and works as expected.
20:25:02 <heat> you recompiled the gnu-efi-libs?
20:26:27 <klys> it's the headers. I had wrong headers then
20:26:47 <heat> odd
20:27:35 <klys> yeah I thought I put my 3.0.8 headers there though those aren't the ones I had.
20:33:24 <heat> anyway, I gtg
20:33:25 <heat> have fun
20:33:38 --- quit: heat (Quit: Leaving)
20:38:48 <klys> this rogue set of efi headers has yet to be identified after comparing it to all my trees. http://show.ing.me/efi.old.tar.gz
20:50:11 <klys> doug16k, the version of seabios you saw csm hooks in it, which fork of seabios were you looking at?
20:51:03 <klys> coreboot, coreos, or qemu.git ?
20:54:59 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
20:55:17 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
20:58:09 --- quit: nj0rd_ (Ping timeout: 276 seconds)
21:00:58 --- join: bluezinc (~bluezinc@unaffiliated/bluezinc) joined #osdev
21:01:20 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
21:01:39 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
21:04:36 --- quit: freakazoid0223 (Remote host closed the connection)
21:07:54 --- quit: drakonis (Remote host closed the connection)
21:11:16 --- join: nwm (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
21:11:42 --- join: nj0rd_ (~nj0rd@200116b84586f1003e41206d61135559.dip.versatel-1u1.de) joined #osdev
21:11:43 --- quit: andrewrk (Ping timeout: 240 seconds)
21:11:51 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
21:12:58 --- join: Salek (~salek@91-155-9-229.elisa-laajakaista.fi) joined #osdev
21:15:11 --- quit: salek_ (Ping timeout: 260 seconds)
21:17:27 --- join: andrewrk (~andrewrk@cpe-68-175-109-180.nyc.res.rr.com) joined #osdev
21:19:01 <klys> doug16k, found it, making a csm now.
21:29:19 --- quit: flacks (Ping timeout: 240 seconds)
21:31:31 --- join: flacks (flacks@184.91.69.131) joined #osdev
21:31:49 --- join: typikal (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
21:31:57 --- quit: alyptik (Ping timeout: 240 seconds)
21:33:11 --- quit: bemeurer (Ping timeout: 256 seconds)
21:33:14 --- nick: typikal -> alyptik
21:34:36 --- quit: flacks (Client Quit)
21:36:20 --- join: flacks (flacks@184.91.69.131) joined #osdev
21:37:52 <doug16k> klys, I used the main seabios repo at https://git.seabios.org/seabios.git
21:38:59 <doug16k> note that that's something you `git clone`, not a web page
21:39:14 <klange> https://git.seabios.org/cgit/seabios.git for the web version
21:39:15 <bslsk05> ​git.seabios.org: seabios.git - To submit patches to SeaBIOS, see https://www.seabios.org/Contributing
21:39:42 <klange> which apparently suggests that the correct clone URL is actually https://review.coreboot.org/seabios.git
21:40:00 --- quit: chao-tic (Ping timeout: 244 seconds)
21:41:30 <doug16k> I just pulled from a remote with the link I provided, latest tag is rel-1.11.2
21:42:03 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
21:42:38 <klange> I'm sure it's all just CNAMEs for the same thing
21:42:48 <klange> or some sort of mirroring setup
21:42:52 <klange> I don't really want to know.
21:47:09 --- join: manzerbredes (~loic@2a01cb0885e31500cfc30bb534d5bc37.ipv6.abo.wanadoo.fr) joined #osdev
21:48:03 <doug16k> probably. I remember building coreboot and it had no ACPI (how? don't know), grabbed seabios, worked
21:49:48 <doug16k> the coreboot was intended for flashing onto supported real motherboards, not sure if I had to do something to make it use qemu fw_cfg or something
21:51:28 <klys> both seabios trees appear to be generating this error: /root/src/sys/seabios/./src/farptr.h:93: undefined reference to `__segment_CS'
21:51:46 --- join: typikal (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
21:52:03 --- quit: alyptik (Ping timeout: 268 seconds)
21:52:11 <doug16k> did you run `make menuconfig` and save in there?
21:52:24 <klys> I have a .config for csm builds
21:52:43 <doug16k> from where?
21:52:54 --- nick: typikal -> alyptik
21:52:59 <klys> anyway I suspect this error will catch you regardles sif you get seabios.git
21:53:04 <klys> will upload
21:53:20 <doug16k> you don't need some .config from somewhere. run make menuconfig
21:53:40 <klys> I did
21:53:48 <doug16k> in there you can pick the build type
21:53:53 <klys> I did
21:55:27 <doug16k> works for me
21:55:51 <klys> no goog results yet on undefined __segment_CS
21:55:59 <klys> here upload a tarball for me
21:56:02 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
21:56:06 <klys> unless you know one
21:56:40 <doug16k> I just `make clean` it, did `make menuconfig` and configured it to build csm, did `make -j16`, worked
21:57:03 <klys> I got at least one assembly error I had to fix in two of the files
21:57:20 <klys> building with gcc-7 and gcc-8
21:57:44 <klys> binutils 2.31-1
21:57:59 <klys> :i386 targets on all that
21:59:02 <doug16k> klys, when you did make menuconfig you tabbed over and hit the < Save > button, right?
21:59:09 <klys> yes it saved
22:00:16 --- join: Amaan (uid4967@gateway/web/irccloud.com/x-cpbmkatayeruaxgp) joined #osdev
22:00:37 <doug16k> https://gist.github.com/doug65536/70650d8be7c8b49bde7104ba05334d50
22:00:38 <bslsk05> ​gist.github.com: gist:70650d8be7c8b49bde7104ba05334d50 · GitHub
22:01:38 --- join: Lowl3v3l (~Lowl3v3l@ulbp2362.ulb.uni-jena.de) joined #osdev
22:01:48 <klys> yeah doug16k what's your binutils version?
22:02:00 <doug16k> 2.30
22:02:03 <klys> k
22:02:23 <doug16k> gcc 7.3.0
22:05:11 <klys> mostly the same. gcc 7.3.0-25, binutils 2.30.90.20180710-1 from debian.
22:06:26 <klys> the reason I wnat your tree is to test it and see why it linked with perhaps nm -s or just make/ld
22:06:40 <doug16k> seabios is about as easy as it gets to build. if you just clone it and whack `make` it just works
22:07:01 <doug16k> IIRC
22:07:09 <klys> will try retargetting gcc to amd64 if advisable, please advise.
22:08:17 <doug16k> my gcc is 64 bit of course, because my system is 64 bit. yours isn't?
22:08:33 --- join: sammwch (heddwch@lambdaos.org) joined #osdev
22:08:43 <klys> doug16k, nm -s out/*.o out/*/*.o | grep __segment_CS
22:10:12 <klys> I have two undefined in ccode16.o and code16.o
22:10:28 <klys> other segment regs are mentioned also.
22:11:05 --- join: FreeFull_ (~freefull@defocus/sausage-lover) joined #osdev
22:11:07 <klys> I've changed my c compiler out at lesat twice today
22:12:00 <doug16k> can you paste the terminal output of the failed make?
22:12:13 <doug16k> on a paste site of course :)
22:14:26 --- join: ornitorr- (~ornitorri@163.172.62.96) joined #osdev
22:15:49 --- quit: palk (Ping timeout: 240 seconds)
22:16:43 --- join: shakalaka (~shakalaka@ec2-52-52-27-0.us-west-1.compute.amazonaws.com) joined #osdev
22:16:50 --- quit: manzerbredes (*.net *.split)
22:16:53 --- quit: Affliction (*.net *.split)
22:16:55 --- quit: allight_ (*.net *.split)
22:16:55 --- quit: mpetch (*.net *.split)
22:16:57 --- quit: FreeFull (*.net *.split)
22:17:00 --- quit: sferrini (*.net *.split)
22:17:02 --- quit: R3x_ (*.net *.split)
22:17:08 --- quit: ybden (*.net *.split)
22:17:08 --- quit: glenda (*.net *.split)
22:17:09 --- quit: ornitorrincos (*.net *.split)
22:17:09 --- quit: m712 (*.net *.split)
22:17:09 --- quit: shakalaka_ (*.net *.split)
22:17:09 --- quit: PyroLagus (*.net *.split)
22:17:11 --- quit: edr (*.net *.split)
22:17:11 --- quit: sircmpwn (*.net *.split)
22:17:12 --- quit: stux (*.net *.split)
22:17:12 --- quit: md_5 (*.net *.split)
22:17:12 --- quit: heddwch (*.net *.split)
22:17:14 --- join: edr (~edr@enlo.co) joined #osdev
22:17:14 --- quit: edr (Changing host)
22:17:15 --- join: edr (~edr@pdpc/supporter/professional/edr) joined #osdev
22:17:21 <klange> doug16k: do you have a (recent) ISO of dgos somewhere accessible? I want to poke it with a stick :)
22:17:55 --- join: md_5 (~md_5@mcdevs/trusted/md-5) joined #osdev
22:18:15 <klys> doug16k: https://paste.debian.net/1034191/
22:18:16 <bslsk05> ​paste.debian.net: debian Pastezone
22:19:19 --- quit: tyler569 (Ping timeout: 240 seconds)
22:19:21 --- quit: bitch (Ping timeout: 260 seconds)
22:19:32 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
22:19:36 --- join: bitch (hctib@gateway/shell/elitebnc/x-nwsxnhbnlktknoqu) joined #osdev
22:19:37 --- quit: bitch (Changing host)
22:19:37 --- join: bitch (hctib@unaffiliated/bitch) joined #osdev
22:19:37 --- quit: bitch (Changing host)
22:19:37 --- join: bitch (hctib@gateway/shell/elitebnc/x-nwsxnhbnlktknoqu) joined #osdev
22:19:49 --- quit: smeso (Ping timeout: 240 seconds)
22:19:56 --- quit: Goplat (Ping timeout: 260 seconds)
22:20:19 --- quit: sha-2 (Ping timeout: 240 seconds)
22:20:19 --- quit: atk (Ping timeout: 240 seconds)
22:20:19 --- quit: Wild (Ping timeout: 240 seconds)
22:20:56 <doug16k> klange, I don't actually. so far it's almost all kernel too, not much user mode to play with yet
22:21:14 <klange> All work and no play makes dgos a dull user experience ;)
22:21:38 --- join: atk (~Arch-TK@ircpuzzles/staff/Arch-TK) joined #osdev
22:21:42 --- join: tyler569 (~tyler569@209.182.232.125) joined #osdev
22:21:42 <doug16k> yeah I've been so focused with massive driver support that I've neglected getting quake to run D:
22:21:43 --- join: sha-2 (Sha2@gateway/shell/elitebnc/x-aqlydfaigmhvtwqy) joined #osdev
22:22:39 --- quit: bauen1 (Remote host closed the connection)
22:22:44 --- join: Wild (~Wild@archlinux/trusteduser/wild) joined #osdev
22:22:47 --- quit: chao-tic (Client Quit)
22:22:53 <doug16k> I have a ton of virtio base working. virtio 3d looks damn easy too. can't wait until I have virtio buffers flying back and forth
22:23:15 <klys> the gcc:amd64 bit isn't helping either.
22:23:28 <geist> eah virtio gpu is pretty neat
22:23:35 <geist> it's a bit stateful, which is a bit annoying but so it goes
22:23:36 <klange> You can port Yutani and then write a virtio 3d backend for it :)
22:24:31 --- join: smeso (~smeso@unaffiliated/smeso) joined #osdev
22:24:34 <doug16k> that text rendering algorithm you use is easy to convert to a shader too, isn't it?
22:24:58 <klange> Indeed!
22:25:30 <klys> doug16k you can't be serious about using a non-retargetted /usr/bin/as on seabios
22:26:05 <doug16k> klys, the normal gcc toolchain works, nothing special at all
22:26:14 <klys> oh yes you can, as -32
22:29:10 --- quit: robert_ (Ping timeout: 256 seconds)
22:30:52 --- join: S_Gautam (uid286066@gateway/web/irccloud.com/x-fbfwekuqlvpqqnjf) joined #osdev
22:31:05 <doug16k> klange, it could be as fast as filling a buffer with texture atlas texcoords and screen coordinates then using instancing to render each quad
22:32:27 <doug16k> and instancing runs at ludicrous speed in my experience
22:35:37 --- join: manzerbredes (~loic@2a01cb0885e31500cfc30bb534d5bc37.ipv6.abo.wanadoo.fr) joined #osdev
22:35:38 --- join: Affliction (affliction@2402:1f00:8101:135::) joined #osdev
22:35:38 --- join: allight_ (allight@nat/google/x-eurvtjbzwghpefew) joined #osdev
22:35:38 --- join: mpetch (~mpetch@vps2.gnubg.com) joined #osdev
22:35:38 --- join: sferrini (sid115350@gateway/web/irccloud.com/x-schkrcywsucvbmmk) joined #osdev
22:35:38 --- join: R3x_ (sid181433@gateway/web/irccloud.com/x-fvxtaemencoqtzkq) joined #osdev
22:35:38 --- join: ybden (~ybden@coleridge.vehk.de) joined #osdev
22:35:38 --- join: glenda (~glenda@tunnel272116-pt.tunnel.tserv29.fmt1.ipv6.he.net) joined #osdev
22:35:38 --- join: m712 (~annoying@unaffiliated/thefam) joined #osdev
22:35:38 --- join: PyroLagus (PyroLagus@i.have.ipv6.on.coding4coffee.org) joined #osdev
22:35:38 --- join: sircmpwn (znc@irc.sircmpwn.com) joined #osdev
22:35:38 --- join: stux (stux@2a01:270:2050:1337::1) joined #osdev
22:36:43 <doug16k> I have my virtio base and virtio-gpu drivers negotiating 3d support successfully. just finishing up my virtio virtqueue code and I'll be creating a framebuffer and issuing commands
22:37:49 --- quit: bitch (Ping timeout: 240 seconds)
22:38:01 --- quit: geordi (Ping timeout: 260 seconds)
22:38:07 <doug16k> s/(driver)s/\1/
22:38:19 --- quit: atk (Ping timeout: 240 seconds)
22:39:27 --- join: geordi (~geordi@ns510081.ip-192-99-4.net) joined #osdev
22:39:44 --- join: palk (~palk@unaffiliated/palk) joined #osdev
22:40:07 --- join: bitch (hctib@gateway/shell/elitebnc/x-jrosinyxklbtxuxy) joined #osdev
22:40:27 --- quit: flacks (Ping timeout: 244 seconds)
22:40:41 --- join: atk (~Arch-TK@ircpuzzles/staff/Arch-TK) joined #osdev
22:42:43 <doug16k> klange, so, you copy all of your libc headers and startup code and libraries into the cross compiler's gcc install directory, right? is the cross compiler build is part of your build?
22:43:13 --- join: flacks (flacks@184.91.69.131) joined #osdev
22:43:26 <klange> doug16k: I use a sysroot
22:43:27 --- quit: manzerbredes (Ping timeout: 276 seconds)
22:44:17 <doug16k> meaning, when you build a user mode program you pass an option that points it at your libc headers and libraries?
22:44:19 <klange> doug16k: the cross gcc is specific to the particular checkout and has an embedded sysroot pointing to the "base" directory used to build the ramdisk, which is where the headers are out of git, as well as where the libraries end up
22:45:34 <doug16k> ah so when you compile the cross compiler it has to know where the libc will be up front?
22:45:46 <klange> Basically.
22:45:55 <klange> Though I believe sysroot can be overridden.
22:46:09 <klange> man gcc → -sysroot=dir
22:46:13 <klange> er, --sysroot=dir
22:46:25 <klange> so in theory you could retarget it to another base
22:46:53 <klange> My Makefile also does a small amount of magic to ensure it has the toolchain in its path so you don't have to activate anything.
22:47:44 <klange> i686-pc-toaru-gcc -print-sysroot → /home/klange/Projects/workspace/toaru-nih/util/../base
22:48:39 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
22:48:48 <klange> ^ ..'s because the gcc build script sets it to "$DIR/../base" after setting DIR to $(cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
22:51:21 <doug16k> hmm, when I `x86_64-elf-g++ -print-sysroot` my cross compiler it prints nothing. you set a sysroot in your gcc configure I guess?
22:51:29 <klange> Yes.
22:52:06 <klange> both binutils and gcc are built using --with-sysroot=$TOARU_SYSROOT (described previously)
22:53:13 <doug16k> cool. one of the things bogging me down for user mode is escaping the chicken and egg issue of building a cross compiler that builds the stdlib then getting the stdlib to be used by gcc :D
22:53:36 <doug16k> gcc doesn't care if the sysroot is empty at first?
22:53:39 <klange> In my current setup, I build only a targeted gcc.
22:53:46 --- quit: bemeurer (Max SendQ exceeded)
22:53:57 <klange> It may complain if your include paths are non-existent, but empty is no problem.
22:55:01 <klange> I build a single GCC which I use for my kernel, bootloader, and userspace. Kernel/boot code gets a healthy dose of -ffreestanding and also sets some defines so my own headers know they're building kernel stuff.
22:55:38 <klange> -ffreestanding should put you in the clear for having an empty sysroot.
22:56:33 <klange> I also finally moved my kernel headers into <kernel/> by putting them in the sysroot's /usr/include/kernel
22:57:08 --- quit: sysfault (Remote host closed the connection)
22:57:34 --- join: sysfault (~exalted@pool-108-53-157-115.nwrknj.fios.verizon.net) joined #osdev
22:57:44 <doug16k> ah, for user-mode usable includes right? user mode program would #include <kernel/foo.h>?
22:57:50 <klange> [for values of finally equal to march of this year]
22:57:55 <klange> yep
22:58:52 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
23:04:07 --- join: xerpi (~xerpi@250.red-83-45-196.dynamicip.rima-tde.net) joined #osdev
23:08:39 --- quit: spare (Quit: leaving)
23:10:02 --- quit: R3x_ (Quit: Updating details, brb)
23:10:16 --- join: R3x_ (sid181433@gateway/web/irccloud.com/x-pycfeqvsjmgalaov) joined #osdev
23:14:41 --- join: manzerbredes (~loic@myriads-lg.irisa.fr) joined #osdev
23:23:09 --- quit: graphene (Remote host closed the connection)
23:27:34 --- join: light2yellow (~l2y@185.220.70.163) joined #osdev
23:33:33 <doug16k> klys, what does this command say: which as
23:33:44 --- join: [Brain] (~brain@brainwave.brainbox.cc) joined #osdev
23:35:26 --- quit: tadni_ (Remote host closed the connection)
23:35:26 --- quit: tadni- (Remote host closed the connection)
23:36:50 <doug16k> klys, try using x86_64-linux-gnu-as instead of as. you might have some strange build of as in /usr/local/bin that is throwing off your test where you hand-assemble it
23:43:18 --- join: glauxosdever (~alex@ppp-94-66-200-106.home.otenet.gr) joined #osdev
23:43:32 <klys> doug16k, which as /usr/bin/as ls -l /usr/bin/as /usr/bin/as -> x86_64-linux-gnu-as ls -l /usr/bin/x86_64-linux-gnu-as -rwxr-xr-x 1 root root 893880 Jul 16 03:40 /usr/bin/x86_64-linux-gnu-as
23:45:45 <klys> doug16k, also, https://paste.debian.net/1034196/
23:45:47 <bslsk05> ​paste.debian.net: debian Pastezone
23:47:40 <doug16k> klys, weird!
23:49:53 --- join: grouse (~grouse@83-233-9-2.cust.bredband2.com) joined #osdev
23:51:28 <doug16k> klys, why is it compiling that ACPI stuff? that's weird
23:51:53 <doug16k> seabios should be cluelessly getting ACPI tables from qemu fw_cfg
23:51:53 <klys> it's part of the debian package, not sure
23:52:34 <doug16k> seabios can't mindread what to put in the tables
23:55:41 --- join: tadni (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
23:56:04 --- join: tadni_ (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
23:56:14 --- quit: tadni_ (Remote host closed the connection)
23:59:59 --- log: ended osdev/18.07.17