thinkpol has quit [Remote host closed the connection]
thinkpol has joined #osdev
spare has quit [Remote host closed the connection]
netbsduser has joined #osdev
vdamewood has joined #osdev
gog has quit [Quit: byee]
netbsduser has quit [Ping timeout: 256 seconds]
navi has quit [Ping timeout: 268 seconds]
agent314 has joined #osdev
agent314_ has quit [Ping timeout: 272 seconds]
netbsduser has joined #osdev
* geist
yawns
netbsduser has quit [Ping timeout: 252 seconds]
Gooberpatrol66 has joined #osdev
Gooberpatrol66 has quit [Remote host closed the connection]
Matt|home has joined #osdev
netbsduser has joined #osdev
netbsduser has quit [Ping timeout: 252 seconds]
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #osdev
srjek has quit [Ping timeout: 264 seconds]
netbsduser has joined #osdev
heat has quit [Ping timeout: 246 seconds]
netbsduser has quit [Ping timeout: 268 seconds]
Gooberpatrol66 has joined #osdev
netbsduser has joined #osdev
netbsduser has quit [Ping timeout: 268 seconds]
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
netbsduser has joined #osdev
Gooberpatrol66 has quit [Remote host closed the connection]
<geist>
question: what is the most elegant way to test for 'bitness' (32 or 64) of a particular architecture inside the compile?
<geist>
i'm using sizeof(void *) but dunno if there's a more logically correct #define that is universal and the 'correct' way
<childlikempress>
on cheri, sizeof(void*) is 16, but sizeof(size_t) is 8--what result do you want?
<kazinsal>
probably sizeof(uintptr_t)
<childlikempress>
i would use sizeof, only thing is it doesn't work at preprocessing time, but there is gcc/clang-specific __SIZE_bla you can use
<geist>
good question. cheri is a good point, or really anything else that has a tagged or far pointer
<geist>
yah this is simply a case where i have some generic code that needs to make a distinction of address space size, so i think sizeof(void *) (or uintptr_t) is logically correct
<geist>
just didn't know if there was a universally defined __BITS__ or something
<geist>
but i dont see it
<childlikempress>
for address space size you'd want size_t no?
<childlikempress>
128-bit pointers but 64-bit address space
<childlikempress>
(on cheri)
<geist>
well, i suppose that may be true, re: cheri
<geist>
i suppose uintptr_t would follow the size of void *, not size_t
<geist>
for background, the situation is i discovered that my PCI bus code was happily using >4GB BARs on 32bit arches with no MMU (ie, riscv in machine mode)
<kazinsal>
looks like limits.h just defines __WORDSIZE statically per arch
<geist>
yah i was looking at __WORDSIZE. dunno if it's standard or not
<geist>
i suppose another case where sizeof() would return something wonky is if you dont consider the size of a byte
<geist>
though... if you had say a 16 bit byte would sizeof be in units of that?
<childlikempress>
yes
<geist>
i've only worked with one DSP arch that was that way, but i think the fiction was still that a byte is 8 bits, it's just that sizeof(char) == 2
<childlikempress>
but i think it's reasonable to say you don't support not-8-bit bytes
<geist>
oh actually scratch that, i think it was in units of char
<childlikempress>
in c, char=byte
<childlikempress>
sizeof(char)==1 always
<geist>
because i explicitly remember memcpy and whatnot needing to be a unit of char, yeah
<geist>
yah
<geist>
i guess my point is the test should be something like (sizeof(something) * __CHAR_BIT__), i *guess*
<childlikempress>
how come i don't work for google
<geist>
since in this case it's in reference to 64bit PCI, which is deifned in terms of 8 bit bytes
<geist>
no one knows arch minutae, since the vast majority of code anywhere (and especially at google) is either x86-64 or arm
<geist>
you'd be surprised how little this sort of shit comes up in the vast majority of stuff
<geist>
ie, low level language nerds does not make the world go round
<childlikempress>
sure, more operative is i don't have a degree and don't leetcode and don't have the temperament for a full-time job :p
<geist>
he
<geist>
heh
<childlikempress>
oh and google is lamez0rz(?) these days anyway
<geist>
i hope the leetcode stuff isn't as important as i think it is. cause i'd fail that shit so hard now
<childlikempress>
depends where you go i think--i haven't really had to do any? but i have the impression it's really heavily weighted at google
netbsduser has quit [Ping timeout: 260 seconds]
<geist>
good question. i got into google the hard way: by working for 10 years at other places, building up enough experience and networking, and then getting hired by having proven myself already and being needed at the time
<geist>
IMO all companies should have a back door for precisely that sort of hiring, but some of them dont, and that's their loss
<childlikempress>
oh i thought they made everybody do it. there's a story i think ken thompson had to some whiteboard algorithms or w/e?
<geist>
nah but maybe they do now. i've been there for 12 years
<geist>
if so, their loss
<childlikempress>
wouldn't be surprised--per aforementioned lamez0rz
<geist>
and i kinda doubt ken had to
<geist>
there are some luminaries around that i bet came in because they're amazing first and foremost
<bslsk05>
www.theregister.com: C language inventor spurns Google's language exam • The Register
Gooberpatrol66 has joined #osdev
<geist>
oh haha yeah that. that is some seriously dumb shit
<geist>
but really i'm sure someone would set the bit on his account
<geist>
it's basically via some sort of peer reviewed, etc, thing that certifies you're towing the proper line for a given language
<geist>
'readability' is what they call it
pebble has joined #osdev
<geist>
it's less so that you're hard core about that language, and more that you can be trusted to follow the style guide for that language, etc
<geist>
i haven't worked in that part of the company so i have zero readability
<geist>
kinda like taking a drivers exam: just because you build cars doesn't mean you're going to follow the rules of the road. and yeah it's a pain and silly for most people
<childlikempress>
is that like. being allowed to commit without having your crap reviewed?
<childlikempress>
if it is being reviewed they should broadly speaking catch it then no?
<geist>
you always have to have your stuff reviewed, but it must be reviewed by someone that has the readability bit
<geist>
so if you dont have the readability bit you can still make cahnges, you just have to get it reviewed that someone that does. but even if you have the bit you still need to get it reviewed
<geist>
or at least i think that's the gist of it
<geist>
or maybe if you have readability you can make a change and someone without it can review
netbsduser has joined #osdev
<kazinsal>
yeah I got into the university I work at in a similar way, albeit much more recently. spent a decade doing all sorts of in-demand stuff at a local, fairly well known VAR/MSP, built my skills well enough to be able to just solve problems on the fly, and rolled up while they were looking for someone who knew exactly what I knew
<kazinsal>
if you're going into the right place and you can prove you know your shit the thinking person's way (which is *not* a dang memorize-the-leetcode-answers exercise) you can nail it just through being the right person
<geist>
heh, another clever GCC thing for ARM that took me a mnute to decode
<geist>
movx1, #0xffffffffffff0044
<geist>
x1, #0xc900, lsl #16
<geist>
it's loading the constant 0xffffffffc9000044
<geist>
the first mov it knows that the second nibble of bytes is going to be overwritten by the movkx1, #0xc900, lsl #16 instruction
<geist>
so it can take advantage of that and synthesize the rest of the 64bit word with a negative value
<kazinsal>
ooh. neat trick
<geist>
i chopped it off before, but yeah
netbsduser has joined #osdev
pebble has quit []
<geist>
ah interesting. i have a failure here where i'm running LK in a qemu+kvm situation on a raspberry pi 5, so it's using the virtualization stuff
<geist>
it fails what appears to be 'randomly' when writing to a uart register. moving code around changes the failure to either always happen or never
gbowne1 has quit [Read error: Connection reset by peer]
Mach has quit [Ping timeout: 256 seconds]
<geist>
in order to leave everyone not hanging, its the writeback. For some reason on this version of qemu on this raspberry pi with this compiler, this is suddenly a thing.
<geist>
well, okay, prboably just haven't been running LK that much under KVM on ARM machines, so this is a semi-known issue
<geist>
the gist is when running under a VM you really should access hardware using simple instructions
Mach has joined #osdev
zxrom has quit [Read error: Connection reset by peer]
zxrom has joined #osdev
<kof673>
> i guess my point is the test should be something like (sizeof(something) * __CHAR_BIT__) something like that i would make my own define, and have code use that, and then only one place to change if it was not quite correct. and allow manually override as well
<kof673>
that is a q if you want a code base littered with its own defines though
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
qubasa has joined #osdev
<geist>
re: the invalid str/ldr instruction for trapping in hypervisors: i knew this once and frorgot it
<geist>
if it's not a 'simple' load/store instruction, when it is trapped in EL2 on armv8, it will not set the ESR_EL2.ISV bit, which means the 'instruction syndrome valid' is unset
<geist>
which means it basically doesn't populate the lower portion of the ESR that says how the instruction faulted (read/write, register, width)
<geist>
in this case KVM just punts to user space, and qmeu presumably naks it, and thus it bounces back to the guest as a Synchronous External Abort
<geist>
just traced it through the linux KVM code
<geist>
very very tight and complicated code
<geist>
but i must say reasonably documented
zetef has joined #osdev
Vercas9 has joined #osdev
<kof673>
> Note that POSIX requires pointers to objects and pointers to functions to be the same size: 2.12.3 Pointer Types
<kof673>
i of course do not mandate that, ~c89 lol
<kof673>
> These are the two serpents, given and sent by Juno, (that is the nature metallic), they which the strong Hercules, that is to say, the sage and wise man, must strangle in his cradle, that is, overcome and kill them, to make them putrify, corrupt, and ingender at the beginning of his work.
<kof673>
j/k but you could use a union if desired
netbsduser has joined #osdev
netbsduser has quit [Read error: Connection reset by peer]
gog has joined #osdev
xvmt has quit [Ping timeout: 256 seconds]
netbsduser has joined #osdev
GeDaMo has joined #osdev
Vercas9 has quit [Ping timeout: 260 seconds]
<kof673>
then of course salamander-lambda follows. fun with typedefs j/k
goliath has joined #osdev
navi has joined #osdev
srjek has joined #osdev
alpha2023 has quit [Ping timeout: 268 seconds]
pebble has quit [Remote host closed the connection]
pebble has joined #osdev
xvmt has joined #osdev
pebble has quit []
pebble has joined #osdev
gsekulski has joined #osdev
Vercas9 has joined #osdev
Vercas9 has quit [Remote host closed the connection]
Vercas9 has joined #osdev
m257 has joined #osdev
gsekulski has quit [Quit: Leaving.]
erai has quit [Ping timeout: 246 seconds]
gsekulski has joined #osdev
bleb has quit [Ping timeout: 264 seconds]
bleb has joined #osdev
m3a has quit [Ping timeout: 240 seconds]
teardown has joined #osdev
Vercas has joined #osdev
MrCryo has joined #osdev
pebble has quit []
jjuran has quit [Ping timeout: 255 seconds]
jjuran has joined #osdev
Matt|home has quit [Remote host closed the connection]
jjuran has quit [Client Quit]
jjuran has joined #osdev
warlock has quit [Ping timeout: 268 seconds]
npc has joined #osdev
MrCryo has quit [Quit: MrCryo]
m257 has quit [Quit: Client closed]
MrCryo has joined #osdev
m257 has joined #osdev
MrCryo has quit [Remote host closed the connection]
heat has joined #osdev
Mach has quit [Ping timeout: 256 seconds]
Vercas9 has quit [Quit: Ping timeout (120 seconds)]
Vercas has quit [Quit: Ping timeout (120 seconds)]
m257 has quit [Ping timeout: 250 seconds]
m257 has joined #osdev
m257 has quit [Ping timeout: 250 seconds]
MrCryo has joined #osdev
zetef has quit [Ping timeout: 260 seconds]
teardown has quit [Ping timeout: 260 seconds]
teardown has joined #osdev
<heat>
geist, yeah esr.arm64.dev is great
<heat>
i think the linux side of google (android maybe?) wrote that
Vercas9 has joined #osdev
MrCryo has quit [Remote host closed the connection]
Vercas has joined #osdev
FreeFull has quit [Ping timeout: 255 seconds]
FreeFull has joined #osdev
zxrom has quit [Quit: Leaving]
azonenberg has quit [Remote host closed the connection]
gsekulski has quit [Ping timeout: 272 seconds]
m257 has joined #osdev
Arthuria has joined #osdev
Arthuria has quit [Ping timeout: 268 seconds]
gsekulski has joined #osdev
stolen has joined #osdev
xenos1984 has quit [Ping timeout: 268 seconds]
xenos1984 has joined #osdev
teardown has quit [Ping timeout: 260 seconds]
teardown has joined #osdev
gog has quit [Quit: Konversation terminated!]
m257 has quit [Ping timeout: 250 seconds]
asarandi has quit [Quit: WeeChat 4.2.2]
asarandi has joined #osdev
joe9 has joined #osdev
Vercas has quit [Quit: Ping timeout (120 seconds)]
Vercas9 has quit [Quit: Ping timeout (120 seconds)]
Vercas9 has joined #osdev
Vercas has joined #osdev
gsekulski has quit [Ping timeout: 260 seconds]
gog has joined #osdev
xenos1984 has quit [Ping timeout: 256 seconds]
<netbsduser>
i have successfully loaded my first program on m68k
<netbsduser>
dynamically-linked, using libstdc++, and with thread-local storage to better exercise mlibc
<heat>
congrats
<heat>
hey netbsduser do you want a fun POSIX fact?
<netbsduser>
i always do
<heat>
say you have a MAP_PRIVATE mapping and you write to it
<heat>
it's permissible for the OS to throw away your data on e.g a truncate on the underlying file
<heat>
and it is what linux does, CoW does not matter, they just truncate
<netbsduser>
this one is quite shocking
<netbsduser>
i was a bit surprised they made that provision (but, i thought, some weird platform must have done it so they put it in) but more surprised to learn it happens with linux
xenos1984 has joined #osdev
<heat>
i went through the code and i think it happens because they just willy-nilly unmap the CoW'd page without checking if its the same page as the page cache's
<heat>
and because they use the page tables as their amap thing... the page just gets freed
<MrBonkers>
Mlibc detected. I was called?
<zid`>
alert, alert
<zid`>
changing the lightbulb to the red one
<heat>
mlibc managarm
<netbsduser>
yes MrBonkers
Bonstra has quit [Remote host closed the connection]
<MrBonkers>
It’s nice work netbsduser did. Always nice to see a new architecture work with mlibc
<netbsduser>
thanks, but it's yourselves who deserve most of the credit
Bonstra has joined #osdev
<netbsduser>
your libc was almost ready-made for an m68k port
<heat>
mlibc is wack, i only use libc's that take advantage of C's () vs (void)
<netbsduser>
leo genericised it nicely in a commit last year
<MrBonkers>
Sounds like we’re achieving our goals then
<heat>
char *p,*v,c,*d = 0;
<heat>
unsigned i, j;
<heat>
for (i=0; (buf[i] = "/proc/self/fd/"[i]); i++);
<heat>
"\0\1\2\4\7\3\6\5"[(0x17*base)>>5&7];
<netbsduser>
heat: tbf it might well be what i end up doing as i abolished amaps for process-private anonymous memory
<heat>
i haven't done that yet
<netbsduser>
i had fully abstract pmap operations before, now i've abolished them and assume the existence of page tables. for software refilled TLBs mock ones can be made which the refill trap can deal with
<netbsduser>
i don't think i assume multi-level tables so vax is not necessarily impossible
gsekulski has joined #osdev
zetef has joined #osdev
Bonstra has quit [Quit: Pouf c'est tout !]
Bonstra has joined #osdev
Gooberpatrol66 has quit [Remote host closed the connection]
gsekulski has quit [Ping timeout: 252 seconds]
<zid`>
disaster, nobody has uploaded honzuki fanbook 4 part 2 yet
<nikolar>
Wait until Monday
<zid`>
someone will do it at the weekend at least
<zid`>
22:30 tonight maybe if I am lucky
<zid`>
stupid jnovel doesn't accept money from anything but a visa card or I'd have bought a bunch of stuff
gorgonical has joined #osdev
<gorgonical>
I didn't know my research into trusted OSes was going to require learning how to convert between yuv camera raw formats to bmp to feed into an image recognition pipeline of my own design
<gorgonical>
I want my money back
<nikolar>
How did you not know that
<gorgonical>
I never wanted to know what chroma subsampling was
<nikolar>
yuv conversion is the backbone of all trusted computing
<nikolar>
I mean subsampling isn't that crazy or a concept
<gorgonical>
No but there's enough possibilities that you have to know about it
<gorgonical>
441, 420, 444, etc
<nikolar>
Yeah
<gorgonical>
And even how you technically are supposed to convert between Y back to RGB. I am not, I'm just copying the Y value into each RGB channel
<gorgonical>
This is not correct, I know
<nikolar>
Lol
<gorgonical>
I still don't really know what factor set was used in the conversion because I don't know what my underlying color space is
<gorgonical>
Etc etc. This is all information I can't unlearn
<nikolar>
Just don't think about it ¯\_(ツ)_/¯
zxrom has joined #osdev
<gorgonical>
That's the plan
<nikolar>
Kek
<nikolar>
Or you can obses about video conversion and compression
<nikolar>
And then create your own video compression format
zetef has quit [Remote host closed the connection]
stolen has quit [Quit: Connection closed for inactivity]
zetef has joined #osdev
<zid`>
4:4:4 for life btw
<zid`>
*red danger text, but completely unreadable*
netbsduser has quit [Ping timeout: 260 seconds]
netbsduser has joined #osdev
CutieMelo has joined #osdev
gbowne1 has joined #osdev
CutieMelo has quit [Ping timeout: 256 seconds]
gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
<geist>
heat: re that VM stuff. i knew this, we learned it in zircon the hard way, but you should probably do the same if you have't already
<geist>
when dealing with things that can be virtualized you really probably have to always access mmio via accessor functions that use specific instructions
<geist>
i've bumped into it countless times on x86 on zircon too, especially since the compiler has a lot of choices
<geist>
too much of an embedde pattern of doing something like `*REG32(address) = 5;`
<geist>
or, the whole structure of registers thing, which also doesn't really work
<geist>
though i haven't seen the compiler do it, a structure of registers also allows the compiler to use whatever instruction it feels like, and that's a problem waiting to happen
<gorgonical>
zid`: while 444 is of course the best fidelity, reasoning about how to pack the pixels and all that is pretty horrifying
<gorgonical>
i rather prefer the simplicity of planar formats
<geist>
re converting though, i though it's a fairly straightforward algorithm
<geist>
may require some muls and divs but fairly certain you can find it around the interwebs
<gorgonical>
it might be, but the waters are so muddied because of the overlap between analog and digital and various standards. an amateur like me has a hard time discerning what's relevant
Starfoxxes has quit [Ping timeout: 255 seconds]
<geist>
ah so this particular thing isn't for work
<gorgonical>
in theory maybe the yuv is just a conversion from the underlying bayer mosaic in rgb in the first place, but what standard exactly was used to convert between the color space i don't know
<gorgonical>
no it is lol
<geist>
heh well then do it right!
<gorgonical>
i mean it only has to *just* work. the thing I'm really showing is that you can do all this stuff with my research product
* geist
gets out the wet trout
<gorgonical>
the real thing I'm benchmarking is how many frames per second I can do image recognition on
<gorgonical>
all this is support harnesses and whatnot
<heat>
geist, oh i know, but volatile loads and stores work /okay/ for me atm
<geist>
yah may be that color isn't that important, and the Y is enough
<heat>
i don't see it codegen really stupid stuff
<geist>
heat: well, see where i bumped into the problem is a series of stores using volatle stores
<geist>
and it chose for whatever reason to do a sequence like
<gorgonical>
that's the working theory, that copying the y value into rgb produces a recognizable image, even if the color representation is not right
<geist>
`str reg, [reg], offset!; store reg, [reg]`
<heat>
yeah it used those weird arm64 addressing modes right? i think i looked at it a bit
<geist>
instead of `str reg, [reg]; str reg, [reg, #offset]`
<geist>
both are equally valid, the first one is just a little silly
<geist>
this is with gcc 14.1, FWIW, which seems to be exceptionally tricky in its codegen. kinda impressive to be honest, (been staring at a lot of less than stellar clang arm codegen a lot)
<heat>
is tricky good or bad here?
<zid`>
yea using just the Y is effectively just using the luminance
<geist>
good, in general, but sometimes it decides weird sequences that are equally okay
<heat>
yeah
<heat>
maybe they are
<geist>
though i *think* it's generally trying to move the base reg into a better space. in general reusing single base registers for a sequence of stores i've found compilers to be fairly bad at
<gorgonical>
zid`: am i correct in the thought that trying to reconvert to rgb correctly would produce the "right" representation?
<gorgonical>
rather than blindly copying Y to each RGB channel?
<heat>
i'm still on clang 15 and gcc 12.2, so i'm a bit late
<heat>
rebasing all my patches(patchen) takes some time because of compiler-rt
<zid`>
G = Y; B = G-DeltaB; R = G-DeltaR; is the 'normal' encoding for video
<heat>
(and libsanitizer)
<zid`>
two low res deltas for red and blue, off of a black and white signal that is actually the green channel
<heat>
in any case yeah i had noticed most Real Systems do inline asm for mmio
<gorgonical>
Wait wait but I have a yuv planar raw
<gorgonical>
so the Y is the "true" grayscale image, right?
<heat>
i don't do volatile structs though, i personally don't like it
<zid`>
gorgonical: I don't think so sadly
<zid`>
It's a very very good approximation, but I think you need to subtract out green and red's effect too
<gorgonical>
hmm
<geist>
btw, ridiculous amount of aurora borealis going on right now, if you're in UK you might be able to see soon as the sun goes down
<zid`>
G = Y - 0.395U - 0.581V
<gorgonical>
I guess that's consisent with what I've read: yuv is luma and then red-difference and blue difference
<zid`>
geist: single map I saw suggested we'd miss it, but idk how it will move around over the night
<zid`>
okay found a better map, scotland gets it (as usual), england does not (as usual)
<bslsk05>
www.swpc.noaa.gov: Aurora - 30 Minute Forecast | NOAA / NWS Space Weather Prediction Center
<gorgonical>
but the idea of a luma/chroma format split implies that the luma *should* be the pure grayscale copy, right?
Starfoxxes has joined #osdev
<geist>
apparently they have a satellite up at one of the lagrange points that can see the solar wind coming in before it hits the earth
<zid`>
luma is the greyscale yea
<gorgonical>
that's the impression I get from the wikipedia image sample, anyway
<zid`>
that's why G needs fixing up
<zid`>
luma channel is a 'brightness map'
<gorgonical>
Right
<heat>
i'm too low for aurora
<gorgonical>
Then given a YUV luma plane, converting to an equivalent rgb value can be done by just running one of those equations in reverse?
<heat>
didn't want to see it anyway :(
<zid`>
It's a 3x3 matrix full of constants
<heat>
otoh it was 28C today suck it northerners
<zid`>
[[0.299, 0.587, 0.114], ...]
<GeDaMo>
It was warm and sunny here today :P
<zid`>
oh those are the BT.470 constants I think, everything is BT.709 now
<geist>
it's in the low 20s today here too, first nicely warm day of the year
<zid`>
if you treat 709 as 470 it looks a bit too dark
<gorgonical>
zid`: but always true is that copying the luma value (assuming 8bit) to the rgb channels is just wrong
<gorgonical>
an approximation
<zid`>
no that should be fine, I think, idk what colourspace that's called though
<gorgonical>
oh yes that's right. But the "correct" conversion depends on how you got that Y plane in the first place doesn't it?
<zid`>
It depends more on what your output device is
<zid`>
because you technically need to gamma adjust it
<gorgonical>
the context is that these yuv planes i'm getting out are from an undocumented ISP block so I don't really know what the underlying oclor space is
<gorgonical>
camera data goes in, yuv420p planes come out
<zid`>
2.2 gamma woo
<zid`>
Just assume it's rec709
<zid`>
it's almost certain it will be
<zid`>
if it looks wrong to you then try 601
<gorgonical>
Why do these standards have a hundred names each
<zid`>
bt.709 vs rec709 etc?
<gorgonical>
itu 709 as well
<zid`>
cus it was never a standard standard
<zid`>
It was a whitepaper or something
<zid`>
and various technical bodies adoptied it
<zid`>
like ISO C90 vs ANSI C89
<gorgonical>
so then in theory my constants are 0.0722, 0.2126, and 0.7152
<gorgonical>
Matrix mult with [y, 0, 0] to get the rgb values back for the grayscale version
<gorgonical>
some steps omitted
<heat>
geist, random question but have yall considered KASAN poisoning the struct pages?
<zid`>
or G = 1.1644*Y + 0.21325*U - 0.53291*V + 76.878, if you want a different output space :P
<heat>
i feel like its a good idea, i just haven't tried it yet
<geist>
heat: dunno, good question
<heat>
basically to help stop accidental struct page UAFs
<geist>
i honestly dont really know much about the KASAN stuff
<zid`>
(imagemagick actually lets you specify the matrix, which is kind of cool)
<geist>
we have a fair amount of debug asserts testing for the page being in the wrong state, etc which generally catches that sort of stuff
<zid`>
rather than input and output colourspaces, you can just -color-matrix "1.1 0 1.8 0 ..."
<heat>
also wow that vm_cow_pages is a thicc boy
<heat>
does it take long to compile?
<gorgonical>
but wait
<gorgonical>
what's the coordinate space of this matrix? My Y values are 0 to 255
<netbsduser>
poisoning page structs is one thing but what if you rely on their continued existence
<gorgonical>
this is truly a nightmare
<heat>
netbsduser, i would say that is an awful idea
<zid`>
If you're throwing it on a computer monitor you want 'rgb', if you've calibrated it then you want whatever you calibrated it to if your application is colourspace aware (via api) else rgb and it will convert but you'll lose any extra range
<netbsduser>
type stability very useful
<netbsduser>
it's a similar pattern as is done with RCU in the gnu/linux kernel
<heat>
there's only one thing that could rely on continued existence, and it's the page allocator
<heat>
and you can fno-sanitize=kernel-address that bit
<gorgonical>
no wonder you can get a whole degree in computer graphics. this is insane
<zid`>
It's not like, a h uge issue, to be in the wrong space
<zid`>
if you set your monitor to srgb instead of rgb for exa
<zid`>
mple, you'll barely notice except for red
<geist>
heat: oh in the zircon kernel? so far there arne't really any files in the kernel that take more than a few seconds. usually it's some test code that pushes it, something that stamps out a template a bunch of times for testing purposes
<geist>
but compared to some long ass compilation files in the rest of fuchsia, the kernel is practically instantaneous
<zid`>
if you confuse yuv for rgb you get cool stuff though
<geist>
note we just turned on LTO foe release builds in fuchsia, like yesterday, and wow did the release build time get more
<geist>
but... no LTO for kernel, yet.
<heat>
geist, yeah 7KLoC is pretty large
<netbsduser>
heat: i need it for paging; the page daemon needs to invert the usual lock order
<heat>
if your page is in an LRU after being freed, it's pretty insane
<netbsduser>
actually come to think of it i had another way to deal with this, i forgot the details, it involved setting a bit in the page struct while the paging queues lock is held, and a vm object which wants to free itself defers that when it sees the bit (so the page daemon can lock the object), so it's not a real issue
<gorgonical>
oooh
<zid`>
like, if you're just doing B&W machine vision, RGB = YYY is 100% fine
<zid`>
(or just doing 8bit black and white as your actual output)
<gorgonical>
it's the first one. I'm just dropping the UV/CbCr/whatever they're called channels
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
zetef has quit [Remote host closed the connection]
<zid`>
22:16 got it, tiny prepub of a weird side-novel go
<gorgonical>
Why is this happening??? float * iter = whatever; later: *iter = val/255.0;
<gorgonical>
"error: pointer value used where a floating-point was expected"
<zid`>
time to pare it down to a test-case
<gorgonical>
iter is a *float type, and val and 255.0 are both floats. What the hell is the compiler on about?
<zid`>
at which point you will trivially find it yourself anyway and we won't need to be involved
<heat>
did you forget a ; before that line
<heat>
is val a pointer?
<heat>
many stupid questions
<gorgonical>
val is a float
<gorgonical>
I must be missing something so obvious
<gorgonical>
fuck
<zid`>
test case, test case, test case
<gorgonical>
I am
<zid`>
there we go
<gorgonical>
nevermind. I'll see myself out
<zid`>
What was it? shadowed val with another dec? missed ;?
<gorgonical>
too many layers of pointers to dereference and I had the wrong amount of dereferencing for val
<zid`>
oopsie doopsie
<gorgonical>
yep
<zid`>
Have you considered knowing the types of your identifiers
<gorgonical>
It would be easier were I using a better language
<gorgonical>
"Statically-typed" c is a myth
<zid`>
it's static until you cast, and there's a way to get the compiler to reject that, I'd say it holds for all useful values of holds
<gorgonical>
just as an aside: it's safe to cast an int up to a float with a (float) cast right?
<gorgonical>
I've always assumed that was safe to do
<zid`>
yes it's just a value re-interpretation
<zid`>
(same as all casts, really)
<zid`>
it's only a 'problem' if you need the answer to come out exact for your code to work, and your float type can't do that
<gorgonical>
I guess the danger really comes from trying to cast a float to an int. But that really depends on how your machine works doesn't it
<gorgonical>
It's fully different registers
<zid`>
no it's fine, but like I said, it's a value reinterpret
<zid`>
so you might lose a bunch of digits
<gorgonical>
Right. C's job is to correctly convert between f0 and r0 or whatever
<heat>
>too many layers of pointers to dereference
<zid`>
I'm a 7 star programmer heat
<heat>
something's up with your pointers and something's up with your naming
<heat>
float *val is like int *integer
<zid`>
irl though I basically never use anything beyond *
<zid`>
** is rare, and is almost always only "pointer to opaque handle"
<gorgonical>
frame * frames; plane * planes; data * data
<gorgonical>
frames[0].planes[0] is still a pointer
<heat>
that's not my problem with th ename
<zid`>
he wants ppFramesFrame
<heat>
float val makes sense, float *val doesn't
<zid`>
frames[0].planes[0] makes no sense
<gorgonical>
the real code was frames[0].planes[0]/255.0, which is not valid
<zid`>
what type is 'planes' there
<heat>
ah oh so you had no val
<gorgonical>
I committed the classic SE error of lying about the code I was running. Because I am a fool
<zid`>
I assume multiple 'plane', and a 'plane' is a compound
<heat>
zid`, do note that i sometimes use some slight hungarian notation for ** in out parameters
<zid`>
so you had pointer to compound, so the [0] still leaves you with a compound
<dostoyevsky2>
heat: Because when hackers see you are running OpenBSD they just give up and go somewhere else, very much like someone looking for sushi wouldn't just order fugu sushi
<heat>
is this mofo using the "first they came for ..."?
<Ermine>
> system-D
<heat>
as south park once said: "THEY TOOK ER JERBS UTILITIES"
<childlikempress>
mjg: is that fucking real what
<zid`>
dostoyevsky: I believe the thing they mutter under their breath is "who the fuck has shellcode for openbsd?"
<gog>
hi
<zid`>
gog, elden ring enjoyer?
<gog>
i watched my friend play it
<Ermine>
when hackers see you're running they try to not to die from laughter
<mjg>
however, one of the fucks there is a "senior vp", i suspect that guys' tatoo is fake
<Ermine>
btw, the value you get from hacking openbsd system is lower than cost of hacking openbsd
<Ermine>
S E C U R I T Y
<geist>
zid`: woot
<heat>
no women will ever touch you again as they'll quickly notice you're a loser with a fedora tattoo
<kof673>
thing is, if your employees are tatooed ^^^^^ then does that mean they will just obey since it would be quite ridiculous to get fired and still have the tat lol
<mjg>
> “[I embrace] all the principals they embody. The open source technology, and how anybody can change anything. There’s no hierarchy involved. I do like that from a technological standpoint. That’s what drove me to work at Red Hat, essentially.”
<kof673>
doesn't seem a good negotiating tactic lol
<mjg>
this description of rh is blatantly not true
<kof673>
:/ all corporations are hierarchy, anyways ...
<mjg>
mon
<kof673>
go on :D
<mjg>
key with rh is that trying to do something right will get you fucked
<mjg>
"don't rock the boat" is as true at red hat as everywhere else
<heat>
can we not crap on things not named openbsd tonight?
<mjg>
theo unmatched you on grindr?
<heat>
how do you know theo has a grindr
<heat>
o_0
<Ermine>
Better make a Solaris tatoo so girls know who to kiss
<mjg>
well something clearly set you off
<zid`>
geist: I'm a few hundred miles south of edinburoughgh
<zid`>
else I might be able to see it too
<zid`>
gedamo is the only resident scot I know
<Ermine>
i wonder if valve is still anarchic
<Ermine>
Why EVERYONE on that thread write "systemD"????
<Ermine>
And nobody discusses 'machinectl shell' which is here for years...
<mjg>
do they use arch btw
<heat>
nix is the new arch
<mjg>
what's the catchphrase tho
<heat>
the catchphrase is them explaining nix to you
<mjg>
aight
<heat>
it's a *very* long catchphrase
* clever
hides
<Ermine>
Nix is cool if you like programming languages theory
<clever>
Ermine: it also fixes the "but it worked on my machine" issue
<clever>
years ago, i tried installing flash in firefox, and the "install script" was a single line, it used curl to download a .so file to the right path
<clever>
but being the gentoo ricer i was at the time, curl didnt exist, everything was built without curl support, wget was fine
<kof673>
bsd had "fetch" lol
<clever>
so i just downloaded the .so with wget, put it in the right place, and firefox segfaulted :P
<clever>
all of the research online, had confused users claiming wget corrupts the binary
<clever>
you must install curl and use curl to download it
<heat>
CALLED IT
<clever>
a bit of strace reveals, dlopen("libcurl.so")
<heat>
quick how does the nix programming language work and how does it control the nix package manager
<clever>
installing curl was the fix :P
<heat>
/aabnuaudjuajduajwdaduwha/bin/bash
* clever
whacks heat with /nix/store/ghw9wgd2i33myg9qflx5c8sv5ri4hm8d-shrunken/bin/busybox
<heat>
(i'm lying, if paths were this short we'd be great)
<heat>
lmao
<geist>
we should switch the Daystar to systemd
<geist>
maybe that's why it's throwing a tantrum right now
<Ermine>
ln -s whatever /bin/bash
<clever>
nix solves the above problem, by just making libcurl.so never be in the default search path
<clever>
you must properly define it in the package, or it just never works
<geist>
i bet if the sun was written in rust it wouldn't have sunspots
<heat>
do you think the sun runs solaris?
<clever>
and once properly defined, the whole "but it works on my machine" (because i had curl installed) problem vanishes
<geist>
heat: ooooooh good one
<heat>
see, it scales up to the sun
<geist>
OTOH it only has one core, so it should scale
<heat>
beat that linux
<nikolapdp>
ILLUMOS
<Ermine>
clever: I mean, yes
<Ermine>
it just that my CS seminarist focuses on PLs and he runs Nix
<Ermine>
and there's PL guy in #s6 which is also a maintainer of Nixos
<Ermine>
(But really, nix ideas are sound)
<kof673>
egyptian suns are double, anyways :) </basilisk> > I kill, and I make alive; I wound, and I heal
<heat>
instead of having a nix programming language, they should've used a combination of bash and perl
<Ermine>
> perl
m3a has joined #osdev
<heat>
can someone that uses s6 ever use nix? considering it's written in C++
<Ermine>
yes, there are actually 2 nixos maintainers in #s6 , and they mainain skaware packages in nix
<nikolapdp>
what does it being written in c++ have to do with anything
<zid`>
can we rewrite nikolapdp in C++
<zid`>
I want him to be 40% larger and much harder to maintain