<doug16k>
| twizzler* screwed me up, he's after sortix
isaacwoods has quit [Quit: WeeChat 3.1]
eight has left #osdev [#osdev]
<doug16k>
my system is broken: /tmp/ccCaJAL3.s:29: Error: unknown .loc sub-directive `view'
<doug16k>
^ I get that when I optimize and generate debug info on anything newer than gcc-7
<doug16k>
wish I knew how that happened
<doug16k>
omg something put `as` in /usr/local/bin
<doug16k>
fixed
qookie has quit [Ping timeout: 248 seconds]
iorem has joined #osdev
Lucretia has quit [Quit: Konversation terminated!]
jaevanko has joined #osdev
Lucretia has joined #osdev
<heat>
i feel so tempted to rewrite my rewrite of the build system
jaevanko has quit [Client Quit]
<doug16k>
what did you wish you did?
<heat>
i wish I never tried out gn
<heat>
it's cool and all but it's so fucking complex
<heat>
it lets you configure everything but you also need to configure everything
<heat>
all I want is a build system that's expressive and lets me depend on projects with other build systems
<doug16k>
hand made unified diff blocks are a fun to make
<doug16k>
I love forging things for some reason
<doug16k>
if you want your printout to look exactly like something, I love it
<doug16k>
I made payroll software and when I did the end of year documents (T4 in canada) I made it pixel perfect replica of the pdf you get off government site
<gog>
forgery is based
<doug16k>
they even had one of the field headings out of position a bit, I replicated that
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<doug16k>
since then I have seen some other software's T4's, they look ridiculous
<doug16k>
so dumb the value in the field is touching the box enclosing it, and it's at far bottom left with a bunch of blank above and to right of text
<doug16k>
and box outlines are hairline - narrowest thing the printer can do apparently
heat has quit [Ping timeout: 244 seconds]
<doug16k>
yay, 11.1.0 builds
<doug16k>
when I am going to try a new compiler, I always hope the warnings are better
<doug16k>
everything else is good enough
<doug16k>
it's too bad we hardly have a clue what the dimensions of a pixel are on most machines. on a printer you can do stuff with exact measurements
<doug16k>
and even when there is a field that says it, when you read it, you hardly believe it is correct anyway
<doug16k>
o
<doug16k>
it's there to just make you happy
<kazinsal>
doug16k: oh god please tell me you didnt write ceridian
<doug16k>
didn't
<kazinsal>
whew
<kazinsal>
that friggin thing mangles my taxes every year
<doug16k>
is the t4 ugly? that'll tell you how much they care
<kazinsal>
nah, it's pretty close to a real one
<doug16k>
ah they passed the 1st test of my gauntlet then :P
<kazinsal>
not sure if it's perfect or not but the first time I saw it I went "huh, that's pretty good"
<doug16k>
you have seen the hideous ones right?
<doug16k>
it's like they just barely learned to put text in a position and draw horizontal and vertical lines
<doug16k>
default properties for everything. they select courier of course
<doug16k>
neat, building with gcc 11.1 breaks my efi bootloader. Load Error now
gog has quit [Quit: bye]
<kazinsal>
yeah my previous job was like, heres some boxes in roughly the tight spots
<kazinsal>
right*
gog has joined #osdev
<doug16k>
weird! suddenly my EFI bootloader loads at 0x140001000 instead of 0x400000
<doug16k>
oops, 0x401000
Lucretia has quit [Quit: Konversation terminated!]
gog has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
<doug16k>
no matter what I do, ld forces the base address of my efi bootloader above 0x200000000
<doug16k>
even .text 0x400000 : { ... doesn't do it
<doug16k>
you'd get 0x200400000
<geist>
interesting, actually above 4GB huh
aquijoule__ has joined #osdev
<doug16k>
now I have to say -Wl,--image-base,0x400000
<doug16k>
haha new debug section names to delete, .debug_line_str .debug_rnglists
aquijoule_ has quit [Ping timeout: 272 seconds]
<doug16k>
whew. fixed
<doug16k>
not sure why but there seems to be some reason to do with address randomization to avoid preferred load address below 4GB
<doug16k>
why even be that aligned. might as well byte align it
<doug16k>
ah, must be 0x200 alignment, 512, sector
RyanW has quit [Quit: Konversation terminated!]
<doug16k>
good enough
iorem has quit [Quit: Connection closed]
iorem has joined #osdev
BUZZ_ON_FREENODE has joined #osdev
BUZZ_ON_FREENODE is now known as Guest7263
amanita has joined #osdev
<doug16k>
aww, I hate it when youtube starts getting mad and starts pausing stuff to see if I am watching
<doug16k>
don't worry youtube, I don't waste your bandwidth
<Affliction>
I've never had that happen
<doug16k>
it's from using it for music
<Affliction>
Not even when I fall asleep while watching on mobile, and wake up to it being much further down the playlist.
Guest7263 is now known as switch_on_Freeno
<doug16k>
maybe the ai thinks it is quite likely I am afk with music on
<doug16k>
it doesn't do it during interesting videos for me either
<Affliction>
hm
<doug16k>
polite music on youtube has a still picture and just uses sound bandwidth
<doug16k>
some videos would be entries into a dct artifact causing competition
switch_on_Freeno is now known as SwitchOnFreenode
<doug16k>
"let's make the entire screen change every frame"
SwitchOnFreenode has quit [Quit: Leaving]
<geist>
omg
<geist>
i do wonder if youtube has a special algorithm for encoding videos that are basically static
<geist>
or a short sequence of frames
<geist>
obviously can do keyframe + some number of deltas but seems like you could perpetually keep deltaing
<geist>
and ify ou seek, synthesize a new keyframe dynamically
<zhiayang>
sounds like they should have something going on in that front
<zhiayang>
internally, anywya
<zhiayang>
there's a lot of videos that basically have one frame every 5 minutes
<geist>
maybe its' feature of the codec they use?
<zhiayang>
possibly
<geist>
right, exactly. those static short loop things
<zhiayang>
i'd be surprised if it's not optimised at all
mctpyt has quit [Ping timeout: 248 seconds]
Terlisimo has quit [Quit: Connection reset by beer]
<kazinsal>
if you run it through the youtube music site or app they seem to just encode it as a regular ol' youtube video stream, just with no actual mp4 or vp9 in the stream. just AAC
<Affliction>
don't they use opus these days?
<Affliction>
At least the videos I pull with youtube-dl are almost always vp9+opus or h264+opus
<geist>
yah though question is does it serve the same stream in those cases
<doug16k>
stats for nerds says opus on this still frame music
<kazinsal>
yeah, I get mp4a/aac in the music app
<kazinsal>
so it's sending out a differently encoded stream for that
<doug16k>
ah I meant just youtube webpage on desktop on video that happens to be music with still video
<doug16k>
it transfers it in spikes, so it is difficult to say how much bandwidth it uses
<Affliction>
I think they use separate video and audio multiplexes, with DASH
Terlisimo has joined #osdev
<Affliction>
So, wouldn't surprise me if they just send an opus keyframe when the image changes
<Affliction>
er, vp9*
<Affliction>
and if the music app doesn't show video (I've not used it), they'd just request the audio stream
<Affliction>
watch the video, you'd get both.
<kazinsal>
yeah
<Affliction>
youtube-dl -F can show you the list of streams
amanita has quit [Ping timeout: 252 seconds]
lleo has joined #osdev
janemba has quit [Read error: Connection reset by peer]
<doug16k>
oh wow, gcc 11 won't build the qemu source I have to info tlb prototype: ../qemu/util/qemu-thread-posix.c:520:5: error: ‘__sigsetjmp’ accessing 200 bytes in a region of size 72 [-Werror=stringop-overflow=]
mctpyt has joined #osdev
janemba has joined #osdev
mctpyt has quit [Ping timeout: 248 seconds]
<doug16k>
is this a new warning? 'int memcmp(const void*, const void*, size_t)' reading 12 bytes from a region of size 4 [-Wstringop-overread]'
<geist>
yah i saw something like that in LK too
<doug16k>
it's correct, I was cheating to look for GenuineIntel across 3 dwords by taking &cpuid_info.ebx
<geist>
haven't fixed it, but it seems more aggressive about spotting that sort of thing
<geist>
yah
<doug16k>
awesome
<geist>
was a piece of test code where via some path it ends up casting a smaller thing to a bigger thing. actually kidna surprised it never saw it efore
<doug16k>
I recently added a bunch of attribute((access(...))) stuff so I can't be sure if that helped or builtin memcmp knew enough
<doug16k>
...and gcc upgrade made it work
<doug16k>
on that one, I have _access(read_only, 1, 3) _access(read_only, 2, 3)
Affliction has quit [Quit: Read error: Connection reset by beer]
Affliction has joined #osdev
<doug16k>
which expand to __attribute__((__access__(read_only, 1, 3))) __attribute__((__access__(read_only, 2, 3)))
<doug16k>
I think gcc 11 is responsible though
<doug16k>
3 memcmp will probably make codegen better anyway. probably just compares
<doug16k>
one for each of "Genu" "ineI" "ntel"
<geist>
so here's what i want: a packed attribute/pragma that also doesnt always mean 'assume you dont know the alignment'
<geist>
the two seem to be conflated in the compiler
<kazinsal>
for eg. something that you know will always be packed but will also always be eg. word size aligned?
<doug16k>
yeah
<kazinsal>
seems like it would be handy, yeah
<doug16k>
theoretically it might be misaligned it means
<geist>
so for example: riscv doesn't like unaligned stuff, fine. so for the tcp/ip stack i have to declare ip/eth/etc headers as packed
<geist>
fine. so i *could* for example just at the top of the function copy to a local versino of it that the compiler *knows* is at least aligned to something
<geist>
and then it can use somewhat nicer accessors
<geist>
like, for example reading a 32bit word that's 2 byte unaligned as two 16 bit words then reassembling them
<geist>
but short of literally redeclaring the structure with and without the packed attribute, and then manually copying between, and working with the unpacked ones
<geist>
i can't just copy one to another thats local (and alignde)
<geist>
the codegen still insists on doing everything byte at a time, always.
<doug16k>
are you saying riscv generates a sequence of byte accesses just because it is packed, even when aligned?
<geist>
yep
<doug16k>
oh no
<geist>
even when it *knows* it's aligned
<doug16k>
is the size aligned too?
<geist>
possible its jsut bad codegen on the compiler's case ndit just doesn't have the path to be smarter about it
<doug16k>
if the size isn't then packed makes it all misaligned
<geist>
but clang does the same thing, actually botches it worse
<geist>
yah but if i just make one struct locally, on the stack, the i'd assume it'd be smart enough to know the local alignment
<geist>
and override the 'i dunno how this is aligned' logic
<doug16k>
ah you mean the most trivial case is bad
<geist>
yah like struct { 16, 32 } __packed;
<geist>
it completely destroys that, byte at a time *every time*
<geist>
even if i declare one locally on the stack and use it
<doug16k>
it is thinking about the type, not the instance
<doug16k>
don't have to go all the way to that. can -fno-builtin-memcpy
<geist>
note in tis case f2 = *f; also doens't work obviously, since it knows it's a copy and elides the second version
<geist>
yah this 'sees through the memcpy and uses the original pointer' is a real security issue. there's a story at work that something like that was found in <browser>
<geist>
ie, some ipc packet in shared memory was thought to be copied locally and used
<geist>
but compiler saw through the memcpy and accessed the shared buffer directly
<moon-child>
if it's shared then it should be _Atomic
<moon-child>
in which case the compiler would know it can't just access directly
<geist>
yah but you can't _Atomic an entire structure
<geist>
OTOH this may not be a great case because to a certain extent it's still doing the bytewise copy. so it can't really simplify it that much
<moon-child>
there is (or, is proposed) memset_s, for zeroing out secrets. Maybe they should add an anologue for memcpy
<doug16k>
is there already constant-time strcmp and memcmp?
<doug16k>
are*
<moon-child>
I think not in std
<geist>
anyway you imagine my chagrin when looking at the codegen for this stuff
<geist>
it's no bueno. of coruse it's riscv's fault for not doing unaligned accesses, but it doesn't have to be *this* bad
<moon-child>
'risc is great for compilers' they said!
tenshi has joined #osdev
<doug16k>
it's tolerable when bad stuff like that is needed because it is really misaligned, but it could at least peek and see if it can drop the packed for a field access
<geist>
arm64 with the strict alignment switch on is about as bad
<geist>
except it has much nicer instructins for reconstructing the words
<doug16k>
same as x86_64? nobody would turn on AC because compilers assume it is ok?
<doug16k>
(alignment check)
<geist>
well, -mstrict-align is a switch that tells the compielr to assume it can't
<geist>
the only real reason you'd do that on ARM is if you're running with the cache off
<doug16k>
I should try that on x86_64
<doug16k>
you can only alignment check user mode though
<geist>
so say you have some bootstrap code thats running pre-mmu or pre-cache, you'd compile it with this switch
<doug16k>
ah
<geist>
ocne you enable the mmu (and thus can enable the data cache) then youc an turn on full unaligned access on the cpu and never think about it again
<doug16k>
can't mstrict-align x86_64
<geist>
i think it's an arm64 specific flag
<doug16k>
seemed widely applicable enough. weird
<geist>
well, i guess it's on arm64 becausei t's mandatory in some cases
<geist>
on x86 it'd only be nice
<geist>
or interesting
<doug16k>
yeah, I was mostly curious to see what it would degenerate into
<doug16k>
ah, is it because back in the day you just fiddled with the bytes in an exception handler and said screw performance?
<doug16k>
I remember the thing being that they fix up misalignments in exception handler so it works, just hideously high overhead
<doug16k>
is that just specific to that
<geist>
hmm?
<kazinsal>
whoops. built the toolchain in the wrong directory. time to do that again...
<doug16k>
geist, could you just throw misalignment at the kernel and it would emulate through it?
<doug16k>
some kernels did that, right?
<geist>
on what arch?
<doug16k>
68k?
<doug16k>
I think
<geist>
oh you mean generically. sure, but that'd probably be bad
<doug16k>
or alpha?
<geist>
but that's kinda the strategy for riscv now. the arch says 'a given implementation may or may not handle unaligned accesses, but it has an unaligned trap for it'
<geist>
which is pretty hand wavy way of saying 'dont do unaligned accesses'
<geist>
since trapping and emulating suuucks
<doug16k>
yes of course
<doug16k>
the trap means it makes it work at all
<doug16k>
when it would have failed
<geist>
traditinally classic ARM (pre armv5 or v6 or so) was actually worse
<geist>
an armv4 core (say arm7tdmi) would actually load the data around the address, swizzled
<geist>
according o a pattern. it was totally screwey, though of course folks used it as some clever byte swizzling thing
<geist>
basically it'd load the 4 byte word the start address was within, but i think put the byte yu were pointing to at the bottom of the register
<geist>
and then rotate around
<doug16k>
values near the pointer and values near the pointee?
<geist>
pointee
<geist>
ie, if you tried a 4 byte load at addrss 3 i think it'd fill the register with somethig like 2103
<geist>
or something weird like that
<doug16k>
ah
<geist>
anyway later arm revisions added a 'fault on unaligned access trap bit' and then later added a new bit to let you enable unaligned access
<geist>
that's an example of ARM playing a long game over the course of 10-15 years
<doug16k>
you have to handle it
<doug16k>
correction: if you want to say it is high performance you have to
<geist>
first add a chicken bit to disable the feature, then remove the feature, then add the anti featureenable bit, then in next revision make it mandatory
<geist>
by v7 the cores have to handle unaligned accesses except in specific cases (like the cache is disabled, or atomics)
<geist>
yah so i remember in around 2009 or so there was still a bit of a debate int he arm linux world if you should allow unaligned accesses in user space (ie, set the bit) or force user space to get their shit together
<geist>
i used to fall in the latter camp, but eventually linux kernel decided to default to the former and then it was all over
<geist>
more and more code just assumed it could unalign, and then you can't put it back in the bottle
<doug16k>
programs that do aligned accesses run faster
<doug16k>
you still win
<geist>
that was the idea, force code to do it right by causing a trap
<geist>
but linux decided to default to allowing unaligned code, so pretty quickly you get user code that doesn't work with strict alignment enabled
<doug16k>
yes
<geist>
so risc starting out the gate by making it implementation defined is of coruse going to be a problem eventually, but baby steps for them
<doug16k>
I remember trying alignment check on in windows 7. if you had a click for each misaligned access, it'd be a buzz
<doug16k>
never stops
<doug16k>
it's pointless to AC on x86 now
<doug16k>
nice thing though, -fsanitize=undefined strictly enforces it as much as hardware alignment check enabled
<doug16k>
it enables -fsanitize=alignment
<doug16k>
I had to fix multiple acpi things. seabios acpi has lots of misaligned stuff
<doug16k>
qemu U should say
diamondbond has joined #osdev
<doug16k>
just taking the address of a structure that isn't aligned properly triggers it, don't even need to do an access
<doug16k>
using it in a pointer expression checks it
<doug16k>
it knows that can't happen. if that struct has an int in it, it's guaranteed addressof that struct is divisible by sizeof(int)
<doug16k>
geist, there is a warning for that. it can tell you every place it generates bad code. -Waddress-of-packed-member
<doug16k>
at least many places. maybe not every
<doug16k>
when you first mentioned it I thought you meant that, then realized you meant actual bad code from it
<doug16k>
from packed
<doug16k>
I avoid packed pretty hard now
<doug16k>
example: my 64 bit idtr struct is 3 16 dummy limits, then the real limit, then the base. no packed, pass addressof limit[3] if you know what I mean
<doug16k>
pass to cpu
<doug16k>
alignment isn't that hard. I wish more people understood it
<doug16k>
on past cpus it might take two accesses to access a dword so screw it, just 2 byte align. then you end up with stupid uint16 then uint32 struct
<doug16k>
if I ended up with uint16_t then uint32_t I'd see if I could pack pairs of them, so the two uint16's match the uint32
<doug16k>
fat12 does that :P
<sham1>
You can always use access or functions that take byte arrays and spit out the proper unsigned type or whatever
<sham1>
No need to fudge around with alignments while also allowing for structs to be clearer and without dummy values
<doug16k>
on riscv the compiler uses byte accesses on packed structs, regardless of whether that particular instance is aligned or not
<jjuran>
Classic Mac OS has 2-byte-aligned int32 fields all over the place
<jjuran>
Some on-disk formats are even 1-byte-aligned
immibis has quit [Remote host closed the connection]
flx has quit [Ping timeout: 264 seconds]
<kazinsal>
Woohoo, build server is up and running
diamondbond has quit [Ping timeout: 264 seconds]
MarchHare has quit [Ping timeout: 264 seconds]
<geist>
oh woot. anything special in your setup?
<kazinsal>
nothing terribly special, no. though interestingly despite having fewer CPUs at less than half the clock rate, due to how slow WSL1's I/O is the build server VM is 50% faster than WSL1
<j`ey>
why not linux for a build server? if youre using WSl
<kazinsal>
the build server is a linux box, yeah
<j`ey>
oh misread, got it
<kazinsal>
replacing my previous WSL based build chain
<j`ey>
but it's still a VM? on a windows machine?
<kazinsal>
nah, on an ESXi host
<j`ey>
cool
<kazinsal>
so now I'm contemplating whether to go to bed (a smart idea) or continue fighting with this e1000e (a smart idea for later)
<j`ey>
e1000e from bed
gareppa has joined #osdev
gareppa has quit [Remote host closed the connection]
eschaton has joined #osdev
<kazinsal>
aha! I was punching the wrong rx tail into the thing. derf.
GeDaMo has joined #osdev
KidBeta has quit [Ping timeout: 264 seconds]
SwitchToFreenode has joined #osdev
Lucretia has joined #osdev
knebulae has quit [Read error: Connection reset by peer]
alexander has joined #osdev
immibis has joined #osdev
flx has joined #osdev
<geist2>
kazinsal: stay up! keep at it
<geist2>
never stop
mctpyt has joined #osdev
qookie has joined #osdev
zagto has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
knebulae has joined #osdev
<froggey>
it's the weekend, no need to sleep
SwitchToFreenode has quit [Remote host closed the connection]
SwitchToFreenode has joined #osdev
ozxui_ has joined #osdev
ozxui has quit [Ping timeout: 248 seconds]
transistor has quit [Ping timeout: 265 seconds]
KidBeta has joined #osdev
dennis95 has joined #osdev
Arthuria has joined #osdev
mingdao has quit [Quit: leaving]
flx- has joined #osdev
flx has quit [Remote host closed the connection]
Oli has quit [Read error: Connection reset by peer]
Oli has joined #osdev
gog has joined #osdev
SweetLeaf has quit [Quit: WeeChat 3.1]
heat has joined #osdev
dutch has joined #osdev
KidBeta has quit [Read error: Connection reset by peer]
tricklynch has quit [Ping timeout: 272 seconds]
<heat>
good afternoon high intellect individuals
<gog>
:(
<gog>
thanks for excluding me
tricklynch has joined #osdev
tricklynch has quit [Read error: Connection reset by peer]
tricklynch has joined #osdev
tricklynch has quit [Read error: Connection reset by peer]
tricklynch has joined #osdev
tricklynch has quit [Read error: Connection reset by peer]
tricklynch has joined #osdev
hgoel_ has quit [Remote host closed the connection]
flx-- has joined #osdev
aquijoule_ has joined #osdev
lleo has quit [Read error: Connection reset by peer]
flx- has quit [Remote host closed the connection]
aquijoule__ has quit [Remote host closed the connection]
<renopt>
good morning everyone
<renopt>
>:O
isaacwoods has joined #osdev
<gog>
<:0
Brnocrist has quit [Ping timeout: 244 seconds]
Brnocrist has joined #osdev
<heat>
everyone except gog of course
decartes has joined #osdev
Geertiebear has joined #osdev
dormito has quit [Quit: WeeChat 3.1]
dormito has joined #osdev
mctpyt has quit [Ping timeout: 264 seconds]
vdamewood has joined #osdev
mctpyt has joined #osdev
flx-- has quit [Remote host closed the connection]
flx- has joined #osdev
<heat>
i could be writing code and being productive but I'm stuck here looking at build systems ahhhhhh
<gog>
just use makefiles
<heat>
no
<heat>
makefiles are bad
<gog>
i know
<heat>
i will also never ever use autotools
<gog>
agreed
<gog>
autotools is very bad
<zhiayang>
honestly i'm thankful that autotools exists
<zhiayang>
do i want to write those autoconf files? hell no
<zhiayang>
but it's really miraculous that i can go to some sparc system running 15 year-old solaris and still, `./configure; make all; make install` will work
<heat>
right now my options are: 1) GN, which I already more or less know how it works but is very googly and chromy; 2) Bazel, also very googly but simpler and way more widespread; 3) Meson, which is also used a bunch; 4) cmake, which is very widely used but fuck me the syntax is garbage
<zhiayang>
what are you buildign
<heat>
my whole OS lol
<gog>
i tried cmake once and trying to massage it to build bare metal stuff is a little annoying
<zhiayang>
hmm
<zhiayang>
why have you just ruled out makefiles
<zhiayang>
other than "makefiles are bad"
<heat>
because they are bad
<zhiayang>
because...?
<heat>
very bare bones and solve absolutely nothing
<zhiayang>
you're building an OS
<zhiayang>
what do you need to solve
<gog>
he wants to depend on other build systems without knowing the details of the build system
<heat>
also that but
<heat>
if I want to add a package that depends on other packages, I'd like to do it seamlessly
<heat>
I want to add build targets without explicitly writing a whole bunch of boilerplate like you usually need to
<zhiayang>
i doubt you'll find something like that
<zhiayang>
if you do let me know because i want it too
<zhiayang>
as long as it doesn't start with "cm" and end with "ake"
<heat>
all the options I listed are more or less this
<zhiayang>
cmake? simple?
<heat>
depends
<zhiayang>
i despise cmake
<heat>
the only build system I listed that doesn't generate ninja files is bazel
<zhiayang>
(what is GN btw)
<Geertiebear>
meson is really nice
<Geertiebear>
i can vouch for meson
<heat>
zhiayang: build system for chromium, v8, fuchsia, and a bunch of other build systems
<heat>
of other google projects I mean
<zhiayang>
i see
<meisaka>
I wonder if scons would work for an OS
<gog>
i used scons in one of my very early experiments
<gog>
it was OK
<heat>
i was trying out going for gn but damn the complexity is overwhelming
<zhiayang>
maybe i'm just old but i think make is a good level of abstraction sitting between "literally writing a shell script" and "the build system does everything for you"
<j`ey>
gog: i hated scons
<gog>
it's not great
<heat>
everything is so damn configurable but the issue is that you need to configure everything and I don't have insider access to gn nor chromium people
<zhiayang>
the concern is that the "simpler" the build system gets, the more impossible it is to get it to do something that's not "normal"
<gog>
it was a little easier than cmake to get to make bare metal stuff
<gog>
but still suboptimal
<heat>
bazel is very samie in terms of syntax but way more widespread which is super nice
<MrBonkers>
Might not be exactly what you’re looking for but maybe xbstrap (https://github.com/managarm/xbstrap) can fill in at least a part of the role that you’re looking for. Managarm uses it to orchestrate the entire build process and afaik it works with all build systems (disclaimer, as a regular contributor to Managarm I might be slightly biased)
<bslsk05>
managarm/xbstrap - Build system for OS distributions (7 forks/27 stargazers/NOASSERTION)
<heat>
MrBonkers: I would guess it mindlessly tries to rebuild every package?
<heat>
which is the only sane way the more I think of it
<Geertiebear>
wdym with mindlessly rebuild?
<heat>
you never get a "ninja: no work to do"
<MrBonkers>
Well no, if the package is already build it won’t rebuild it unless asked. On the ci server this is only the case when versions change, revisions are bumped or (for some packages, like the kernel and libc) a commit is pushed to master. Locally, that would only happen if the user requests it
<MrBonkers>
We do actually, managarm uses ninja for it’s own projects so unless reconfigured it will only rebuild what has changed
alexander has quit [Ping timeout: 264 seconds]
MarchHare has joined #osdev
flx- has quit [*.net *.split]
Geertiebear has quit [*.net *.split]
Brnocrist has quit [*.net *.split]
Oli has quit [*.net *.split]
Mikaku has quit [*.net *.split]
xenos1984 has quit [*.net *.split]
opios2 has quit [*.net *.split]
ids1024 has quit [*.net *.split]
paulbarker has quit [*.net *.split]
kazinsal has quit [*.net *.split]
kingoffrance has quit [*.net *.split]
brown121407 has quit [*.net *.split]
catern has quit [*.net *.split]
FireFly has quit [*.net *.split]
merry has quit [*.net *.split]
flx- has joined #osdev
flx- has quit [Remote host closed the connection]
merry has joined #osdev
flx- has joined #osdev
kazinsal has joined #osdev
smarton has joined #osdev
xenos1984 has joined #osdev
Mikaku has joined #osdev
Oli has joined #osdev
mingdao has joined #osdev
Brnocrist has joined #osdev
srjek|home has quit [Quit: Leaving]
xenos1984 has quit [*.net *.split]
flx- has quit [*.net *.split]
kazinsal has quit [*.net *.split]
Affliction has quit [*.net *.split]
tenshi has quit [*.net *.split]
zagto has quit [*.net *.split]
junon has quit [*.net *.split]
sortie has quit [*.net *.split]
sm2n has quit [*.net *.split]
Amanieu has quit [*.net *.split]
johnjay has quit [*.net *.split]
kazinsal has joined #osdev
Amanieu has joined #osdev
junon has joined #osdev
sm2n has joined #osdev
zagto has joined #osdev
flx has joined #osdev
sortie has joined #osdev
srjek has joined #osdev
xenos1984 has joined #osdev
Geertiebear has joined #osdev
Oli_ has joined #osdev
iorem has quit [Quit: Connection closed]
Oli has quit [Ping timeout: 264 seconds]
tenshi has joined #osdev
kingoffrance has joined #osdev
srjek|home has joined #osdev
srjek has quit [Ping timeout: 252 seconds]
alexander has joined #osdev
gog has quit [Quit: bye]
redeem has joined #osdev
gog has joined #osdev
vai has quit [Remote host closed the connection]
srjek|home has quit [Read error: Connection reset by peer]
flx has quit [Ping timeout: 264 seconds]
<heat>
i just had a great revelation: no bazel
<heat>
that requires java and fuck me if I need to port java to my OS
paulbarker has joined #osdev
<j`ey>
heat: 1 down
amj has quit [Quit: WeeChat 3.0]
amj has joined #osdev
pretty_dumm_guy has joined #osdev
alexander has quit [Ping timeout: 245 seconds]
<heat>
i hate this
<zhiayang>
make is written in C (:
<zhiayang>
though i suppose it isn't a lot of extra effort to get c++
<heat>
i have C and C++ support lol
<heat>
my OS already exists
<heat>
i'm just trying to fix its deeply broken build
<Geertiebear>
are you looking for a build system to build your kernel or the whole distro?
<heat>
the whole thing
<heat>
right now I have a frakenstein of a thing that has the root build as a makefile, the kernel as a makefile, musl(libc) is a ./configure & make, large parts of userspace are gn but two or three big targets are really just wrappers around a PKGBUILD-like shell script that calls make
<Geertiebear>
i'd heavily recommend xbstrap
<Geertiebear>
it's the simplest way of building a custom distro
<Geertiebear>
it is in python tho but that also isn't too hard to port
<froggey>
only one thing to do: write your own
<immibis>
you can write your own script to generate a ninja script (you can also do that with make)
<immibis>
that would be an unopinionated option
<j`ey>
Android had a Makefile -> Ninja thing
tricklynch has quit [Ping timeout: 252 seconds]
koon has joined #osdev
<heat>
Geertiebear, I would rather not depend on a custom tool that I don't control and is poorly documented
tricklynch has joined #osdev
amj has quit [Quit: WeeChat 3.0]
<Geertiebear>
heat: that's a fair point, documentation is lacking right now
<Geertiebear>
but properly building distro's is not too simple (to do elegantly) so in this case i'd much rather use xbstrap than roll my own
<kc8apf>
As far as bazel-likes go, Buck also requires Java. Pants v1 (https://v1.pantsbuild.org/) is fairly self contained and has moderate support for a variety of languages.
<bslsk05>
v1.pantsbuild.org: Pants: A fast, scalable build system
<kc8apf>
Then there is bitbake......
<kc8apf>
I've also seen Conda abused in all sorts of ways
<nur>
okay so I am still stuck on debugging this interrupt routine handler, a default one that just calls my printk... and I know it's not the IDT because it WAS working before I decided to try to pass the registers as a struct into the C function from an assembly function
<heat>
what you're doing in that function is possibly incorrect
<heat>
tip:
<heat>
do your pushad and all the other cute pushes everyone does, then align your stack and call your C code
<nur>
oh
<heat>
I honestly don't know how stack alignment works for stack-based argument passing so I can't help you there
<heat>
also, passing a pointer is way better than doing it by value
<nur>
but when the interrupt handler is called, the stack pointer could be anywhere
<nur>
why do the alignment after
<nur>
shouldn't it be before
<doug16k>
if you passed registers_t * to the interrupt handler, then you could easily realign the stack before calling it
amanita has joined #osdev
<nur>
wouldn't the stack pointer need to point to where registers_t is at though
<heat>
pushstuff; mov %esp, %eax
<heat>
then align your stack and push %eax
<doug16k>
^
<doug16k>
you need it to be aligned after the argument push
<nur>
so I don't need to pad the struct then?
<heat>
no
<nur>
interesting
<doug16k>
easy way is to first make enough space for the most stack arguments you need, then AND esp with -16 to align it, then mov the arg to (%esp), then call
<nur>
let me try
<nur>
doug16k, I will of course need to save the original esp before I make this space right
<doug16k>
right
<doug16k>
in a callee saved register. ebx, esi, edi, or ebp
<doug16k>
handler will preserve it for you
srjek has joined #osdev
<nur>
ah I was using eax
<nur>
and manually saving eax
<nur>
ebx is "safe"?
<heat>
if you pushed it
<nur>
well I can use eax too right
<nur>
why ebx, esi, edi or ebp?
<heat>
oh wait ebx is callee saved I think
<nur>
what is... callee saved
<heat>
a function that is called needs to preserve some specific registers to comply to the ABI
<heat>
where preserving means the called function pushes and pops it when it needs to use it
<nur>
ah and my called function is a C function that will do this
<heat>
yes
<nur>
NEAT
<nur>
I did not know this
<heat>
heat*
<nur>
well yes
flx has joined #osdev
<nur>
BUT I still need to push ebx before I use it in the interrupt handler because it might still be in use when the ISR was called
<nur>
and I can't just clobber it
<nur>
right?
<heat>
yes
kee has joined #osdev
<nur>
thanks
<nur>
let me try and wrap my head around why it might work
amanita has quit [Ping timeout: 268 seconds]
<nur>
question: does the frame pointer factor into this somehow
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
<heat>
no
<heat>
when the ABI says "the stack must be 16 byte aligned on function entry" it really means "the stack must be 16 byte aligned before the call instruction
<heat>
every function has an 8 byte(on 64-bit) stack-misalignment on its first instruction
<heat>
which usually gets fixed by the simple push %rbp
<heat>
on 32-bit the math is different but the concept is the same
<nur>
ah I see
opios2 has joined #osdev
* gog
meows
* moon-child
pets god
<heat>
don't touch god
<doug16k>
nur, you don't load ds or es with anything, and you forgot to cld
<doug16k>
user code could screw over that isr with this: xor %eax,%eax ; mov %ax,%ds ; mov %ax,%es ; std ; lol: jmp lol
<doug16k>
abi requires eflags.df=0 before call too
mctpyt has quit [Ping timeout: 264 seconds]
<doug16k>
and ds base == cs base == es base == ss base
<doug16k>
ds es usable
* transistor
meows
FireFly has joined #osdev
<doug16k>
need to move your kernel ds selector into ds and es and add a cld
z_is_stimky has joined #osdev
<doug16k>
interrupt will have the right ss already. push will use ss automatically so it will work before you fix up ds es
mctpyt has joined #osdev
<geist>
had a realization last night: in the summer if you dont live on the equator the moon is lower on the horizon when it's full than the winter
<geist>
had to ponder orbital mechanics a bit but it makes sense
<geist>
it's basically low enough on the horizon here that i dont really see the moon at my house when it's full because it's in the trees
<GeDaMo>
I'm far enough North that the sun is rising in the North East at the moment
<geist>
GeDaMo: oh? about how far north?
<geist>
i'm at about 47.5N so it's far enough that summer days are pretty darn long
<GeDaMo>
57°N
<geist>
though that's really no big deal compared to most of europe
<gog>
64.5°N
<doug16k>
geez
<gog>
sun makes most of a circle across the sky rn
<geist>
woot. gog: when is sunset there?
<gog>
geist: NaN
<gog>
:p
<geist>
well it sets, but i guess you never leave twilight
<geist>
you'd have to be within the artic circle for it to technically never set
<geist>
so yeah you're right at the arctic circle huh
<gog>
civil twilight is the only twilight rn
<geist>
doug16k: oh you're in that part of canada that the US is actually higher than (ignoring alaska)
<doug16k>
43.54
<gog>
only about 4 hours worth
<doug16k>
yeah usa goes slightly north of that
<FireFly>
civil twilight, better than unruly twilight
<doug16k>
main part
<geist>
doug16k: right. most folks in the us dont realize that seattle, and in genera anything along the long border w/canada is more north than maine even
<geist>
and north of most of ontario, etc
<geist>
well the populated parts of ontario
<gog>
i like that little part of minnesota that juts over the border
<gog>
lake of the woods i think
<gog>
so there's a part of minnesota that technically can't be accessed by car without crossing through canada
<geist>
but anyway it never occurred to me that the position of the moon along the eliptic would put it very low on the horizon at night in the winter
<geist>
which makes sense, because when it's full, it's opposite the sun
<geist>
and thus is on the opposite part of the eliptic
<geist>
in the case of gog you'd just never see the moon presumably
<geist>
at best it'd just be under the horizon, opposite the sun
dennis95 has quit [Remote host closed the connection]
<geist>
but you can see how anything north of the hump gets no night
vdamewood has joined #osdev
<geist>
oh neat it visualizes where the moon is too, and since it's mostly full it's opposite (180 degrees east/west and on the opposite side of the equator)
<geist>
plus whatever +5 degree additional tilt the moon's eliptic is off of the earths, and i dont know what phase that is
<bslsk05>
'Roland SC-88 Sound Canvas Demo' by Yappri Japan (00:02:17)
<geist>
oh it was the roland MT-32 I was thinking about. when i was little lots of games supported it (it was just general midi over a parallel port i think, or maybe serial)
<geist>
but it was the gold standard of game music on PC
<GeDaMo>
I think the MT-32 came out before General MIDI was defined
<geist>
yah funny, literally watching a video about it righ tnow
<kazinsal>
yeah those are really cool
<kazinsal>
excellent sound for the time
<kazinsal>
I love those videos where someone hooks up a Sierra game from the late 80s/early 90s to like, a dozen different sound chips working their way up from PC speaker to MT-32
<geist>
yah
<geist>
looks like MT-32 was 1987 and general midi came along in like 91-92
<kazinsal>
oh, not sure if you saw geist but I did end up fixing my e1000e driver last night :)
<geist>
cool
<kazinsal>
turns out I had an off-by-one error this entire time and the non-e e1000s just silently accepted it.
<geist>
spent some time yesterday breaking apart some 'single console' assumptions in LK that i've been meaning to deal with forever
<geist>
i had 'fixed' it on some other branches but never made it back into mainline
<kazinsal>
awesome
<geist>
but it's messy: one of the pros of the current solution is printf() works anywhere in the kernel, inside interrupt handlers, regular code, etc
<geist>
but. what i really need to do is properly redirect printf through a handle so i can run separate threads that redirect their output to a socket, etc
<geist>
but then that means i *probably* should grow something like kprintf vs printf an then basically demand low level deep kernel code use the former
<geist>
which is easy enough to mechanically do, but i dunno about all the folks downstream what their code will do
<geist>
so i'm trying not to excessively break folks that are using the codebase
<kazinsal>
yeah, right now I have a similar issue; printf() implicitly writes using current_terminal->WriteBytes() but there's only ever one current_terminal across CPUs and it's pretty much assumed to mean "whatever's hooked up to the serial port"
<geist>
right. so what prompted this is i was doing some tcp/ip work and i want to bust out a quick n dirty telnetd
<kazinsal>
so in theory it's fairly ready to shove into multiple terminals but the current_terminal is a global
<kazinsal>
yeah
<geist>
which would start a new shell. no problem, can create a new shell, but i need printfs that are run as a by product under that shell or any threads it spanws to redirect back to the socket instead
<geist>
yah i just went through and set basically the current_terminal is a TLS thing
<geist>
not exactly a process or file descriptor per se, but this is within a single address space kernel,
<geist>
so it's kinda like a pseudo process
<geist>
and set it up such that new threads inherit the TLS pointers from the parent
<kazinsal>
gotcha
<geist>
so i'm debating. i think i'll add a kprintf() that directly goes to the 'console' which will continue to be defined as 'whateer the platform feels like the console is'
<geist>
probably vga text and/or serial/etc
<geist>
then have the default stdin/stdout handle redirect to that, but if you printf inside some deep kernel code it will assert and tell you to use kprintf instead
<geist>
and hopefully i dont break too many people downstream
<doug16k>
they probably felt funny calling the other one and will be relieved to call something that seems reentrant
<geist>
the real question is whether or not the default stdout handle will attempt to dynamically fall back to kprintf like stuff or if it's an assert and fix code issue
<geist>
it does kinda makes sense though to have two levels of printf in a codebase like this: it's a single blob of code, but some stuff like panic messages or exception printfs or whatnot should not attempt to be fancy about getting their bits out
<kazinsal>
I guess the best way I can quickly patch mine up would be to replace current_terminal with eg. active_tasks[my_cpu]->terminal
<geist>
but 'regular' printfs can be as part of some embedded app that's trying to just do stuff
<kazinsal>
so that each task can be attached to its own terminal/file/whatever
<geist>
yah question is what is a task in your system
<geist>
I suppose i could do something like that: add some cheezy task_t that is nothing more than a collection of threads + some handles to stdout/etc
<geist>
and have a dynamic switch that says 'if i'm inside an int handler, use the global kernel task'
<geist>
ut if you simply ignore it new threads inherit the existing task and that's totally okay. hmmm...
<kazinsal>
yeah, my architecture is a bit less normal. a CPU grabs the next task out of the queue and runs it until it returns. no preemption except in case of an exception
<doug16k>
there is a name for that. you can make posix do that
<kazinsal>
under the assumption that you aren't going to be spending a bunch of time in a task. supposed to be doing things quickly like forwarding a packet or processing headers
<doug16k>
you only context switch when you have no other choice
<j`ey>
kazinsal: but d you reschudule on exception except?
<j`ey>
exit
<j`ey>
i suppose not
<kazinsal>
depends on the severity of the exception
<kazinsal>
if it's a "this task is corrupt", then the task is killed and the next one is grabbed out of the queue
<kazinsal>
if it's a "this CPU is corrupt", then the queue is paused until the CPU is rebooted
<moon-child>
how can you tell if the cpu is corrupt?
<doug16k>
kazinsal, do tasks block and cause it to have to grab another task to run while blocked one is not done?
<kazinsal>
usually reserved for MCEs, stack smashing, etc
<kazinsal>
doug16k: user tasks yes, kernel tasks no
<kazinsal>
kernel tasks are expected to operate on a given set of data
<sortie>
Hello osdev
<kazinsal>
hey sortie
<gog>
howdy
<doug16k>
I define it so the user can't block, they syscall, and kernel thread hosting that user code blocks. it's all kernel threads, a user thread is just a kernel thread that happens to be in user mode
<kazinsal>
ah, yeah, that makes sense
<kazinsal>
I have user mode tasks on their own CPUs
<sortie>
Yo gog
<sortie>
And yay kazinsal
<kazinsal>
kernel tasks are specifically for things that need to be as performant as possible because they're operating on known factors
<sortie>
osdeving much?
<sortie>
Err that sounded a bit sarcastic and was more like a ‘what's up?’
<kazinsal>
sortie: oh, yeah. fixed my e1000 driver last night (well, technically at 2am) to not have a bug that was being ignored by 8254x chips but not 8257x chips so I now support a lot more NICs than I previously did
<gog>
not lately lol
<kazinsal>
which is good because everything has 82574s in it now
<sortie>
kazinsal: Oh wow that's excellent :)
<kazinsal>
or some derivation thereof
<meisaka>
I'm writing a network stack :3
<sortie>
I should learn from you, drivers still scare me
sortie has left #osdev [Leaving]
<kazinsal>
it's okay, my driver format is *terrifying*
sortie has joined #osdev
<sortie>
^W
<kazinsal>
haha whoops
<kazinsal>
also ended up improving a few bits in my build system to properly support my build server
<sortie>
Sweet, like what?
<meisaka>
at least you have a build system
<kazinsal>
a bit of static module support so I can drop in new modules by just adding a list of object files to a module name, as well as arch-specific ones if needed
<kazinsal>
so now I can have it spit out multiple arches in theory with one build command
* sortie
spits out an arch
<sortie>
That's excellent, love great scripting
GeDaMo has quit [Quit: Leaving.]
tricklynch has quit [Ping timeout: 245 seconds]
<kazinsal>
if you tell it to build an i686-generic target it'll go check what the modules for i686-generic are, then for each of those it'll build everything in the SOURCES_MODULE_<modname> list and everything SOURCES_MODULE_<modname>_<arch> if exists
<heat>
this is making me very sadge
<heat>
today i lost all hope for a good build system
mingdao has joined #osdev
mingdao has quit [Changing host]
<heat>
wanna trade?
tricklynch has joined #osdev
<kazinsal>
if you pass the build script arguments like "arch i686 target generic modules foo,bar clean iso" then it'll do a make clean, set the arch and target, set the module list, build the kernel with the default modules for i686-generic, then build and link in the modules foo and bar, then spit out a live test ISO
<kazinsal>
it'll also auto-detect how many threads to use for make -j
xenos1984 has quit [Ping timeout: 252 seconds]
<kazinsal>
and tell you if you're missing required programs and what package you should probably be able to find them in
<kazinsal>
and as an extra cherry on top it now spits out a nice built-by string and throws that in the boot banner
<kazinsal>
"[notice] <kernel.boot> Starting i686-generic ARE 0.9.4-dev+d34131e, built by troy@build.dev.araxes.net on May 29 2021."
tricklynch has quit [Ping timeout: 268 seconds]
<kazinsal>
also discovered that the build server, despite having fewer cores at less than half the clock speed than my desktop, is faster at building the OS because WSL1's I/O speed is really *that* bad
tricklynch has joined #osdev
<kazinsal>
and while I was at it I threw together a couple scripts to scp a fresh ISO to both my desktop and my ESXi host for testing
<kazinsal>
since Windows now just straight up supports sshd
<heat>
i watched the champions league final
<heat>
so much progress today
zagto has quit [Quit: Konversation terminated!]
gog has quit [Quit: bye]
xenos1984 has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<geist>
kazinsal: side note: what esxi are you using? the freebie one?
<geist>
i endedup moving off of it to just using qemu on a host machine, but it was mostly because iw anted to consolidate to a single new machine
Oli_ has quit [Ping timeout: 265 seconds]
<kazinsal>
geist: heh, i have a cron job running on it that resets the eval license every 24 hours so I have a perpetual eval license
<heat>
lol
<kazinsal>
in the near future i'm going to grab a proper lab kit license since they're only 200 usd/year
<kazinsal>
for the whole vmware stack
<geist>
yah that seems where it gets kinda powerful
<geist>
with just an esxi license you can't to the centralized vcloud or whatever it's called stuff
<geist>
which seems where it gets pretty nifty
<kazinsal>
the free ESXi perpetual license is great but only supports 8 vCPUs per guest
<geist>
you're always doing stuff command line and via their fairly dinky esxi web ui
<kazinsal>
and doesnt support forwarding guest serial ports to tcp on the host
<geist>
right
<geist>
i did remember it was fairly powerflly nice to be able to share disk images and routine serial ports between guests
<kazinsal>
I wanted to be able to netcat to a port on the ESXi box and get the VM's serial console
<geist>
so you can sort of do it anyway by having your OS build server be on one guest, write out disk images to a shared disk image and then boot the second one
<geist>
but... iirc the serial port routing betweenVMs was extremely difficult to set up because of a bunch of undocumented implicitisms
<kazinsal>
which you can configure in the UI with the free license but it just complains in the log when you boot the VM and just connects the com port to nothing
<geist>
took me hours to get it working
<geist>
yah exactly. a bunch of that kinda stuff,e venb etween vms
<kazinsal>
yeah
<geist>
you give it a named pipe, doesn't work. named pipe has to be made in this order, named according to this pattern, etc
<geist>
stuff that's entirely undocumented
<kazinsal>
another thing you can't do on the free license is vlan pruning on trunk ports
<geist>
as if it was intended to be driven by an external UI
<geist>
anyway it was a nice setup, but i eventually just decided to fuck t and switch back to manually running N qemu instances on a shared bridge
<kazinsal>
if you tell it a VM has a vlan trunk on one of its ethernet cards it gets *every* vlan the host sees
<kazinsal>
need the vSphere Distributed Switch feature to prune it down
<kazinsal>
which really is meant for synchronizing VLANs and port groups and such across multiple ESXi hosts and datacenters
<geist>
yah
dhugo has joined #osdev
dhugo has left #osdev [Leaving.]
<kazinsal>
another annoying thing is that vmware workstation chooses your NIC type for you
alexander has quit [Quit: Goodnight o/]
<kazinsal>
based on what guest OS you tell it the VM is running
<geist>
yah agreed. i havea license to vmware workstation but it's not as nice as i'd like. it's a solid VM but more hard coded than i expected
<geist>
vs something like virtualbox which is not asnice VM but more configurable generally
<geist>
like virtualbox i think the real key is to hack the vm config file with a text editor
<geist>
and then i thnk you can make it do whatever you want
<kazinsal>
yeah, and thats where the documentation gets thin
<geist>
also i remember being dissapoint that vmware workstation doesn't seem to have any TRIM support with its disk devices
<geist>
even virtualbox has that, though you have to jump through soem hoops
<kazinsal>
what's really bizarre about virtualbox to me is that it supports three different 8254x cards but nothing newer
<geist>
though it does have virtio-nic
<geist>
(i think)
<kazinsal>
yeah
<geist>
there's some weirdo stuff with virtio-blk and nvme on virtualbox.w here it's there but they dont recommend it
<kazinsal>
need to sit down one of these days and read the virtio spec
<geist>
like, do they not recommend it because it's unsupported/unstable?
<geist>
or ...
<geist>
otherwise in general that's almost certainly the best potential emulated block devices
<kazinsal>
yep. they seem really simple and effective
<geist>
yah virtio is nice to deal with. there's an up front cost of writing the basic virtio detection and ring code
<geist>
but once you ahve that you've got the bottom layer for a plethora of additional devices you can build out of it
<geist>
so i do recommend writing it as two layers like that
<kazinsal>
cool, so theres a standard ring buffer system that you implement and everything else plugs into it then?
<heat>
yes that's more or less how I did it too
<geist>
basically yeah. tghe ring buffer just transfers buffers back and forth and has a doorbell and IRQ mechanism
<kazinsal>
nice
<geist>
and then device drivers use one or more rings for their business
<bslsk05>
github.com: Onyx/kernel/drivers/virtio at master · heatd/Onyx · GitHub
<kazinsal>
I still don't fully trust my e1000e to flip it over to MSI
<heat>
shameless plug for my beautiful amazing code
<geist>
virtio-blk is one of the simplest actually since it's simple a series of transactions with a { header, data, response } transfer
<geist>
and data can either be read or write
<heat>
oh you just gave me a task
<heat>
fix my virtio-net and add blk
<geist>
yah i did blk first. net is a teensy bit more complicated because it uses two rings iirc
<geist>
though that's what you want: functionally two independent pipes
<geist>
virtio-gpu and virtio-serial are a bit more complicated because there's a second layer of messages and state machine to deal with
<geist>
and a few messages worth of handshake
<geist>
havent' looked into virtio-input. i suspect it just starts sending you formatted messages right off the bet
<heat>
i looked at virtio-gpu but I got disappointed once I realised vulkan support isn't quite there
<heat>
although they were working on it. dunno how that's changed
<geist>
well, it might be but may be outside the spec
<geist>
ie, virtio-gpu may simply be the transport for a higher level vulkan thing. somehow the fuchsia emulator punches vulkan through, but i honestly dont know precisely how and/or if it's standard
<geist>
yah dunno if fuchsia emu is using that, or has anything to do with it?
<kazinsal>
i am such a terrible graphics programmer that i wouldnt even know where i would start on gpu stuff
<doug16k>
opengl 3.3 is plenty
<doug16k>
can make a super high speed desktop with just that
kee has quit [Quit: ⭘]
<heat>
having opengl means you need opengl logic and I'm not so sure I'd want to handle that
<doug16k>
it can put buffers in the device. that is why it is fast
<heat>
porting mesa would work I guess?
<kazinsal>
gimme that in kernel cuda
<kazinsal>
write a firewall for a GPU
mctpyt has quit [Ping timeout: 245 seconds]
<doug16k>
virtio handles a lot of opengl for you
<doug16k>
you are at buffer and state change and draw call raw api level
<doug16k>
but it's still draw triangles or strips or whatever like opengl draw calls
<geist>
yah would be kinda fun to figure out te minimum you need to just jam some simple GL draw calls over it
<doug16k>
it's vir "gl" right? it's a wrapper around host opengl
<geist>
like 'i just wanna blit this'
<doug16k>
in opengl, the mindset is already that the renderer might be so far away it could even be over the network
<doug16k>
it is far away, through miles of pcie wires :P
<doug16k>
opengl is perfect for virtualization already
<heat>
that's X11, not opengl
<doug16k>
opengl has the render device and client decoupled just as much
<moon-child>
it's both
<heat>
X11: because everyone has really weird setups right?
<doug16k>
display list is the sequence of stuff you send over the network
<heat>
it's like the one piece of software that's optimised for the uncommon case
<doug16k>
that you avoid sending because it is a display list I mean
<doug16k>
my point is opengl is expecting the device memory to be in a far away land
<doug16k>
so it is a simple matter of wrapping kvm physical page access to let you use host opengl
<doug16k>
say if you write only map a buffer and host opengl actually points you at device memory, it could make your kvm page use what page host opengl wants you to write
<kazinsal>
definitely simplifies some things
<doug16k>
it's more write-only than that though. mostly binding your buffers that you bound to things
<doug16k>
bind the vertex buffer and do draw triangles
<doug16k>
I need to finish all the regressions I caused and do the opengl part of my virgl driver
<doug16k>
partially done
<doug16k>
I think froggey got draw triangle working in lisp or another slightly esoteric language?
<doug16k>
in virtio-gpu virgl
<kazinsal>
part of me wants to port or write an audio stack but there is no reason for a firewall to have one
<doug16k>
kazinsal, more klaxons needed
<kazinsal>
unless i decided i really REALLY hate myself and want to write a voip solution
<doug16k>
network gear needs klaxons doesn't it?
<heat>
ICMP pings should trigger a sound
<kazinsal>
haha, audible whoops when you send a command to blink the LEDs as an identify method
<kazinsal>
"marco.... marco..."
<kazinsal>
your fibre run gets cut and every bit of network gear in the dc screams in horror
<doug16k>
get some text to speech working and make it keep saying, "packet drop detected" with starcraft administrator voice
qookie has quit [Ping timeout: 265 seconds]
<kazinsal>
"you require more throughput licenses."
<heat>
hey google, block any packets coming from 145.123.1.0/24 TCP port 22
<Brnocrist>
OK
<doug16k>
"you can do that in the app!"
<doug16k>
in other words, YOU do it
transistor has quit [Quit: brb]
transistor has joined #osdev
<doug16k>
no matter how amazing they make it, we'll still find things it doesn't handle
amanita has joined #osdev
amanita has quit [Quit: Lost terminal]
mctpyt has joined #osdev
<kazinsal>
alexa, make my network secure. *WAN port shuts off*
amanita has joined #osdev
<kingoffrance>
open the pod bay doors alexa
Oli has joined #osdev
amanita has quit [Ping timeout: 265 seconds]
<kingoffrance>
apparently they covered that, but what if you ask from space
<kingoffrance>
then, you can probably submit a bug report
<bslsk05>
github.com: Mezzano/intel-gma.lisp at master · froggey/Mezzano · GitHub
sortie has quit [Quit: Leaving]
heat has quit [Remote host closed the connection]
heat has joined #osdev
riverdc has joined #osdev
<riverdc>
hi all
<riverdc>
is it recommended to stick with 32bit architectures for a first project? i was planning on targeting the recent raspberry pi models which I only just realized are 64bit
<moon-child>
64-bit is fine
<doug16k>
32 bit arm is more difficult than 64 bit, I thought
<riverdc>
k thanks
<riverdc>
doug16k: how so?
<heat>
the ISA is probably way more dated
<doug16k>
32 bit has much more complicated things for you to know when handling interrupts/exceptions
<heat>
also arm64 has division, arm32 doesn't I think