thinkpol has quit [Remote host closed the connection]
thinkpol has joined #osdev
vdamewood has joined #osdev
crm has quit [Ping timeout: 240 seconds]
<geist>
well been looking at it
<geist>
it's not running LK :( but it seems to be riscv
<geist>
gsp.bin is a straight up riscv64 ELF file, though stripped
<geist>
looks like the core doesn't support compressed instructions FWIW
<klange>
imagine being a position where you can be disappointed it's not running _your_ thing ;)
<geist>
i do know that nvidia does like to generally use LK, but seems to be mostly in the Tegra department
<heat>
from what I've read in #dri-devel they were speculating that the newer archs got open-sourced because they have riscv cores
<heat>
which make them able to do a lot more stuff
craigo has quit [Quit: Leaving]
<heat>
(possibly, the stuff they don't want to open source)
<geist>
yah that's what graphitemaster was saying. you can move the secret bits into riscv and now the kernel driver may be sending more high level stuff to it
<geist>
it's not ideal, but it does mean you can at least use say iommus or whatnot to keep it from doing damage
<clever>
that kinda sounds like how the old broadcom GL stack worked on the rpi
<geist>
since at least that part of it that's interacting with the kernel is known
<heat>
unfortunately this driver really can't be open sourced in its current state
<clever>
where the opengl library was just an RPC shim, forwarding nearly every api call to the firmware blob
<Griwes>
yes, a non zero chunk of the binary blob kernel driver has been offloaded to the on-board cpu, and that's a reason why all this is feasible in the first place
<Griwes>
and arguably a lot of what has been offloaded should've been in firmware in the first place :p
<heat>
the secret(tm) bits
<Griwes>
vOv call it what you want :P
Likorn has quit [Quit: WeeChat 3.4.1]
<Griwes>
there's always secret bits in almost any device you plug into your computer
<heat>
yup
<heat>
i honestly don't get why they're secret in the first place
<heat>
maybe I'm just too naive
<geist>
i am pleased to see that the firmware is not encrypted or otherwise that hidden
<geist>
someone can easily decompile it and try to figure out what its doing
Likorn has joined #osdev
junon has quit [Ping timeout: 240 seconds]
<heat>
clever, btw making direct opengl calls to a device sounds horrible
<Griwes>
eh, it's a piece of the card. that's the correct way to look at it. but I know that some people will make a crime out of not open-sourcing every goddamned bit of the product
<clever>
heat: its got kinda lower latency, due to the firmware core being on the same silicon as the arm core
hgoel[m] has quit [Ping timeout: 260 seconds]
chibill has quit [Ping timeout: 252 seconds]
Irvise_ has quit [Ping timeout: 252 seconds]
<heat>
Griwes, my way to look at it: it's just some firmware, is it really that critical to the IP and the card's performance?
<Griwes>
yes
<Griwes>
yes, it is
<clever>
in the case of the broadcom gl stack on the pi, it contains the GLSL->QPU compiler
<heat>
ok I stand corrected then
<clever>
so there could be secret sauce in its optimizer
<clever>
where you can make the shaders run better
<heat>
I'm mostly more picky with the machine's actual firmware, I don't really mind device firmware
<clever>
with a functional iommu, you can firewall off the device
<Griwes>
I believe that all of our compiler bits are in userspace driver libs
<heat>
like, memory training isn't rocket science, and so isn't an x86 board
<heat>
intel figured it out, amd did as well, so do other smaller companies
<clever>
Griwes: the rpi's mesa gl stack moved shader and CL generation into userland
gog has quit [Remote host closed the connection]
<heat>
shader compilation in userspace is the only way to do it tbh
gog has joined #osdev
<heat>
sane way
<clever>
the kernel driver just audits the CL's to ensure they are valid, and replaces opaque tokens with physical addresses
h4zel has quit [Remote host closed the connection]
<Griwes>
anyway, my main gripe is with people who somehow are fine with proprietary silicon, but not with proprietary bits of software on that same silicon?
<clever>
so you opengl cant abuse the 3d driver as an arbitrary physical memory write primitive
<Griwes>
and like, it's only in software because it was easier to do it that way than doing it in hw
h4zel has joined #osdev
<Griwes>
it's still an integral part of what's going on lol
<clever>
Griwes: my view on that, is that silicon cant change, so its less likely to be manipulated by an evil maid and turned against you
<Griwes>
but it could've been evil from the start
<clever>
where-as firmware blobs, could be doing almost anything, and change what they are doing when things get updated
<Griwes>
also "it can't change" is a lie
<clever>
yes, you do still need to audit it some
<clever>
i mean more like an upgrade in the future, containing a payload that specifically targets you
<Griwes>
there's bits you can flip and fuses you can burn through to change the hardware
<clever>
yep
<clever>
but can you change a fuse so it will catch fire when the string "Griwes" is discovered in ram?
<Griwes>
so I really don't get why there's this perceived fundamental difference
<clever>
with a firmware update, you could
<clever>
and with closed-source firmware, nobody is going to know
<clever>
but with open source firmware, the PR is going to get rejected, and never make it to any end-user
<Griwes>
there could be a hidden piece of hardware that could be programmable with a string
<Griwes>
"pr is going to get rejected" assumes that noone is going to be fed a malicious load that's not a direct build from the OSS source
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
<clever>
yeah, thats where other security comes in, either getting builds from trusted source or building yourself
<clever>
as for hidden hw, i would assume that a skilled user with a microscope can identify flash memory cells
<clever>
and fuses seem to be in tight supply
<Griwes>
you could have programmable "memory" with a series of fuses
<clever>
] otp_dump_all
<clever>
full otp dump
<clever>
00:00000000
<clever>
...
<Griwes>
there's ways to obfuscate
<clever>
66:00000000
<heat_>
do you have an example of closed source firmware being programmed in bad faith?
<clever>
the rpi hardware has 67 OTP slots, of 32 bits each
heat_ is now known as heat
<clever>
Griwes: so thats a total of 2144 bits worth of fuses
<clever>
heat: i cant think of any off the top of my head
<Griwes>
now compare the number of transistors in an rpi and in an H100 :P
<Griwes>
anyway a vendor publishing a malicious firmware load is a suicide
<heat>
clever, exactly
<Griwes>
and if it's a third party, it's arguably harder to create a malicious load when it's not open source
<clever>
Griwes: i would also assume that there is no erasable flash in any rpi silicon, given the lack of use and the need for an spi flash chip
<heat>
i'm not really worried about security
<clever>
Griwes: what if they are forced by court order to reveal the secrets to a TLA?
<clever>
or other govt agency
<Griwes>
to a three-letter acronym?
<heat>
three letter agency
<clever>
yeah
<heat>
CIA, NSA, FBI, etc
<clever>
yep
<clever>
they could force the secrets out of a company, then make their own malicious firmware
<clever>
and mitm it into your updates
<heat>
vote?
<clever>
?
<Griwes>
how is that different from them obtaining a court order to get themselves mitm'd into your trusted provider's update channel?
<heat>
if you disagree with the people that made those laws and gave all that power to those agencies, vote
<heat>
nothing is actually going to stop them yeah
<Griwes>
I beg you to not use that argument or I will become agitated
<Griwes>
(I've seen too many 'just vote' takes on twitter over the past two weeks and I'm already angry at all those people)
<clever>
Griwes: foss is more likely to use gpg ontop of https, and throw a bigger fit when somebody tried to force them to hand over the gpg keys?
<clever>
i would assume
<Griwes>
under a gag order?
<clever>
heat: what if i'm in the wrong country, say canada
<clever>
and the gpu i'm using was made by an american company
<clever>
i cant vote on what america is doing with those gpu secrets
<Griwes>
anyway I don't think there's a fundamental difference here
<Griwes>
if you want to be sure there's no backdoors, you need to make all of your hardware yourself
heat has quit [Read error: Connection reset by peer]
<clever>
Griwes: the other major factor, seperate from all of that mess, is customization
<gog>
brb building my own fab
heat has joined #osdev
<clever>
as an example, if you use the official rpi firmware, you dont have any control over what media the system is booting from
* Griwes
hands heat a znc
<clever>
so there is no way to just jam a copy of tianocore onto a bigger SPI chip, and make the system fully efi compatible
<heat>
my router is crap
<clever>
you must have a start4.elf on one of: sd/usb/nvme/tftp
<clever>
start4.elf on spi isnt a valid option
<heat>
anyway, as I said, I didn't want to agitate anyone :)
<clever>
heat: 2022-05-11 21:56:22 < clever> Griwes: the other major factor, seperate from all of that mess, is customization
<clever>
(you missed that line)
<heat>
i personally don't mind device firmware
<Griwes>
Customization has its own host of problems
<heat>
I do mind machine firmware
<Griwes>
What if I get a device with fully customizable firmware, replace it with a malicious load, and resell the device?
<clever>
and the rpi blurs the lines, because the firmware is required both to boot, and provides runtime services
<clever>
Griwes: in the case of the rpi, you can just boot an SD card with recovery.bin to re-flash the firmware, and its been clensed
<heat>
the rpi is crap in a cheap pcb
<heat>
the way you describe it, it makes me wonder at how that thing even boots
<clever>
heat: what makes it crap? the specs? the lack of docs? the firmware?
<heat>
yes
<heat>
:)
<Griwes>
How does a person who just wants to game and who just buys a gpu ensure they don't have malicious firmware on it?
<heat>
sign it
<heat>
and trust the vendor
<clever>
Griwes: thats a bit harder, there isnt a clear way to re-flash the firmware without first booting your system with it
<clever>
in the case of the rpi4(00), the 1st stage is signed by both an hmac-sha1 key and an rsa keypair
<Griwes>
Heat: I'm specifically talking about someone buying a second hand device
<clever>
but the hmac-sha1 is weak (i already know the key)
<Griwes>
Most people aren't savvy enough to run some magic commands to verify the firmware isn't malicious if you allow customization
<clever>
and the rsa isnt enabled by default
<heat>
cryptographically signed firmware yeah, make the GPU refuse to load any non signed firmware
<gamozo>
Until code isn't riddled with 10 billion security bugs, firmware being open kinda doesn't really matter for security. It's gonna have exploitable bugs kinda either way
<clever>
Griwes: that reminds me, ive seen a LTT video, where they bought a "dead" gpu off ebay, and i think it just had crypto mining firmware, which lacks video output
<heat>
do I want to customise my nvidia gpu's firmware? no, what's the point?
<clever>
they re-flashed it with the stock firmware, and boom, working gpu
<Griwes>
Yeah I think we're aligned on this, heat
<heat>
yup
<clever>
and signed firmware leads to new issues
<Griwes>
clever did bring the customization point up though :P
<clever>
if the firmware is signed, by which keys? how do you customize it then?
<Griwes>
You don't
<Griwes>
You either have strong validation from the vendor, or you have customization
<Griwes>
I really don't see how you can have both
<clever>
exactly
<clever>
the rpi4 kinda has both
<gamozo>
That's always a hard problem I've thought of in my head. What's the best way to control root keys on something like that, and I don't think there is one
<heat>
if you want the firmware to be open, you could have reproducible builds + signed
<clever>
Griwes: the 1st stage can be verified by a broadcom rsa keypair, it will then enforce that the 2nd stage matches a customer generated rsa keypair
<clever>
and the sha256 of that customer pubkey is held in OTP
<clever>
but its an optional thing, only recommended for industrial use on the CM4
<clever>
the only major complaint, is that broadcom holds the keys to the 1st stage
<Griwes>
Rpi *is* a very special case thing: a dev board / specialized device. In both those uses it doesn't really matter that much because people handling it know what they are doing to an extend
<clever>
so broadcom or a TLA could still modify it maliciously
<Griwes>
A gpu tho? Thing that gets resold to non tech savvy people?
<clever>
yeah
<clever>
once you enable CM4 secure-boot, its permanently on
<clever>
and you must know the private key to modify /boot
<clever>
if you loose it, its bricked
<heat>
anyway, point being that h i r e m e n v i d i a
<moon-child>
because they have no guarantee that the pointers do not overlap
<moon-child>
fwiw tcc uses memmove
<moon-child>
am I missing something?
<Mutabah>
might be strict aliasing?
<Mutabah>
not sure
<moon-child>
an S is always allowed to alias an S though...
<Mutabah>
(The compiler might be assuming that the two either perfecetly overlap, or don't overlap at all)
<moon-child>
oh, so then gcc is ok but clang is wrong?
<moon-child>
interesting
h4zel has quit [Read error: Connection reset by peer]
<heat>
clang is also right
<moon-child>
why?
<heat>
if two objects perfectly overlap, the memcpy will = rep movsq
<moon-child>
which memcpy?
<moon-child>
c spec sez: 'If copying takes place between objects that overlap, the behavior is undefined.'
<heat>
the one it's doing
<heat>
spec stupid
<heat>
none of this makes sense anyway because the alignment of S is 1
<heat>
the two objects can overlap as far as I can see
<moon-child>
'spec stupid' so? Doesn't mean you get to ignore it unilaterally; if you're in llvm's position, you have a contract with functions like memcpy, and that contract says you don't get to give them overlapping objects
<klange>
"overlap" is distinct from "are the same".
<heat>
making both gcc and clang wrong
<heat>
yes
<heat>
there may be something we're missing
<klange>
Which is an obtuse pedanticism, but important for the spec.
<moon-child>
klange: if they're the same, then they overlap completely. And spec literally specifies dest/src as 'restrict', which means they can't be the same
<klange>
And for once, the reason for non-equivalent overlapping things to be undefined is one that is obvious for everyone who has had a memcpy vs. memmove fuckup
<moon-child>
sure, I know how it can break in practice. That doesn't mean I think it's ok to break the contract just because it'll probably work fine
<graphitemaster>
<geist> i am pleased to see that the firmware is not encrypted or otherwise that hidden
bauen1 has quit [Remote host closed the connection]
<graphitemaster>
geist, should be noted that the security coprocessor stuff is separate from those cpus and that stuff is locked down hard
<graphitemaster>
plus the risc-v isa nv has is non standard so you need to reverse engineer instructions too :P
<geist>
makes sense. the riscv perhaps doesn't have much more ability beyond what was already done on the host
<geist>
possibly. i ran it through the dissassembler but i should run it again and see what instructions it couldn't decode
<geist>
but it's probably just assist stuff, so not likelky to be too difficult
<moon-child>
heat: re 'alignment of 1' I don't think it's legal for two S to alias each other, regardless of alignment
<moon-child>
though -fno-strict-aliasing doesn't change gcc's position...
<graphitemaster>
geist, some people have already tried disassembling the firmware and found some instruction encodings are disassembling to the wrong instructions but still decoding indicating nv switched the encoding around on some instructions and added instructions that share the same encoding as standard riscv ones
<graphitemaster>
little shuffled around *shrug*
<graphitemaster>
could just be bad decoding too though, no one knows what is different about it from standard riscv
<graphitemaster>
except nv of course
<geist>
yah though really smart people could almost certainly figure it out pretty easily. much more complicated reverse engineering of ISAs have been done
<geist>
alas, its not my wheelhouse. probably shouldn't due to work, etc etc
<graphitemaster>
yeah, plus there's the vbios on the gpu that you don't have access to either, since updates only ever patch that
<heat>
don't worry i hope you can still submit typo patches to the nvidia driver
<heat>
that's the only patches you'll ever need
<graphitemaster>
dunno if anyone has ever dumped that yet
<heat>
those are*
<graphitemaster>
the nouveau people have been talking about a rewrite all day
<graphitemaster>
a new nouveau which uses the firmware for new cards and then there's an open source vulkan driver for nv just around the corner too
<graphitemaster>
then gl via mesa on zink targeting vulkan as the driver
<graphitemaster>
there's your new nv open sores linux graphics stack
<heat>
they could port the kernel driver
<heat>
probably easier than rewriting 1 million LOC
<graphitemaster>
most of kernel driver code is shared by all the drivers
zaquest has quit [Remote host closed the connection]
<graphitemaster>
the actual nouveau part is quite small
zaquest has joined #osdev
<heat>
how many drivers are there and why doesn't nouveau cover all of that?
<graphitemaster>
I mean most graphics drivers on Linux work ontop of DRM and KMS (on the kernel side), with most of everything else in userspace handled by DRM (for talking to the kernel side) and then the whole API side handled by gallium 3d + DRI part of mesa
xenos1984 has quit [Read error: Connection reset by peer]
<graphitemaster>
The actual device driver for the hardware in the kernel is very small comparatively speaking.
xenos1984 has joined #osdev
<heat>
well yes but the nvidia one does too
<graphitemaster>
It's nowhere near 1m lines of code, NV's KMD is though because it has to implement all that crap that already exists
<graphitemaster>
nouveau doesn't though
<graphitemaster>
So that's why they're discussing a rewrite
<graphitemaster>
They want to use all the stuff that exists already in the ecosystem
<graphitemaster>
Not stuff NV provides
<graphitemaster>
To put things in perspective, something like this is probably closer to ~100k lines of C
<graphitemaster>
Maybe even less
heat has quit [Ping timeout: 260 seconds]
sikkiladho has joined #osdev
<sikkiladho>
what's the difference between Gathering and "merge access" in AArch64 Memory Model?
<klange>
merge is a verb; the CPU can determine that code is making multiple accesses and turn them into one access - it can _merge_ them
<klange>
Gathering is the name of the attribute that specifies whether that is allowed
<sikkiladho>
Thank you! So that is the same thing basically.
<klange>
I suppose what I mean to say is the difference is linguistic; they are are different aspects of one piece of functionality - a bit and an action :)
Likorn has joined #osdev
<klys>
]
bauen1 has joined #osdev
Ram-Z has quit [Ping timeout: 276 seconds]
bauen1 has quit [Ping timeout: 240 seconds]
Likorn has quit [Quit: WeeChat 3.4.1]
the_lanetly_052 has quit [Ping timeout: 256 seconds]
Ram-Z has joined #osdev
jjuran has quit [Ping timeout: 240 seconds]
nyah has joined #osdev
vimal has joined #osdev
puck has quit [Excess Flood]
puck has joined #osdev
floss-jas has quit [Ping timeout: 250 seconds]
jjuran has joined #osdev
bauen1 has joined #osdev
mrvn has joined #osdev
sikkiladho has quit [Quit: Connection closed for inactivity]
scoobydoo_ has joined #osdev
scoobydoob has quit [Ping timeout: 252 seconds]
Burgundy has joined #osdev
GeDaMo has joined #osdev
dzwdz has quit [Ping timeout: 240 seconds]
vimal has quit [Quit: Leaving]
psykose has quit [Ping timeout: 248 seconds]
psykose has joined #osdev
<mrvn>
How do I multiply 2 uint16_t in a protable way? In a*b integer promotion first turns both into int (32/64bit systems) or unsigned int (16bit systems). So on 32/64bit systems it can then overflow a signed integer which is UB.
<mjg>
just -fwrapv man
<mrvn>
that isn't portable
<mjg>
it's an artificial problem imo
<kingoffrance>
hmmm, someone asked something liek that a week or so ago. i just have a bunch of 2unit library/functions. that doesnt solve anything, just "big int" code uses that, so theoretically just one single place to fix anyhow
<kingoffrance>
i.e. the result for that i call a "2unit" (because i just use char/short/etc. not the 16_t etc.)
<kingoffrance>
or, 65535*65535 -> fits in 32 bits
Burgundy has quit [Ping timeout: 256 seconds]
<mrvn>
kingoffrance: but not int
<kingoffrance>
yes, i believe i just avoided long long as "base unit" for "big int" stuff because multiply and maybe divide wants something like that
<mrvn>
For big int you want to cast to the next bigger unsigned type instead of having it overflow. So kind of different thing.
* mrvn
still wants a std::more_bits<T>::value_type
<moon-child>
mrvn: you are looking for something portable? uint16_t isn't portable
<mrvn>
it might not exist but then the code won't compile. That's ok. I just don't want UB.
<mrvn>
+ I want to rant about the integer promotion being stupid :)
<moon-child>
cast to uint32_t then?
<mrvn>
int might be 64bit
<moon-child>
what if it is?
<moon-child>
you won't overflow it
<zid>
yea this is all a non-issue, if you have uint16_t you have uint32_t
<moon-child>
.oO( 17-bit ptrdiff_t? )
<moon-child>
but seriously just -fwrapv
<zid>
technically you could use uint_least_32_t
<zid>
To support a weird machine that has uint16_t and uint64_t but no uint32_t
<zid>
cast one side, if it compiles, then uint16_t * uint16_t is safe on that cpu
tomaw has quit [Quit: Quitting]
tomaw has joined #osdev
gog has joined #osdev
<mrvn>
moon-child: it int is 64bit you have the same problem for uint32_t as starting point.
<moon-child>
I thought you want to multiply uint16_ts
<moon-child>
not uint32_ts
<mrvn>
it's just an example
<moon-child>
you can do conservative overflow check with clz
<mrvn>
lets make it generic: I want to multiply a tempate<typename T>
<moon-child>
log(x) + log(y) = log(x*y). So ceil(log(x)) + ceil(log(y)) > log(x*y). So check if ceil(log(x)) + ceil(log(y)) > 32
<moon-child>
hmm there's a uintmax_t right? Just cast to for all your intermediates
<zid>
I already told you the portable way to do it
<zid>
So just do exactly what I say, all of the time, imo
dennis95 has joined #osdev
bliminse has quit [Quit: leaving]
<mrvn>
zid: template<typename T> T mul(T a, T b) { return ???; }
<zid>
Not what was asked unfortunately
<mrvn>
zid: I'm asking now
<zid>
I don't actually know C++
<psykose>
just C+?
<zid>
Just C
<mrvn>
template<typename T> T mul(T a, T b) { return (unsigned decltype(a*b))a * b; } works, right?
<mrvn>
s/mul/umul/
bliminse has joined #osdev
lleo has joined #osdev
PapaFrog has quit [Read error: Connection reset by peer]
LostFrog has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<j`ey>
I had '.got.plt : { *(.got.plt) }' in my linkerscript, I then deleted it and put '*(.got.plt)' in my .rodata section and I get 'error: undefined section `.got.plt' referenced in expression', weird?
<Mutabah>
does it point at the newly added line?
<Mutabah>
if so, kinda weird
<j`ey>
ohh good shout, it doesn't indeed!
<j`ey>
Mutabah: thanks
<Mutabah>
quack
<j`ey>
:-)
<gog>
meow
Likorn has joined #osdev
* vdamewood
gives gog a fishy
* gog
eats fishy
* sbalmos
dangles yarn over gog
* gog
knits yarn
_eryjus has quit [Ping timeout: 246 seconds]
<sbalmos>
talented cat
<vdamewood>
Kitty go prrr
brynet has quit [Ping timeout: 260 seconds]
<mrvn>
*wuff wuff* Kitty go up the tree.
dzwdz has joined #osdev
heat has joined #osdev
<heat>
computer go
<heat>
beep boop
<vdamewood>
No pet computer.
<gog>
what about the commodore PET?
<heat>
computer sad because vdamewood no pet for beep boop
<Griwes>
The aliasing allowance isn't because of how it's defined in code
<Griwes>
There's an explicit provision for std::byte specifically that says it can alias
<j`ey>
yay special cases
<mrvn>
how does the compiler detect that? type named "byte" in namespace "std" only?
<Griwes>
Yes
<Griwes>
it's conceivable for an implementation to have an attribute that it attaches to such a type too, though
<j`ey>
that's how rust does things
<mrvn>
And here I was thinking I should use std::byte* for every buffer so it doesn't trigger an aliasing with everything.
<mrvn>
"using foo = std::byte" preserves the aliasing super powers.
<Griwes>
yeah, because it looks specifically at the *linkage* name, which is canonical
<Griwes>
if you look at libc++ for instance, you'll see that byte is directly in std, with a comment pointing out that it is purposefully not versioned
<mrvn>
have to be carefull replicating that in my kernel
<mrvn>
.oO(and here I was not having namespace std in the kernel)
<geist>
yeah ugh. i was thinking of doing a using into my namespace for that purpose (if i was to go that route)
<mrvn>
namespace MyKernel { using byte = std::byte; }?
<mrvn>
hehe
<mrvn>
That's exactly why I tested if "using" preserves the super powers
RAMIII has quit [Ping timeout: 252 seconds]
RAMIII has joined #osdev
<geist>
thats dissapointing about the compiler hack
<mrvn>
the std::byte hack?
<geist>
yeah
bradd has quit [Ping timeout: 276 seconds]
bradd has joined #osdev
sonny has joined #osdev
<sbalmos>
always have to be special rules somewhere. ;)
<mrvn>
writing to byte sucks, you always have to cast first.
sonny has quit [Remote host closed the connection]
<heat>
Griwes, wait the compiler looks at the linkage name in those situations?
<Griwes>
By "linkage name" I don't mean "mangled name", if that's what you're thinking
<Griwes>
Just the name that is used for linkage purposes
<Griwes>
So foo in struct foo {}, bar in typedef struct {} bar (yes, this exact case is handled by assigning bar as the "canonical" name for the type, to match with what C does in this specific case)
bradd has quit [Quit: No Ping reply in 180 seconds.]
bradd has joined #osdev
<heat>
ah right
<heat>
i would've though you could use something like may_alias to make that possible
<heat>
vs hardcoding the namespace
mahmutov has quit [Ping timeout: 246 seconds]
<zid>
C has bits of the standard that say if the tag name matches between TUs the structs have to match.. but nobody checks
<zid>
insert fun punning
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
bradd has quit [Quit: No Ping reply in 180 seconds.]
<heat>
funning
mahmutov has joined #osdev
bradd has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
bradd has quit [Ping timeout: 256 seconds]
<gamozo>
is that related to funrolling?
bradd has joined #osdev
lanodan has quit [Quit: WeeChat 3.4.1]
lanodan has joined #osdev
RAMIII has quit [Ping timeout: 260 seconds]
bauen1 has quit [Ping timeout: 252 seconds]
gildasio has quit [Ping timeout: 240 seconds]
Likorn has joined #osdev
gildasio has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
floss-jas has joined #osdev
bauen1 has joined #osdev
sonny has joined #osdev
<zid>
everybody talking about nvidia's news and as far as I can tell.. it's just a case of who does the mmap for the blob, to allow HPC machines to boot properly without the package manager
<geist>
i thinkit's a bit more complicated than that but that's the gist of it in general
<klange>
It is both not the "holy shit they actually did it" unprecedent move from Nvidia everyone wanted, but it's also not completely useless.
vdamewood has joined #osdev
<Griwes>
it's an approach that allows everyone to eventually have a fully featured kernel-level driver vOv binary firmware blobs are nothing new
<klange>
for cards no one owns *shrug*
<Griwes>
For cards where this is feasible.
<Griwes>
Also saying noone owns Pascal+ is... very silly
<klange>
Your own docs say it's Turing+.
<Griwes>
Oh, is it turing+? I thought it went further back
<klange>
(I have a Pascal card, so that difference matters to me.)
<Griwes>
Okay that's slightly less silly but saying "noone owns them" is still somewhat silly
<klange>
I _am_ being obtuse and hyperbolic, but it does seem like ownership by actual human beings is shockingly low for anything from the last five years.
* heat
wonders how different the amdgpu driver is in terms of firmware/driver ratio
* Griwes
wonders why he still has "pascal+" in his brain as the support chart for this
<klange>
does Pascal have the same "fun stuff moved to firmware" or was that introduced in RTX/Turing?
<heat>
because blaise pascal was a very cool individual
<klange>
(does the Turing GTX 16-series chipset have that?)
<heat>
i think so
<heat>
for the second question that is
<Griwes>
Yeah it seems that only Turing+ has the current gen of the on-card coprocessor; and I'm fairly certain it's an architectural feature, so whether you have rt cores or not doesn't matter (but don't quote me on this)