<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
<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?
<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?
<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
<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
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
<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]