Search logs:

channel logs for 2004 - 2010 are archived at ·· 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

Wednesday, 8 March 2023

00:01:00 <mrvn> And qemu doesn't support multiboot2 since my patch hasn't been merged (yet).
00:02:00 <klange> can I see that patch? did you implement the framebuffer stuff? I tried to do it for the multiboot1 implementation but the interfaces to the graphics system made it seemingly impossible
00:02:00 <mrvn> klange: i basically copied the muliboot option rom and changed the format.
00:03:00 <brunothedev> is there ANY multiboot2 implementation on osdev
00:03:00 <mrvn> grub
00:04:00 <mrvn> or do you mean kernel?
00:05:00 <klange> Not on the wiki, but there's lots of references on the forum.
00:05:00 <klange> And I already linked to mine.
00:06:00 <brunothedev> klange: oh i missed it
01:12:00 <heat> netbsduser, borrowing the svr4 book since it can't get here soon enough, good shit man
01:19:00 <heat> really weird that they picked the fucking mips r3000 processor as an example
01:38:00 <heat> oh jeez
01:38:00 <heat> their read/write syscall just page faulted memory in
05:42:00 <CompanionCube> svr4 book?
12:10:00 <brunothedev> i decided that i am gonna make a driver similar to vesafb,
12:25:00 <nortti> why? it gives you nothing over bootloader-provided framebuffer, and requires you go through the legacy bios-style boot for you to be able to use graphics
12:26:00 <ThinkT510> maybe for learning purposes or fun
12:29:00 <brunothedev> i have a bios-only computer
12:31:00 <brunothedev> also, i dont want to become dependant on grub, i want to write my own bootloader later
12:33:00 <brunothedev> also, i dont know assembly, so is this code correct: "int 0x10\n mov [call], %ax
12:33:00 <brunothedev> "\n" is for newline
12:45:00 <brunothedev> is it possible to get into real mode in C?
12:46:00 <zid> No, C doesn't even have a concept of a processor
12:46:00 <zid> C programs run on an abstract machine
12:49:00 <jjuran> I have some C code I'd like to run. Where can I get an abstract machine?
12:52:00 <sham1> At an implementation near you
12:53:00 <zid> jjuran: compile it
12:53:00 <zid> from an abstract machine language source file
12:54:00 <zid> I need to figure out what I am going to do for a cooler
12:54:00 <brunothedev> zid: are you talking about crt0?
12:54:00 <zid> No.
12:54:00 <zid> cheap aio: £55, noctua box fan: £70, corsair aio: £150
12:54:00 <zid> wtf are these prices
12:56:00 <brunothedev> ok so i will make 2 assembly functions to load real mode or protected mode, and call then on the c code
13:03:00 <brunothedev> asm("jmp real-mode");
13:06:00 <gog> it's not going to be that easy
13:07:00 <theWeaver> imagine doing osdev and expecting anything to be easy
13:08:00 <theWeaver> couldn't be me
13:10:00 <zid> gog: Okay what do you think to this plan, I get another coolermaster 212, but with AM4 mounting holes, and then put my existing 212 on top of it, like a sega genesis tower of power
13:14:00 <nortti> brunothedev: if you try to execute code that was compiled for 32-bit protected mode in real mode, at best you will get an illegal instruction error, and at worst it will run and silently do the wrong thing. you will need to either write everything that happens in real mode in assembly or use a second C compiler that targets 16-bit x86
13:15:00 <nortti> or, alternatively, leave such things for your bootloader
13:23:00 <zid> (like vesafb, the thing you said you want to emulate)
13:28:00 <brunothedev> is that the grub frmaebuffer have little docs tho
13:30:00 <sham1> They have enough docs
13:40:00 <brunothedev> theWeaver: the bare bones page should make more clear about these things, a simple multiboot1 header with a vga text mode printer is too little
13:40:00 <theWeaver> ¯\_(ツ)_/¯
13:41:00 <theWeaver> tell it to the page maintainer, who is not me
13:42:00 <zid> also, it's correct
13:42:00 <zid> it's the *bare bones* tutorial
13:42:00 <zid> if you want fonts and graphics, follow a fonts and graphics tutorial
13:44:00 <sham1> Or better yet, don't follow tutorials, but try different things out and read up on fonts and graphics
13:50:00 <brunothedev> i declared the multiboot2 header in the assembly file, something tell me to declare it on the c file
13:50:00 <brunothedev> specially the framebuffer struct
13:51:00 <klange> There is no "grub framebuffer". There is the framebuffer passed to you through multiboot by your multiboot-compliant bootloader, which happens to be grub (and can be _your_ bootloader in the future)
13:51:00 <klange> The documentation you need is in the multiboot spec, either or
13:51:00 <bslsk05> ​ Multiboot Specification version 0.6.96
13:51:00 <bslsk05> ​ Multiboot2 Specification version 2.0
13:51:00 <klange> The spec example kernel even includes framebuffer drawing samples.
13:52:00 <kof123> CompanionCube: the magic garden explained : the internals of UNIX system V release 4 i think that might be what they are talking about
13:52:00 <klange> (search for "case MULTIBOOT_TAG_TYPE_FRAMEBUFFER" in the second link)
13:57:00 <brunothedev> by linking the assembly file, i assume i already have acess to the multiboot2 header, correct?
13:59:00 <klange> What would linking have to do with having a header? Headers are just textual inclusion.
13:59:00 <brunothedev> klange: multiboot2 structs
13:59:00 <brunothedev> it is the assembly file
14:00:00 <klange> Oh you mean _that_ header. You were talking about C so I was confused.
14:00:00 <klange> The header you build in the assembly is for the bootloader to read to understand what you want. The one that you want to read from is a different thing the bootloader gives you.
14:01:00 <klange> It does this by providing a pointer in a register. That should be %ebx on x86. It also puts a magic value in %eax so you can know you're getting a valid header.
14:01:00 <klange> This is all demonstrated in the sample kernel that comes with the multiboot documentation.
14:01:00 <heat> CompanionCube,
14:01:00 <bslsk05> ​ Sorry! Something went wrong!
14:03:00 <sham1> Another hard day of ok sham1@ behind me
14:04:00 <heat>
14:04:00 <sham1> Reviewing PRs can be annoying when they're big
14:04:00 <heat> Reviewed-by: Shamothy Sham <>
14:05:00 <heat> actually Shamothy Wuan
14:05:00 <klange> Steamed Ham I
14:06:00 <heat> it's a regional dialect
14:07:00 <sham1> Right. I suppose I'll have to replace my slack profile pic with Principal Skinner
14:07:00 <sham1> Steamed PRs
14:13:00 <netbsduser> heat: it truly is great
14:13:00 <netbsduser> i decided to copy their approach to read()/write() also
14:14:00 <netbsduser> it might be the easiest way to maintain coherence between read()/write() and mmap()
14:15:00 <heat> naw
14:15:00 <heat> just map the pages directly man
14:27:00 <heat> having a demand fault file mapping scheme in the fucking kernel is just needless complexity
14:27:00 <heat> I really don't see what they're getting at
14:27:00 <heat> it will also be slower
14:27:00 <heat> mmap vs read? mmap, because the read implementation does mmap!
14:29:00 <heat> will also require a TLB shootdown on SMP systems for every read/write
14:29:00 <nortti> did svr4 support SMP?
14:30:00 <heat> i'm fairly sure it did
14:30:00 <heat> at least its descendents did
14:31:00 <heat> ok, "SVR4.2MP" did
14:45:00 <netbsduser> heat: i forgot if SVR4 does it but in NetBSD similar is done through the unified buffer cache framework
14:46:00 <netbsduser> the kernel keeps an LRU queue of mapped windows into the UBC (which is what mmap() also maps) of a file
15:00:00 <zid> guys how do you install windows 10
15:01:00 <zid> Tools I have: Another computer, that can't be powered on at the same time
15:01:00 <zid> The end.
15:01:00 <sham1> Why can't it be powered on at the same time
15:01:00 <sham1> That may give us a hint
15:01:00 <zid> I'm going to transfer the cooler
15:02:00 <zid> and power supply
15:02:00 <nortti> use the microsofot boot media generator to generate one on a usb stick?
15:02:00 <GeDaMo> Just copy it to a floppy disk and install from that :P
15:02:00 <zid> GeDaMo: yea that's my problem, my floppy disk is only 1.44MB
15:03:00 <zid> the w10 iso is like, at least 3MB
15:03:00 <sham1> Alright. Yeah, that advice should work. Unless you don't already have a Windows machine, in which case things get more difficult and you'll have to get the installation medium in another way
15:03:00 <zid> won't work cus you added a tool
15:03:00 <zid> I told you the tools I had
15:04:00 <sham1> Can confirm, |Windows 10 ISO| ≥ 3MiB
15:04:00 <sham1> Well then you're SOL
15:04:00 <zid> what about
15:04:00 <zid> sham1 hosts me a PXE netboot windows 10
15:04:00 <GeDaMo> Can you move the disk from one machine to another too?
15:05:00 <zid> GeDaMo: not until my RMA gets back
15:05:00 <zid> my final solution to the w10 problem: GPT partition RMA'd ssd, put /boot/efi onto it from w10 install image
15:05:00 <zid> pray the installer can install w10 to itself
15:13:00 <sham1> Narrator: it cannot
15:13:00 <sham1> Because I'd wager that in true Windows fashion, it cannot do things like override open files
15:13:00 <zid> I thought of an easier idea
15:13:00 <zid>
15:13:00 <bslsk05> ​
15:13:00 <sham1> Why don't you have a USB stick
15:13:00 <zid> I do but it's too small
15:14:00 <zid> I had three, they are all equally too small
15:14:00 <zid> I've not transfered a file via usb stick in 20 years
15:14:00 <sham1> Get yourself a 32GiB thumbdrive. You'll never know when you'll need it
15:14:00 <zid> and 4GB is enough for w7 installer, so I've never had to think about it before now
15:14:00 <zid> sham1: should I change my wishlist for you the?
15:15:00 <zid> wtf it's cheaper
15:15:00 <sham1> Well no, it was just a suggestion
15:15:00 <zid>
15:27:00 <mjg> heat:
15:27:00 <bslsk05> ​ Copying Data 2000% Faster With Advanced Vector Extensions | by Josh Weinstein | Medium
15:27:00 <mjg> > Overall, the standard code took around 12–13 seconds to copy 32 GB of data, while the AVX2 code took only between 0.63–0.73 seconds, around a 20X or 2000% performance improvement.
15:27:00 <mjg> there you go mofer
15:28:00 <mjg> as we all know, memcpy of 32G at a time is liek lowballing it
15:28:00 <mjg> also the only non-avx way is to do a one byte loop
15:31:00 <mjg> there it is, they *did* generate various funky memcpys after all
15:32:00 <bslsk05> ​ automemcpy/ at main · google-research/automemcpy · GitHub
15:33:00 <GeDaMo> Wouldn't it be better to avoid copying that much data in the first place? :|
15:35:00 <zid> splice all the things
15:35:00 <mjg> GeDaMo: i don't think person has ay need to copy 32G
15:36:00 <mjg> GeDaMo: i think they just did a heavily misguided benchmark with utter disregard or realities
15:36:00 <mjg> s/or/of
15:36:00 <mjg> with basic idea that perf diff of the sort is going to be the same for any size
15:36:00 <mrvn> sham1: I find (cheap) USB sticks always break or don't work at all. and small ones are dead slow.
15:37:00 <mrvn> Last 2 times I bought an USB M2.key ssd/nvme adaptor and and nvme.
15:38:00 <kof123> ^ if they are really cheap, fake sizes supposedly (usb sticks)
15:39:00 <kof123> never saw that myself, but dont really trust any of them
15:39:00 <mrvn> mjg: that automemcpy code is horrible. Why does every "else" branch have "else if (!cond)"?
15:39:00 <sham1> Yeah. I like Sandisk because those are fairly reliable
15:39:00 <sham1> And Kingston
15:39:00 <mrvn> kof123: I don't think I've had a fake size yet. Just that you write a file and when you read it back you get IO errors.
15:40:00 <mrvn> And 8GB sticks are like 1MB/s.
15:40:00 <mjg> mrvn: it is autogenerated
15:40:00 <mjg> mrvn: they tried to brute force towards the fastest variant
15:40:00 <mrvn> mjg: I know. but they don't seem to know what "else" means.
15:40:00 <mjg> lollers are guaranteed to pop up
15:43:00 <mrvn> mjg: Are they all of the form "do somethingh for small blocks else CopyRepMovsb"?
15:44:00 <mjg> no, there is tons of simd
15:44:00 <mrvn> ahh, not all. Found one that has no CopyRepMovsb in it
15:45:00 <mjg> thre is a disconnect between this file adn what landed in llvm automemcpy
15:45:00 <mrvn> I assume "CopyAlignedBlocks<32>()" has simd stuff behind it.
15:46:00 <mrvn> Which function is the winner?
15:47:00 <mjg> no idea yet
15:47:00 <mjg> the data is just csv
15:47:00 <mjg> 42M
15:49:00 <mrvn> Can't see how an "if (count == 1) else if (count == 2) else if (count == 3) ..." chain could ever be faster than a repmovsb loop for (count < 16). Unless the compiler makes that a jump table or something with constant time for all branches.
15:50:00 <mrvn> memcpy_I16_O256_B64_Linf_noopt() for an extreme example.
15:50:00 <heat> mjg, cern probably copies 32GB all the time man
15:50:00 <mrvn> heat: you think they have that small a file?
15:51:00 <mjg> mrvn: it is making a jump table
15:51:00 <mjg> and it sucks, but it is faster than erms
15:52:00 <heat> mjg, btw can I pick your brain on vfs internals not related to path walking
15:53:00 <mjg> it's all stupid
15:53:00 <mjg> but sure
15:54:00 <heat> how do struct buf's fit into the page cache stuff
15:54:00 <heat> like what's the relation between a vm_page and a struct buf
15:54:00 <mjg> that i know very little about mate and don't want to handwave
15:54:00 <heat> I've also noticed that "allegedly" you store the struct bufs in the inode in dirty and clean lists which felt really fucking weird
15:54:00 <heat> I would've thought you do writeback and dirtying in vm objects
15:55:00 <mjg> most of what you see there is an unfixed mess from late 80s/early 90s
15:55:00 <mjg> with "modernity" bolten onto it
15:55:00 <mjg> bolted
15:55:00 <heat> yay unfixed mess
15:55:00 <mrvn> mjg: That's the kind of thing I actually don't want my compiler to do. If I want a jump table I would write switch()
15:55:00 <mjg> grep for LK_KERNPROC to get a taste
15:57:00 <heat> i suppose you don't know a lot about when pages are locked either?
15:57:00 <heat> I honestly don't fully understand the need for a per-page lock
15:58:00 <heat> the SVR4 book mentions locking the page when faulting a page in through IO
15:58:00 <heat> but that seems silly
15:59:00 <mjg> pages are locked across i/o but the de facto lock is handrolled
15:59:00 <mjg> known as "exclusive busy"
15:59:00 <mjg> this bit i do know because it actively fucks with performance
16:00:00 <heat> why would they be locked across IO?
16:00:00 <Bitweasil> kof123, I got a fake 2TB USB storage drive. There are tools to test them fairly well.
16:00:00 <heat> what does the lock do in this case?
16:00:00 <Bitweasil>
16:00:00 <bslsk05> ​AltraMayor/f3 - F3 - Fight Flash Fraud (121 forks/1875 stargazers/GPL-3.0)
16:00:00 <mjg> prevents others from using the page, e.g. installing it into pmap during a page fault
16:01:00 <mjg> they can find there is one, but it is "in flux", so they wait for the i/o to clear
16:06:00 <kof123> interesting. i thought it was mainly cheap stuff e.g. ebay from who knows where. some of them supposedly loop around, maybe a20 is a good name
16:06:00 <heat> mjg, so mmap takes a shared lock and IO takes an excl lock?
16:06:00 <heat> does writeback also take the excl lock?
16:06:00 <mjg> mmap also takes an excl lock
16:06:00 <heat> why?
16:06:00 <mjg> because there is some idiocy where you can "shared busy" a page... and invaldiate it anyway
16:06:00 <heat> doesn't that just serialize mmap?
16:07:00 <mjg> erm, that's in fault handling
16:07:00 <mjg> mmap does not fuck with pages if it can avoid it of course
16:07:00 <mjg> but yes, the vm does not scale
16:07:00 <heat> ah yes, right
16:07:00 <mjg> all mmap ops are serialized for given address space
16:08:00 <mjg> and fault handling write locks it as well
16:08:00 <Bitweasil> kof123, some are smarter, but, yeah. The problem is that they're now learning to get rid of negative feedback ("I refunded his money, what's his problem?"), and prices are "plausible" in some cases.
16:08:00 <heat> mjg, wanna know a very funny fact?
16:08:00 <mrvn> heat: can't the same page not be in different mappings? Same file mapped in different processes. If process 1 faults a page in the page gets locked and when process 2 accesses the same page it gets blocked till the IO is done.
16:08:00 <heat> the svr4 page struct was a bunch of unsigned ints as flags
16:08:00 <Bitweasil> 2TB of old laptop drive for $40 is about right, 2TB for $25 or $30... sounds plausible, not *obviously* fraud, but the one I got was quite fake, about 50GB of actual storage on 2TB reported.
16:08:00 <heat> or at least that's how they paint it in the actual book
16:10:00 <heat>
16:11:00 <heat> oh wait no, it's grossly misrepresented
16:11:00 <heat> they should be unsigned <member_name> : 1;
16:11:00 <Bitweasil> You should be able to use uint8s and be OK across even weird architectures...
16:11:00 <heat> as they actually seemed to be
16:12:00 <Bitweasil> I guess some stuff can only do 32-bit aligned reads, though. Hrm.
16:12:00 <ilovethinking> how do i figure out why my grub image doesn't work
16:12:00 <ilovethinking> what can be the problems
16:12:00 <ilovethinking> cuz grub-mkrescue runs successfully
16:14:00 <Bitweasil> Define "doesn't work"?
16:26:00 <ilovethinking> Bitweasil: i am tryin to print an OK using
16:26:00 <ilovethinking> mov dword [0xb8000], 0x2f4b2f4f
16:27:00 <ilovethinking> but nothing happens
16:28:00 <Bitweasil> Does grub drop you in plain old VGA mode? I thought it tended to use more advanced video modes.
16:28:00 <heat> depends if you ask for it
16:29:00 <heat> will definitely not be in text mode if you're doing EFI
16:29:00 <ilovethinking> idk if im doing efi
16:29:00 <ilovethinking> probably not
16:29:00 <ilovethinking> im just doing it using the spec
16:29:00 <heat> is this a VM?
16:30:00 <ilovethinking> yes\
16:30:00 <ilovethinking> im also cross referencing using this
16:30:00 <ilovethinking>
16:30:00 <bslsk05> ​ A minimal Multiboot Kernel | Writing an OS in Rust (First Edition)
16:45:00 <netbsduser> heat: some kernels put struct bufs into the vm object so they 'overlay' the page cache so to speak. i'm not sure that i care for it
16:46:00 <heat> wdym "into"?
16:46:00 <heat> do they overlay struct page/vm_page like linux?
16:47:00 <heat> linux pretty much keeps a linked list of buffer_head's (for each block) on each page
16:47:00 <netbsduser> in Linux they do, and i know (but can't remember) at least one other kernel which has unified page/buffer cache that does this
16:47:00 <heat> i assume freebsd?
16:47:00 <heat> thats what I was looking into anyway
16:48:00 <netbsduser> i think that's one of them, and darwin might do the same
16:48:00 <heat> how else would you map file pages to block numbers?
16:48:00 <heat> this sounds pretty optimal
16:49:00 <netbsduser> i went for the netbsd approach where the unified buffer cache is not used for FS metadata but only for file pages, and then there is vnode ops `getpages` and `putpages` which just pass the page(s) to be gotten/put to disk
16:50:00 <netbsduser> so when those are getting paged out the FS might have to pull in the relevant metadata to figure out how the pages map to disk blocks
16:51:00 <netbsduser> the approach where they keep bufs around but point them into the page cache, that's superior in this case since you don't have to figure out where the blocks go when it's time to put the page back to disk
16:55:00 <ilovethinking> heat: any possible clue what could be wrong?
16:56:00 <heat> ilovethinking, nope
17:07:00 <mrvn> ilovethinking: run qemu -kernel without grub
17:09:00 <ilovethinking> mrvn: bro i can;t use mb2 w i
17:09:00 <ilovethinking> t
17:15:00 <mrvn> well, you could if I could find my old mb2 patch for qemu.
17:15:00 <mrvn> output text on the serial port
17:16:00 <immibis> doesn't qemu have some debugging ability?
17:16:00 <immibis> set a breakpoint at the start of your kernel? (or what should be the start)
17:20:00 <streaksu> setting up gdb is really easy and really useful indeed
17:21:00 <streaksu> its also a really nice tool to have for a lot of systems programming, be it osdev or not
17:23:00 <mrvn> immibis: qemu has a small internal debugger and supports attaching gdb
18:29:00 <netbsduser> i would have had a stroke by now were it not for GDB
18:29:00 <netbsduser> that or i'd have had to implement my own kernel debugger, i suppose, but GDB does a fine job
18:37:00 <mrvn> netbsduser: have you implemented the gdb stubs in your kernel?
18:38:00 <netbsduser> mrvn: i just use QEMU's builtin facility
18:48:00 <mrvn> netbsduser: with the stubs GDB will see your processes and threads and not just CPU cores. At a certain point that becomes more helpful.
19:57:00 <chibill> Question does anyone have experience working with the APIC? (When booted via UEFI)
19:57:00 <chibill> Been reading the wiki page about them and trying to figure out how to properly set them up from Rust.
19:58:00 <mrvn> All I know is people complaining about parsing the APIC tables
19:59:00 <chibill> You mean the ACPI Tables?
20:00:00 <mrvn> probably.
20:00:00 <chibill> APIC is the basically replacement for the PIC (Used for interrupt stuff)
20:02:00 <chibill> I need to get paging fully setup first I think, since to find the APICs (Local and the IOAPIC) you need to look at an entry in the ACPI Tables and the rust library for that wants you to have a handler. So I am proabably going to need to start dynamically managing me memory.
20:08:00 <Bitweasil> Hm? Aren't the APIC and IOAPIC at rather defined memory addresses during startup?
20:08:00 <Bitweasil> Or does EFI move them?
20:18:00 <chibill> They are at defined addresses but supposedly (according to the Wiki) some UEFI "bioses" may relocate them on you. I will try the default address for now and see what happens.
20:19:00 <Bitweasil> Seems reasonable to me.
20:40:00 <zid> That zip needs a ☣ on it
20:41:00 <zid> I ran a tooled called 'ryzen dram calculator' but it decided to try populate the initial values from my own spd information
20:41:00 <zid> injected a driver into my intel i5 machine and promptly crashed it
21:27:00 <brunothedev> can i acess the multiboot framebuffer struct which was written in assembly from c
21:28:00 <mrvn> I don't know. can you?
21:29:00 <brunothedev> mrvn: i am asking if i can
21:29:00 <mrvn> I'm also pretty sure it was writte in C since qemu doesn't support FB.
21:30:00 <mrvn> Hint: C source it also just turned into asm. So access from C is the same as access from asm.
21:30:00 <brunothedev> mrvn: i am asking, if i can access the framebuffer struct, which i wrote in assembly, from c
21:31:00 <mrvn> and if you made it accessible then you can
21:31:00 <mrvn> for example you need to give it a symbol and make that .global
21:32:00 <mrvn> or define the struct in C and then write to the C symbol from asm
21:38:00 <immibis> brunothedev: you defined a memory layout in assembly and you want the C compiler to know about it without also writing it in C? sorry, not happening. It doesn't understand assembly so you have to write the same thing again in C
21:39:00 <immibis> or you just want to access some memory location? that's fine but again, the compiler doesn't understand your assembly declarations so you have to tell it the same thing but in C
21:59:00 <brunothedev> immibis: a struct
22:06:00 <immibis> i'm not sure what counts as a struct in assembly; if it's the same what a C struct is, then you have to write it again in C
22:08:00 <mrvn> in GAS? Nothing, no such thing.
22:08:00 <mrvn> don't think nasm has it either
22:09:00 <lav> iirc at least one of the two does
22:09:00 <lav> well they're directives
22:09:00 <mrvn> GAS has some convoluted helper macros to compute offsets for struct members.
22:11:00 <lav> nasm has some slightly better structs it seems
22:11:00 <lav> like you can declare one and then instatiate multiple of them in your .data
22:14:00 <klange> brunothedev: you're not making any sense; you are not defining a struct in assembly. The data you are preparing in assembly for multiboot(2) is not something you have any reason to access from C, it is read-only data embedded in your binary that the bootloade reads.
22:14:00 <brunothedev> oh ok
22:16:00 <brunothedev> ok, so should i just create a multiboot_tag_framebuffer and the data is automatically pit on by the bootloader?
22:16:00 <mrvn> if you do it like all the other tags and the other tags work then yes
22:17:00 <mrvn> You can also define the tags in C and make it a lot more readable.
22:17:00 <klange> In multiboot2 there are request tags - read-only data embedded directly in your kernel binary - and response tags - data loaded into memory by the bootloader and whose address is given to you from a pointer passed in %ebx when your program code is jumped to.
22:18:00 <heat> just had a great nap
22:18:00 <heat> 10/10
22:19:00 <bnchs> hi cold
22:20:00 * brunothedev cold: just had an awful work day
22:20:00 * brunothedev cold: 0/10
22:20:00 <heat> I live for some good fucking naps
22:20:00 <heat> straight up better than sleeping normally
22:21:00 <bnchs> heat's evil twin brother cold prefers bad fucking sleeps
22:23:00 * mrvn throws heat and a pizza into the oven.
22:24:00 <brunothedev> so, i will make a "multiboot_tag_framebuffer" on the c code and it will fill with all the data i need, correct?
22:26:00 <immibis> why don't you tell us what you are trying to do
22:26:00 <mrvn> if you mean the response tag then no. the bootloader puts that somewhere else in memory
22:28:00 <brunothedev> immibis: i am trying to get the multiboot framebuffer address so that i can make a console
22:29:00 <immibis> what is a multiboot framebuffer address?
22:29:00 <brunothedev> immibis:
22:29:00 <bslsk05> ​ Osdev-Notes/ at master · dreamos82/Osdev-Notes · GitHub
22:33:00 <mrvn> brunothedev: you have to add the request tag to the array of your other tags and then parse the responce tags looking for the framebuffer info tag
22:36:00 <brunothedev> mrvn: already put a request tag, now idk how to find and parse the responce tags
22:38:00 <immibis> brunothedev: here is the specification for the response tags:
22:38:00 <bslsk05> ​ Multiboot2 Specification version 2.0
22:38:00 <klange> brunothedev: did you read the actual multiboot2 sample code from GNU?
22:38:00 <brunothedev> klange: yes, but it is kind cloudy, specially the ifndef which makes most of the code useless
22:39:00 <klange> What ifndef?
22:39:00 <klange> There are no ifdefs or ifndefs in this code.
22:39:00 <bslsk05> ​ kernel.c\doc - grub.git - GNU GRUB
22:40:00 <brunothedev> the multiboot2.h file, see it up
22:40:00 <klange> Start from here, the entry point of the binary:
22:40:00 <bslsk05> ​ boot.S\doc - grub.git - GNU GRUB
22:41:00 <klange> brunothedev: That's just so that the assembly can include the header to get the #define'd constants. The structs are not used in assembly is not C.
22:41:00 <klange> as assembly is not C*
22:41:00 <brunothedev> who neeeds c# when there is c* /s
22:42:00 <klange> * is a typographic signifier that I am making a correction to my previous statement
22:42:00 <brunothedev> i know, but out of context it is funny
22:43:00 <heat> it's obviously c *, not c*
22:45:00 <brunothedev> because that i always put a space
22:47:00 <immibis> btw brunothedev you understand that header files are just copy-paste, right?
22:47:00 <immibis> when you do #include the compiler just copy-pastes whatever is in that file
22:47:00 <immibis> no magic
22:48:00 <mrvn> C*c;*c={0};
22:48:00 <brunothedev> immibis: #ifndef made a good portion of the file useless for bot.S, so this is why i wondered
22:48:00 <klange> Let's not even see 'compiler' here. The preprocessor does it. Which is why the assembly file can do it - '.S' with a capital S is a hint that the C preprocessor should be run before assembling (this happens automatically if you use the right tools)
22:49:00 <klange> brunothedev: It made a good portion of the file not a massive syntax error for boot.S.
22:49:00 <immibis> brunothedev: other way around. A good portion of the file is useless for bot.S, so they made this #ifndef so you could still get the benefit of the other portion
22:49:00 <immibis> the assembler doesn't understand C; the compiler doesn't understand assembly
22:49:00 <immibis> but preprocessor directives like #define work in both because it's the same preprocessor
22:53:00 <brunothedev> it is funny clangd screaming at me using the main function with a void tyoe and weird arguments
22:56:00 <klange> That's one of the reasons kernel C entry points are usually called something different like "kmain" or "cmain" - "main" has special meaning and the compiler treats it differently.
22:56:00 <heat> should not be so in -ffreestanding
22:56:00 <heat> IMO
22:57:00 <klange> I don't recall off hand if the spec includes that provision or not in freestanding, but it seems compilers don't bother to make the distinction...
22:57:00 <mrvn> in freestanding there is no code that would call main(). You write that yourself so you might as well call a different function.
23:00:00 <heat> it does
23:00:00 <brunothedev> i think linux has a main function
23:00:00 <heat> wrong
23:01:00 <brunothedev> heat: not a normal main though
23:01:00 <klange> I like 'kmain'. It's my own personal main.
23:01:00 <heat> klange, 1) hosted can still define whatever main prototype it wants (implementation defined) 2) "In a freestanding environment (in which C program execution may take place without any benefit of an operating system), the name and type of the function called at program
23:01:00 <heat> startup are implementation-defined. "
23:01:00 <brunothedev> klange: brunothemain is a good idea too!
23:01:00 <heat> i really have like 2 different mains
23:01:00 <brunothedev> i already have a brunothedebot
23:02:00 <heat> wait, 3. boot protocol main, kernel_main, smpboot_main
23:03:00 <brunothedev> the ultiboot spec has reamined the same for how much time? Found a repo hosting the example code on github and the last update was 3 years ago
23:04:00 <mrvn> heat: (2) does not say "main" still has a pre-defined prototype.
23:04:00 <mrvn> does not preclude *
23:04:00 <mrvn> does not negate? How do you formaulate that in english?
23:05:00 <klange> "does not _not_ say main has a pre-defined prototype"?
23:06:00 <mrvn> double negatives are frowned upon
23:06:00 <klange> So am I by my parents, but I'm still here and there's nothing you can do about it.
23:06:00 * mrvn frowns at klange
23:15:00 <mrvn> "I'm not saying that, but I'm also not not saying that."
23:16:00 <mrvn> -- Donna, Suits 8x10
23:16:00 <mrvn> Guess I can't frown at double negatives anymore.
23:31:00 <kof123> all i know is i did the math from a c89 draft, for how many 6 significant char "external identifiers" you get. first "digit" i believe is 26 (A-Z, _ makes 27) other 5 "digits", 37 possibilities (A-Z, _, 0-9). i punch those numbers into my calculator, it makes a happy face </cave johnson>
23:32:00 <kof123> i mean, if you didnt mind nonsensical names and simply add them up, it is still quite a lot
23:33:00 <kof123> if you try to fit abbreviations into them, you are insane even by my standards
23:34:00 <klange> now you may draw to your heart's content
23:34:00 <mrvn> uhoh, he talks in the plural.
23:35:00 <mrvn> Don't listen to the voices in your head.
23:35:00 <klange> You can, perhaps, even start by drawing a heart.
23:36:00 <mrvn> I started by drawing a Moose X-ing sign but transfering a full HD splash screen over serial was annoying.
23:36:00 <brunothedev> so now i am gonna follow
23:36:00 <bslsk05> ​ Drawing In a Linear Framebuffer - OSDev Wiki
23:36:00 <mrvn> brunothedev: first you need a font and text output.
23:37:00 <klange> I suggest spending a few months writing a TrueType parser + rasterizer. /s
23:38:00 <brunothedev> klange: that would rewuire a filesystem, i am ready to port ZFS! /s
23:39:00 <brunothedev> mrvn: how can idraw the font tho
23:40:00 <brunothedev> the 'putchar' function of example function has a goto call, who with a sound mind USES GOTO IN C!!
23:41:00 <FireFly> I think it's reasonably common to use as kind of a "finally" to cleanup before returning as error handling when something goes wrong
23:42:00 <klange> Dijkstra's famouse rant was about a very different 'goto'.
23:44:00 <brunothedev> apparently, the multiboot2 example code uses 0xB8000
23:45:00 <klange> You're looking at the code that writes to text mode memory.
23:45:00 <klange> You want to look at the code here:
23:45:00 <bslsk05> ​ kernel.c\doc - grub.git - GNU GRUB
23:46:00 <klange> And particularly things like this:
23:46:00 <bslsk05> ​ kernel.c\doc - grub.git - GNU GRUB
23:49:00 <heat> klange, bbbbut goto considered harmful don't use gotoo!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
23:49:00 <heat> just duplicate resource destruction everywhere, it's good
23:49:00 * \Test_User makes a macro for goto so it's only one "goto" used :P
23:50:00 <\Test_User> (not actually)
23:50:00 <heat> using goto is like saying voldemort's name
23:50:00 <klange> Everyone knows the best flow construct is comefrom
23:50:00 <mrvn> brunothedev: You have a framebuffer, you need a font with a glyph for every char. Then you create a text buffer for the console depending on the framebuffer size / font size * scrollback and write some code to copy glyphs onto the framebuffer and to scroll it.
23:51:00 <klange> I've written, like, seven of these.
23:51:00 <mrvn> for(int line = 0; _True; line += 10) switch(line) { case 10: ... break; case 20: ... break; ... }
23:52:00 <mrvn> klange: please, comfrom unless (cond)
23:55:00 <heat> comefrom is actually genius
23:56:00 <heat> like goto but you declare who can jump there
23:56:00 <heat> declarative CFI really
23:58:00 <mrvn> heat: it's horrible because it's non local. A comfrom some pages later totally changes your control flow in the code you are reading.
23:58:00 <mrvn> or am I thinking of something else?
23:59:00 <\Test_User> make it require both comefrom and goto?
23:59:00 <brunothedev> do i need a linker script for the multiboot2 eader
23:59:00 <mrvn> brunothedev: yes, like every kernel