xenos1984 has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
blockhead has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
zid` has joined #osdev
zid has quit [Ping timeout: 256 seconds]
ThinkT510 has quit [Ping timeout: 240 seconds]
ThinkT510 has joined #osdev
<jason1234>
geist: so basically this is one of the only kernel that does m68k + arm + i386,... with low memory system. freedos with bios console is only x86. well, it would seems. is that right? congratulcations anyhow.
<jason1234>
geist: it would be only system to run on all my machines, atari st, 220 cs toshiba, and modern PCS, notebook and ryzen 3
<jason1234>
or capable at least. very versatile. More OS similar are welcome.
<jason1234>
+ too : memdisk+grub but as well qemu with -curses, since it seems to use the bios console (old ibm) and allow keys like ctrl+alt+supp to reboot.
<jason1234>
netbsd was the only one maybe, universal. but they had to drop the low mem machines. and there is no support for atari/amiga... due to cpu.
ElectronApps has joined #osdev
k8yun has joined #osdev
k8yun has quit [Remote host closed the connection]
k8yun has joined #osdev
nyah has quit [Quit: leaving]
Lugar has quit [Quit: Bye]
<geist>
yah that and possibly netbsd
<geist>
ah yeah you just said that
<geist>
yah probably because they're using mmuless
<geist>
not you got me interested in getting an amiga
* gog
appears
<gog>
yo soy tu amiga
<gog>
y una buena amiga entonces
gog has quit [Quit: byee]
<geist>
bye gog!
<klange>
but it was too late; gog was already gone
<bslsk05>
www.reuters.com: SoftBank's sale of Arm to Nvidia collapses, Arm to IPO - source | Reuters
nostalgia has quit [Remote host closed the connection]
<geist>
huh interesting
<geist>
not surprised it fell through since some time ago, but the IPO is interesting
<gorgonical>
I was mostly worried about nvidia/arm because nvidia is shaping up to join FAANG in using microsoft's playbook: just acquire everything and delete the competition
<gorgonical>
I can say that there has been a lot of nervous talk in the HPC academia I know about nvidia probably crushing arm as an interesting alternative to x86 and some labs are aggressively pursuing risc-v as a fallback
<gorgonical>
So this news is... better?
* Griwes
is first-hand experiencing the pain of not being allowed to participate in discussions on a certain topic
<gorgonical>
We have an interloper in our midst!
<moon-child>
Griwes: :/
<geist>
yah i'm sure nvidia are mostly good people, but damn if they didn't treat us like shit the last time i had to deal with em professionally
<geist>
they were super dicks
<geist>
and a bit of that can really ruin the whole image of the company
<geist>
but, that was over 10 years ago, etc etc
<geist>
and they are responsible for embedding LK into various products. so yay!
dh` has quit [Ping timeout: 265 seconds]
k8yun_ has quit [Read error: Connection reset by peer]
<Griwes>
mkay, I now "only" need to write the code generation part of this tool for my syscall definition DSL and I'll be able to go back to writing kernel code (...I will then at some point need to come back to the tool and add "module" support to it, but hopefully that should be easy because I've been writing the code with it in mind from the start)
<Griwes>
hmm, no, before going back to writing kernel code I'll need to integrate this into the build system
<Griwes>
shouldn't be too bad, I'll just need to start spewing out a make deps file too
<klange>
Every time I see headlines about financial dealings of SoftBank I feel the urge to note they are a cell service provider, but over the last five years they've really made their name actually make sense.
<klange>
Still not a bank in the usual sense, though... but they are more of a corporate holding company now, so *shrug*
<Griwes>
yeah I had to scratch my head every time I heard their name back when I was working at Nokia around BTS software
<klange>
ARM is still a UK company, even with SoftBank ownership, and the it seemed like the nvidia deal was majorly blocked by the UK authorities.
<Griwes>
"why is a company called SoftBank buying out cell tower solutions"
<Griwes>
s/out/our/
* klange
's current cell service is through SoftBank... via an MVNO service from LINE.
<bslsk05>
elektron.sigsegv.ch: Centralizing Resource Cleanup Paths in C
<zid`>
That does infact, look shit
<kingoffrance>
.....every one of thoes ideas looks kind of terrible, its a question which is least terrible. quote The set of parameters of driver_init_or_shutdown needs to be the union of the set of parameters of both _init and _shutdown and the return types need to be made compatible somehow.
<kingoffrance>
if nothing else looks like trying to cram a design into things that werent designed that way
<moon-child>
actually I have toyed with the idea of making serialization and deserialization code the same, with a flag to control which you do
<moon-child>
buut
<zid`>
boots go on your feet
<kingoffrance>
i would argue its not really centralized except superficiallydestroy_c(data->c); unregister_b(); release_a(data->a);
<kingoffrance>
i dont have a good answer, but someday i will mess around with pragma
* kingoffrance
holds on butt waiting for moon-child explanation
<kingoffrance>
*onto
<zid`>
moon-child wanna pick the silly method I use to boot my kernel?
<kingoffrance>
the thing is, "the standard way of doing this" some people do not like, and havent seen an answer except "dont use c"
<kingoffrance>
i mean, relatively, doesnt seem like anyone cares
sprock has quit [Quit: brb]
<moon-child>
zid`: start with uefi
<moon-child>
then springboard back to real mode
<moon-child>
get back to long mode
sprock has joined #osdev
<moon-child>
and then run the bootloader again in your realmode emulator
<zid`>
no uefi sadly I don't have the tools
<zid`>
'sadly'
<zid`>
I have -kernel booting a 32bit jmp $ atm, and 64bit jmp $ binary still on my machine.
<zid`>
Silly options include -device file=64bit.bin,addr=0x200000
<moon-child>
can't you get the tools tho
<zid`>
catting the two elves together
<moon-child>
like it's not that hard
<zid`>
linking them together
<zid`>
shhh
<moon-child>
also tcc cross-compiler takes like 5s to build
ElectronApps has joined #osdev
<zid`>
tcc doesn't include libeufi.so does it
<zid`>
wait stop trying to send me down this path you evil man
<moon-child>
wtf is a libuefi.so
<moon-child>
you don't link with anything
<zid`>
the thing you link against for all the uefi symbols?
<moon-child>
that's the clever bit
<moon-child>
no there are no symbols
<moon-child>
you get handed a pointer
<moon-child>
to a struct
<moon-child>
of function pointers
<moon-child>
so, you need to know the layout of that struct, and the layout of the things that the function pointers accept
<moon-child>
but there aren't actually any symbols
<zid`>
ah so I'd just need headers
<zid`>
don't have those either, phew
<zid`>
dodged
<moon-child>
just steal from gnu efi
<moon-child>
(public domain, despite the name)
<zid`>
why do you hate me so much? :(
* zid`
sulks
<moon-child>
it's your own fault for being so damn cute
<zid`>
pick something reaaasonable, that a sane person might doo
<klange>
I've got an EFI loader if you want a reference. It's not too terrible.
<zid`>
damnit now you've got klange doing it
<zid`>
where's that company that mails people glitter
<klange>
They don't ship to Japan.
<zid`>
moon-child's getting it
<moon-child>
pretty sure they don't ship to canada either
doppler has quit [Ping timeout: 240 seconds]
ekathva has joined #osdev
ekathva has quit [Remote host closed the connection]
<kingoffrance>
post any more links like that you have moon-child because i will have to deal with that some day
<moon-child>
wait links like what
<moon-child>
glitter supply?
<moon-child>
uefi?
<kingoffrance>
the terrible cleanup code
<moon-child>
oh
<kingoffrance>
i havent seen any good answers except "dont use c" :)
<moon-child>
hmm
<moon-child>
__attribute__((cleanup)) is good
<moon-child>
custom allocators + shadow stack can work
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
<zid`>
hmm embedding one into the other slightly more complicated than I was expecting because of the mixed ELFs
<zid`>
i386:x86-64 architecture of input file `kernel.bin' is incompatible with i386 output
<zid`>
Just shove it in a section you big meanie
<Mutabah>
You need to force the format type to `binary`
<zid`>
yea I guess
dh` has joined #osdev
<zid`>
I think I will just install grub it's easier than this :p
<klange>
I highly recommend not investing too much time into bootloaders.
<zid`>
fuck bootloaders indeed
<zid`>
but nobody actually supports 'normal desktop cpus' as a bootable architecture
doppler has joined #osdev
<Griwes>
generation of user headers and the vdso code done, next up will be the hard part, i.e. generation of the kernel code that does common checks on input and output parameters, but that's for tomorrow
<Griwes>
this is very pleasantly much simpler than anything that attempts to be a real compiler
bauen1 has quit [Ping timeout: 256 seconds]
zaquest has quit [Remote host closed the connection]
<zid`>
yea I got a cd booting again and my shit all loaded, took a total of 5 minutes and it wasn't 30 seconds because I refused to copy paste the mkisofs command
<zid`>
and I looked things up
zaquest has joined #osdev
GeDaMo has joined #osdev
gog has quit [Quit: byee]
gog has joined #osdev
<gog>
zid`: libefi.so is only if you want the library functions
<zid`>
oh gog is alive
<zid`>
I'm trying to do a singular makefile to torture myself atm
<zid`>
rather than one for boot and one for kernel
<moon-child>
what library functions?
<gog>
gnu-efi
<moon-child>
oh
<zid`>
how do I build these .o files differently
<moon-child>
why bother?
<zid`>
%.o : %.c isn't going to cut it
<zid`>
oh does.. dir1/%.o : dir1/%.c work
<moon-child>
anyway just do o/boot/%.o: boot/%.c; o/src/%.o: src/%.c
<moon-child>
yeah
<moon-child>
i didn't bother. Though I did in my audio lib where I was building a bunch of decoding libs and wanted to pass different cflags to all of them
<gog>
i need to probably re-do my build setup but it works and i'm scared to change it
<geist>
yay internet came back
<geist>
was out for 3 or 4 hours
<gog>
yay
* gog
slices a bagel for geist
<kazinsal>
mmm, bagels
<nur>
did you make any progress on writing the next great american novel
<gog>
the codes of wrath
<geist>
no but i cut up some cardboard boxes
<gog>
mine eyes have seen the glory of the coming of the code/it is merging all the branches where the repos have been stored?
<gog>
the battle hym of the programmer!
<gog>
sorry i'm not well today
<zid`>
I think I am worse I tried to read that as hymen
<gog>
and the argument about whether it's random is a technical one rather than a logical one
<zid>
I wonder if there's a better plan than just.. copying basically everything up from 0-1MB
<zid>
I guess maybe C000-C7FFF might do, that's the vga bios region
<zid>
and then do the bios region on top if it isn't happy enough
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<zid>
I may just cheat and use a +x page mapping over these
the_lanetly_052_ has joined #osdev
dennis95 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
vdamewood has joined #osdev
lkurusa has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 240 seconds]
k8yun_ has quit [Quit: Leaving]
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
dude12312414 has joined #osdev
air has joined #osdev
<gog>
brb writing bytecode to zid's framebuffer
dude12312414 has quit [Ping timeout: 276 seconds]
dude12312414 has joined #osdev
<zid>
I mean, I did nop sled into my framebuffer earlier
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #osdev
<nature>
zid: Sorry I didn't see your mention earlier, I managed to get where I wanted to by getting the different resolution, now I am back at reading some assembly source of colorforth to try to understand it better
<zid>
sounds gross
<zid>
but what did you settle on ultimately?
<nature>
Settle about what? (I am embarrased my memory is failing me)
<nature>
I basically used the "hack" by defining the "structures" I needed on disk with db, dw, dd etc.. after the first 512 bytes and then I did a mov for the "VBE2" signature
<GeDaMo>
Part of the reason Colorforth uses colour and very large characters is because of Charles Moore's failing eyesight
<dmh>
i love colorforth
<zid>
we were talking about how you were going to organize memory for your buffer
<zid>
and set up your segmentation
<nature>
I basically kept things as simple as possible and kept es at 0
<zid>
I'd say es = 7e0 is actually simplest but same shit
<gorgonical>
Speaking of forth: I've had a dream for a long time to re-invent the world by writing a forth in assembly, then a lisp in forth, then a c compiler in lisp, then an os, etc.
<nature>
I just felt it easier to reason about when using the labels I defined for my "structures"
<gorgonical>
One of those "If only I had the time (and weren't so lazy)
<j`ey>
gorgonical: you know about Mes right?
<gorgonical>
I don't
<j`ey>
gorgonical: "GNU Mes is a Scheme interpreter and C compiler for bootstrapping the GNU System"
<j`ey>
"The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting."
<bslsk05>
jbangert/trapcc - Computing with traps (45 forks/1062 stargazers/BSD-3-Clause)
<GeDaMo>
"This is a proof by construction that the Intel MMU's fault handling mechanism is Turing complete."
<nanovad>
Ah, I've seen that. cursed
<gorgonical>
Does this rely on somehow what is put into the stack frame on page fault? By abusing the access addresses?
<gorgonical>
I.e. by carefully specifying your memory addresses you can precisely manipulate what ends up in the stack frame after a page fault occurs?
<Bitweasil>
Something along those lines, yeah.
<Bitweasil>
It's a fun read.
<Bitweasil>
You'd have no problem following it, call it research! :D
<Bitweasil>
It's a creative abuse of a few different corners of x86 MMU/exceptions/etc.