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
<bslsk05> ​github.com: Release ToaruOS v2.1.0 · klange/toaruos · GitHub
<heat> woohoo
<heat> congrats
<sbalmos> nice
epony has joined #osdev
<kof123> one-liners within one-liners, a quine written within and without
_whitelogger has joined #osdev
heat has quit [Ping timeout: 276 seconds]
divine has quit [Remote host closed the connection]
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
gog` has quit [Ping timeout: 240 seconds]
divine has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
vdamewood has joined #osdev
archenoth has quit [Ping timeout: 250 seconds]
bradd has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
bradd has joined #osdev
bradd has quit [Client Quit]
bradd has joined #osdev
bradd has quit [Client Quit]
bradd has joined #osdev
bradd has quit [Client Quit]
bradd has joined #osdev
<jjuran> Why would you tell a program to KILL itself anyway?
<klange> It's just a joke about beginners not knowing how to exit vi(m).
bradd has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
bradd has joined #osdev
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
bgs has joined #osdev
bradd has quit [Remote host closed the connection]
bradd has joined #osdev
bgs has quit [Remote host closed the connection]
bradd has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
bradd has joined #osdev
gorgonical has quit [Ping timeout: 240 seconds]
vdamewood is now known as vdameboo
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
<zid> til linux 5.9 removed tty scrollback
<zid> code was broken so they removed it rather than fixing it
<Mutabah> well, most people use screen/tmux, so probably best to remove it from the kernel
<klange> just run screen/tmux, i guess
<zid> screen doesn't help
<zid> the solution is "use a virtual terminal"
<Mutabah> Well, not for early boot I guess
<sham1> Just look through journald, ez
marshmallow has quit [Ping timeout: 260 seconds]
scoobydoo has quit [Ping timeout: 252 seconds]
scoobydoo has joined #osdev
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
scoobydoo has quit [Ping timeout: 252 seconds]
scoobydoo has joined #osdev
m5zs7k has quit [Ping timeout: 240 seconds]
m5zs7k has joined #osdev
\Test_User has quit [Quit: e]
\Test_User has joined #osdev
archenoth has joined #osdev
epony has quit [Remote host closed the connection]
Ali_A has joined #osdev
epony has joined #osdev
CryptoDavid has joined #osdev
jjuran has quit [Ping timeout: 250 seconds]
jjuran has joined #osdev
jjuran has quit [Remote host closed the connection]
jjuran has joined #osdev
<moon-child> til linux had tty scrollback in the first place
<moon-child> never tried it I guess
<moon-child> shift+pgup?
ZipCPU_ has joined #osdev
ZipCPU has quit [Ping timeout: 250 seconds]
ZipCPU_ is now known as ZipCPU
<kof123> dont recall, *bsd it might be [or was] scroll lock then page up etc. to toggle ...
<kof123> *lock to toggle, then
<kof123> wherever that was, presumably was an "actual usage of scroll lock" <gives award>
<moon-child> oh! Is that what scroll lock is?
<kof123> no idea, but fits the name
<kof123> ctrl-s and ctrl-q of course
<kof123> kind of do similar
lte678 has joined #osdev
<kof123> i think sysrq was "system request" so sometimes (or used in combination) to drop into debugger?
<kof123> again, dont recall where
lte678 has quit [Client Quit]
<kof123> on an old linux system, ctrl-s turns on scroll lock, so presumably does the same
<kof123> (ie hitting scroll lock presumably is same as ctrl-s)
Ali_A has quit [Ping timeout: 244 seconds]
moon-child is now known as Mondenkind
knusbaum has quit [Quit: ZNC 1.8.2 - https://znc.in]
knusbaum has joined #osdev
<sham1> At least on FreeBSD one uses Scroll Lock to enable scrolling
<klange> I opted to just not do a 'kernel console' I have a dumb escape sequence parser to get some color out of debug text occasionally, but otherwise you have your choice of the userspace graphical terminal emulator (which only runs under the compositor, though it _used_ to have a dedicated fullscreen mode), the userspace VGA text mode terminal, or using a serial console.
gog` has joined #osdev
gog` has quit [Read error: Connection reset by peer]
<zid> agetty is life
gog` has joined #osdev
gog` has quit [Client Quit]
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
wgrant has quit [Ping timeout: 260 seconds]
sprock has quit [Ping timeout: 260 seconds]
sprock has joined #osdev
wgrant has joined #osdev
<sham1> I feel that doing terminal emulation completely in userspace is probably the way to go
<sham1> To tie it to the kernel in a subsystem somewhere feels like asking for trouble
Burgundy has joined #osdev
vai has joined #osdev
<zid> yea adding a buffer to agetty seems logical
elastic_dog has quit [Ping timeout: 250 seconds]
elastic_dog has joined #osdev
romzx has quit [Quit: Leaving]
<bslsk05> ​drewdevault.com: Notes from kernel hacking in Hare, part 3: serial driver
romzx has joined #osdev
stux has joined #osdev
<mrvn> zid: I think there are some things you have to tie to the kernel. Like the buffering mode.
<mrvn> that has to at least pass through the kernel to the input device
Burgundy has left #osdev [#osdev]
genpaku has joined #osdev
lte678 has joined #osdev
epony has quit [Ping timeout: 252 seconds]
dutch has quit [Quit: WeeChat 3.7]
epony has joined #osdev
nick64 has joined #osdev
<nick64> Does `virt_to_phys()` work correctly for all kernel addresses in Linux?
<zid> there's a comment with it about its capabilities afaik
<zid> it's one of the very few things in the linux kernel I've looked at, for some reason
<nick64> It says: "It is only valid to use this function on addresses directly mapped or allocated via kmalloc."
<nick64> But I'm not sure if I know what " addresses directly mapped " constitutes
<nick64> If I have a local stack variable, does that count?
<zid> is your stack kmalloc'd?
<zid> (I imagine the answer is yes)
<nick64> How can I verify?
<nick64> It is not "my stack" per se, it is a local variable in a function I mean
<zid> which lives on a stack
<zid> which is yours
<nick64> I mean, it is part of the OS, not something I manually allocated/mapped
<nick64> The stack was there for me to use, basically the question you asked me is what I was asking here in the first place, is the stack mapped using kmalloc or anything like that which supports virt_to_phys?
truepassion has joined #osdev
<truepassion> hi, in armv8a, can we do cache operations like clean, invalidate even if caches are disabled in sctlr?
<nick64> Any idea zid ?
<zid> I said I thought it was
<zid> and you're the only one in a position to make a simple test
<zid> to see if it gives a valid result
lanodan has joined #osdev
spikeheron has joined #osdev
* nick64 What kind of test?
* nick64 zid: what kind of test? I am getting a value when I pass the virt_to_phys(&mystackvar), but what could possibly be a test that confirms if it is physical address?
<nick64> zid: slack cmd-enter habits, please excuse
<zid> well.. it'll be an integer
<zid> smaller than the amount of ram you have
<zid> and it will contain the data you have in your stack
<zid> If you don't care what the physical address *is*, you don't.. care
<zid> if you care, you have a test you can run
<zid> "I need it so I can give it to the DMA controller" -> Give it to the DMA controller and see if it works, etc
<nick64> It'll be an integer: It could be a random number which happens to be an integer
<nick64> smaller than the amount of ram you have: It was, a relatively small, but then it can be pure random
<nick64> and it will contain the data you have in your stack: Ah! But sir, how will I "check" that? There is no way to "inspect" a physical address from the software side right
<zid> yes, map it somewhere
eroux has quit [Ping timeout: 250 seconds]
<zid> if your 0xFFFF80000.. address really points to "b00b"s at 0xBEEF physical, then mapping it literally anywhere else, will *also* gives b00b
<zid> s/gives/give
<nick64> Oh! Yeah that makes sense
<nick64> Let me try that test
<nick64> The test I did and failed was: Put the output of virt_to_phys in a variable, created a light weight virtual device, pass the variable content to the virtual device's PCI register, made the virtual device DMA a marker value to that address, check from the guest kernel whether the virtual address contains the marker value
<nick64> The DMA attempt crashed the whole system
<nick64> I shoudl probably get more familiar with virtualbox debugging
<ddevault> qemu
<nick64> Yeah that's on my todo too
eroux has joined #osdev
GeDaMo has joined #osdev
awita has joined #osdev
<nick64> ```
<nick64> int* new_virtual_address;
<nick64> zid: you meant something like this right?
<nick64> int mystackvar = 0x1337
<nick64> fd = open("/dev/mem", O_RDWR);
<nick64> new_virtual_address = mmap(NULL, 1024, PROT_READ | PROT_WRITE, MAP_SHARED, virt_to_phys(&mystackvar));
<nick64> assert (*new_virtual_address == mystackvar)
<nick64> ```
<nick64> Sorry for the paste, I assumed IRCCloud was supposed to convert to link!
<zid> no because it's buggy in about 4 ways, but otherwise yues
<nick64> 1. missing fd in mmap
<nick64> 2. mmap usage in kernel code
<nick64> 3. ? 4. ?
<mrvn> unaligned address, attempting to map something where a mapping already exists
<mrvn> size not a multiple of pagesize
<zid> pointer aliasing, offset into page
<nick64> "attempting to map something where a mapping already exists" is exactly what zid suggested me to do, is that not possible?
<mrvn> no
<nick64> Well, how else can I verify if the physical address is valid?
<mrvn> you have to map the physical address, not the virtual one
<nick64> Isn't that what I am doing in the code above?
<mrvn> s/not the virtual one/not the file content/
<nick64> The virtual one is put to NULL
<zid> optimization, another thing
<mrvn> actually, you aren't mapping to where somethign exists assuming virt_to_phys isn't the identity function, my mistake
<nick64> Ins't the file offset N same as physical address N?
<mrvn> nick64: as is it's the FDS
<mrvn> FD
<mrvn> try new_virtual_address = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, align(virt_to_phys(&mystackvar), 4096));
<mrvn> zid: how would you avoid pointer aliasing? That's the whole idea of it
<mrvn> nick64: oh and you need to use the offset of the stack variable inside the page to read later
<nick64> Okay, and after I do that, instead of
<nick64> `assert (*new_virtual_address == mystackvar)`
<nick64> `assert (*(new_virtual_address+offby) == mystackvar)`
<nick64> offby = virt_to_phys(&mystackvar) - align(virt_to_phys(&mystackvar))
<nick64> I will have to do
<nick64> Right?
<mrvn> modulo size of pointer messing up your math
<mrvn> size of the pointed to thing
<mrvn> int is 4 byte
<nick64> Oh right, so `assert (*((void*)new_virtual_address+offby) == mystackvar)` ?
<mrvn> and you probably should use volatile pointers to work around the aliasing and check that changing mystackvar also changes the other mapping and it's not just accidentally 0x1337
<mrvn> can't do math on void. use intptr_t
<mrvn> or offby/sizeof(int)
<dminuoso> If on GHC, `__attribute__((__may_alias__))` is the proper way to work around aliasing.
<dminuoso> *GCC even.
<nick64> But offby may not be multiple of sizeof(int) right
<mrvn> dminuoso: are you sure? gcc sees that mystackvar and the mmap result can't be the same in any sane code
<mrvn> nick64: wrong. mystackvar (on most archs) is aligned to the size of int
<nick64> How can that be? The stack could contain misaligned variables right?
<zid> Not if it's a C program
<mrvn> nick64: no, that would violate the alignment requirements
<zid> else how would the code access it in the first place, before you started doing silly things
<nick64> If compiler forces alignment, won't that break many algorithms?
<nick64> That depend on certain datastrucutre member being at certain offset
<mrvn> nick64: you could have an arch where int has size 4 but alignment 2 and then you have a problem. but x86, arm, ppc, ... don't do that
<dminuoso> I dont know of many algorithms that make that assumption, nick64.
<j`ey> nick64: thats a different thing
<mrvn> nick64: it breaks broken code. That's why that code is broken.
<mrvn> nick64: algorithms have to follow the C alignment rules too
<nick64> Okay I just checked, I was partially right but partially wrong
<nick64> The algorithm violates the alignment rules, but it forces compiler to comply
<nick64> Using pragma pack magic
<dminuoso> mrvn: Yes, quite sure. In general volatile pointers are not the ideal way to do incompatible aliasing because they bust a bunch of optimizations along the way.
<mrvn> nick64: that code is 99.99% sure just plain wrong.
<zid> You need to optimization bust here though, he's trying to do int x = 37; if(blah == x)
<mrvn> dminuoso: in this case you might even need memory barriers if the L1 cache is not physically tagged
<zid> which is just.. going to compile to if(blah == 37)
<mrvn> zid: that's ok.
<zid> he's going to *really* struggle not to have it do that, infact
<zid> asm block probably required
<nick64> Oh I will not do this in a single process
<nick64> That shoudl sovle it right?
<mrvn> zid: the problem comes when you then do: x = 23; if (blah == x)
<nick64> Once I know the physical address, I will run a DIFFERENT process to map it to it's virtual
<mrvn> The optimizer then says: 37 != 23 so this is always false
<nick64> Does that make sense?
<mrvn> nick64: you can do that
<mrvn> doesn't realy change anything
<nick64> Okay, I dont think I understood the volatile issue here
<mrvn> nick64: volatile forces the compiler to always read the value from ram and not assume anything about it. So if you read "blah" multiple times it always gets the latest value.
<dminuoso> mrvn: there is no guarantee that the value is being read from ram from C by itself.
<dminuoso> And Im not sure you get that guarantee from GCC either
<mrvn> dminuoso: volatile guarantees it is read (from ram or caches)
<dminuoso> Yes, *or* caches.
archenoth has quit [Ping timeout: 244 seconds]
<zid> volatile int x = 1337; and a volatile pointer can guarentee it
<mrvn> dminuoso: if your caches aren't physically tagged then you need a memory barrier/flush as well
<nick64> So the compiler "knows" that the mapping I am creating points to the same "mystackvar" and try to optimise it as an opaque predicate if I don't use volatile mrvn ?
<zid> but that's your only way, the rest is just.. knowing how the compiler is going to work
<zid> and cheating
<nick64> *points to the same thing pointed to by mystackvar
<mrvn> nick64: if you don't use volatile the compiler knows they are not the same ram and optimizes accordingly. Too bad it is wrong in this case.
archenoth has joined #osdev
<nick64> What's wrong if compiler thinks they are not the same RAM location?
<mrvn> nick64: then it won't see a change in one var when you write to the other.
<zid> You need it to, infact
<zid> if if thinks they're the same, it's going to optimize out the memory access
<zid> and delete the if()
<mrvn> zid: it never things they are the same. At least I don't believe any compiler is smart enough to understand /dev/mem and virt_to_phys
<mrvn> But "int mystackvar = 0x1337;" might actually never write anything to the stack.
<mrvn> The "&mystackvar" assures it gets allocated stack space. But I'm not sure just calculateing the phys address of it forces the compiler to actually initialize it
<nick64> "At least I don't believe any compiler is smart enough to understand /dev/mem and virt_to_phys" This is what I was thinking too
<nick64> Okay, I should really split my code into kernel and user to not confuse anyone now
<nick64> It was more of pseudo code
<mrvn> nick64: the problem, as I see it, is to force the compiler to actually write values to ram and read them from ram (or cache) using the other pointer. For that you need volatile.
<nick64> If it were two pointers pointing to the same C variable, that I would understand
<mrvn> nick64: in a sense they are
<nick64> But here like you said, the compiler doesn't know they point to the same data. In fact they don't "contain the same virtual" address which is what we mean when we say two pointer pointing to same data
<mrvn> nick64: the problem comes when the compiler (thinks it) knows they aren't pointing to the same var.
<nick64> If they are not, due to non-determinism, they could end up being the same data by chance, so compiler has no groounds to optimise it right?
<nick64> I am not asking the processor if they are same pointer, I am specifically asking if they contain the same data
<nick64> Even two PHYSICALLY separate RAM addresses can contain same data BY PURE CHANCE
<mrvn> nick64: the problem is mmap() is basically UB. You mapping the same physical page a second time screws up all kinds of assumptions.
<mrvn> as for "BY PURE CHANCE". That's why I said you have to write and test multiple values.
<nick64> Ah gotcha, understood, I will use a 128 bit high entroy string
<nick64> Instead of a single integer
<mrvn> no, just keep testing values. The chance it's accidentally right twice is already basically 0.
<mrvn> there would have to be a second process changing the value in the same way as your code or something.
<nick64> If a 128 bit high entropy string happen to be same by chance, we have bigger problems to worry for humanity :P
<mrvn> nick64: you might have just mapped the page the random number generator has it's stack frame in
<zid> You forgot the bias.
<Matt|home> nick64 : is the possibility of that occurring actually non zero? im sure it's small enough that it's irrelevant, but im curious if it's impossible
<zid> 90% of things are 0
<nick64> zid: that's fine, I'll artifically seed a quality 128 bit data
<mrvn> Matt|home: if it where impossible the random number generator wouldn't be optimal. It would never output some values.
<nick64> using var a = <data>
<Matt|home> there was an interesting quote i remember reading about entropy.. it said that no matter how many times you drop a lightbulb to watch it shatter, it will never rearrange itself into it's original shape. i wonder if that's actually true
<nick64> mrvn: if kernel does map the same physical address to two processes, without specifically being asked to do that, that is a kernel bug right?
<mrvn> nick64: that's what happens with every bit of shared code and data
<klange> That depends on your definition of "specifically being asked to do that"
<nick64> Unless I am a root user, I can't create such a shared mapping in the first place I suppose
<mrvn> Matt|home: given the physics of dropping a lightbulb and it shattering that will never happen. Why would the glass ever rebound to get back into the original position?
<nick64> The physical address in picture here is already organically being used as backing for the stack variable in my module, and it is artifically being mapped into my userspace process with root privs, but then if kernel also happens to have shared that for a mapping in a CSPRNG, that is probably a kernel backdoor :P
<Matt|home> dunno. my physics-fu isn't that up to par
<Matt|home> i assume some complex thermodynamics
<mrvn> Matt|home: you would have to have some force acting on the glass to bounce back. And no air resistance.
<nick64> mrvn: Matt|home or a transparent control flow to the SMI handler from the heavens :P
<nick64> But I'm sure Dr. Manhattan wouldn't care for a broken light bulb
<Matt|home> i launched up vs code for a project but im a little excited today to focus. maintenence is supposed to come over to fix some horrifically broken shit
<mrvn> Matt|home: by the way, nothing says entropy can't reverse itself. It's just our experience in the way time flows that it goes mostly one way.
<Matt|home> fun fact: last night i installed debian no less than 8 times trying to figure out why it wouldn't work on my dad's pile of shit desktop
<Matt|home> turns out it was a shitty bug with UEFI and lenovo's piece of shit bios. cms legacy fixed it. it was pretty nostalgic looking at a vga install screen
<mrvn> huh? Default is graphical
<mrvn> can't do chinese on vga
<Matt|home> For whatever reason, when I tried installing with the UEFI installer, lenovo's bios had a very strange bug. It wouldn't let the bootloader files get written to the correct directories, sometimes it would change where they were placed, other times I would get an error or just a splash screen
<Matt|home> It behaved differently every single install
<mrvn> Matt|home: secure boot to the fail
<Matt|home> I really don't know the specifics of what caused it to behave that way (secure boot was off the whole time i made sure of it)
<Matt|home> but i just said fuck it and went with the cms installer
<mrvn> Matt|home: it might have been off but was if off off?
<Matt|home> I have no idea. Apparently UEFI bug issues are common with older lenovo desktops, not sure why.
<mrvn> because they are old from when the uefi was buggy?
<Matt|home> it was from 2015 :p
<klange> I think "bouncing back into the original shape" is feasible absent "original position", but being broken glass it would not hold this form, and it sure ain't gonna spontaneously glass-weld itslef back together.
<Matt|home> in any case, i don't plan on installing another OS on that pile of garbage anytime soon, so a legacy install shouldn't mess with OS system updates right?
<mrvn> klange: or hold the noble gasses inside
<mrvn> klange: to bounce back you need something to bounce back from, like a perfeclty bouncy enclosure
<klange> (Unlike very clean cuts of certain metals, which _can_ just spontaneously weld themselves back together if the exposed surfaces don't oxidize or the oxidization is removed)
<mrvn> klange: see vacuum welding :)
<zid> cold welding is fun, if you have a spaceship
<clever> zid: and then isnt fun, when you get locked outside!
<mrvn> "I'm sorry, Dave, I can't do that"
<zid> moon them until they let you back in
<mrvn> zid: and get freezer burns on your ass?
<Matt|home> my bootloader is for a legacy bios, but then again it's for a legacy cpu from 1986 so....
<Matt|home> i actually haven't messed around with uefi very much im curious about it
<zid> I've still never used it
<Matt|home> all i remember about looking into modern os dev stuff was reading the number of pages on the current intel manual. and going 'nop'. :p
<mrvn> Matt|home: just use iot to load grub and then you don't care if it was BIOS or UEFI
<mrvn> -o
<Matt|home> yeah that was an option i considered just bypassing it altogether, but maaaaan.. it was so frustrating and i wasn't really super familiar with how to do that in linux
<zid> manual's not really gotten much thicker since the pentium pro, except for the instruction ref
<Matt|home> also, half the time the grub installer would just exit with error code 1 and no further info
<Matt|home> so that was fun..
epony has quit [Ping timeout: 252 seconds]
<zid> (there's two manuals in one now though, for the two arches desktop chips now support
<Matt|home> like seriously if you were an average computer user who didn't know how to do anything other than follow basic prompts for an OS install you'd never be able to fix it. your computer would wind up in an unusable state, and you'd either wind up paying someone exhorbitant money to fix it or waste money buying a new one. that's not cool
<zid> bios boot a floppy disk is still my prefered method
<zid> everything else is error prone
epony has joined #osdev
<Matt|home> rofl.. opposite to my experience. i remember the nightmares of slackware floppy install. jfc
<zid> if it did anything at all, the bios part was reliable and perfect
<zid> the rest is a slackware issue
<Matt|home> anyway sorry for the rant, ima head out
heat has joined #osdev
dude12312414 has joined #osdev
Raito_Bezarius has joined #osdev
<heat> fyi stacks are not kmalloc'd
<heat> at least they werent
Raito_Bezarius has quit [Max SendQ exceeded]
<heat> ooh they are conditionally kmalloc'd
<heat> what a horrible idea
<heat> lets put stacks in the middle of the heap, they never overflow right?
<heat> anyway modern kernels should use CONFIG_VMAP_STACK which maps them properly and has guard pages, etc
awita has quit [Ping timeout: 244 seconds]
archenoth has quit [Ping timeout: 244 seconds]
archenoth has joined #osdev
<truepassion> hi, in armv8a, can we do cache operations like clean, invalidate even if caches are disabled in sctlr?
Raito_Bezarius has joined #osdev
awita has joined #osdev
Raito_Bezarius has quit [Max SendQ exceeded]
Raito_Bezarius has joined #osdev
Raito_Bezarius has quit [Max SendQ exceeded]
CryptoDavid has quit [Quit: Connection closed for inactivity]
Raito_Bezarius has joined #osdev
bauen1 has quit [Ping timeout: 260 seconds]
Terlisimo has quit [Quit: Connection reset by beer]
Terlisimo has joined #osdev
orccoin has joined #osdev
bradd has quit [Ping timeout: 240 seconds]
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
<freeload7> <truepassion> "hi, in armv8a, can we do cache..." <- If the cache trap bit is set, then the instruction will trap. If not it should execute (but may not have an effect)
Vercas6 has joined #osdev
<truepassion> freeload7: thanks!
<truepassion> why do you say it may not have an effect?
<truepassion> if the caches contain non-invaldated lines then CMOs should have an effect even if caches are disabled in sctlr.c, right?
bauen1 has joined #osdev
einkoder has joined #osdev
archenoth has quit [Ping timeout: 250 seconds]
archenoth has joined #osdev
<freeload7> <truepassion> "if the caches contain non-..." <- If my undestanding is corrct, than sctlr.c will disable any new memory accesses from being cached. Any cache instr will invalidate anything that was there before
<freeload7> <truepassion> "why do you say it may not have..." <- So yes, it should have an effect
archenoth has quit [Ping timeout: 250 seconds]
wereii has quit [Quit: ZNC - https://znc.in]
wereii has joined #osdev
archenoth has joined #osdev
orccoin has quit [Ping timeout: 252 seconds]
xenos1984 has quit [Ping timeout: 240 seconds]
xenos1984 has joined #osdev
archenoth has quit [Ping timeout: 244 seconds]
archenoth has joined #osdev
dude12312414 has quit [Ping timeout: 258 seconds]
dude12312414 has joined #osdev
archenoth has quit [Ping timeout: 272 seconds]
archenoth has joined #osdev
xenos1984 has quit [Ping timeout: 276 seconds]
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
xenos1984 has joined #osdev
gorgonical has joined #osdev
<gorgonical> you know what's wild is that after doing what the manual says my i2c driver works real well
<gorgonical> almost like that's important
<clever> who would have thought!
<gorgonical> I just read it so many times and never actually *read* that line. My eyes passed over it but it did not become information
<clever> what did the line say?
<gorgonical> When the controller changes status it will set the interrupt flag high in the control register. If you aren't taking interrupts you poll on that. You clear this flag by writing a 1, not a zero
<clever> ah, thats standard interrupt stuff
<gorgonical> Yeah, but I've never interfaced with a peripheral that did this I guess
<gorgonical> Like, I'm used to the two-part interrupt where you ack in a separate register
<clever> so you can read the interrupt reg, write the value back to clear things, then act on every bit that is set
<clever> and if an unrelated interrupt happens, you wont clear it
<gorgonical> yeah heat explained it that way too. It makes a lot of sense, but I've never seen it so my assumptions really got me
<gorgonical> spent/wasted a lot of time on that lesson :(
<clever> ive seen it in many things on the rpi
<gorgonical> this is the i2c controller on the pine64 board, so a similar environment
<gorgonical> Now I have the scarier task of writing a driver for the data lines of a MIPI interface
<gorgonical> MIPI CSI
<clever> on the rpi, thats handled by the unicam peripheral
<clever> the driver already exists
<gorgonical> not for my kernel
<clever> but ive had trouble making it work with the open firmware
<gorgonical> ofc I can/will probably port the linux driver, but it's still some effort
gog has joined #osdev
archenoth has quit [Ping timeout: 250 seconds]
archenoth has joined #osdev
Reinhilde has quit [Quit: Bye Open Projects!]
Reinhilde has joined #osdev
<gog> hi
<Ermine> Hi gog
<gog> what's new
<Ermine> Idk, my life is boring.
<GeDaMo> I had no Internet this morning. And then it came back on :|
<gog> dang
<gog> i took an e-scooter to work this morning and it slipped out from under me on a corner, but i'm a cat and landed on my feet
lte678 has left #osdev [#osdev]
<Ermine> cat skills
<heat> sup gogggersgs
DrPatater is now known as Patater
<geist> truepassion: i can confirm what freeload7 said. yes, cache flushing instructions still work even if the cache is disabled
<geist> think of the cache as always being there, but the enable/disable button is just whether or not the cpu fetches through it
<clever> but i have also had a fatal exception, unexpected cache hit
<clever> which implies that the arm checks the cache, even when it is off
<geist> possibly
<clever> and if you dont evict the cache after turning it off, it will catch your sloppy code and fault
<geist> in general you should clean it up indeed and conversely you should expect other code you dont control to not have cleaned it up
<heat> yay sloppy code
<geist> the real concern is dirty cache lines that have not yet been writte out, but otherwise wont ever get cleaned once you turn off the cache unless you do it yourself
<geist> since the cache doesn't have a timer or anything that flushes things on its own, dirty lines will just sit there until something evicts it
<clever> and the "unexpected cache hit" fault protects you from that, assuming you dont involve another core into the mess
<clever> but it might be an implementation dependant thing
<clever> the core is simpler to design, if it just always checks the cache
<clever> because it will spend 99.9% of its life in that mode
<heat> meanwhile x86: https://i.imgflip.com/6yjdku.jpg
GeDaMo has quit [Quit: Physics -> Chemistry -> Biology -> Intelligence -> ???]
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
awita has quit [Remote host closed the connection]
hmmmm has quit [Ping timeout: 272 seconds]
<geist> heh
<geist> heat: oh i forgot if i mentioned it or not but the current AMD arch docs have some new cpuid leaves to describe topology *with* provisions to describe AMD's upcoming Hybrid (big.little) stuff
<geist> basically it's what intel should have done for alder lake
<geist> but then i got to looking and indeed AMD has publically disclosed it, so i think i can talk about it
<clever> makes me wonder what other fun secrets you know
chartreuse has joined #osdev
vai has quit [Ping timeout: 260 seconds]
bauen1 has quit [Ping timeout: 250 seconds]
<gog> geist: did you know there's cat yoga in seattle
<heat> geist, what did intel do? I can't remember
<heat> ACPI?
<kazinsal> yeah I think there's some godawful ACPI tree you have to navigate
<heat> that's kind of annoying but intel requires ACPI anyway
<heat> if its just a static table that doesn't bother me much
<heat> bytecode... yeah, fuck that
<heat> s/requires/pretty much requires/
<heat> you know, i was thinking
<heat> i wonder what will happen when the need for different cpuids per core comes along
<gog> probably just a new acpi table
<gog> firmware spins up and queries each core and fills it in
<heat> i was imagining the CPUs falling back to the minimal common feature-set at boot and then showing the real cpuids when an msr is written or something
<kazinsal> yeah it's probably something funky because the e-cores can be turned off in BIOS
<heat> you can't add an acpi table because that will break old stuff
* Ermine is imagining cat yoga
<gog> cpuid will still exist
<heat> in this case, it worked because if you don't read the acpi table you'll just have worse performance
<gog> but that msr idea isn't bad either
<heat> you'll always need cpuid
<gog> the BSP always has to be whichever
<gog> probably the high-performance core
<gog> so naiive software can still use it
<gog> then the MADT will only have entries for cores that are peers to the BSP
<heat> that doesnt really matter I think
<gog> then if you want the eneergy efficiency you can enable it and use another table
<heat> the big problem is that operating systems assume cpuid is constant between cores
<heat> (cpuid feature bits)
<gog> right, which means they'll have to be fixed to use the e-cores
<heat> no
<heat> you'd have a better experience with every core but with a minimal feature set
<clever> heat: ive heard of anti-cheat getting upset when cpuid changes, and assuming it means your cheating
bauen1 has joined #osdev
<heat> if you get e-cores without avx512, you'll be better off with more cores and no avx512 rather than less than half the cores and avx512
<gog> hm
<heat> it's not like you're likely to have major differences
<heat> avx512 is a likely candidate, idk what else though
<heat> it's possible you're better off with avx consuming a bit more power but being twice as fast than just sse4 and twice as slow
<heat> .oO(avx1024)
vai has joined #osdev
dude12312414 has quit [Remote host closed the connection]
vai is now known as Jari--
bauen1 has quit [Ping timeout: 244 seconds]
bauen1 has joined #osdev
CryptoDavid has joined #osdev
bauen1 has quit [Ping timeout: 244 seconds]
<Jari--> hi
<Jari--> do you guys think it is possible to hire help on an osdev project?
<Jari--> would that help, to get it on the track again
<Jari--> any experiences on hiring?
<Jari--> possibly later getting funding
bauen1 has joined #osdev
<heat> it's not happening
<Jari--> I want a new game for my kids
<heat> nobody gives a shit about new operating systems
<heat> people barely care about existing ones
<Jari--> heat, yeah but if kids would like to play the games on it...
<gog> where are you going to get funding?
<heat> only big tech with fuck you money can have the resources to create an OS (see Google)
<Jari--> banks, financials
<gog> banks aren't going to finance an operating system
<gog> they have computer systems that are decades old
<Jari--> well, sell your flat and make an OS
<gog> i rent
<Jari--> lol joking
<heat> become homeless and have a broken unstable operating system
<heat> best of both worlds
<Jari--> but serious on making one
<gog> yes
<Jari--> dont sell your flat
<clever> heat: maybe make it temple themed!
<heat> i understand the reference but :((
<gog> :((
<heat> rip terry man
<gog> i was gonna say
<gog> i will never get paid to work on an operating system and that's fine. i get paid working on an application that's actually profitable
<Jari--> he probably talked with the extraterrestrials through prayers
<Jari--> got ideas, and help
<Jari--> ;-P
<heat> you can totally get paid to work on an OS
<heat> but it's not going to be your shitty OS
<Jari--> heat, Facebook should be making an OS, not metacosmos
<heat> the only people that care about my OS are me and... sometimes mjg_ when i'm dickmeasuring with other unices
<heat> and i've spent a significant amount of time banging keys for this shit
<heat> if magically from one day to the other my OS got 100% stable and pending problems got fixed, I would still have a worse linux
<heat> and that's ok
<heat> but it's not what companies want because it makes negative money
<Jari--> heat, man before people even bought MS-DOS, this assembly code based OS, I am thinking if I get first 10, later 100 to run my OS, I would win!
<Jari--> whats your target of audience, how many you are planning to have?
<Jari--> all you need is marketing
<heat> MS-DOS is long gone
<heat> unix is long gone
<heat> 4.4BSD is long gone
<gog> you need more than marketing
<gog> you need applications
<heat> the bar is higher than ever
<gog> you need large userbases for those applications who will pay because their work depends on the applications
<heat> you need features, performance, security, stability, userbase, applications
<Jari--> heat, if I recall right, 2022, now you need is a web browser
<\Test_User> "you need a well-established OS to get a well-established OS"
<heat> early 90s was probably the best chance you had for a new OS
<Jari--> one applications, that changes everything
<heat> do you know how hard it is to port a web browser?
<Jari--> maybe you could fix an old portable web browser?
<heat> a web browser is also not a feasible project
<gog> the consequence of web browsers becoming a universal application platform is that they're now huge systems of software in and of themselves
<Jari--> surprised how bad code we are left with, on browsers, chrome really so good? or we just dont have anything better?
<heat> an operating system and a web browser at the same time even less
<heat> chrome is good enough and has huge manpower and money behind it
* Jari-- brews coffee
<heat> it's also consequently open-source, so most other "web browsers" are just shiny chrome
<gog> webkit ate everything
<gog> from humble khtml
<heat> the speed at which the v8/chrome team rolls out fixes is extraordinary
<heat> the testing each version gets is unbeatable
<heat> firefox cannot come close to that
<heat> and firefox is company backed
<gog> safari exists too
<heat> lmao
<Jari--> webkit runs on Maemo
<heat> if you want to talk in unix terms
<heat> chrome is linux
<heat> big corp backed, lots of money behind it, lots of adoption and testing
<heat> firefox is bsd
<heat> dying slowly without many people behind it except really really passionate people that keep it rolling
<gog> i should work on firefox
<gog> it has several frustrating bugs that force me to use chrome from time to time and i find that insulting
<heat> i use both firefox and chrome
<heat> suck it idiots
<gog> fuck you
<gog> :P
<heat> fuck you
<heat> i bet you're writing this on safari
<heat> you perv
<gog> yeah safari with kiwiirc
<gog> which means it's going to crash soon
<bslsk05> ​www.reddit.com: Running Ubuntu 22.10 w/ Kernel 6.0+ on my PinePhone Pro because why not. : linux
<heat> using linux on a phone sounds like hell
<gog> bUt AnDrOiD iS lInUx
<heat> unless they somehow skipped the year of the desktop linux for the year of the mobile linux
<bslsk05> ​jamethy/sdl2-cef - SDL2 combined with the Chromium Embedded Framework (6 forks/14 stargazers/NOASSERTION)
<gog> every yyear is the year of desktop linux if you're stubborn enough
<Jari--> Chromium embedded sounds promising, but how many libraries do you have to port for it to run? lol :) but still best I found
<heat> a whole operating system
<heat> it doesn't even work on the BSDs without a bunch of patches
<heat> and the BSDs stole the graphics stuff from linux
<Jari--> Opera used to run on Windows 386
<heat> (and the audio I think)
<heat> oh wait sorry, my bad
gildasio has quit [Ping timeout: 258 seconds]
<heat> nintendo also wrote their own OS for the nintendo switch
<gog> opera of today is not the same as opera of the past
<heat> see, two operating systems by companies with FU money
<heat> funnily enough, both microkernels
<Jari--> Microsoft probably saving billions on development, by using Chrome
<gog> microkernel good
<heat> nooooooo
<heat> unix good
<heat> file go brrr
<gog> unix microkernel?
<heat> noooooooo
<kazinsal> user space drivers as files
<gog> yes
<heat> io_uring moment
<heat> guy
<heat> great idea
<heat> new idea
<Jari--> How many CPUID extensions are you supporting guys?
<gog> Jari--: 69420
<heat> have bytecode program and install it in kernel
<heat> then expand bytecode to do whatever
<heat> then finnish unikernel
<gog> heat: did you know my kernel is going to be based around the interpreter i claim i'm going to write
<heat> Jari--, I support none, i'm not an x86 CPU
<gog> (i'm lying)
<heat> gog, write an EBC interpreter
<Jari--> Google has this new script kernel
<gog> lmao
<gog> poor EBC
<gog> it was such an... idea
<freeload7> Maybe Libweb will be competitive. Kling posted a picture of the browser on Instagram.
<heat> it's still out there!
<heat> EbcDxe
<heat> freeload7, i bet 100k on that not happening
<gog> maybe that'll be useful during the long painful transition from x86 to arm
<heat> i know their operating system turned into a web browser but jeez, the bar is so fucking high
<heat> even opera and microsoft gave up
<heat> gog, huh?
<heat> sweetie, they have an x86 emulator in edk2-non-osi (qemu TCG torn apart)
<Jari--> guys
gildasio has joined #osdev
<Jari--> Amiga and C64 did it before, get games to your OS and become new Jack Tramiels !
<heat> it's so you can run x86 option ROMs
<gog> oh
<gog> i'm so behind the times
<gog> i just wanna write my toy software
<heat> yes you are
<Jari--> you could combine computer recycling business, get subsidities to develope your OS
<Jari--> Windows 10 too slow for many PCs
<heat> that's why you're gonna write EbcDxe on your itanium CPU
<gog> that's right
<heat> i have an idea
<gog> anybody have HP's phone number? i'll take a few itanum workstations off their hands
<gog> nobody's using them anyway
<heat> buy my NFTs, and you'll have a license to my new operating systems I will totally deliver on
<heat> the login is the NFT
<heat> and we'll all be in a monke world in my web server Onyx community
<gog> i'll buy 10
<gog> line go up
<heat> hehehe line go upppp
<heat> the rug go byebye
<heat> D:
<gog> D:
<gog> i'm still gonna hodl
<heat> WAGMI
<gog> i have an endless supply of copium i will always wait for my dubious investment to pay off
<heat> every sound investment goes through a point where you're down 1000%
<heat> remember, you're not getting rug pulled, you're the one rug pulling
<heat> so just hodl
<bslsk05> ​www.ebay.com: HP Integrity RX2800 i2 8SFF, 1 x Itanium2 9310, 16GB, 2 x 1200W RX2800i2 | eBay
<heat> look at this bad boy
<heat> 2400W
<heat> it's power efficient compared to new x86 cpus!
<gog> it doubles as a warming table for your meals
<heat> WHAT
<freeload7> can it run crysis tho?
<freeload7> Or the latest saints row?
<heat> idk buy it and find out man
<gog> i'm buying it
<heat> geist, we got someone!
<geist> noice!
<heat> have fun with your 8-way-segmented virtual address space
<freeload7> 8 levels of pagetables? That must be some intense stuff
<heat> no
<heat> they didn't even have page tables
<bslsk05> ​www.ebay.com: HP Integrity RX8640 16-Way 8 x Itanium 9140N 1.6GHz 64G 2x 146GB 15K Unix Server | eBay
<gog> i want this one
<heat> does it come with an HP-UX license
<geist> no it's more like there are 8 separate page tables, it splits the 64bit vaddr into 8 segments
<gog> i hope not
<heat> enterprise unixxxxxxxx
<geist> much like how ARM splits the aspace into 2. ia64 just has 8 top level ones and you can choose which ones to populate and how
<clever> what else are we going to use those 64bits for! lol
<gog> it's got 9 fucken fans on the back lmao
<gog> on that's the front with the faceplate off
<heat> it doubles as your house's cooling/warming solution
<heat> shitty cold iceland winters will become less shitty and cold
<gog> who needs geothermal when you have itanium
<clever> gog: i have heard of using a ground loop for cooling instead
<geist> side note it hink this also means ia64 is one of the few arches that give a true 64bit addrss space
<gog> you can combine them with a heat pump for both
<clever> gog: heatpump just allows a greater differential, the first time i saw it, the guy was just running his PC water cooling loop thru the basement floor slab raw
<clever> there was a loop in the concrete, like infloor heating
<gog> ohhh i get it
<gog> yeh concrete has big thermal mass it'd work great for that
<clever> so your limited by whatever temp the ground is, plus whatever differential your heatsinks cause
<heat> geist, turns out pml6-less 64-bit address space has already been achieved
<gog> if it's an actual basement then it's basiclaly always like 10C
<heat> intel is just evolving backwards
<geist> how so?
<clever> gog: LTT is doing the same thing, with his swimming pool
<heat> itanium :v
<gog> yeh i saw that video lol
<clever> gog: so basically, he has several 1000 galons worth of heatsink
<clever> and what was the rule, 1 joule of energy to raise 1 litre of water by 1 degree c?
<heat> tbh i don't think we're reaching 64-bit address space anytime soon
<heat> simply because of address tagging
<clever> from what i can tell, address tagging isnt enforced in hardware, at least on arm?
<gog> 1000 gallons is 3800 liters
<clever> and you must wrap every pointer de-reference with a check and remove tag opcode?
<geist> TBI?
<heat> arm handles tagging no problem through TBI and MTE
<geist> yah through TBI it simply ignores the top 8 bits and the operative bit that makes it an upper or lower bit is bit uh, 56? 55?
<heat> intel and amd have also developed THEIR OWN SEPARATE FUCKING EXTENSIONS
<clever> geist: ah, but then nothing is actually verifying the tags?
<heat> which means you'll have both 8-bits and 16-bits there (57-bit address space and 48-bit)
<geist> that's correct. the TBI bits work as they say 'top bits ignore'
<clever> so you still need to add extra opcodes, to validate the tag?
<geist> MTE is different, and i dont actually grok it yet. that has some validation
<heat> i think MTE just works
<heat> it's what linux uses for its in-kernel hwasan
<heat> I believe userspace HWAsan uses software tagging (as you say, check the bits and then deref)
<heat> a fun ASAN tidbit I found out about: you need to get a heuristic to understand if you GPF'd because of a bad ASAN dereference
<heat> particularly as you get asan inlined and a possible address range check because impossible
gildasio has quit [Ping timeout: 258 seconds]
gildasio has joined #osdev
xvmt has quit [Ping timeout: 250 seconds]
darkstardevx has quit [Remote host closed the connection]
darkstardevx has joined #osdev
xvmt has joined #osdev
darkstardevx has quit [Max SendQ exceeded]
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
darkstardevx has joined #osdev
darkstardevx has quit [Max SendQ exceeded]
darkstardevx has joined #osdev