channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev&y=18&m=9&d=22
12:30:08 <oo_miguel> the pci device structure for the e1000 card should have interrupt pin and interrupt line set to something, right? or is it normal that i see just zeroes there?
12:37:18 <oo_miguel> aah sry , i was reading at the wrong offset :P
02:10:59 <Shockk> is it a bad idea to place the text section of executables on my OS at virtual addr 0?
02:11:30 <zid> yea
02:11:51 <tyler569> for starters, C defines '0' as an invalid pointer
02:11:51 <zid> it means you either can't use 0x00000000 as your null pointer, or your null pointer dereferences don't crash
02:11:58 <Shockk> ah right
02:11:59 <zid> tyler569: not relevent
02:12:13 <zid> 0 is the null pointer constant, but 0x0 does not have to be the null pointer
02:12:39 <zid> if the system's 'null pointer is 0xDEADBEEF then C will actually assign pointers 0xDEADBEEF is you assign a 0 to them
02:12:46 <Shockk> hmm okay so would it be fine setting it to like, the first page above 0?
02:12:51 <Shockk> i.e. 0x1000
02:12:57 <zid> Shockk: go for 2MB imo
02:13:18 <zid> It's a nicer number (most .text sections will be less than 2MB so they will all just look like 0x20034E etc
02:13:28 <zid> and it's the start of an entry not the 2nd entry
02:13:29 <Shockk> oh wait you're right but for a different reason I just remembered, I do a 1:1 mapping of the lower 32MB I think
02:13:50 <Shockk> I forgot why I do that lol
02:14:17 <Mutabah> zid: Eeeh.... actually, if you _Ever_ dereference a pointer of value 0, it's UB
02:14:29 <Mutabah> zid: That said, it's very unlikely, even with this form
02:14:30 <zid> Mutabah: That's.. what?
02:14:35 <Mutabah> 10:11 < zid> tyler569: not relevent
02:14:44 <zid> okay but what are you trying to say
02:14:55 <Mutabah> The compiler can assume that pointers are never zero
02:15:03 <zid> 0 is the null pointer constant from within the language, p = 0; *p is always UB yes
02:15:05 <Mutabah> And if that assumption breaks, strange things can happen
02:15:19 <zid> but the point is that that '0' there in that C source, doesn't have to represent 'all bits 0' in the actual pointer
02:16:13 <tyler569> but it does on every major system, unless he's asking about something super esoteric or using a very strange compiler
02:16:25 <tyler569> which I would hope would have been prefaced in the question
02:16:27 <Shockk> I'm just asking this stuff because I think it's finally time to do a real sbrk or mmap, so I can write my libc's malloc finally
02:16:30 <zid> I was just pointing out that it's nothing to do with C
02:17:05 <Mutabah> Shockk: Linking to 2/4MB as the base for userland programs is the best idea on x86
02:17:17 <Mutabah> (2MB for x86-64, 4 for x86 - it's the first entry in the second PD)
02:17:52 <Shockk> hmm that's true
02:17:52 <Mutabah> That leaves the zero and lower pages as invalid (to help in catching bugs), and makes things nice and aligned without wasting too much space/memory
02:18:20 <zid> putting it at 2GB or whatver sounds fun, gives it lots of 'room' but it limits the amount of congitugous memory you have, so if you only have 4GB of address space that limits you to 2GB arrays
02:18:48 <zid> and 0 is awkward because of null pointer derefs, so that sort of leaves you with 'just below the top' or 'just above the bottom'
02:19:18 <Mutabah> zid: well, in most x86 OSes, the kernel lives at 2/3 GB
02:19:29 <zid> Mutabah: You could put it at 0 if you had .text at 2GB :)
02:19:32 <Shockk> my kernel is at 0xC0000000 (3GB)
02:19:58 <Mutabah> zid: You could... but there's a reason why neary every kernel is "higher half"
02:20:04 <Shockk> in reality I don't need anything close to that amount of space but it doesn't matter right now
02:20:08 <zid> I was going to put 1/2GB there but that looks like half
02:20:13 <zid> so I just chose to say 2GB
02:20:48 <zid> Shockk: Wait until you buy a graphics card with a 1GB memory window ;)
02:21:31 <Shockk> hmm so if I'm trying to understand the basic layout of a process's virtual address space; its text and data could be mapped to a region just above 0, as already mentioned,
02:21:33 <tyler569> the kernel can be at virtual 3G while the gfx card is at physical 3G, that's no problem at all
02:21:50 <zid> yes, but that's not relevent
02:21:53 <Shockk> at some point after this, I would put the heap, which expands upwards, and the stack resides at the top of the non-kernel address space?
02:21:57 <Shockk> (expanding downwards?)
02:22:02 <zid> sounds good
02:22:16 <Shockk> okay great
02:22:17 <zid> That's almost precisely why stacks tend to grow down
02:22:35 <zid> otherwise things all want to run in the same direction and you have to space them very carefully
02:23:40 <zid> and artifically stops you having like, a process that wants 2GB of heap and 1MB of stack, and also a process that wants 1MB of heap and 2GB of stack
02:23:47 <zid> because you have no idea where they will 'meet' in advance
02:24:06 <Shockk> and regarding stack-heap collision, is it wise to set a limit on stack size on a particular process, so that if sbrk or whatever tries to grab that part of memory, the kernel would prevent it from doing so, rather than collisions just being dependent on how much stack space is currently in use?
02:24:16 <Shockk> oh
02:24:24 <Shockk> you kind of talked about this while I was typing it out
02:24:24 <Shockk> lol
02:24:43 <zid> well if your stack or heap grows into the other one, sbrk or mmap will fail because that memory is already mapped
02:25:49 <Shockk> hmm
02:27:23 <Shockk> in terms of the stack, should I generally just be reserving a large enough chunk of the upper address space for the stack, and then if there are page faults within that region, just map them?
02:27:43 <zid> that's perfectly viable yea
02:28:04 <Shockk> then that restricts the available address space for the heap though, I guess
02:28:33 <zid> I wouldn't allow giant stacks without the process asking for one
02:28:38 <Shockk> ah right
02:28:47 <zid> what are the medium sized pages on x86, a meg?
02:28:56 <Shockk> I guess what I'm wondering is how processes should ask for stack space, like I wonder if there's part of POSIX that specifies how to do so
02:29:21 <Shockk> also I forgot how big
02:29:22 <zid> ulimit can set it before the program starts
02:29:34 <Shockk> ahh right
02:29:58 <zid> posix has erm, getrlimit I think?
02:30:21 <zid> and technically processes can just use a heap allocation to grow their own stack if they really want to
02:30:40 <pikhq> And for threads you can set a thread attribute to say what stack size the new thread should use.
02:30:55 <pikhq> (... before creating the thread, obviously)
02:31:15 <Shockk> ahh shit, threads are something I need to think about sometime
02:31:34 <pikhq> Worth having in mind, but there's a lot of higher priorities. :)
02:31:36 <zid> You can ignore threads for a long time
02:31:54 <Shockk> zid: can I wait() a while before I look into them
02:31:54 <Shockk> :D
02:31:55 <zid> people can implement them without your help if they really want them
02:34:16 <Shockk> ah I see it, so a process could call setrlimit for RLIMIT_STACK
02:38:29 <burzos> Does the CPU ask the cache for an entire cache line? Or does it ask the cache for a specific address + # of bytes? Or does it ask the cache for a specific address and the cache returns the cache line containing that address?
02:39:00 <burzos> Then the cache only makes fetches and stores from main memory at the cache line granularity.
02:39:04 <zid> it is the cache :P
02:39:09 <zid> the cache asks memory for cache lines
02:40:02 <zid> The cpu can basically only access cache (as though it were memory), not memory
02:40:50 <burzos> I'm confused about where the unneeded bytes are masked off from the cache line.
02:40:56 <zid> what do you mean, masked off
02:41:01 <zid> what do you mean, unneeeded for that matter
02:41:23 <zid> the cpu sees cache like you imagine seeing memory, it just has bytes in it and maybe you want byte 7 maybe you don't, who cares
02:41:25 <burzos> Well the cache line is 64 bytes, but the program only wants to access 8 bytes at some address. So where do the other 56 bytes get 'removed' from the lookup
02:41:33 <zid> what removal
02:41:40 <zid> that is the width of the register or whatever
02:41:56 <zid> why aren't you asking why the cache asking memory needs to mask off 32GB-64 bytes
02:42:29 <burzos> How does the correct offset into the cache line get into the register?
02:42:38 <zid> the register never contains cache offsets
02:42:53 <zid> it contains a memory address
02:42:57 <zid> the cache is almost entirely transparent
02:43:08 <zid> it just *happens* that the cache's buffers are 64 bytes wide
02:43:44 <zid> to be*
02:44:09 <burzos> If I say `mov rax, [0x08]`; at what point does the processor figure out that it only cares about the second byte in the cache line.
02:44:17 <zid> never, because that's the 8th byte
02:44:22 <burzos> Lol
02:44:27 <zid> through 15th or whatever
02:44:47 <zid> Now imagine a cpu with no cache
02:45:06 <zid> If I say `mov rax, [0x08]`; at what point does the memory controller figure out to discard the other 31.999GB of memory.
02:45:07 <burzos> Ok, when does the processor realize it only cares about bytes 8-15.
02:45:13 <burzos> Hm ok
02:45:27 <zid> it's a silly question, why is anyone 'discarding' anything
02:45:32 <zid> that's just the width of the read that is happening
02:45:43 <burzos> Yeah, but there are two different widths.
02:45:48 <zid> no there aren't?
02:45:50 <burzos> There is the width of the register and the width of the cache line.
02:45:50 <zid> There's like 12
02:46:11 <zid> byte, short, word, dword, qword, 10 byte fpu word, etc
02:46:55 <Mutabah> burzos: In a simple CPU, there's just one memory read size - the bus size. The CPU sets the address and read/write lines, strobes the "memory request" line, waits a bit, then reads the state of the data bus
02:46:55 <burzos> Ok, sure. But my question is how does the second width distinguishing happen. So the cache has the right cache line, but the instruction only wants some subset of the data.
02:46:56 <tyler569> burzos: to get an answer more detailed than "it just happens" you'd need to talk to intel hw engineers, becaue that will be implemented somewhere in the wires between the cache and the registers
02:46:58 <zid> burzos: There's also the width of the memory module, 32GB
02:47:07 <zid> why is that not relevent to you
02:47:23 <zid> burzos: Again, replace 'cache' with 'dimm'
02:47:27 <zid> and the answer sounds silly
02:47:31 <zid> so why do you think they are different
02:47:39 <zid> s/answer/question
02:48:32 <burzos> Mutabah: If there is no cache, the FSB connects the cpu to the memory controller? This is the bus size you mean?
02:49:14 <zid> burzos: Imagine a system with 4096 byte cache lines, you can implement it just as (cache_no[addr>>12])[addr&0xFFF];
02:49:37 <zid> burzos: Imagine a system with 4096 byte memory dimms, you can implement it just as (dimm_no[addr>>12])[addr&0xFFF];
02:49:52 <zid> why is the memory controller allowed to do the latter, but your cache system not allowed to do the former
02:50:27 <Mutabah> burzos: Kinda...
02:50:48 <Mutabah> burzos: So - Logically (I don't know/care how it actually happens)
02:50:59 <burzos> zid: You don't like my question because I'm not also asking anothe question?
02:51:28 <Mutabah> burzos: When you do a memory access, the CPU sends a message out on the bus saying "give me the bytes starting at address X" (which would be rounded to some multiple - the bus size)
02:51:41 <zid> burzos: Pretend you told me "I understand that dogs never fall over, because they have four legs, but why don't cats fall over?"
02:51:54 <zid> I'm asking you why you think cats are special
02:51:57 <Mutabah> burzos: Then, when it receives the memory, it masks it down (discarding effectively) to just the data it needed
02:52:16 <zid> You've never questioned that memory controllers are capable of finding the right address and giving you some bytes, why are you asking it about cache
02:54:37 <burzos> zid: Fair enough. I think it's because I understand the cache is doing get/set on the size of the cache line into main memory. But I don't understand what the size of the operation into the cache is.
02:54:48 <zid> the size of the operation you did
02:54:52 <zid> why would do it a smaller one lol
02:55:34 <zid> You could design a chip if you wanted that had 256 input pins, 64 output pins and 8 selector pins for the offset
02:55:55 <zid> bam, you just created a cache lookup chip
02:56:53 <burzos> Ok, then my real question was about data alignment. Are compilers enforcing alignment because the access must be on a single cache line, or for some other reason related to the access size into the cache.
02:57:10 <zid> some cpus aren't capable of straddling cache lines
02:57:15 <zid> or busses, or something
02:57:22 <zid> so they require strict alignment
02:57:37 <burzos> Mutabah: This bus size is equivalent to the strictest alignment?
02:57:40 <zid> because there literaly isnt' a circuit for connecting the top half of one cache line to the bottom half of another or whatever
02:58:16 <burzos> Well, the CPU would have to do two memory accesses and it wouldn't be atomic.
02:58:51 <Mutabah> burzos: Classically yes, but I'd guess that on modern super-scalars the bus size is actually a cache line
02:59:08 <zid> https://cdn.discordapp.com/attachments/417023075348119556/492892563485753355/unknown.png
02:59:12 <zid> I drew you a picture
02:59:29 <burzos> thanks bro
02:59:35 <zid> all you're doing is offsetting which wires are connected to EAX by 2 if you're doing a read that starts at offset 2 within the cache line
03:00:08 <zid> why is there any 'masking' or whatever, you only have 4 input wires, more literally could not be connected at once
03:00:55 <burzos> So if I have a 64 byte struct, then why does the alignment of its members matter internally?
03:01:12 <burzos> As long as the whole struct is aligned on a cache line, the members should be able to have whatever layout
03:01:13 <zid> because C code is suppsoed to work between platforms
03:01:36 <zid> and a LOT of platforms only allow 4 byte reads from addresses ending in 0 4 8 B
03:02:09 <burzos> ok so tl;dr the word size on x86-64 is really 64 bytes, but on most platforms it's still 4 or 8.
03:02:19 <zid> no
03:02:29 <zid> word size doesn't really enter into it
03:02:46 <zid> word size isn't even really a concept that means anything
03:02:57 <burzos> Ok, then the `memory access width`.
03:03:09 <zid> x86 has variable access widths
03:03:13 <zid> and no alignment requirements
03:03:16 <zid> (for the most part)
03:03:28 <burzos> So the maximum access width on x86-64 is 64 bytes?
03:03:35 <zid> I think it might be higher
03:03:38 <zid> avx-512 etc
03:03:54 <burzos> Ok, the maximum access width on a platform will be atleast the size of its cache line.
03:04:14 <zid> no?
03:04:18 <zid> avx-512 can fill 2 at once
03:04:38 <burzos> Right, which is greater than the cache line.
03:04:42 <zid> there's no maximum or minimum or whatever, it's just whatever you can be bothered to design and spend the silicon on
03:05:41 <zid> I could trivially make a cpu with 1MB cache lines, 8bit memory bus
03:05:44 <bcos_> Erm. AVX-512 = 512-bits = 64 bytes = 1 cache line (unless its misaligned?)
03:05:48 <zid> and 2MB registers
03:05:52 <zid> oh right, counting is hard
03:06:51 <bcos_> Allowing things to be spread over multiple cache lines is ugly (gets hard for cache coherency, etc), so (even though silicon can and does support it) it's "discouraged"
03:07:07 <zid> most people just say "fuck you"
03:07:24 <burzos> bcos_: But alignment within a cache line does not matter?
03:07:29 <zid> for 6502 16 bit reads that straddle xx00 regions incur an extra cycle
03:08:24 <zid> z80 doesn't give a flying fuck, arm7tdmi won't even let you read from addresses that aren't even and doesn't have an 8bit read at all, etc
03:08:33 <zid> it's literally just what you want to spend silicon doing
03:23:10 <_mjg> real men develop in production
03:29:16 <johnjay> someone posted an example before about maximum align width or something before
03:29:21 <johnjay> causing a 32-bit -> 64 bit bug
03:30:06 <johnjay> basically they were mallocing something and then returning a pointer that was misaligned
03:30:15 <johnjay> because char * wasn't the same as the align or something
06:27:59 <johnjay> rain1: did you find out about the uefi thing? is it in grub?
07:27:06 <burzos> Why shouldn't I use shared memory to implement my system calls. Each thread shares a page with the kernel, and condition variables signal when a request or response is ready.
07:27:34 <Mutabah> That would require the kernel to be actively watching the buffer...
07:28:01 <Mutabah> or do you mean populating a list/queue of syscalls, then tellign the kernel to go attack them (with a software interrupt/syscall instruction)
07:28:51 <burzos> It has to actively watch because I can't trigger a wakeup mechanism from userspace without a syscall?
07:29:15 <Mutabah> Well, yeah...
07:29:22 <zid> I mean, syscalls already sort of work on a shared memory principle
07:29:42 <zid> the userland has the syscall code mapped into it by the kernel, and there's a special opcode to run those shared pieces of code with higher privledges
07:29:56 <Mutabah> Syscalls are how you tell the kernel to do something, you hand conrol over to it and it goes and does something (while the user thread is 'suspended')
07:30:36 <Mutabah> (sycalls are "System Calls" - it's just like calling a function, except there's a switch to kernel mode and a fixed entrypoint)
07:30:36 <zid> Mutabah: I always prefered the view that you become the kernel temporarily and execute carefully constructed code that doesn't let you be naughty despite you running ring0 :D
07:30:45 <Mutabah> zid: That works
07:31:16 <burzos> Yeah makes sense.
07:32:05 <zid> I should boot my vmware back up after I rebooted, I added interrupts to my thing, I should actually write a page fault handler and stuff
07:32:39 * zid picks the lazier option and does nothing
07:33:44 <burzos> zid: What unique stuff do you want to do with your OS?
07:34:18 <johnjay> zid: idk if it was you or someone else, but they had a good summary of the benefits of using vmware vs vbox vs qemu
07:34:26 <zid> burzos: none
07:34:29 <johnjay> i guess bochs is probably the most accurate to actual x86_64?
07:34:34 <zid> I use bochs to emulate my shit
07:34:37 <zid> but develop in a vmware VM
07:34:52 <burzos> It's unix-clone?
07:35:00 <zid> it's a nothing clone so far
07:35:02 <johnjay> like everytime you make a change?
07:35:08 <zid> but I doubt it will do anything special
07:35:14 <johnjay> or is it like you do a bunch of stuff, then check it real quick in bochs to see any problem
07:35:22 <zid> It's not like I set out to make an rtos with tetris acceleration or anything
07:35:33 <zid> johnjay: 'make run' launches my OS in bochs, it boots in about half a second
07:35:48 <burzos> Yeah tetris acceleration is hard to get right without quasi-finite left right thrusters.
07:36:04 <graphitemaster> idk why more kernels don't have an async syscall queue / pipe mechanism applications just stuff into
07:36:26 <graphitemaster> seems easier than triggering an explicit syscall/interrupt and having it schedule the application away
07:36:43 <johnjay> burzos: i was very impressed with toaruOS. nice visuals and completely from scratch, nice code layout as well
07:36:55 <zid> My code is such a clusterfuck mess :D
07:36:59 <graphitemaster> let the timer interrupt be the only thing that triggers the kernel
07:37:05 <zid> I have no idea what the structure of anything is going to be when I finish it
07:37:11 <graphitemaster> saves so much complexity in reentrancy
07:37:12 <johnjay> oh when you say develop you mean, you're writing your code *inside* a vmware?
07:37:16 <zid> yes
07:37:18 <zid> I said that
07:37:19 <burzos> johnjay: I watched a couple toaruOS videos, looks nice
07:37:20 <Mutabah> graphitemaster: What about tickless kernels?
07:37:22 <johnjay> ok i was confused
07:37:39 <johnjay> so you're probably running a linux host then or something and a windows guest?
07:38:05 <zid> yes
07:38:08 <graphitemaster> Mutabah, if your kernel doesn't have a timer interrupt then you can only ever be cooperatively scheduled otherwise you could just issue a ton of processes that busy-wait with for(;;)
07:38:21 <graphitemaster> and dead lock the entire OS
07:38:50 <burzos> graphitemaster: Usermode can write to the queue without a context switch? How does the kernel know which process made the request.
07:39:05 <graphitemaster> each process gets its own
07:39:23 <burzos> What stops A from writing to B's?
07:39:24 <graphitemaster> you write to the shared memory, triggers a page fault, kernel knows which belongs to which process
07:39:36 <graphitemaster> the queue is mapped only for that process
07:39:46 <graphitemaster> and the mapping isn't copied on fork
07:39:47 <Mutabah> graphitemaster: Also, wouldn't a timer-only kernel be just as bad as tying task wsitches to the timer
07:40:05 <Mutabah> (something we've been telling newbies NOT to do for years)
07:40:06 <zid> graphitemaster: Sounds crap for anything with if() in it :P
07:40:12 <graphitemaster> how so?
07:40:16 <zid> imagine stat(f); if(!f) open(blah); else open(blah2);
07:40:24 <zid> I have to wait 2 timer ticks for that
07:40:55 <Mutabah> during which you'll be spinning
07:40:56 <graphitemaster> right it would be a heavy triggered timer
07:41:07 <Mutabah> And doing sweet F-A
07:41:16 <graphitemaster> you don't need to spin
07:41:33 <graphitemaster> you write to the queue when there's nothing to do, like a nop
07:41:39 <graphitemaster> which triggers the switch to another process
07:41:52 <graphitemaster> because page faults would also trigger the switch of course
07:42:02 <graphitemaster> so the only things triggering context switches here are pfs and timer interrupts
07:45:19 <Mutabah> Ok, so now you're triggering an exception instead of just doing a simple `syscall` instruction
07:45:39 <Mutabah> Note: Modern CPUs will predict quite nicely through the syscall instruction
07:45:48 <Mutabah> Meanwhile, a page fault is a full pipeline flush
07:46:02 <graphitemaster> the point is the act of writing to the shared memory itself the syscall you want to make (including it's arguments, via copy) will itself cause a page fault
07:46:09 <graphitemaster> which will then be handled by the kernel
07:46:29 <Mutabah> But then why not just use the dedicated syscall instruction?
07:46:34 <graphitemaster> you have no choice in either way, it's not possible to have shared memory without a page fault
07:46:59 <Mutabah> Do it the virtio way - Have a queue and then inform the other side (the kernel in this case) when the head changes
07:49:37 <burzos> Singularity style software isolation avoids privilege escalating just to tell the kernel that a request is ready.
08:05:21 <immibis> graphitemaster: I believe there've been a bunch of proposals for linux to have a "batch issue syscall" syscall to reduce kernel switch overhead
08:05:42 <immibis> graphitemaster: but note that on most systems, a syscall is not the same as a scheduler context switch. Linux syscalls execute in the context of the thread that issued them
08:08:52 <Mutabah> Anyone know of a good video adapter supported by qemu that has a "hardware" cursor
10:35:03 <froggey> Mutabah: virtio-gpu supports a cursor
10:35:03 * Mutabah is away (not here ...)
10:48:16 <Mutabah> Hmm... might be an idea then... *checks if it's supported in 3.0*
10:49:11 <Mutabah> Ooh, it does
10:49:48 <froggey> yeah, and it's a core device feature. no need to test feature bits
12:22:17 <klange> ow
12:23:05 <zid> did you die
12:23:10 <zid> should I open the champagne
12:26:50 <klange> so fun fact, if your ceil() is broken, cairo may trash memory
12:28:36 <zid> That sounds fun
12:32:39 <klange> so i have a Cairo renderer for my compositor... again...
01:29:46 <dennis95> Testing my binutils port. https://imgur.com/a/Gh1SfJJ
01:29:47 <bslsk05> imgur.com: Imgur: The magic of the Internet
01:40:58 <klange> with your own libc? very impressive
01:41:13 <klange> still fighting with some missing stuff with binutils last I checked
01:43:54 <johnjay> klange: did you consult gnu stuff mostly when making toaruOS
01:44:01 <johnjay> or bsd and others as well?
01:44:28 <dennis95> yes, it is using my own libc.
01:45:44 <klange> johnjay: i read barely anything the first time around, but now that I'm hacking up my own libc i've read a lot more manpages
01:46:45 <johnjay> klange: oh right i forgot you used newlib right
01:46:59 * johnjay recalls some custom libc project called musl or something
01:47:47 <klange> musl is a Linux libc
01:47:57 <klange> very lightweight compared to glibc
01:48:14 <klange> good choice if you want to use an existing libc in an OS, though it'll kinda shoehorn you into a linux-like syscall ABI
01:48:42 <johnjay> oh ok. i think somebody in that project was telling me some useful books for numerical stuff for that
01:48:57 <johnjay> i forget, one was something about theory of computation from the 60s
01:49:01 * johnjay can't recall
01:51:19 <booyah> klange: anyway, is there something to improve in linux syscall ABI?
01:52:16 <klange> it's not so much that there may be something to improve, but do you want to necessarily be a Linux clone?
01:55:57 <klange> Cairo, Pixman, and Freetype all back to working states. https://i.imgur.com/0GTsbYT.png
01:56:31 <klange> And as an optional modules, so the whole UI still works just fine without them.
01:56:42 <klange> Probably a good time to start working on getting the package manager back.
01:58:24 <klange> Though the very nice Python one I had was built on gzipped tarballs and JSON manifests...
01:58:43 <klange> Hm, though the installer didn't use the package manifest, just the server manifest...
01:59:07 <klange> gzip+tar would be good things to build. I've been banging my head over implementing DEFLATE for a while, though.
01:59:21 <klange> DEFLATE would be very helpful in my bootloader
02:16:13 <Mutabah> damn, virtio goes whole-ham on PCI features
02:17:40 <Mutabah> (They use PCI capabilities)
02:52:17 <rain1> could anyone help me with UEFI?
02:52:35 <rain1> which binutils and gcc TARGET should I use to build the efi-pe?
02:53:09 <rain1> and how should I turn it into something I can execute in qemu? I have got -boot OVMF-pure-efi.fd
02:56:21 <clever> rain1: https://gist.github.com/edwardw/7587876 this makes use of `x86_64-efi-pe-ld --oformat pei-x86-64 --subsystem 10 -pie -e efi_main` and then generates an ISO that contains the efi/boot/bootx64.efi path
02:56:22 <bslsk05> gist.github.com: Boot to Rust in OS X · GitHub
02:57:19 <rain1> ok, i will try something along these lines
02:57:33 <rain1> using gcc x86_64-pc-linux-gnu and x86_64-efi-pe-ld ld
02:59:42 <rain1> I don't have hdiutil, it seems to be mac only
02:59:47 <rain1> wonder what ill use on linux to do the same t hing
03:00:10 <clever> one min
03:00:30 <clever> rain1: xorriso is one option
03:00:46 <clever> rain1: https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/make-iso9660-image.sh#L57-L62
03:00:48 <bslsk05> github.com: nixpkgs/make-iso9660-image.sh at master · NixOS/nixpkgs · GitHub
03:09:56 <klange> I do... terrible roundabout things.
03:12:17 <klange> I build two EFI loaders, one 32-bit and one 64-bit. I convert them to PE through objcopy with a special target I think is provided by gnu-efi. I wrap that, my kernel, my modules, and my ramdisk into a FAT image. I mark that as an el torito alternate image (primary is the shoddy BIOS CD loader) in an ISO built by xorriso.
03:12:56 <klange> And then things get really interesting because the ISO has also has stub file entries for all the files in the FAT image and I go in and hack up the ISO extents so that it becomes a hybrid/shadow filesystem for the FAT.
03:13:07 <klange> (*FAT must be built with strict 2048-byte sectors for this to work obviously)
04:19:09 <rain1> i can build the efi file but i couldn't figer out the way to make an iso
04:26:19 <klange> I think the tricky bit that the documentation fails to mention is that if you want an EFI EL TORITO image, the payload is a FAT filesystem image - not the EFI loader.
04:33:21 <rain1> ah..
04:33:49 <rain1> i should try making a fat32 image and boot it as usb
05:18:24 <lachlan_s> Is it just me, or is everyone really depressed these days?
05:19:21 <lachlan_s> Seems like everyone hates their life
05:20:42 <FireFly> d-do you have any context?
05:21:48 <lachlan_s> Just talking to my friends and from my own experience.
05:22:20 <lachlan_s> It's mostly among the stem kids I know, so I assume that a lot of people here know what I'm talking about.
05:23:55 <FireFly> Hmm...
06:49:53 * geist yawns
06:49:56 <geist> good morning folks
06:54:08 <drakonis> mornin'
06:55:10 <geist> well, 5 minutes till morning is over, but i got up in time
06:58:23 <zenix_2k2> so a nooby question, i have know that when i make a syscall is meant to change the privilege of user right ? in order to perform stuffs on the hardware but isn't it a bit insecure ? like even normal users can send them
06:58:39 <zenix_2k2> anyway not so sure if the contexts i stated was right so pls correct me if i am wrong
07:01:47 <geist> yes but that's part of the responsibility of the kernel
07:02:06 <geist> it validates that arguments to the syscall user space passes the kernel are valid, and that the user process has the right to do what it's asking
07:02:23 <geist> ie, disallow opening a file that the user doesn't have permission for, that sort of thing
10:09:51 <oo_miguel> I am trying to create my first simple e1000 driver. Is it correct that I can talk to the device with i/o or through mapped memory ALTERNATIVELY? or do I need to utilize both?
10:32:58 <VegetableLasagna> oo_miguel, as far as I can tell from the wiki, you need to check the PCI configuration space. But, in all fairness, you probably won't run into systems where you need to use the I/O address space.
10:34:02 <VegetableLasagna> See https://wiki.osdev.org/Intel_Ethernet_i217#How_the_Gears_Move_.28Class_methods_implementation.29
10:34:03 <bslsk05> wiki.osdev.org: Intel Ethernet i217 - OSDev Wiki
10:34:37 <VegetableLasagna> The constructor below looks at BAR0.
10:34:51 <VegetableLasagna> bar_type = pciConfigHeader->getPCIBarType(0);
10:35:33 <oo_miguel> yeah I am trying to follow this. I just was not sure if there are any situations where I will need both (i/o AND memory mapped access)
10:36:02 <oo_miguel> since I now concenterated on the memory mapped part, which is what qemu seems to offer according to its bar0
10:53:23 <geist> VegetableLasagna: sadly no. some devices still need IO
10:53:29 <geist> even pretty modern stuff
10:53:45 <geist> but mostly no. but be prepared to deal with both io and mmio at the same time
10:59:15 <geist> interestingly enough for emulators, it's a little bit easier to trap and handle io accesses than mmio
10:59:44 <geist> so that's why you'll see for example by default the virtio 'kick' register to start processing on a ring is an IO access
10:59:55 <geist> even if everything else is mmio in the device
11:10:31 <Shockk> so I put my OS onto bare metal today finally
11:10:35 <Shockk> https://www.youtube.com/watch?v=Q4WR5-lPx0w
11:10:36 <bslsk05> 'shkOS on real hardware' by Shockk (00:00:27)
11:16:50 <johnjay> Shockk: the long awaited day has arrived
11:17:00 <johnjay> \o\
11:17:05 <johnjay> /o/
11:17:35 <geist> grats!
11:17:54 <geist> oh look at those chibi coke cans
11:18:21 <Shockk> lol
11:26:09 <johnjay> heh someone in another channel showed me that. it's a cheering smiley
11:42:36 <Shockk> quick question
11:43:05 <Shockk> if I put an mbr onto an image, and place an ext2 partition beginning at sector 2048 on the drive, for example,
11:43:25 <Shockk> are the contents of sectors 2 to 2047 defined?
11:44:25 <Mutabah> depends on how you create the image
11:45:16 <Shockk> just using fdisk to write the partition table, and then mkfs.ext2 -F on the image