<bslsk05>
redirect -> consent.youtube.com: Before you continue to YouTube
<heat>
2 days late but still very funny
SpikeHeron has joined #osdev
heat has quit [Ping timeout: 276 seconds]
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
<mxshift>
zstd or how to improve compression by presharing a bunch of data
<klange>
i thought that was brotli
GeDaMo has joined #osdev
<mxshift>
it
<mxshift>
it's both
rorx has quit [Ping timeout: 250 seconds]
rorx has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
gog has quit [Ping timeout: 250 seconds]
<Mutabah>
Took hacks, but managed to do that pe->elf conversion :)
<Mutabah>
where hacks = every segment writable
<zid>
sounds fun, why did you do that
<Mutabah>
Trying to run a windows driver in linux userspace :)
<moon-child>
I like it
zid has quit [Read error: Connection reset by peer]
zid has joined #osdev
<zid>
oopsie, dropped my keyboard
<zid>
computer go GrrGrrGrrGrrGrrGrrGrrGrrGrr
air has quit [Quit: Client killed by user]
air has joined #osdev
* pesdauskes
kernel reload complete
* pesdauskes
electricity restored
elderK has quit [Quit: Connection closed for inactivity]
<geist>
oh zstd, makes sense. didn't know there was a file format for it, but guess there is
<clever>
i recently saw a rootfs.cpio.zst
<clever>
implies that linux can decompress zstd initrd's
<kazinsal>
yeah, I think it was added in 5.something
epony has quit [Ping timeout: 252 seconds]
awita has joined #osdev
epony has joined #osdev
awita has quit [Quit: Leaving]
Burgundy has joined #osdev
Vercas6 has quit [Remote host closed the connection]
Vercas6 has joined #osdev
aleamb has quit [Quit: WeeChat 2.8]
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
Burgundy has quit [Ping timeout: 276 seconds]
jafarlihi has joined #osdev
mavhq has quit [Ping timeout: 260 seconds]
<jafarlihi>
Hello. I'm making a C compiler here: https://github.com/jafarlihi/ccompiler I wanted to ask if an identifier is supposed to be an AST node? I'm trying to add variable assignment expression and having identifier be an AST node would allow me to use existing infra for setting it as the child of expr, but are identifiers are generally a standalone AST node in established compilers?
<Maja[m]>
yeah an identifier would usually be a leaf nod
<Maja[m]>
s/nod/node/
darkstardevx has quit [Remote host closed the connection]
darkstardevx has joined #osdev
<jafarlihi>
I made some changes in compiler and I get this when running it, any idea what this says?: Inconsistency detected by ld.so: dl-fini.c: 92: _dl_fini: Assertion `ns != LM_ID_BASE || i == nloaded' failed!
pesdauskes has quit [Remote host closed the connection]
<jafarlihi>
This is glibc bug right?
<sortie>
Probably rather glibc detecting your bug
<jafarlihi>
Shouldn't it be compile time error or something
<sortie>
Well aren't you the compiler here, not erroring?
<jafarlihi>
I'm trying to run the compiler, it doesn't error segfault or anything, just prints that
<jafarlihi>
Compiled with gcc
<sortie>
Oh you're saying that's what happens when you execute your compiler, not its output
<jafarlihi>
Right
<jafarlihi>
Wanna see the diff that causes it?
<sortie>
Yes please, I mean you should've shown that up front
zaquest has quit [Remote host closed the connection]
<sortie>
I don't immediately see anything wrong
<sortie>
Can you try undo parts of that change and see which particular one is causing the problem?
<jafarlihi>
Ok
<jafarlihi>
Will try
<sortie>
The _dl_fini thing sounds like the global constructors feature, I wonder if initArray is somehow interfering with it, although it's not in the protected namespace
<sortie>
Is the latest code with this bug up on github?
<jafarlihi>
No
pesdauskes has joined #osdev
<sortie>
The bug is caused by git master + that diff?
<sortie>
There's no makefile, how do you compile the program?
<jafarlihi>
Yes
<sortie>
In case you're using weird compiler options
<sortie>
Yeah then my thinking is that you're probably corrupting the process at runtime
<sortie>
Try running it through gdb or valgrind, or turn on undefined behavior or address space sanization
<jafarlihi>
Ok thanks
gog has joined #osdev
<sortie>
jafarlihi, I don't see any particular kind of cursed abuse of compiler features, it's pretty plain C. The only problem is that the C isn't that good. There's a lot of suspicious string handling that seems super susceptible to buffer overflows
<sortie>
https://github.com/jafarlihi/ccompiler/blob/master/main.c#L83 ← Like here, you assume the output is no more than 2048 bytes, you're gonna get heap corruption if you're wrong. You need to use another allocation pattern that figures out exactly how much is needed, or dynamically resizes. Or just writes to a file.
<bslsk05>
github.com: ccompiler/main.c at master · jafarlihi/ccompiler · GitHub
<bslsk05>
github.com: ccompiler/main.c at master · jafarlihi/ccompiler · GitHub
<sortie>
jafarlihi, lots of cases to comment on, you can find them yourself, but just saying that bad allocation patterns and hard-coded array fixes are bad, and can lead you to mysterious corruptions like this
<sortie>
Hope you solve it :)
<heat>
good to see you here sortie
<heat>
long time no #osdev
<heat>
:)
<sortie>
Well I *am* osdev'ing this weekend
<sortie>
Now for my own cursed osdev problems: Is the reason the nightly CI failing because last night's commit broke the network stack, or was it just a flake?
<heat>
run it again? :v
<klange>
oh wow a sortie, those are rare
<gog>
hia
<sortie>
klange hiiiiyya its been known to happen from tiem to tiem
* sortie
boots the OS smokescreen and sees a cursed shell crash like never before
* mrvn
knows why his strings are struct { size_t len; char data[]; } like
<mrvn>
I'm still considering if my language should support multiple dynamically sized arrays in a struct. Like { size_t len1; size_t len2; char data1[]; int data2[]; }
<sortie>
https://pub.sortix.org/sortix/crazy-os/crazy-os-smokescreen-shell-crash.png ← The crash doesn't look so cursed as much as the shell has been working perfectly for me for years, I made no changes that could affect it (only networking), it's crashing mid-line on an unattended VM with no keyboard input
<sortie>
... and it's failing in UTF-8 decoding??
<heat>
lol
jafarlihi has quit [Ping timeout: 250 seconds]
<heat>
memory corruption really do be crazy
<heat>
bikeshed, write an asan implementation and test it
<heat>
if it doesn't work, bikeshed again and write an msan implementation, and test it
<sortie>
Dammit heat this is your fault
<sortie>
Don't nul terminate the hostname you'll be fine
<heat>
and then, write a tsan impl and test it for race conditions
<heat>
postpone the 1.2 release to 2024 for a full sanitizer suite
<sortie>
Like this bug is literally heat's fault
<sortie>
Look what you made me do
<heat>
what did i make you do
<sortie>
No wait it was nortti
<klange>
see, this is why I do what I do, I always know who to blame
<sortie>
You contributors all look alike to me
<sortie>
So what happened was that I changed my init, a commit reviewer noticed that I gave a nul byte to sethostname which isn't needed, so I removed it, except I see my sethostname(2) is buggy and used the wrong length of the new hostname, copying corrupted data into the hostname field, that made sh(1) crash flakily when the corruption didn't decode as UTF-8
<sortie>
This bug is probably reproducible by.. simply installing my OS
<sortie>
And hey.. my smokescreen did in fact notice something was wrong by randomly failing
<heat>
asan when bby
<sortie>
heat, wouldn't have caught it, it was even happening across user kernel boundraries with safe copies
<sortie>
Kernel doesn't care whether it's reading uninitialized data from user-space, it just needs a consistent copy of the garbage input user-space dared call it with
<heat>
yes, i meant asan for the kernel
<heat>
you clearly corrupted something
<sortie>
What do you mean?
<sortie>
Userland just set a corrupted hostname, but it was a consistent hostname
<heat>
wait hrm
<heat>
why is it decoding utf8???
<sortie>
The hostname buffer was just appened with random bytes but user-space could've done that if it wanted
<sortie>
The shell is decoding as UTF-8 when rendering
<heat>
why?
<heat>
you should already store things in ASCII/UTF-8
<sortie>
In order to keep track of column offsets when generating escape codes to update the prompt
<sortie>
It is stored as UTF-8, but it's decoding it to figure out the width of the glyphs
<heat>
that seems overly complicated
<heat>
VT100 has escape codes to see where you are in [X, Y] i'm pretty sure
<sortie>
Have fun when pressing the Left Arrow button after typing æøå and the prompt is corrupted
<pesdauskes>
reset
<heat>
sortie, what's the problem with those?
<sortie>
heat: 'æ' is two bytes. So a UTF-8 unaware shell would then try to move the cursor one byte back into the middle of the character.
<heat>
that's the terminal emulator's problem
<sortie>
It's not
<sortie>
Because at some point the shell needs to say “you've gone past the end“
<zid>
You need to know about encoding if you're mixing byte position and glyph
<sortie>
Or what if you enter another character
<sortie>
heat, this is the interactive shell prompt with line editing
<zid>
That's sorta why codepages exist :P
<heat>
hmm yeah i see
<zid>
I don't actually know how utf-8 works wrt terminals
<zid>
do they just have variable byte-length lines?
<sortie>
heat, big life tip here, try understand the problem a bit more before jumping to conclusions, it's going to make working with you a bit harder than it needs to be
<sortie>
I do love your strong opinions though, just make sure you got the right context where they apply
<zid>
heat: wow you really pissed him off
<zid>
Usually it's only me doing that to people
<sortie>
zid, oh hardly, just think of it was friendly developmental feedback :)
<heat>
sortie, yeah got it
<zid>
You wrapped back around to sounding super mad sortie by being low key about it :P
<zid>
a bit mad -> wtf dude, a lot mad -> you utter bastard, very very mad -> You are an incomperable reprobate who I shall ne..
pg12 has quit [Quit: pg12]
<heat>
i was confused because the move-cursor escape codes should handle UTF-8 properly
<heat>
a two byte code will just fit in one console cell
<sortie>
I even blamed heat for another person asked me a question where I personally introduced a bug
<zid>
I recommend blaming everything on heat at all times
<sortie>
Yeah my terminal handles UTF-8 and unicode just fine
<sortie>
(No font support, and no support for weird combining unicode sequences, but hey, the basics work)
<zid>
some of the time you're correct to do so, the rest of the time it's just cathartic
<heat>
weird combining unicode sequences are weird and hard to support in a console
<sortie>
The shell still needs to model what the terminal does so it can properly update the display, and also to maintain the line editing aspect
<zid>
I wonder of people (like say, libterm?) bother to maintain an x -> byte offset mapping, or they just walk characters forwards each time
<zid>
or backwards I suppose is also possible in utf-8, because you can tell how many bytes of encoding a byte is from
<heat>
sortie, i would suggest to fallback to byte -> 8-bit ASCII instead of erroring out in utf-8
<sortie>
I bet a lot of older stuff is super careful to compute efficient escape code updates since bandwidth was the limiting factor
* zid
ponders using ucs-4 internally
<heat>
yeah that's what i do
<sortie>
heat, nah, just emit U+FFFD REPLACEMENT CHARACTER
<zid>
ucs-4 seems like the programmatically cleanest thing to do
<heat>
my console cell array is a 2D array of utf32_t + a few more things
<zid>
but maybe not the most performant for a specific use-case
<sortie>
Fun fact, I actually patch byte 0 of the VGA font to be the replacement character, so unicode can properly not display in VGA
<heat>
i'd say it's probably the most performant, iterating is EZ
<zid>
nah most performant would be to leave it in the display-encoding
<sortie>
Yeah I'm pretty sure my terminal is a 2D array of wchar_t plus attributes
<zid>
so that you didn't have to iconv it to it every time you drew it
<zid>
but it complicates the x,y etc logic as above
<heat>
sortie, everybody gangsta until -fshort-wchar rolls around
<zid>
so if the cursor is doing a lot of seeking is slow, if it's doing a lot of printing it's fast
<zid>
libmaxsi sounds like someone spelled maxis wrong
<sortie>
heat, my life became significantly happier once I dropped MSVC support
<sortie>
Or actually any kind of Windows support
<heat>
you'll need to bring fshort-wchar back if you want UEFI
pg12 has joined #osdev
<sortie>
Sounds like a bootloader problem to me
<heat>
haha
* heat
laughs in UEFI Runtime Services
* zid
laughs in grub 0.97
<sortie>
heat, serious question, what would I want to use those for?
<zid>
I never understood the appeal of doing anything other than ExitBootServices
<heat>
variables, shutdown, reboot
<heat>
firmware updates
<sortie>
Hmm a bit useful yeah
<sortie>
Can I just stash something minimal somewhere in the kernel to interact with those?
<heat>
yeah
<sortie>
I can just give it an int16_t in my definitions instead of wchar_t
<heat>
but L"" goes brrr :(
<zid>
why do I want to variables
<sortie>
Isn't there like a u16"" these days?
<heat>
installing a bootloader
<zid>
so you use uefi in order to use uefi
<heat>
there's also more platform configuration, but yeah boot order stuff is the normal OS usage
<puck>
linux also uses uefi to stash kernel panics into before rebooting
<zid>
Mobile Suit Gundam - The Witch from Mercury - EP4 is out btw guys, get to it
<heat>
although in apple M1+, your firmware settings menu is actually XNU
<heat>
(although they dropped uefi)
<zid>
I can't imagine being far enough into an osdev project
<heat>
puck, oh yeah good point
<zid>
that I care about uefi other than getting out of it asap
<zid>
alien to me
<heat>
i think they also stash coredumps?
<puck>
i don't think so, pstore just stores oopses and panics; there's not much space for coredumps
<zid>
"kernel in known bad state, quick write to as much nvram as you can!" :P
<zid>
*e1000 firmware is now a copy of dmesg*
<heat>
well, if the fw is buggy thats a whole other problem
<heat>
in general you MUST NOT TOUCH FIRMWARE MEMORY
<zid>
except to store panics
<heat>
so if that's corrupt here be dragons i guess
<heat>
unless you wanna do this in SMM
<heat>
which would be *hilarious*
<puck>
my uefi used normal BootNNNN entries to store the path to the setup and boot menu .efi files (they were FvFile, but)
<puck>
anyways some linux installer overwrote Boot0000 which pointed to Setup
<heat>
lol
<heat>
i think some new aptio shit skips BootNNNN these days
<puck>
...*new*? oh no
<heat>
it tries to discover the microsoft bootloader, GRUB, etc and boot those directly
<puck>
i had read about this being the case on early UEFI systems
<zid>
is puck new or a rename
<puck>
anyways that laptop got bricked after someone manually crafted a uefi device path that had a self-reference, and i had to fix it with flashrom + hexdump
<puck>
hex edit*
<heat>
apparently there are a few bad flaws in BootNNNN but I don't quite understand it
<zid>
seems new, yukari.puck.moe is a funny rdns, gj
<puck>
i mostly lurk here :p
<puck>
(see also: bslsk05)
<zid>
amg bslsk05 hacked you
<heat>
bug report: bslsk05 stops printing long messages in the middle of utf8 sequences
<heat>
plsfix
<ThinkT510>
the only puck I'm familiar with is the character from final fantasy 9
<zid>
Bug: Terminal is capable of dealing with hungarian
<puck>
heat: i will fix this some day but it'll be overdesigned as usual
<zid>
ThinkT510: No shakespeare?
<heat>
hungarian notation or hungarian language?
<ThinkT510>
zid: that is probably where FF got it from
<zid>
language
<zid>
indeed it did
<heat>
puck rhymes with luck
<zid>
Thanks heat
<heat>
ABCs with heat
<zid>
Can you teach me how to count in hex
* heat
has vietnam flashbacks
<zid>
:D
<zid>
It's okay heat I already know how, 1 2 3 4 5 6 9 a b c d e f 10f 11f 12f
<heat>
tfw 5 nerds get mercilessly baited into teaching someone how to count for 2 hours
<heat>
you and your goddang abacus
<zid>
I learned that's how abaci worked at least
<j`ey>
abacashi
<zid>
abbakashi is my ninja name
<j`ey>
err abacaxi apparently
<zid>
that's a chinese ninja
<j`ey>
*portugese
<zid>
That's heat's job
<heat>
helo
<zid>
You know how people call kanji moon runes?
<heat>
no
<zid>
k
wootehfoot has joined #osdev
Raito_Bezarius has quit [Ping timeout: 264 seconds]
wootehfoot has quit [Remote host closed the connection]
wootehfoot has joined #osdev
<gog>
hi
Raito_Bezarius has joined #osdev
Raito_Bezarius has quit [Max SendQ exceeded]
vdamewood has quit [Ping timeout: 250 seconds]
Burgundy has joined #osdev
vdamewood has joined #osdev
Raito_Bezarius has joined #osdev
eroux has quit [Ping timeout: 252 seconds]
eroux has joined #osdev
jimbzy has joined #osdev
xvmt has quit [Ping timeout: 272 seconds]
xvmt has joined #osdev
<ddevault>
hrm
<ddevault>
I'm getting a weird issue on an old core 2 duo L7500
<ddevault>
page fault with reserved write bit set
<ddevault>
PML4/PDPT/PD/PT flags are respectively 100111, 100111, 100111, and 111
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
Vercas60 has joined #osdev
Vercas6 has quit [Ping timeout: 258 seconds]
Vercas60 is now known as Vercas6
heat has quit [Remote host closed the connection]
wootehfoot has joined #osdev
Piraty has quit [Quit: -]
Piraty has joined #osdev
wootehfoot has quit [Quit: Leaving]
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
wootehfoot has joined #osdev
Vercas6 has quit [Ping timeout: 258 seconds]
Vercas6 has joined #osdev
heat has joined #osdev
wootehfoot has quit [Read error: Connection reset by peer]
xenos1984 has quit [Read error: Connection reset by peer]
pesdauskes has quit [Remote host closed the connection]
SGautam has quit [Quit: Connection closed for inactivity]
<geist>
ah so they're just hard disabled?
<geist>
ah duo 2. yeah iirc i vaguely remember something about either broken NX or something in that generation
<geist>
but at the time NX was just a optional, nice to have so it didn't really matter much if it were disabled
<heat>
but linux /proc/cpuinfo lists nx
<heat>
which suggests the cpuid bit should be there, but apparently it isn't
<GeDaMo>
CPUID: NX; CPU: ¯\_(ツ)_/¯
<geist>
oh hmm. wonder if there's a MSR or something to reenable it
<geist>
that linux knows about
<geist>
i didn't read the full backlog. is the issue that you tried to set it because you assumed NX was avail but turns out it isn't so it fires a #GP or something?
<heat>
the cpuid he's getting isn't the cpuid linux gets
<heat>
he's lacking the nx bit, linux isn't
<GeDaMo>
Is there another way of detecting NX?
<heat>
no
pbx has quit [Quit: leaving]
xenos1984 has joined #osdev
<heat>
i checked the sauces and linux doesn't even have quirks in that code
<heat>
...what if it's a microcode issue?
<geist>
oooh oooh actually
<geist>
and linux updates the microcode...
pbx has joined #osdev
gxt has quit [Remote host closed the connection]
<GeDaMo>
How do you check the version of the microcode?
<heat>
cpuid probably
gxt has joined #osdev
<heat>
geist, oh yeah funny amd ucode fact: amd cpus need ucode updates per-thread, not per-core
<geist>
yep
<heat>
linux fixed this right in this release
<geist>
iirc the rules are: always update per thread, even if you dont need to. i think it depends a lot on the precise microarch, but it's always safe to treat every thread as a new core
<heat>
yeah
<heat>
they were getting a bug where half the threads in an SMT system had a different cpuid
* Griwes
is suddenly very glad he is years away from needing to worry about microcode updates
<geist>
but this does answer what i was thinking. early in the zircon project i remember at the time we were mandating that NX existed I was mentioning that there were some core 2s i had heard that didn't support NX
<geist>
but couldn't find any evidence of it. not that it matters much, but still, i had only anecdotally heard it, but didn't have any proof
<geist>
i have an early core 2 and had the same conclusion: linux seems to think NX is there. but i hadnt considered the microcode angle
<bslsk05>
github.com: lk/feature.c at master · littlekernel/lk · GitHub
<geist>
largely untested sinc ei haven't really run it on anything but a 386sx and a am486 since that's all i have around
<Ermine>
geist: so are you the author of littlekernel?
<geist>
and i think there was a whole pile of complexium if you consider all the non intel cores floating around at approximately the same time (K5, K6, cyrix, rise, via, etc) but iirc they were generally roughly categorized as 486 or 586 class
<geist>
Ermine: yep!
<Ermine>
Oh, cool!
<pbx>
geist: 386 or lower would be relatively easy right? no 32 bit prefix -> 286 or lower, no BSWAP -> 386 or lower, etc
<pbx>
prolly have to make sure you dont crash any older parts
<geist>
yeah there's a whole test sequence for <386
<geist>
obviously in this case since the code is 32bit there's no point here trying to test for <386
<geist>
also i was trying to stay away from probing by test + #GP since i didn't want to write that machinery
<geist>
but yeah you could test for cpuid by simply trying it, or rdtsc by trying it
<geist>
but then you have to deal wit the fault and whatnot
<pbx>
true :)
<Ermine>
Once upon a time I pressed some buttons on my old phone and 'little kernel ...' line showed up.
<bslsk05>
www.rcollins.org: Detecting Intel Processors -- Knowing the generation of a system CPU
<geist>
Ermine: teehee. yeah it's still in lots of stuff
<geist>
the new pixel phones have like 4 copies of LK
<geist>
i keep finding more LKs in there
<pbx>
how'd that happen anyway?
<pbx>
did you develop it for work, or did it get adopted
<geist>
used by various teams at various companies to get a little runtime environment to do stuff
<geist>
nope. nothing at all to do with me. folks just picked it up and use it
<heat>
lol, how so?
<geist>
and i typically dont even hear about it unless someone sends me an email asking for help
<heat>
trusty is one
<geist>
oh gotta go. BBIAB
<geist>
going to clean some gutters on my house. my dad is here with the ladder
<heat>
the bootloader can be lk or UEFI these days I guess
<heat>
maybe lk as a hypervisor too? /shrug
<pbx>
heat: have you seen linuxboot?
theruran has joined #osdev
<heat>
yes i have
<heat>
why?
<pbx>
linux as boot loader is a think too these days ;)
<heat>
yeah but arm cpu vendors are providing their stuff as UEFI modules
<heat>
like qualcomm
<heat>
so you can't replace DXE with linux i assume
<heat>
and doing UEFI -> lk -> linux sounds stupid
SpikeHeron has joined #osdev
selve has quit [Remote host closed the connection]
selve has joined #osdev
scaleww has joined #osdev
<clever>
heat: when you say that, my lk->lk->lk->linux chain sounds silly! :D
<heat>
might as well replace linux with fuchsia for the lk->lk->lk->lk
<heat>
:D
<clever>
in my case, the 1st LK is a special dram init build, it must fit within 128kb, and is basically a bootloader
<zid>
linux -> little -> linux -> linux -> little
<clever>
the 2nd LK is the final firmware for the VPU
<clever>
and the 3rd LK is the initial arm payload, whose only job is to load linux
<clever>
so the 1st and 3rd LK are both acting as bootloaders
<j`ey>
current m1 boot chain is: iboot1 -> iboot2 -> m1n1 -> m1n1 -> u-boot -> grub
<clever>
that u-boot -> grub part sounds weird
<heat>
i assume that's just for linux
<j`ey>
heat: yeah for asahi
<j`ey>
clever: because grub is just more standard for distros
<clever>
but couldnt you skip the uboot and load grub directly?
<clever>
what is uboot doing specially?
<j`ey>
uboot has the nvme drivers etc
<j`ey>
I mean, m1n1 has them too but.. idk :P
<clever>
ah yeah, grub does lack nvme drivers entirely
<clever>
it relies on the uefi firmware to provide nvme drivers
<j`ey>
m1n1 is more low level
<clever>
so, which of those stages implements uefi?
<heat>
uboot
<j`ey>
u-boot
<clever>
that explains things
<heat>
they ditched uefi for m1+
<j`ey>
now u-boot gives it back!
<heat>
death taxes and uefi
<geist>
yay house gutters are clean(er)
<geist>
re: lk in pixel stuff, the bootloader is just part of it
<geist>
there are other LKs in there
<geist>
that are around during runtime as well
<geist>
this is not news though, you can find this by looking at the android update, so i'm not leaking anything in particular
<heat>
ah wait, the CPUs for pixels are google's now aren't they?
<heat>
as in, made by google
<geist>
yeah
<heat>
"Google Tensor"
<geist>
pixel 6 and 7
<heat>
so trusty + hypervisor + bootloader
<heat>
I count 3 lks
<heat>
where else could you stash an lk
<j`ey>
browser
<heat>
lk as wasm
<clever>
heat: which reminds me, i did have discussions before about abusing LK for secure-monitor and hypervisor on arm, but a lot of the control reg stuff would have to be rewritten
<kazinsal>
lk on the baseband chip
<clever>
heat: dont make me try a wasm port....!
<heat>
do it
<heat>
i fucking dare you
<clever>
lol
<clever>
i already have webusb shipping LK to an rpi
<clever>
i'm one step away from cross-maching IPC, LK<->LK
<heat>
kazinsal, ooh yeah good point, lk as firmware on devices
<heat>
i was just thinking of the cpu
<geist>
yeah it's pretty good as a firmware
<j`ey>
LK replacing Minix on intel ME
<heat>
yes please
<heat>
lk replacing tianocore
<geist>
well, see i don thtink it'd be as appropriate a way to run UEFI or whatnot, since it has fundamentally different notions of ownership of timers and interrupts or whatnot
<geist>
but as a place to run some code to do something, like boot a system, or run a radio, or whatnot its basically a very lightweight but otherwise functional MT system
<heat>
yes, i mean as a way to replace uefi
<heat>
:)
* pbx
is starting to hate TCP
<mjg_>
try nfs
<zid>
try appletalk
<kazinsal>
IPX! IPX! IPX! *banging on table* IPX! IPX!
<CompanionCube>
let's go FULL ENTERPRISE and use SNA!
<mjg_>
is this a support group?
pesdauskes has quit [Quit: joins libera]
* mjg_
would not mind
<kof123>
its all luminiferous aethernet to me
<CompanionCube>
also CHAOSNET just *sounds* cool
<kof123>
^
<kof123>
you must join the aethernet and chaosnet
<heat>
DOORS
<heat>
DOORS OVER IPV4
<heat>
WHO SAYS NO
zid has quit [Remote host closed the connection]
zid has joined #osdev
<CompanionCube>
would it be really different from vintage ONC RPC which is also from sun
<CompanionCube>
add on NIS+ just because
scaleww has quit [Read error: Connection reset by peer]
heat has quit [Remote host closed the connection]
Burgundy has quit [Ping timeout: 260 seconds]
<mxshift>
I should try to boot LK once I get my RapidCAD system built. That should be entertaining