<mrvn>
And qemu doesn't support multiboot2 since my patch hasn't been merged (yet).
<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
<mrvn>
klange: i basically copied the muliboot option rom and changed the format.
<brunothedev>
is there ANY multiboot2 implementation on osdev
<mrvn>
grub
<mrvn>
or do you mean kernel?
<klange>
Not on the wiki, but there's lots of references on the forum.
<klange>
And I already linked to mine.
meisaka has joined #osdev
<brunothedev>
klange: oh i missed it
LostCarcosa has joined #osdev
xvanc has quit [Remote host closed the connection]
brunothedev has quit [Quit: WeeChat 3.6]
meisaka has quit [Ping timeout: 248 seconds]
meisaka has joined #osdev
xvanc has joined #osdev
[itchyjunk] has joined #osdev
xvanc has quit [Remote host closed the connection]
LostCarcosa has left #osdev [Leaving]
xvanc has joined #osdev
xvanc has quit [Remote host closed the connection]
xvanc has joined #osdev
xvanc has quit [Remote host closed the connection]
<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
<ThinkT510>
maybe for learning purposes or fun
eroux has quit [Ping timeout: 255 seconds]
<brunothedev>
i have a bios-only computer
<brunothedev>
also, i dont want to become dependant on grub, i want to write my own bootloader later
<brunothedev>
also, i dont know assembly, so is this code correct: "int 0x10\n mov [call], %ax
<brunothedev>
"\n" is for newline
valshaped has quit [Ping timeout: 255 seconds]
slidercrank has joined #osdev
eroux has joined #osdev
valshaped has joined #osdev
<brunothedev>
is it possible to get into real mode in C?
<zid>
No, C doesn't even have a concept of a processor
<zid>
C programs run on an abstract machine
<jjuran>
I have some C code I'd like to run. Where can I get an abstract machine?
<sham1>
At an implementation near you
<zid>
jjuran: compile it
<zid>
from an abstract machine language source file
<jjuran>
YOU WOULDN'T DOWNLOAD A COMPUTER
<zid>
I need to figure out what I am going to do for a cooler
<brunothedev>
ok so i will make 2 assembly functions to load real mode or protected mode, and call then on the c code
eroux has quit [Remote host closed the connection]
<brunothedev>
asm("jmp real-mode");
<gog>
it's not going to be that easy
<theWeaver>
imagine doing osdev and expecting anything to be easy
<theWeaver>
couldn't be me
<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
zxrom has joined #osdev
<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
<nortti>
or, alternatively, leave such things for your bootloader
<zid>
(like vesafb, the thing you said you want to emulate)
<brunothedev>
is that the grub frmaebuffer have little docs tho
<sham1>
They have enough docs
<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
<theWeaver>
¯\_(ツ)_/¯
<theWeaver>
tell it to the page maintainer, who is not me
<zid>
also, it's correct
<zid>
it's the *bare bones* tutorial
<zid>
if you want fonts and graphics, follow a fonts and graphics tutorial
<sham1>
Or better yet, don't follow tutorials, but try different things out and read up on fonts and graphics
<brunothedev>
i declared the multiboot2 header in the assembly file, something tell me to declare it on the c file
<brunothedev>
specially the framebuffer struct
<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)
<bslsk05>
www.gnu.org: Multiboot Specification version 0.6.96
<bslsk05>
www.gnu.org: Multiboot2 Specification version 2.0
<klange>
The spec example kernel even includes framebuffer drawing samples.
<kof123>
CompanionCube: the magic garden explained : the internals of UNIX system V release 4 i think that might be what they are talking about
<klange>
(search for "case MULTIBOOT_TAG_TYPE_FRAMEBUFFER" in the second link)
<brunothedev>
by linking the assembly file, i assume i already have acess to the multiboot2 header, correct?
<klange>
What would linking have to do with having a header? Headers are just textual inclusion.
<brunothedev>
klange: multiboot2 structs
heat has joined #osdev
<brunothedev>
it is the assembly file
<klange>
Oh you mean _that_ header. You were talking about C so I was confused.
<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.
brunothedev has quit [Quit: WeeChat 3.6]
<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.
<klange>
This is all demonstrated in the sample kernel that comes with the multiboot documentation.
<sham1>
Right. I suppose I'll have to replace my slack profile pic with Principal Skinner
<sham1>
Steamed PRs
<netbsduser>
heat: it truly is great
<netbsduser>
i decided to copy their approach to read()/write() also
<netbsduser>
it might be the easiest way to maintain coherence between read()/write() and mmap()
<heat>
naw
<heat>
just map the pages directly man
theboringkid has joined #osdev
<heat>
having a demand fault file mapping scheme in the fucking kernel is just needless complexity
<heat>
I really don't see what they're getting at
<heat>
it will also be slower
<heat>
mmap vs read? mmap, because the read implementation does mmap!
<heat>
will also require a TLB shootdown on SMP systems for every read/write
<nortti>
did svr4 support SMP?
<heat>
i'm fairly sure it did
<heat>
at least its descendents did
<heat>
ok, "SVR4.2MP" did
eddof13 has joined #osdev
theboringkid has quit [Ping timeout: 248 seconds]
gabi-250_ has quit [Remote host closed the connection]
gabi-250_ has joined #osdev
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<netbsduser>
heat: i forgot if SVR4 does it but in NetBSD similar is done through the unified buffer cache framework
<netbsduser>
the kernel keeps an LRU queue of mapped windows into the UBC (which is what mmap() also maps) of a file
gabi-250_ has quit [Ping timeout: 255 seconds]
vdamewood has joined #osdev
xvanc has joined #osdev
xvanc has quit [Ping timeout: 248 seconds]
gabi-250_ has joined #osdev
<zid>
guys how do you install windows 10
Vercas has quit [Remote host closed the connection]
<zid>
Tools I have: Another computer, that can't be powered on at the same time
<zid>
The end.
<sham1>
Why can't it be powered on at the same time
<sham1>
That may give us a hint
<zid>
I'm going to transfer the cooler
<zid>
and power supply
<nortti>
use the microsofot boot media generator to generate one on a usb stick?
<GeDaMo>
Just copy it to a floppy disk and install from that :P
Vercas has joined #osdev
<zid>
GeDaMo: yea that's my problem, my floppy disk is only 1.44MB
<zid>
the w10 iso is like, at least 3MB
<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
<zid>
won't work cus you added a tool
<zid>
I told you the tools I had
<sham1>
Can confirm, |Windows 10 ISO| ≥ 3MiB
<sham1>
Well then you're SOL
<zid>
what about
<zid>
sham1 hosts me a PXE netboot windows 10
<GeDaMo>
Can you move the disk from one machine to another too?
<zid>
GeDaMo: not until my RMA gets back
<zid>
my final solution to the w10 problem: GPT partition RMA'd ssd, put /boot/efi onto it from w10 install image
<zid>
pray the installer can install w10 to itself
<sham1>
Narrator: it cannot
<sham1>
Because I'd wager that in true Windows fashion, it cannot do things like override open files
<bslsk05>
medium.com: Copying Data 2000% Faster With Advanced Vector Extensions | by Josh Weinstein | Medium
<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.
<mjg>
there you go mofer
<mjg>
as we all know, memcpy of 32G at a time is liek lowballing it
<mjg>
also the only non-avx way is to do a one byte loop
<bslsk05>
github.com: automemcpy/x86-64_memcpy_functions.cc at main · google-research/automemcpy · GitHub
xenos1984 has quit [Read error: Connection reset by peer]
<GeDaMo>
Wouldn't it be better to avoid copying that much data in the first place? :|
xenos1984 has joined #osdev
<zid>
splice all the things
<mjg>
GeDaMo: i don't think person has ay need to copy 32G
<mjg>
GeDaMo: i think they just did a heavily misguided benchmark with utter disregard or realities
<mjg>
s/or/of
<mjg>
with basic idea that perf diff of the sort is going to be the same for any size
<mrvn>
sham1: I find (cheap) USB sticks always break or don't work at all. and small ones are dead slow.
<mrvn>
Last 2 times I bought an USB M2.key ssd/nvme adaptor and and nvme.
gxt__ has quit [Ping timeout: 255 seconds]
<kof123>
^ if they are really cheap, fake sizes supposedly (usb sticks)
<kof123>
never saw that myself, but dont really trust any of them
<mrvn>
mjg: that automemcpy code is horrible. Why does every "else" branch have "else if (!cond)"?
<sham1>
Yeah. I like Sandisk because those are fairly reliable
<sham1>
And Kingston
<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.
<mrvn>
And 8GB sticks are like 1MB/s.
<mjg>
mrvn: it is autogenerated
<mjg>
mrvn: they tried to brute force towards the fastest variant
<mrvn>
mjg: I know. but they don't seem to know what "else" means.
<mjg>
lollers are guaranteed to pop up
gxt__ has joined #osdev
<mrvn>
mjg: Are they all of the form "do somethingh for small blocks else CopyRepMovsb"?
<mjg>
no, there is tons of simd
<mrvn>
ahh, not all. Found one that has no CopyRepMovsb in it
<mjg>
thre is a disconnect between this file adn what landed in llvm automemcpy
<mrvn>
I assume "CopyAlignedBlocks<32>()" has simd stuff behind it.
<mrvn>
Which function is the winner?
<mjg>
no idea yet
<mjg>
the data is just csv
<mjg>
42M
<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.
<mrvn>
memcpy_I16_O256_B64_Linf_noopt() for an extreme example.
<heat>
mjg, cern probably copies 32GB all the time man
<mrvn>
heat: you think they have that small a file?
<mjg>
mrvn: it is making a jump table
<mjg>
and it sucks, but it is faster than erms
eddof13 has joined #osdev
<heat>
mjg, btw can I pick your brain on vfs internals not related to path walking
<mjg>
it's all stupid
<mjg>
but sure
<heat>
how do struct buf's fit into the page cache stuff
<heat>
like what's the relation between a vm_page and a struct buf
<mjg>
that i know very little about mate and don't want to handwave
<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
<heat>
I would've thought you do writeback and dirtying in vm objects
<mjg>
most of what you see there is an unfixed mess from late 80s/early 90s
<mjg>
with "modernity" bolten onto it
<mjg>
bolted
<heat>
yay unfixed mess
<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()
<mjg>
grep for LK_KERNPROC to get a taste
<heat>
i suppose you don't know a lot about when pages are locked either?
<heat>
I honestly don't fully understand the need for a per-page lock
<heat>
the SVR4 book mentions locking the page when faulting a page in through IO
<heat>
but that seems silly
<mjg>
pages are locked across i/o but the de facto lock is handrolled
<mjg>
known as "exclusive busy"
<mjg>
this bit i do know because it actively fucks with performance
<heat>
why would they be locked across IO?
<Bitweasil>
kof123, I got a fake 2TB USB storage drive. There are tools to test them fairly well.
<mjg>
prevents others from using the page, e.g. installing it into pmap during a page fault
<mjg>
they can find there is one, but it is "in flux", so they wait for the i/o to clear
bauen1 has quit [Ping timeout: 248 seconds]
<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
<heat>
mjg, so mmap takes a shared lock and IO takes an excl lock?
<heat>
does writeback also take the excl lock?
<mjg>
mmap also takes an excl lock
<heat>
why?
<mjg>
because there is some idiocy where you can "shared busy" a page... and invaldiate it anyway
<heat>
doesn't that just serialize mmap?
<mjg>
erm, that's in fault handling
<mjg>
mmap does not fuck with pages if it can avoid it of course
<mjg>
but yes, the vm does not scale
<heat>
ah yes, right
<mjg>
all mmap ops are serialized for given address space
<mjg>
and fault handling write locks it as well
<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.
<heat>
mjg, wanna know a very funny fact?
<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.
<heat>
the svr4 page struct was a bunch of unsigned ints as flags
<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.
<heat>
or at least that's how they paint it in the actual book
<bslsk05>
os.phil-opp.com: A minimal Multiboot Kernel | Writing an OS in Rust (First Edition)
jjuran_ has joined #osdev
pieguy128 has quit [Ping timeout: 268 seconds]
pieguy128 has joined #osdev
jjuran has quit [Ping timeout: 268 seconds]
jjuran_ is now known as jjuran
<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
<heat>
wdym "into"?
<heat>
do they overlay struct page/vm_page like linux?
<heat>
linux pretty much keeps a linked list of buffer_head's (for each block) on each page
<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
<heat>
i assume freebsd?
<heat>
thats what I was looking into anyway
<netbsduser>
i think that's one of them, and darwin might do the same
<heat>
how else would you map file pages to block numbers?
<heat>
this sounds pretty optimal
streaksu has joined #osdev
<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
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #osdev
<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
<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
<ilovethinking>
heat: any possible clue what could be wrong?
<heat>
ilovethinking, nope
frkzoid has joined #osdev
<mrvn>
ilovethinking: run qemu -kernel without grub
xvanc has joined #osdev
xvanc has quit [Read error: Connection reset by peer]
<ilovethinking>
mrvn: bro i can;t use mb2 w i
<ilovethinking>
t
danilogondolfo has quit [Remote host closed the connection]
<mrvn>
well, you could if I could find my old mb2 patch for qemu.
<mrvn>
output text on the serial port
<immibis>
doesn't qemu have some debugging ability?
<immibis>
set a breakpoint at the start of your kernel? (or what should be the start)
xvanc has joined #osdev
<streaksu>
setting up gdb is really easy and really useful indeed
<streaksu>
its also a really nice tool to have for a lot of systems programming, be it osdev or not
<mrvn>
immibis: qemu has a small internal debugger and supports attaching gdb
ilovethinking has quit [Quit: WeeChat 3.8]
LostCarcosa2 has joined #osdev
LostCarcosa2 has quit [Client Quit]
streaksu has quit [Ping timeout: 256 seconds]
xvanc has quit [Remote host closed the connection]
xenos1984 has quit [Ping timeout: 246 seconds]
xenos1984 has joined #osdev
xvanc has joined #osdev
xvanc has quit [Remote host closed the connection]
xvanc has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
xvanc has quit [Remote host closed the connection]
xvanc has joined #osdev
xvanc has quit [Remote host closed the connection]
xvanc has joined #osdev
xenos1984 has quit [Ping timeout: 246 seconds]
<netbsduser>
i would have had a stroke by now were it not for GDB
<netbsduser>
that or i'd have had to implement my own kernel debugger, i suppose, but GDB does a fine job
xenos1984 has joined #osdev
<mrvn>
netbsduser: have you implemented the gdb stubs in your kernel?
robem has joined #osdev
<netbsduser>
mrvn: i just use QEMU's builtin facility
bnchs has joined #osdev
gog has quit [Quit: Konversation terminated!]
<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.
craigo has quit [Quit: Leaving]
theboringkid has joined #osdev
theboringkid has quit [Client Quit]
terminalpusher has joined #osdev
xvanc has quit [Remote host closed the connection]
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
<chibill>
Question does anyone have experience working with the APIC? (When booted via UEFI)
<chibill>
Been reading the wiki page about them and trying to figure out how to properly set them up from Rust.
<mrvn>
All I know is people complaining about parsing the APIC tables
elastic_dog has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
elastic_dog has joined #osdev
<chibill>
You mean the ACPI Tables?
<mrvn>
probably.
<chibill>
APIC is the basically replacement for the PIC (Used for interrupt stuff)
kpel has joined #osdev
dude12312414 has joined #osdev
<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.
gabi-250_ has quit [Ping timeout: 255 seconds]
dude12312414 has quit [Remote host closed the connection]
kpel has quit [Quit: .]
<Bitweasil>
Hm? Aren't the APIC and IOAPIC at rather defined memory addresses during startup?
<Bitweasil>
Or does EFI move them?
gabi-250_ has joined #osdev
xvanc has joined #osdev
<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.
<Bitweasil>
Seems reasonable to me.
xvanc has quit [Remote host closed the connection]
xvanc has joined #osdev
zid has quit [Read error: Connection reset by peer]
xvanc has quit [Remote host closed the connection]
xvanc has joined #osdev
zid has joined #osdev
<zid>
That zip needs a ☣ on it
<zid>
I ran a tooled called 'ryzen dram calculator' but it decided to try populate the initial values from my own spd information
<zid>
injected a driver into my intel i5 machine and promptly crashed it
SpikeHeron has quit [Quit: WeeChat 3.7.1]
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
SpikeHeron has joined #osdev
xvanc has quit [Remote host closed the connection]
brunothedev has joined #osdev
<brunothedev>
can i acess the multiboot framebuffer struct which was written in assembly from c
<mrvn>
I don't know. can you?
<brunothedev>
mrvn: i am asking if i can
<mrvn>
I'm also pretty sure it was writte in C since qemu doesn't support FB.
<mrvn>
Hint: C source it also just turned into asm. So access from C is the same as access from asm.
<brunothedev>
mrvn: i am asking, if i can access the framebuffer struct, which i wrote in assembly, from c
<mrvn>
and if you made it accessible then you can
<mrvn>
for example you need to give it a symbol and make that .global
<mrvn>
or define the struct in C and then write to the C symbol from asm
xvanc has joined #osdev
<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
<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
tepperson has joined #osdev
<brunothedev>
immibis: a struct
<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
<mrvn>
in GAS? Nothing, no such thing.
<mrvn>
don't think nasm has it either
<lav>
iirc at least one of the two does
<lav>
well they're directives
<mrvn>
GAS has some convoluted helper macros to compute offsets for struct members.
<lav>
nasm has some slightly better structs it seems
<lav>
like you can declare one and then instatiate multiple of them in your .data
<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.
<brunothedev>
oh ok
<brunothedev>
ok, so should i just create a multiboot_tag_framebuffer and the data is automatically pit on by the bootloader?
<mrvn>
if you do it like all the other tags and the other tags work then yes
<mrvn>
You can also define the tags in C and make it a lot more readable.
<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.
<heat>
just had a great nap
<heat>
10/10
<bnchs>
hi cold
* brunothedev
cold: just had an awful work day
* brunothedev
cold: 0/10
<heat>
I live for some good fucking naps
<heat>
straight up better than sleeping normally
<bnchs>
heat's evil twin brother cold prefers bad fucking sleeps
* mrvn
throws heat and a pizza into the oven.
<brunothedev>
so, i will make a "multiboot_tag_framebuffer" on the c code and it will fill with all the data i need, correct?
xvanc has quit [Remote host closed the connection]
<immibis>
why don't you tell us what you are trying to do
<mrvn>
if you mean the response tag then no. the bootloader puts that somewhere else in memory
xvanc has joined #osdev
<brunothedev>
immibis: i am trying to get the multiboot framebuffer address so that i can make a console
xvanc has quit [Remote host closed the connection]
<immibis>
what is a multiboot framebuffer address?
<bslsk05>
github.com: Osdev-Notes/Framebuffer.md at master · dreamos82/Osdev-Notes · GitHub
<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
<brunothedev>
mrvn: already put a request tag, now idk how to find and parse the responce tags
<bslsk05>
git.savannah.gnu.org: boot.S\doc - grub.git - GNU GRUB
gabi-250_ has joined #osdev
<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.
<klange>
as assembly is not C*
xenos1984 has quit [Read error: Connection reset by peer]
<brunothedev>
who neeeds c# when there is c* /s
<klange>
* is a typographic signifier that I am making a correction to my previous statement
<brunothedev>
i know, but out of context it is funny
<heat>
it's obviously c *, not c*
<brunothedev>
because that i always put a space
<immibis>
btw brunothedev you understand that header files are just copy-paste, right?
<immibis>
when you do #include the compiler just copy-pastes whatever is in that file
<immibis>
no magic
<mrvn>
C*c;*c={0};
<brunothedev>
immibis: #ifndef made a good portion of the file useless for bot.S, so this is why i wondered
<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)
<klange>
brunothedev: It made a good portion of the file not a massive syntax error for boot.S.
<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
<immibis>
the assembler doesn't understand C; the compiler doesn't understand assembly
<immibis>
but preprocessor directives like #define work in both because it's the same preprocessor
<brunothedev>
it is funny clangd screaming at me using the main function with a void tyoe and weird arguments
<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.
<heat>
should not be so in -ffreestanding
<heat>
IMO
<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...
<mrvn>
in freestanding there is no code that would call main(). You write that yourself so you might as well call a different function.
<heat>
it does
<brunothedev>
i think linux has a main function
xenos1984 has joined #osdev
<heat>
wrong
<brunothedev>
heat: not a normal main though
<klange>
I like 'kmain'. It's my own personal main.
<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
<heat>
startup are implementation-defined. "
<brunothedev>
klange: brunothemain is a good idea too!
<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
<mrvn>
heat: (2) does not say "main" still has a pre-defined prototype.
<mrvn>
does not preclude *
<mrvn>
does not negate? How do you formaulate that in english?
<klange>
"does not _not_ say main has a pre-defined prototype"?
<mrvn>
double negatives are frowned upon
<klange>
So am I by my parents, but I'm still here and there's nothing you can do about it.
* mrvn
frowns at klange
<mrvn>
"I'm not saying that, but I'm also not not saying that."
<mrvn>
-- Donna, Suits 8x10
<mrvn>
Guess I can't frown at double negatives anymore.
terminalpusher has quit [Remote host closed the connection]
<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>
<kof123>
i mean, if you didnt mind nonsensical names and simply add them up, it is still quite a lot
skipwich has joined #osdev
<kof123>
if you try to fit abbreviations into them, you are insane even by my standards
<brunothedev>
YES WE GOT THE DAMN FRAMEBUFFER ADDRESS
<bslsk05>
git.savannah.gnu.org: kernel.c\doc - grub.git - GNU GRUB
<heat>
klange, bbbbut goto considered harmful don't use gotoo!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
<heat>
just duplicate resource destruction everywhere, it's good
* \Test_User
makes a macro for goto so it's only one "goto" used :P
<\Test_User>
(not actually)
<heat>
using goto is like saying voldemort's name
<klange>
Everyone knows the best flow construct is comefrom
<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.
<klange>
I've written, like, seven of these.
<mrvn>
for(int line = 0; _True; line += 10) switch(line) { case 10: ... break; case 20: ... break; ... }
<mrvn>
klange: please, comfrom unless (cond)
<heat>
comefrom is actually genius
<heat>
like goto but you declare who can jump there
<heat>
declarative CFI really
<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.
<mrvn>
or am I thinking of something else?
<\Test_User>
make it require both comefrom and goto?
<brunothedev>
do i need a linker script for the multiboot2 eader