klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
opal has quit [Remote host closed the connection]
opal has joined #osdev
nyah has quit [Ping timeout: 250 seconds]
FreeFull has quit []
gog has quit [Ping timeout: 250 seconds]
CYKS has joined #osdev
[_] has joined #osdev
[itchyjunk] has quit [Ping timeout: 265 seconds]
heat_ has joined #osdev
heat has quit [Ping timeout: 265 seconds]
heat_ is now known as heat
c2a1 has quit [Remote host closed the connection]
freakazoid332 has joined #osdev
<geist> Yah seems like the instructions are pretty important. Reminds me I need to double check the fuchsia implementation is properly detecting the armncrc instructions
<JerOfPanic> m0rn1ng everyone !
<heat> sup
<geist> I'm on a plane. Amazing orc works
<heat> maybe you're hallucinating and this is not real
<geist> Very possible. Some wine has been consumed
<JerOfPanic> I am meaning of life in aging
<JerOfPanic> 42
<geist> Grats it's your birthday?
<JerOfPanic> I have better health because of exercising than I had in 20s when I ate 5 pizza boxes a day
<JerOfPanic> pizza power helps to code
<JerOfPanic> Jesus Christ my search engine is putting HTML tags, like 100 gigabytes of them, in a database
<JerOfPanic> 130 pages
<geist> That's been my experience the last few years too. As a rusult of covid I stopped eating out and started eating less and better
<JerOfPanic> remove tags, cut strings, will help
<geist> And lost weight and overall much better health
<heat> oh I had the opposite experience
<heat> uber eats became the lazy food option
<geist> Many people do
<geist> Yah moving to the woods probably helped because there's no Uber eats
<heat> new UEFI spec, now in HTML \o/ https://uefi.org/specs/UEFI/2.10/index.html
<bslsk05> ​uefi.org: UEFI Specification 2.10 — UEFI Specification 2.10 documentation
<geist> I don't really eat better per se but I eat a lot less and it turns out I just don't need that much food.
<geist> Ooh
<kazinsal> I'm rapidly approaching that point where I'm realizing I need to start waking up early and going to bed before the date rolls over...
<geist> Like regular people hours?
<geist> Never!
<heat> >looks at the time
<heat> >03:13
<heat> damn right
[_] has quit [Remote host closed the connection]
<heat> so I got bored tonight so I aggregated my useful low-levelish bookmarks into a gist: https://gist.github.com/heatd/1b722c84395b7e6d0d353ca04679ac2a
<bslsk05> ​gist.github.com: Pedro's great link collection · GitHub
<heat> this may be useful to someone, hopefully
Matt|home has quit [Quit: Leaving]
<geist> Nice I'll have to take a look in a bit
<klange> heat: oh shit sphinx, who died on the UEFI board that something this useful could be finally be done?
* klange is going to assume the Queen herself demanded the EFI specs continue to be published as a (broken!) PDF.
<heat> klange, :D
<heat> they did it for ACPI earlier last month
<heat> so maybe not the queen
<heat> I'm trying to ping someone so the UEFI PI spec gets published as HTML too
<klange> Must have been Abe, then.
zid has quit [Ping timeout: 265 seconds]
zid` has joined #osdev
zid` has quit [Read error: Connection reset by peer]
zid has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
zid has quit [Read error: Connection reset by peer]
zid has joined #osdev
heat has quit [Ping timeout: 268 seconds]
carbonfiber has quit [Quit: Connection closed for inactivity]
<nur> is anyone attending Linux Plumbers
xenos1984 has quit [Quit: Leaving.]
<geist> Wheres that?
<linkdd> hello there
<linkdd> i'm tinkering with a 64 bits kernel (for x86_64), and i'm having an issue with handling the interruptions. when entering long mode, i set up the paging and the GDT and then perform a long jump to the 64 bits code. so far so good. the I remap the PIC, the IDT and unmask the IRQs and finally enable interruptions. So far so good. The problem is that when I trigger an IRQ (pressing a key for example), my ISR
<linkdd> handler is called, I push some registers on the stack in assembly and then call the C function to handle the interrupt. As soon as that C functions returns, qemu reboots. I'm not even going back to the ISR which would pop the saved registers and then call `iretq`.
<linkdd> What would be the problem? The GDT entries? The IDT entries?
<linkdd> (i had no problem implementing this in 32 bits years ago...)
smach has quit [Ping timeout: 252 seconds]
<Mutabah> A qemu reboot is a triple fault
<Mutabah> so, that means that you've just done soemthing quite invalid and the exception handler couldn't run
<Mutabah> Probably broken the stack pointer somehow
<Mutabah> Check #1. How do you know that the code doesn't reach the iretq?
<linkdd> i debugged step-by-step with gdb, it's literally the `ret` instruction of the C function that triggers the triple fault
<Mutabah> Ok - so that might be popping a bad return address
<Mutabah> e.g. a non-canonical address
<Mutabah> Possible catch you might have missed - most x86_64 ABIs assume an aligned stack (to 16 bytes) - if you don't maintain that alignment in the assembly, then the called C code might do some really unexpected things
<linkdd> https://bpa.st/7PZA the ASM code for the ISR handlers being called
<bslsk05> ​bpa.st: View paste 7PZA
<linkdd> (nasm)
<linkdd> oops bad copy/paste
<bslsk05> ​bpa.st: View paste VMZQ
<linkdd> https://bpa.st/CHQQ the signatures of my isr_handler and irq_handler functions
<bslsk05> ​bpa.st: View paste CHQQ
<geist> Hmm are you disabling red zone?
<geist> A thing you gotta do on x8664
<linkdd> -mno-red-zone in the gcc flags?
<geist> Yes
<linkdd> nope i'm not, gonna try that
<geist> Yeah it manifests itself as exactly what you see. Might not fix I since you might has multiple problems but you gotta do it nevertheless
<linkdd> ok, indeed it seems i have multiple problems
<geist> Not surprising
<geist> It's hard to get right
pieguy128_ has joined #osdev
pieguy128 has quit [Ping timeout: 268 seconds]
<linkdd> https://bpa.st/GOQQ FYI, the value of the iframe structure when entering the irq_handler C function
<bslsk05> ​bpa.st: View paste GOQQ
<geist> Stack alignment is my second guess as I think someone else marooned
<geist> Alas can't look at that right now
<geist> But someone else might be able to
<linkdd> my stack is initialized before i switch to long mode (so while i'm in 32 bits)
<linkdd> with: align 4096
<Mutabah> At the point when you call the function, SP must end with hex 8
<geist> Exactly that
<Mutabah> (i.e. by 8 bytes, one push, off being 16-byte aligned)
<geist> Because the call instruction will realign it
<linkdd> it does end with hex 8
<Mutabah> compare the stack state (SP value, and the value at the top of the stack) between just after the `call` and just before the `ret`?
<geist> Okay so it not making it back from c what are you dojng in c?
<linkdd> Mutabah: hang on
<linkdd> geist: just sending the EndOfInterrupt command to the PIC and printing a message to the screen (it works)
<geist> Are you sure you're not trashing the stack in tlthe print routine?
<geist> Is overflowing a string buffer?
<geist> Ie
<Mutabah> Hmm... that alignment requirement might be a very fun cause of rare corruption in an interruptable amd64 kernel :/
<Mutabah> (IRQ happens just before a `call`, while the stack is unaligned)
<geist> No x8664 realigns in hardwire
<Mutabah> Ah, phew
<geist> Different from 32
<Mutabah> had forgotten that
<geist> Yeah it's some silly detail I think only when doing same ring transitions
<linkdd> so, after the `call irq_handler`, no instruction executed yet, the rsp contains the following value: 0x109f40
<Mutabah> and check the value at that address too
opal has quit [Ping timeout: 258 seconds]
opal has joined #osdev
<geist> So what iid do is stop the emulator just before returning to isr handler
<linkdd> and right before the ret: 0x109f68
<Mutabah> well, not only has that lost alignment, it's also gained a LOT of bytes
<Mutabah> ... unless that's one of those ret-imm instructions?
<geist> Lost actually since it's higher up
<geist> And stack grows down
<Mutabah> Good point
<Mutabah> So it's over-popped somewhere, that's... new
<geist> Looks like something is getting trashed isside your c code
<geist> There's something going on that clearly we're not seeing yet
<linkdd> so maybe my struct interrupt_frame_s is wrong
<geist> Possible so you're printing bad values?
<linkdd> let me check the values in the registers and the values in my struct when i enter the function
<linkdd> the value of rbp in my struct (0) differs from the one in the register
<linkdd> 0x109f60
<linkdd> ah no ok, it's normal, i set rbp to rsp before pushing the other registers
<linkdd> why do i do this?
<geist> So that's odd. Are you sure it doesn't make us past the ret?
<linkdd> yes, as soon as i ask gdb to execute the instruction, qemu reboots
<geist> Okay here's what I'd do. Put an infinite loop just after the call
<geist> I don't trust gdb. See if qemu hits the loop
<linkdd> before the ret? i tried with asm("cli; hlt;") and it did hang (and not reboot)
<geist> Possible gdb just can't trace through the isr routing properly
<geist> After the call. Where the ret is supposed to return to
<linkdd> or you mean in the ASM routine?
<geist> Yes
<linkdd> nope, it reboots anyway
<Mutabah> Pass `-no-reboot -d int -D qemu_int_log.txt` to qemu
<geist> Kay have you tried tracing it with qemu? It has tracing capability. Generates a firehouse but youll see it
<Mutabah> that'll cause it to quit instead of reboot, and write out a trace file of all interrupts (including the three triggers for the triple fault)
<geist> At least see where the ret goes which is provably a good hint
<geist> Ysh
<geist> Next level you can trace with cpu,exec,int
<bslsk05> ​bpa.st: View paste SDUQ
<zid> oh Mutabah got there before me, I was too busy eating to type, wanted to say to disable qemu from rebooting and have -d int up
<zid> now how will I get my comission
<geist> Yah was trying to walk throgh the basics first but think we got there at the same time
<Mutabah> Line 441 - The IP/SP are quite strange
<Mutabah> IP looks like it has string data in it (... "23/99\0") plus some other random bytes
<Mutabah> And SP is far too round
<linkdd> omg
<linkdd> i'm so dumb
<linkdd> char buf[16];
<linkdd> memset(buf, 0, 128);
<linkdd> .........
<linkdd> classic buffer overflow
<linkdd> it works now
<geist> In the print routine?
<linkdd> just before the print routine. in isr_handler (C function) i allocate a char buf[128], but in the irq_handler i changed it to 16 and forgot to update the memset
<geist> Surprised you didn't get a warning for that. Crank the warnings to the top
<linkdd> it's my own implem of memset
<clever> void nvpair_get_string(packed_nvpair_middle *val, char **name) { ... memcpy(*name, val->value.str.value, len); *name[len] = 0;
<geist> Yup that was one of my guesses. Buffer for printing,overrun
<clever> i had my own buffer overflow yesterday
<clever> it was indexing into the wrong pointer in name
<nur> geist, Dublin but also remote
<clever> by pure chance, the string was still null terminated, but it trashed another var on the stack
<geist> Ah
<clever> (*name)[len] = 0; solved it
* Mutabah fights the urge to RESF
<zid> really edible sexy function
<geist> You did good mutabah
<linkdd> ok so now, the iretq returns to the wrong address :P
<linkdd> i'm gonna debug this on my own
<linkdd> thanks people
<bslsk05> ​godbolt.org: Compiler Explorer
<zid> gcc does warn for this some of the time at least..
bauen1 has quit [Ping timeout: 250 seconds]
<zid> You may have needed LTO in order to catch it
<zid> so that it could see into your definition for memset
<geist> Yay grats linkdd
bauen1 has joined #osdev
bradd has quit [Ping timeout: 244 seconds]
bradd has joined #osdev
bauen1 has quit [Ping timeout: 264 seconds]
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
bauen1 has joined #osdev
bauen1 has quit [Ping timeout: 268 seconds]
bauen1 has joined #osdev
junon has quit [Quit: Bridge terminating on SIGTERM]
Irvise_ has quit [Quit: Bridge terminating on SIGTERM]
Killy has quit [Quit: Bridge terminating on SIGTERM]
chibill has quit [Quit: Bridge terminating on SIGTERM]
chibill has joined #osdev
Irvise_ has joined #osdev
Killy has joined #osdev
jack_rabbit has joined #osdev
junon has joined #osdev
nur has quit [Quit: Leaving]
Matt|home has joined #osdev
nur has joined #osdev
m5zs7k has quit [Ping timeout: 248 seconds]
m5zs7k has joined #osdev
netbsduser has joined #osdev
<Matt|home> contentious question : in terms of strictest policies to follow, which kernel written in C is a good example to look at? e.g. "All variables must be written with hungarian notation. all memory allocation must conform to x standards. no more than 2 indents" etc
<klange> I have a pretty strict policy that I don't think anyone is capable of following.
<Matt|home> im looking at coreutils for gnu right now and some of it is pretty inconsistent, so im curious what OS team has the highest standards in general
<Matt|home> klange : no offtopic?
<klange> Ah, no, I'm not complaining about the content of your message.
foudfou has quit [Remote host closed the connection]
<klange> I mean my kernel has a code policy that is... difficult for others ;)
<Matt|home> typing one handed is hard :(
<Matt|home> what is it just curious
foudfou has joined #osdev
<zid> It's rare to see someone admit to typing one handed
<Mutabah> "all code must be written by klange"
<klange> Mutabah got it in one.
<Matt|home> ah
<klange> "all code must be written one-handed" is probably easier ;)
<Matt|home> i know it's really silly to focus on stuff like this
<Matt|home> but look at this for example
<bslsk05> ​github.com: src/cd9660_node.c at master · openbsd/src · GitHub
<Matt|home> lines 62-65 . why the hell are they grouped like that when everything else has whitespace
<Matt|home> why are comments that fit on one line given 3..
<Matt|home> why is the function type one line above the function name
<klange> I think the strictest things you'll find are ones that are enforced by a linter.
<Matt|home> i know it's silly to get caught up in these things. i know. but my OCD/autism/whatever is telling me that if an employer looks at my code in the future they'll think im an idiot for doing it that way -_-
<klange> Function return type on separate line I think was comment so you could search for "^function_name("
<klange> common*
<j`ey> Matt|home: they wont care
<Matt|home> im just tryin to stick with some style/standard for my own code i guess..
<j`ey> thats a lot easier with one person only
<klange> Or a formatter.
<kof123> eh, "when in rome" for "hobby" stuff i am format nazi, but really consistency is #1. for real life/work, i guess im not sure you have a choice :D
<kof123> i consider it more "easier to do large global changes" if things are broken similarly consistently, rather than 100 slightly different twisty passages
<Matt|home> hm. im reading a rather old, old document on writing bug-free code. the problem is.. im really not sure the compilers' optimizers won't just eliminate all the extraneous stuff this article is advocating for
<netbsduser> Matt|home: easy question to answer
<Matt|home> hm?
<netbsduser> the declarations are all different in duration
<j`ey> Matt|home: it will eliminate it if it can prove it isnt needed?
<netbsduser> the global function declaration has its own line, then global variable definitions have another, an external declaration gets another line, and finally a static function gets another line
<Matt|home> ah
bauen1 has quit [Ping timeout: 265 seconds]
<netbsduser> openbsd along with the other BSDs (though macOS seems to defy it a lot) all inherit the most venerable C styling of all and i would suggest them (along with illumos) as a reference for consistency
<Matt|home> https://www.duckware.com/bugfreec/chapter4.html " 4.4.2 What to Use for Data Type Identification " <-- maybe im misunderstanding this. it seems to be advocating for making sure the types you pass to functions are of the correct type. but C lacks reflection. so this guy suggests using some weird class descriptor thing
<bslsk05> ​www.duckware.com: Writing Bug-Free C Code: The Class Methodology
<Matt|home> is that nuts, am i insane or is that nuts, or is this justified
<Matt|home> or am i just bad at coding
<Matt|home> " An object's type identifier is simply a pointer to its class descriptor structure. " .. except if the object isn't addressable yo. this has to be an older document
<Matt|home> ty netbsduser :p
GeDaMo has joined #osdev
tarel2 has joined #osdev
zaquest has quit [Read error: Connection reset by peer]
c2a1 has joined #osdev
maksy has joined #osdev
<maksy> I'm trying to read from a hard drive via bios, but my routine gives an error code 0x0c80. Where can I find what it means?
<Mutabah> What is giving you that error code? (what BIOS call)
<Mutabah> Look up that call in the docs (e.g. RBIL) and see what the error code means
<maksy> 0x13 is the call and AH is set to 0x42
<bslsk05> ​www.ctyme.com: Int 13/AH=42h
vdamewood has joined #osdev
<maksy> I guess it's this one
<Mutabah> So error code 0x0C is "unsupported track or invalid media"
<Mutabah> maybe you specified a bad disk?
<maksy> I have code in MBR that succesfully reads the code in VBR by using the same routine.
<Mutabah> Dang... just saw the ads at the bottom of the RBIL pages... talk about a blast from the past
<maksy> but the code in VBR can't read the kernel from the following tracks
<zid> The joys of writing a 80s bootloader
<Mutabah> maybe clobbered the packet?
<Mutabah> or accidentally clobbered DL
<zid> half the time these issues end up being something like that ^
<maksy> yeah I'll check them
<zid> they do mov ax, 42; mov ax, data; mov es, eax; int 0x10 or whatever
<zid> seen that a *bunch* of times
tarel2 has quit [Quit: Client closed]
<maksy> yeah maybe I should have used multiboot and grub in the first place, but the boot loader is almost working, so I may as well finish it :)
freakazoid332 has quit [Ping timeout: 250 seconds]
<maksy> once I reduce the amount of tracks to 24 the error code disappears
<maksy> which is weird since the size of my kernel is 13k. Doesn't that mean that I should read 26 tracks since one track corresponds to one sector?
MiningMarsh has quit [Ping timeout: 264 seconds]
heat has joined #osdev
AndroUser2 has joined #osdev
<GeDaMo> "almost working, so I may as well finish it" famous last words :P
AndroUser2 has quit [Read error: Connection reset by peer]
c2a1 has quit [Ping timeout: 264 seconds]
AndroUser2 has joined #osdev
<maksy> I was wrong 24 is the right amount:
<maksy> dd if=kernel.bin of=boot.bin bs=512 seek=2 count=26
<maksy> 24+1 records in
<maksy> so something else is broken since the vbr can't jump to the kernel after loading it
<maksy> I see some exceptions occurring but no idea what they mean
zid has quit [Ping timeout: 250 seconds]
<heat> 0xd = GPF
<heat> error code 0x82
[itchyjunk] has joined #osdev
nyah has joined #osdev
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #osdev
zaquest has joined #osdev
tarel2 has joined #osdev
dude12312414 has joined #osdev
MiningMarsh has joined #osdev
xenos1984 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #osdev
dude12312414 has joined #osdev
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #osdev
zid has joined #osdev
<zid> There goes another 2 hours of my life, I found some voodoo at least
<zid> not having a keyboard plugged in dumps me from the uefi splash to the legacy bios splash in order to print "no keyboard detected", and booting from there is much more reliable
skipwich has quit [Client Quit]
skipwich has joined #osdev
tarel2 has quit [Quit: Client closed]
thatcher has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<mjg_> zid: don't forget 'press f1 to continue'
<mjg_> i never tried pluggin one in afterwards
<zid> nah my bios is fancy, no keyboard detected press any key
saltd has quit [Quit: joins libera]
<sbalmos> I'm still looking for that any key. must've been mislabeled.
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
<bslsk05> ​'Wheres The Any Key' by eman4240 (00:01:25)
<linkdd> hey, quick question about the IDT and IRQs, the EndOfInterrupt command should be sent to the PIC at the beginning of the IRQ handler (acknowledging the IRQ even if there is an exception later down the road), or at the end before returning (which would not happen if there was an exception before) ?
<zid> I recommend after
<zid> but ultimately, you have interrupts disabled (i hope) so it shouldn't matter
<linkdd> i should "cli" during the handling of an interrupt? do exceptions like GP Fault or Triple Fault triggers anyway?
<zid> they're already disabled
<zid> iret reenables them
<zid> or you could sti if you're prepared to have your interrupt stack frames.. stack up
<linkdd> ok
<linkdd> so for the keyboard IRQ, i read a byte from the 0x60 port, then i send the EOI command
<zid> the PIC will then be 'allowed' to trigger new keyboard IRQs, but your interrupts will still be disabled so one won't actually fire until after you iret/ti
<zid> iret/sti*
<zid> if you iret without acking, the PIC still thinks you're inside your IRQ handler and never fire one again
<linkdd> yes, my question was more about the difference between acking at the beginning or the end of the handler
<zid> it ultimately doesn't matter, like I said
<mrvn> You need to ack after you cleared the source of the error and before you want to get the next one.
freakazoid332 has joined #osdev
<mrvn> If's an external source like a NIC then you probably have to do something for the NIC to stop keeping the IRQ signal high before you EOI it. Like clear some network buffers and assign new empty buffers to the NIC.
<mrvn> +it
wxwisiasdf has joined #osdev
<wxwisiasdf> hello people i have a small problem - so there is this program called LSD.COM which i am trying to run, however at the second instruction it's modifying ds and making my v86 monitor generate a GPF and go back to 32 bits
<wxwisiasdf> any way to allow programs to arbitrarily control segments without them causing death and destruction?
<wxwisiasdf> do i just disable the gdt? :^)
<mrvn> why doesn't it GPF normally? If you reduce the programms rights then you have to emulate priviledged instructions.
<wxwisiasdf> i am giving it kernel cpl=0
<mrvn> In 16bit code you won't get far with not being able to set DS
<wxwisiasdf> i gave it unlimited rights on cs/ds
<wxwisiasdf> however the gdt is still acting on v86 for some reason
<wxwisiasdf> this LSD.COM program sets cs=ds
<mrvn> You have to find out what the meaning of that is in real 16bit mode and then catch the GPF and emulate that behavior.
<mrvn> or not run LSD.COM
<wxwisiasdf> :^)
AndroUser2 has quit [Read error: Connection reset by peer]
FatAlbert has joined #osdev
<FatAlbert> hello #osdev
<FatAlbert> clever: thanks for the expalantions yesterday about the dynamic linker
AndroUser2 has joined #osdev
xenos1984 has quit [Ping timeout: 268 seconds]
xenos1984 has joined #osdev
wxwisiasdf has quit [Quit: Lost terminal]
Matt|home has quit [Ping timeout: 268 seconds]
<zid> Think I might be 'upgrading' to a 6700k
<zid> 40 -> 16 pci-e lanes, 50 -> 34GB memory, 4.5GHz -> 4.2GHz (but IPC difference about cancels this), 6 cores -> 4 cores
<zid> Not bad for 7 years of improvements intel ;)
<geist> you replaced a server chip with a desktop chip
<zid> What socket is the 8086k I wonder
<FatAlbert> zid: great processor
<FatAlbert> it was my go to processor for overclocking
<FatAlbert> it has been a while since i was cs player
<zid> the correct socket, but they held their value pretty well, £175 is a good price it seems
<zid> Was a weird limited edition cpu
<FatAlbert> i can give it to you for 120$
<FatAlbert> but i tell you upfront ... this cpu was under alot of stress ... but also under proper custom water cooling loop
<FatAlbert> zid: even though you are an asshole sometimes i want us to be on good terms because you are regular at #osdev
Matt|home has joined #osdev
<FatAlbert> zid: i can get down to 100$ but that's it
troseman has quit [Ping timeout: 244 seconds]
<heat> zid, can't get any newer?
<heat> 6th gen is already pretty old
<zid> doesn't really matter, they're all the same crappiness until 12xxx
<heat> I'm willing to bet a currentish-gen mid-range/lower end chip will outperform the 6700k
<zid> or amd
<Ermine> heat: ... and I have 3rd gen
<FatAlbert> and i have ...
<heat> Ermine, fucking ancient
<zid> 6700k isn't good, but it is however, INCREDIBLY cheap
<zid> It's going to be a downgrade to my £12 xeon
<zid> but it's also just sat in a friend's garage doing nothing and he says I can use it
<netbsduser> which zeon out of interest?
<bslsk05> ​en.wikipedia.org: Ivy Bridge (microarchitecture) - Wikipedia
<netbsduser> i have two e5-2670s in my workstation
<heat> what the fuck is this logo
<heat> gives off 90s vibes
<netbsduser> i like it
<netbsduser> modern logos are pure shite anyway
<netbsduser> it's always announced with "this million-dollar design is revolutionary" and you see it and it's just the company logo in a sans-serif font with a particular colour
<heat> and 90s ones were good? come on
<sham1> One doesn't justify the other
<sham1> Modern logos are a hypercorrection
<heat> i like some modern logos
<heat> for instance, intel's
<sham1> Some are fine, yeah
<sham1> Although there are some products that use a serif font for a logo and that's just wrong
* sham1 glares at ExpressVPN
<zid> netbsduser: what stepping?
<heat> at least it's not comic sans
<heat> I see *way too many* serious uses of comic sans when looking at "normal people"'s shit
<zid> I have a C2 that goes up to 44x, and a G0? that is fully unlocked
<sham1> I mean comic sans is just at the point where in the post-irony world it's good again
<zid> we should all switch to matisse EB, for everything
<zid> which if you know what that is, you know, and once you google images it, you will also know, unless you don't know, in which case we can't be friends
<netbsduser> SR0KX which is handy
<netbsduser> some earlier version had a vt-d issue
<zid> That's a C2 stepping I think
<zid> might be different for the v2s I don't know much about them
<zid> I'm not sure how many dual socket server boards will let you try running it at 5GHz though :P
dude12312414 has quit [Read error: Connection reset by peer]
dude12312414 has joined #osdev
wootehfoot has joined #osdev
xenos1984 has quit [Ping timeout: 268 seconds]
xenos1984 has joined #osdev
FreeFull has joined #osdev
gog has joined #osdev
wootehfoot has quit [Read error: Connection reset by peer]
dude12312414 has quit [Ping timeout: 258 seconds]
dude12312414 has joined #osdev
<FatAlbert> zid: and.. you are never again bothering me with being off-topoic :P
<FatAlbert> have a nice day
FreeFull has quit [Ping timeout: 252 seconds]
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
GeDaMo has quit [Quit: Physics -> Chemistry -> Biology -> Intelligence -> ???]
epony has quit [Remote host closed the connection]
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
puck has quit [Excess Flood]
gog has quit [Ping timeout: 265 seconds]
puck has joined #osdev
bauen1 has joined #osdev
epony has joined #osdev
gog has joined #osdev
<linkdd> should a microkernel delegate IRQ handling to user-space processes?
<linkdd> or should it maintain a data structure in kernel space and expose an API for user-space processes?
<Griwes> I mean your cpu-level IRQ handler (the thing that gets invoked when an IRQ is asserted) needs to be mapped always, so I don't think there's really a question unless you're doing a single address space
<heat> agreed
<heat> it would also be impossible to share irqs
<heat> i think a good question is how to implement it efficiently though
<heat> ideally you minimize the number of trips to the kernel
<heat> ioctl(irq_fd, IRQFD_WAIT, NULL) seems obvious, but probably not ideal
<Griwes> ...at that point you're doing polling except you've also used up an IRQ slot lol
<heat> are you?
<heat> polling would involve spinning
<heat> you're not spinning
<ThinkT510> managarm has an interesting approach to microkernel design: https://fosdem.org/2022/schedule/event/agrinten/
<bslsk05> ​fosdem.org: FOSDEM 2022 - Managarm: Design of a pragmatic fully-asynchronous microkernel
<Griwes> oh I read that as one step further than you meant it
<Griwes> yeah my current thinking is that you just bind an IPC primitive that the kernel can cheaply send messages to to an IRQ subscription and then the handler dutifully blocks a thread or two on that IPC primitive
<Griwes> but I'm sure there's an amount of issues with that that I will discover once I start actually writing drivers :P
<heat> I can definitely imagine some sort of protocol where the IRQ handler drops down to userspace and switches threads directly
<linkdd> yeah it could prioritize the process and schedule it immediately
bauen1 has quit [Read error: Connection reset by peer]
<linkdd> my question was more like "where do we draw the line" as in, what is part of the kernel, and what's not. should the keyboard driver (handling IRQ 1) live in the kernel for example?
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<heat> no
<heat> that is not very microkernely
<linkdd> so we do need the cpu-level handler for IRQ 1 to communicate to the user-space process of the keyboard driver
<heat> yes
<Griwes> heat: I've considered a bunch of ways to have the kernel magically enter some userspace routines on events but it has always, and will always, reek of signals to me, and honestly fuck that nonsense
<heat> at the very least you could directly dispatch a thread
<heat> no signals here
<bslsk05> ​www.usenix.org: Transcending POSIX: The End of an Era? | USENIX
<heat> Async. I/O | aio_submit
<heat> 😂😂😂😂😂😂
FreeFull has joined #osdev
opal has quit [Remote host closed the connection]
WinBamStudios has joined #osdev
opal has joined #osdev
FatAlbert has quit [Ping timeout: 250 seconds]
FatAlbert has joined #osdev
FreeFull has quit [Ping timeout: 268 seconds]
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #osdev
FatAlbert has quit [Ping timeout: 268 seconds]
WinBamStudios has quit [Ping timeout: 264 seconds]
AndroUser2 has quit [Ping timeout: 250 seconds]
AndroUser2 has joined #osdev
joe9 has quit [Quit: leaving]
<bslsk05> ​'Unix50 - Unix Today and Tomorrow: The Languages' by Nokia Bell Labs (00:59:32)
joe9 has joined #osdev
joe9 has quit [Remote host closed the connection]
<epony> the end is more about end of "printing" and "subscription" magazines and in person "presentations" for prestige hotels
<klange> Really, those all happened years ag, but of course USENIX is behind on these things...
netbsduser has quit [Remote host closed the connection]
heat has quit [Remote host closed the connection]
heat has joined #osdev