<heat>
a lot of weird stuff going on because they don't require PCIe
sonny has joined #osdev
<heat>
like you have two separate scatter gather list types, and they're not supported on all commands, and one can't be used in nvme-over-fabrics
<heat>
they probably went for lots of weird "haha IOPS goes brrrrrrrrrrrr" optimisations
<heat>
(also, because of this, the linux driver is way more complex since it needs to support fabrics and PCIe)
<mrvn>
you could just ignore one list, right?
<zid>
where's the bit of the spec that makes it dma straight to my gpu for texture uploads
<mrvn>
ahh, that's why there are 2 lists. :)
<heat>
no
<heat>
"PRPs shall be used for all Admin commands for NVMe over PCIe implementations. SGLs shall be used for all Admin and I/O commands for NVMe over Fabrics implementations (i.e., this field set to 01b). An NVMe Transport may support only specific values (refer to the applicable NVMe Transport binding specification for details)."
heat has quit [Ping timeout: 240 seconds]
heat has joined #osdev
<heat>
i've just noticed the ambiguity in the PRP statement - you can also use SGLs over PCIe for IO commands
sonny has quit [Ping timeout: 252 seconds]
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
gog has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
wxwisiasdf has joined #osdev
<wxwisiasdf>
hi
<mrvn>
wo?
<gog>
hi
<heat>
hell
<heat>
o
<mrvn>
hell is other people -- Rugnetta
<gog>
good thing i'm a cat
<heat>
killall cat
<wxwisiasdf>
delete cat
<wxwisiasdf>
wait no if i delete cat my *nix dies :(
<mrvn>
apt-get install dog
<heat>
tac | tac
<wxwisiasdf>
you use apt-get? nooo, the cool people nowdays use conan
<heat>
the cool people use apt
<heat>
apt install > apt-get install
<heat>
actually, sorry
<heat>
the cool people use pacman
<mrvn>
..."Have you mooed today?"...
<wxwisiasdf>
pip install > apt install
<heat>
I USE ARCH
<mrvn>
cool people play pacman
<heat>
BTW
<wxwisiasdf>
oh no they use arch
<wxwisiasdf>
mrvn: what about... pong
<wxwisiasdf>
there is love for pacman, but no love for pong? :(
<mrvn>
you aren't cool enough for pong
<wxwisiasdf>
what about the cubic entertainment box
<wxwisiasdf>
more often called, "that blocky wobbly rectangle pc thingy"
<heat>
ping is better
<mrvn>
the not-idiot-box?
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<gog>
i use "arch"
sympt has quit [Remote host closed the connection]
<zid>
how do you know if someone uses arch
<gog>
they don't shut the fuck up about it
<zid>
:D
sympt has joined #osdev
<gog>
i mean linux is linux
<gog>
i've just been using arch-based for so long i'm in a sort of inertia with it
<zid>
yea I'm fine with gentoo and just cbf to not use it
<zid>
I picked it because it suited my needs and they haven't really changed so why bother
<gog>
i did enjoy the deep customizability of gentoo
<gog>
but not the compiling
<zid>
The compiling used to be a non-issue for me even on a VM, but with my LTO addiction it's starting to become one :P
<gog>
is LTO the new -funroll-loops?
elastic_dog has quit [Ping timeout: 240 seconds]
<zid>
LTO is -O3 for your -O3
<zid>
-Ocubed
<gog>
-O9 i see
<gog>
or would that be 27??
RAMIII has joined #osdev
<zid>
Actually 333,333,333
<zid>
It does use about a million times as much RAM to compile!
<gog>
threes all around
<gog>
i'll drink to that
<gog>
it might be possible that ill give gentoo another go
<zid>
You should test your drink for poison first
<zid>
have two
<gog>
i got a job and i've been working evenings and my paycheck is gonna be pretty good
<zid>
nice, what are you buying me?
<gog>
a computer
<zid>
I've got one thanks, need a new monitor though
<gog>
its for you in the sense that you will no longer have to tolerate my whinging about my shitty netbook
<zid>
I think the OSD chip and/or powersupply are going
<heat>
arch based is just like using linux mint
<heat>
arch linux manually installed = chad move
<gog>
arch cringe amirite
<zid>
if you show it the wrong shade of certain colours you get random 16 pixel wide lines everywhere
<zid>
and it likes to crash
<gog>
that's a bizarre problem for a monitor to have
<zid>
I think it's the OSD chip overlaying garbage
<gog>
yeh
<zid>
because of certain other issues I've seen during the crashes
<zid>
I'm not sure if the logic board is dying, or if the psu is just dying and it's making it flake out though
elastic_dog has joined #osdev
<zid>
I'd take it apart and recap it or whatever, but I don't fancy taking it apart once, let alone twice
<zid>
broken plastic clips and annoying amounts of hotglue are surely down that path
<gog>
maybe worth a try to fix if/when you replace it
<zid>
yea that was the plan
<zid>
get a new monitor, THEN open it
<gog>
yes
<zid>
but I refuse to buy a worse monitor
<zid>
when a better monitor is only twice the price ;)
<zid>
so I am in partially broken monitor limbo
<gog>
you don't have one sitting you can bring out of retirement for the meantime?
<zid>
1440p 144Hz is down to like £249 for a weird brand panel
<zid>
I have a 1280x1024 CRT on my desk that I can't drive unless I swap my 1050ti for my 670 with a bad vrm
<heat>
1440p is always crazy expensive
<zid>
this is 2048x1152
<gog>
why can't your card run it?
<zid>
I bought it because it was literally the only thing >1080p at the time that wasn't the £3000 apple cinema pro display thing
<zid>
>980ti means no RAMDAC
<zid>
I'd need a £100 hdfury
<gog>
ohhh
<zid>
or an ossc or something, anyway
Likorn has joined #osdev
<heat>
you should install arch linux
<heat>
might fix it
<zid>
You might be able to install arch on the osd chip
<gog>
the big q i have is if i should continue to use linux only when i get my new rig
<zid>
it's a standard part basically all monitors use
<gog>
think it'll work even for games
<zid>
and there was that defcon/blackhat/cccc or whatever talk about hacking them
<gog>
proton seems fine enough for what i want to play
<zid>
get two graphics cards
<zid>
passthrough one to a VM
<heat>
i'll always go for windows as well
<heat>
realistically, linux gaming is still crap
<gog>
the one i'm looking at is a ryzen 5 with a discrete nvidia
<zid>
farmville won't know what hit it
<heat>
laptop?
<gog>
yeah
<zid>
oh an laptop
<heat>
doesn't it come with windows?
<gog>
yeah it does
<heat>
ok gr8 problem solved
<heat>
ez
<zid>
I'd go with windows with vmware linux vm then
<heat>
i dual boot
<zid>
but downgrade the windows to xp64 so that it's actually nice to use
<gog>
nah 10 with all the crap cleaned out is fine
<gog>
11 is an absolute no-go for me though
<heat>
11 is better
<gog>
idk i don't like it
<heat>
its like windows 10
<heat>
but slightly different
<zid>
11 just seems identical to 10 for me, but with a TPM being available for ad tracking and drm as a base feature
<zid>
I think that's literally the only reason w11 exists
<heat>
what does a TPM have to do with ad tracking
<zid>
hardware id
<gog>
maybe i'll just use linux only
<heat>
you already have like 1 or 2 mac addresses
<zid>
If they *don't* offer that as a feature to customers they're missing a trick
<heat>
gog, what are you planning to run anyway?
<gog>
nothing terribly new
<zid>
like how facebook integration on website is primarily so they can correlate your other accounts to your facebook account, this lets them also tie in your windows login
<zid>
with it being an 'online' account you will have to port it to new hardwre and they will never ever lose you
<heat>
gog, like what?
srjek has joined #osdev
<heat>
discrete gpus are usually not great
* heat
cries in laptop
<zid>
integrated graphics is like.. fine
<gog>
new vegas, maybe elden ring
<zid>
it runs overwatch these days
<zid>
elden ring isn't even that playable on a 2080
<heat>
hm? last i checked it struggled to run csgo
<gog>
idk if i'll even play it
<gog>
honestly i could probably run new vegas on the 4650's onboard
<gog>
that's my backup plan if the one i have my eye on gets got, it's a floor model and about 25% discount
<heat>
you should play dark souls, the second best video game ever
<gog>
its sibling is slighly less good with half RAM/storage
<zid>
I've already got all the achievements though :(
<gog>
but no discounted model
<gog>
i've shopped around and buying from amazon is about the same after import fees and VAT
sympt has quit [Remote host closed the connection]
Likorn has quit [Quit: WeeChat 3.4.1]
troseman has quit [Ping timeout: 248 seconds]
wxwisiasdf has quit [Quit: Lost terminal]
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
PapaFrog has quit [Ping timeout: 240 seconds]
sympt has joined #osdev
sympt has quit [Remote host closed the connection]
sympt has joined #osdev
PapaFrog has joined #osdev
kaichiuchi has quit [*.net *.split]
ElementW has quit [*.net *.split]
ggherdov has quit [*.net *.split]
stephe has quit [*.net *.split]
mjg has quit [*.net *.split]
stephe has joined #osdev
kaichiuchi has joined #osdev
ElementW has joined #osdev
ggherdov has joined #osdev
relipse has quit [*.net *.split]
Bonstra has quit [*.net *.split]
Dreg has quit [*.net *.split]
klange has quit [*.net *.split]
snickerbockers has quit [*.net *.split]
geist has quit [*.net *.split]
scoobydoo_ is now known as scoobydoo
klange has joined #osdev
snickerbockers has joined #osdev
geist has joined #osdev
Bonstra has joined #osdev
Dreg has joined #osdev
relipse has joined #osdev
bauen1 has quit [Ping timeout: 240 seconds]
<geist>
aso ugh. i thought my server was stable, but nope. crashed again after 3 or 4 days
<geist>
at this point it has to be a cpu failure or a vreg failure or something
<ddevault>
ayy I woke up with an idea as for why I couldn't get to userspace and lo and behold now I have userspace working
<Mutabah>
noice!
<geist>
yay
<kazinsal>
:toot:
GeDaMo has joined #osdev
<gamozo>
woo
<kazinsal>
geist: godspeed you! fellow vaguely broken server emperor
<kazinsal>
my old E5-2650 box is... starting to do really weird stuff. I think the CMOS chip may be failing as no matter how many new batteries I feed it loses its CMOS config with even a few seconds of power loss
<kazinsal>
POST is starting to take longer and longer as well, which is a problem because being sourced from a 1U server, it has a distressingly long POST
<kazinsal>
it's nearing the point where I'm thinking about just getting whatever a 5800X and matching mobo and RAM to replace it and eating the hit to my savings account haha
<kazinsal>
power here can be a bit messy in the winter and spring because a lot of the power distribution grid has a bunch of chokepoints that would have been acceptable to go down when there was only 20,000 people living here but becomes a major disruption when there's 150,000...
<klys>
suggesting the dual socket option
vdamewood has joined #osdev
<klys>
https://www.ebay.com/itm/234456087004 I don't think the regular ryzen models can do this though epyc is similar (ddr4 not ddr5 tho) some cpus support tandem work, some don't
<kazinsal>
honestly I could solve a lot of my power related problems with a cheap UPS but it'd be nice to have some cores that were designed in this decade
<klys>
oh forget that it was the wrong item (needs 7003 support for good spu compatibility)
<klys>
s/spu/cpu/
<kazinsal>
the computational throughput of a 2.0 GHz sandy bridge core is kind of sad in comparison to a fully clocked 5800X or 11900K
<klys>
oh actually that was the right item and I can't read because it's late
vinleod has joined #osdev
vdamewood has quit [Killed (iridium.libera.chat (Nickname regained by services))]
vinleod is now known as vdamewood
bauen1 has joined #osdev
nick64 has joined #osdev
nyah has joined #osdev
bauen1 has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
<lg>
qemu with -m raspi0 doesn't seem to have given me atags data, r0-2 are all 0 when it boots into the kernel stub
eau has joined #osdev
pretty_dumm_guy has joined #osdev
<mrvn>
lg: ATAGS are kind of dead. Device Tree is just better and used on basically all ARMs.
<mrvn>
Not sure why rapsi0 wouldn't have a DT. The other raspi models have them iirc.
<mrvn>
kazinsal: I want an UPS that has an ATX output. It's stupid to boost the battery power back to 230V AC just to have the PSU get it back to 12/5V DC.
<mrvn>
Basically same design as every laptop.
gog has joined #osdev
Burgundy has joined #osdev
Likorn has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
Likorn has joined #osdev
<lg>
mrvn: does the rpi bootloader put that together or is it left as an exercise for the reader?
<mrvn>
it's put together and modified depending on the options and overlays in the config on your boot partition
Likorn has quit [Quit: WeeChat 3.4.1]
gog has quit [Quit: byee]
pretty_d1 has joined #osdev
pretty_d1 has quit [Client Quit]
pretty_dumm_guy has quit [Ping timeout: 260 seconds]
pretty_dumm_guy has joined #osdev
dude12312414 has joined #osdev
nick64 has quit [Quit: Connection closed for inactivity]
Vercas has quit [Ping timeout: 240 seconds]
Vercas has joined #osdev
Likorn has joined #osdev
dennis95 has joined #osdev
Terlisimo has quit [Quit: Connection reset by beer]
Terlisimo has joined #osdev
<mrvn>
How do I write a template<typename T [[gcc:packed]]>?
wand has quit [Remote host closed the connection]
wand has joined #osdev
heat has joined #osdev
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
gwizon has joined #osdev
gwizon has quit [Client Quit]
<Bitweasil>
lg, the dtb files are present, and you can find the dts source files in the Rpi kernel tree. Or just use 'dtc' to disassemble the running ones.
bauen1 has quit [Ping timeout: 240 seconds]
<Bitweasil>
But the bootloader does a few things, and will add overlays/etc depending on config.txt, so what's passed to the kernel isn't exactly what's on disk.
<Bitweasil>
I think it also adds things like the RAM size/range/etc.
<mrvn>
You can't trust the dtc output of the running one in linux. It corrupts it somewhat.
bauen1 has joined #osdev
<Bitweasil>
The one in /sys/firmware or such?
<Bitweasil>
There's a 'file' input type to dtc to handle that.
<Bitweasil>
I guess 'fs'
Matt|home has joined #osdev
dude12312414 is now known as IT_WAS_ALIENS
<mrvn>
Bitweasil: not sure if it was sys or proc but it drops the cell/address sizes at the wrong places.
<mrvn>
I think the virtual FS code for it isn't design to handle cell/address sizes switching between 0, 1 and 2 all the time like the RPi DT does.
<Bitweasil>
Oh, huh. Alright, didn't know that was an issue! TIL!
Brnocrist has quit [Ping timeout: 240 seconds]
bauen1 has quit [Ping timeout: 276 seconds]
bauen1 has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
IT_WAS_ALIENS has quit [Read error: Connection reset by peer]
gildasio1 has quit [Remote host closed the connection]
gildasio1 has joined #osdev
IT_WAS_ALIENS has joined #osdev
dennis95 has quit [Quit: Leaving]
bauen1 has joined #osdev
Brnocrist has joined #osdev
bauen1 has quit [Ping timeout: 248 seconds]
sikkiladho has joined #osdev
bauen1 has joined #osdev
phr3ak has quit [Quit: QUIT]
phr3ak has joined #osdev
mahmutov has joined #osdev
<geist>
oh hmm that might make sense
<geist>
because maybe it re-orders the nodes when it flattens it into the fs
<geist>
so you dont get precisely the order i the FTD
<geist>
FDT
<mrvn>
the tree structure is quite recognizable, it's just not like the original input
<geist>
yah i say that because i have taken to tarring up the /proc/device_tree trees in te past as a nice way to consume them
<geist>
saving a copy when working on a device, etc
<mrvn>
I tried using that as test data for my DT parser and couldn't figure out why it bombed till I compared it to the one from the boot partition.
<geist>
good to know
<geist>
in that case you're saying even the FDT you read out of /proc or /sys is already munged?
<mrvn>
might be specific to the RPi because how it remaps the devices from 32bit peripherals to 64bit arm addresses to 32bit VC addresses
<geist>
yah makes sense
<geist>
i duno what the spec says either, does it say the cell/address/interrupt sizes field be always at the start of the node?
<mrvn>
Van't remember if I checked the raw data or just the dtc output.
<mrvn>
every node can have a cell/address field afaik.
<clever>
one sec
<clever>
/sys/firmware/fdt has the raw fdt that linux received as input
<clever>
and when you run dtc on it, the nodes are returned without any re-ordering (enless you add -s to sort)
<mrvn>
can you diff that against the one on the boot disk?
gildasio1 has quit [Ping timeout: 240 seconds]
<clever>
i also prefer using -s when doing diffs, so order changes dont muck up the diff, but if you want to know about order changes...
gildasio1 has joined #osdev
nur has quit [Read error: Connection reset by peer]
No_File has joined #osdev
No_File has left #osdev [#osdev]
nur has joined #osdev
gildasio1 is now known as gildasio
dra has joined #osdev
gorgonical has quit [Ping timeout: 240 seconds]
sikkiladho has quit [Quit: Connection closed for inactivity]
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
mahmutov has quit [Ping timeout: 240 seconds]
Burgundy has quit [Ping timeout: 240 seconds]
<heat>
yo geist do you know why the nvme spec looks so insanely optimised?
<heat>
i feel like they just went for the max IOPS they could but you may know better as an Industry Insider(tm)
<mrvn>
to get 32GB/s?
<heat>
IOPS, not bandwidth
<mrvn>
do you know how many IOPS you need for 32GB/s?
<heat>
something I finally figured out today - PRP entries only cover a single page, SGL entries cover a phys address + length (like a regular vectored IO thing); it's unclear why anyone would prefer the PRP
<heat>
nope
<mrvn>
8388608 IPOS/s for the PRP entries
moatx has joined #osdev
<mrvn>
Even if SGL what do you think the average length would be?
<heat>
depends on the size of the IO
<mrvn>
ever benchmarked that in your kernel?
<heat>
https://i.imgur.com/mRdijUh.png /me thinks they really just went for IOPS optimisations both in-hardware and in-driver
<mrvn>
I think linux does 128kb (32 pages) read-aheads.
<heat>
no, I don't really do IO larger than a page for now
<mrvn>
And for DBs you probably get 4k access a lot of the time.
<clever>
some engines like sqlite and innodb, allow you to set a page size, and everything operates in units of that
Likorn has quit [Quit: WeeChat 3.4.1]
<mrvn>
that better be the same as the ZFS block size :)
<clever>
for sqlite, the journal is just saving a backup copy of the entire page before its modified in-place
<clever>
and a commit is just throwing out the backup, while a rollback is restoring it
<clever>
when not using the write-ahead-log feature
<clever>
mrvn: nothing currently goes out of its way to make sqlite and zfs line up automatically, the user must choose to
<geist>
heat: yeah right?
<mrvn>
clever: yes, and you better do.
<geist>
also it seems to be designed to be virtualized well too. they really go out of their way to reduce the number of trapped things (ie, accesses to registers)
<geist>
but yeah what i dont copletekly understand is what implementations implement. lots of it is optional, so there's probably some baseline that everything is expected to do
<mrvn>
even the pins on the connector have optional bits.
<mrvn>
well, different notches and all
<geist>
heat: hmm, so what does that linux doc link imply? they actually use PRPs or SGLs?
<geist>
can a PRP do >4K linear run? may be some advantages to that in some situations
<mrvn>
"PRP entries only cover a single page,"
<heat>
geist, it seems they use SGLs since they map better to bio_vec
<geist>
mrvn: maybe they meant a single segment. geez you're being kinda picky today
<mrvn>
or maybe a page could be 2MB? ask heat
<geist>
mrvn exactly
<geist>
anyway yeah linux directly mapping scatter ist to SGLs make sense to me, it's generally what i'd expect for doing IO into a block cache
<heat>
PRP entries represent nvme memory pages
<heat>
which may or may not be 4K (but usually are, for instance fuchsia's driver errors out if the controller doesn't support the native page size)
<geist>
so it is kidna interesting then what the exact purpose of the PRPs are in this case. i suppose one could just issue a crap ton of transfers, breaking everything into 4K
<heat>
that's just something you configure
<mrvn>
It used to be scatter gather was to collect lots of little 4K IOPS into a single big read or write.
<geist>
and except for very high end, since queing transfers on nvme is easy that might make a lot of sense
<heat>
also, more weirdness (dunno if you read it yesterday)
<heat>
<heat> "PRPs shall be used for all Admin commands for NVMe over PCIe implementations. SGLs shall be used for all Admin and I/O commands for NVMe over Fabrics implementations (i.e., this field set to 01b). An NVMe Transport may support only specific values (refer to the applicable NVMe Transport binding specification for details)."
<mrvn>
now we just pass the io vecs to the hardware
<geist>
hmm, what does that mean heat?
<mrvn>
heat: are there any admin commands larger than a page?
<heat>
geist: so, you have admin commands (nvme namespacing, identify, etc) and IO commands (read, write, compare, etc)
<heat>
for whatever reason, you can't use SGLs for admin commands in NVMe over PCIe
<geist>
hmm, interesting okay
<geist>
so it implies that PRPs are *always* implemented, at least
<geist>
does a base implementation have to implement both?
<heat>
except for fabrics
* geist
nods
<heat>
it looks like a PCIe one does? but I'm not too sure
<geist>
yah wondering if a base implementation can get away with just PRPs
<geist>
and if so is it pretty efficient or is that just silly
<geist>
sice you can queue and retire commands pretty easily, i'm thinking PRP only impls is probably pretty good
<geist>
hmm are there restrictions on the native nvme page size? i assume the minimum sector size is 512, but is the max 4k?
<heat>
minimum 4K max 128MB IIRC
<geist>
i have somewhere a i think WD Blue nvme that can and was reformatted (by me) to be 4K sectors
<heat>
but the controller can further restrict that range
<geist>
hmm, that's page at a transfer level, but sectors are different?
<heat>
/shrug
<geist>
since you can definitely have 512 byte sectors still, all my samsguns are 512
<mrvn>
native or emulated?
<heat>
i bet these things don't emulate 512 byte sectors
<mrvn>
that would require 8 times more descriptors.
<geist>
i only say that because it explicitly was a thing i had to reformat using the nvme-cli utilities
<clever>
ive seen exactly 1 rpi user, that had an issue with booting from 4k usb (sata i think) drives
<heat>
mrvn, no it wouldn't, page != sector
<geist>
if you look at the description of teh dvice using `nvme list` it tells you the sizes
<clever>
(the rpi firmware doesnt support it)
<mrvn>
What's the erasure size on NVMEs?
<clever>
but, he found an XP compatability util for his hdd
<clever>
which forced the drive to go into 512 emulation mode
<clever>
and then things worked fine
<geist>
yah as far as i've found, consumer level samsgun devices all only support 512. you can't reformat
<geist>
but the WD ones do let you do 4K
<geist>
but thats at the sector level, and thus presumably sets the minimum transfer block size
<heat>
what does reformatting involve? deleting all namespaces and creating a new one?
<clever>
this is the only time ive ever seen somebody successfuly change the emulation size
<geist>
basically
<heat>
btw something cute I found out about: nvme has fused commands
<geist>
the nvme command can do it if the firmware lets you. i think you reformat at the namespace granularity, but i dunno if devices that actually support more than one namespace let you mix it
<heat>
you can fuse a compare command and a write command to get compare-and-write behavior
<clever>
:O
<clever>
disk block compare??
<heat>
yup
<clever>
i could almost see that being useful for lock-less sharing of an fs
<geist>
so basically a conditional write i guess?
<heat>
yes
<geist>
for that example
<clever>
if you fail the race, the write doesnt happen
<geist>
kidna interesting, though i dont know precisely what that would accomplish except an optimization
<geist>
though i guess if it returns an error code based on what it dooes
<geist>
it'd tell you if the thing it replaced was different or not
<geist>
that might be helpful
<geist>
or if it had the ability to return the old data maybe
<geist>
but seems like that'd be a specialied command that did a read/write
<mrvn>
you mean the new data, right?
<clever>
the only thing that comes to mind in terms of flexibility, is the 1541 from the c64 era
<heat>
you get the status from the command telling you if it failed
<heat>
it works like a cmpxchg as far as I can see
<clever>
where you could read/write blocks to/from the disk drives ram, transfer them to/from the pc, and execute code on the drive itself
<heat>
well, except the xchg
<mrvn>
clever: well, the floppy was another 6502
<heat>
cmpxwrite
<clever>
mrvn: exactly, you can just program it freely, to do whatever you want
<mrvn>
clever: it still took them like 40 years to optimize the firmware to decode the 8to11 encoding at the disk speed.
<geist>
but anyway nvme is the bees knees
<heat>
this is also specified as an atomic operation within certain transfer sizes haha
<heat>
disk mutexes go brrrrrrrrrrrr
* mrvn
throws a lockguard at heat
<heat>
but you define it wrong and get most vexing parse'd
<mrvn>
heat: forgot to give the guard name, did you?
<mrvn>
+a
<mrvn>
*kneel* Loackguard i dub thee Loki.
<geist>
zod
darkstarx has joined #osdev
darkstardevx has quit [Remote host closed the connection]
* Griwes
throws almost always auto and ctad at heat
Likorn has joined #osdev
<heat>
auto lck = std::lock_guard(mtx);
<heat>
this looks horrific
<mrvn>
std::lock_guard lck(mtx);
<heat>
i know it's literally the same codegen, but damn it looks bad
<mrvn>
or better {mtx}
<klange>
with lock():
wxwisiasdf has joined #osdev
<mrvn>
I'm missing that
<wxwisiasdf>
hi, so basically how do i force autoconf to force gcc to force programs to sue shared libraries
<wxwisiasdf>
instead of gcc straight up putting the entire custom libc into the program
<mrvn>
you can #define a WIDTH(mtx) { ... }
<klange>
you don't, because libtool gets in the way
<mrvn>
-D
<wxwisiasdf>
klange: uh oh
<mrvn>
wxwisiasdf: libc isn't put into the binary at all normaly
<heat>
you have to find and patch libtool.m4 and then autoreconf
<wxwisiasdf>
i mean nobody wants a 100KB /usr/bin/cat right
<wxwisiasdf>
mrvn: my autoconf seems to do so apparently
<heat>
it's because your libc is poorly designed
<klange>
damn right -rwxrwxr-x 1 root root 5.8K May 17 07:30 /bin/cat
<wxwisiasdf>
i am cross compiling for s390 on a x86 host, and i told libtools to make libc.la, still it links it as a static lib
<klange>
okay, so you shouldn't need any las for libc
<mrvn>
wxwisiasdf: what do you thing the a in .la stands for?
<wxwisiasdf>
oh
<klange>
your cross-compiler should ✓ Just Do It™
<mrvn>
just install /usr/lib/s390-linux-gnu/libs.so
<klange>
mrvn: 'la' is a 'libtool archive' and it just says where to find the files, it does not imply linking them statically
<heat>
autotools is ❌ Horrifying™
<wxwisiasdf>
i should have used meson :/
<heat>
do it
<klange>
if you are doing something yourself, don't ever use autotools; autotools is something you throw at a project so you can dump it on linux distro maintainers
<heat>
my experiences with meson have been very positive
<heat>
except for that one time where I tried to generate a crt1.o and I couldn't because meson doesn't support making bare object files without horrible hacks
<clever>
klange: what about cmake? the only time ive used that was to deal with windows+linux+mac builds
<wxwisiasdf>
uhhhh
sikkiladho has joined #osdev
<heat>
clever, cmake is like 4x better than autotools
<wxwisiasdf>
my os is basically the kernel + libc + 2 unrelated libs + 8 random programs
<wxwisiasdf>
so uh, will meson do it for that?
<heat>
probably
<klange>
you should probably just write makefiles
<kazinsal>
^^
<GreaseMonkey>
cmake isn't magical when it comes to cross-platform stuff but it's not too shabby
<klange>
meson, cmake, autotools... these are all makefile generators
<GreaseMonkey>
cmake can generate ninja
<GreaseMonkey>
iirc so can meson
<heat>
if you want to shill for google use gn
<klange>
and they all exist for solving the problem of having different build requirements for different _targets_
<wxwisiasdf>
my os builds for both s390 and x86
<klange>
you don't have different targets for your OS (target != architecture, in this case, only platform, and you ARE the platform)
<wxwisiasdf>
oh
<wxwisiasdf>
oh i see
<heat>
i disagree
<heat>
they're incredibly useful abstractions
<wxwisiasdf>
i used to have julia as a build system that used wine for using a special gccmvs version that only ran on windows and could make 21-bit programs for s370
<heat>
cheers that's horrific
<mrvn>
I have julia as fractal generator
<wxwisiasdf>
heat: oh yeah did i also mention i used JCL files
<mrvn>
wxwisiasdf: long live 31bit with s390
<wxwisiasdf>
yes
<wxwisiasdf>
i just find myself "build-system-hopping" and i don't know which to choose
<bslsk05>
github.com: toaruos/auto-dep.krk at master · klange/toaruos · GitHub
<heat>
i know the feeling
<heat>
but autotools is definitely not the answer
<GreaseMonkey>
from what i've heard, JCL exists just so that COBOL programmers can say "at least it's not JCL"
<mrvn>
s390 really makes me want to define CHAR_BITS=10, sizeof(int) = 3;
<wxwisiasdf>
GreaseMonkey: jcl exists so you can copy files using 10 lines of code
<klange>
An OS is really the ideal thing for using (GNU) Make raw. You don't need to automagically locate libraries, you don't need to figure out how to build DLLs for Windows, you don't need to yank a dozen third-party libs off the interwebs... you maybe want automatic discovery of sources [$(wildcard) or $(shell find)]
<wxwisiasdf>
fair
<klange>
What sparked all this recent interest in s390? Isn't it a super dead platform the 90s?
<wxwisiasdf>
klange: oh not s390
<wxwisiasdf>
i am coding specifically for z/arch
<wxwisiasdf>
which is basically s/390 but 2022 edition
<heat>
klange, wildcard is considered harmful
<wxwisiasdf>
the interest mainly came because i don't really know i just wanted to explore something new
<GreaseMonkey>
honestly i'd be tempted to use a Tcl script as a build system
<klange>
heat: my build systems are all built on lots of $(wildcard) and $(patsubst)
<heat>
makefiles don't give you nice things like: readable build system files without 10 macros on top, header deps, builds that rebuild if the build files change
<heat>
out of tree builds
<heat>
builds with multiple targets (compiling a program for both the host and the target OS)
<GreaseMonkey>
"considered harmful" isn't considered enough, because if it were, people would consider it harmful
<heat>
it is harmful, that's why new build systems don't have wildcards
<heat>
or have it as a "EXTREMELY DEPRECATED DO NOT USE" option
<wxwisiasdf>
so uh... do i makefile
<heat>
you'll also want to avoid recursive make (which you don't need to do if you're using a build system on top, since that works things out for you)
<heat>
makefiles are also slower than ninja
<wxwisiasdf>
i guess i will stick for autotools for now
<klange>
whatever you do, stop using autotools
<heat>
oh jeez oh man not autotools
<klange>
you can debate other shit for ages, but autotools is always the wrong answer
<GreaseMonkey>
ninja tends to be quicker at working out what not to build, and also does a reasonable calculation of how many processes you can run
<heat>
i know i just told you not to use makefiles but if the other option is autotools, go for makefiles
<klange>
write out all of your build commands in a static shell script and you've got a better build process than autotools
<GreaseMonkey>
but yeah, plain make will get you a decent amount of the way, even if you're going to use wildcard
<clever>
i recently saw somebody basically abusing make as a shell script
<klange>
hire an intern to manually build everything by hand, and you have a better build process than autotools
<clever>
they had a single rule, with 3 commands, that assembled, linked, and objcopy'd
<GreaseMonkey>
i think people have used make as a parallel init system
<clever>
at that point, its not even make!
<heat>
toybox's build system is just a makefile that calls into some shell scripts
<heat>
it's horrifying but I think the point is that AOSP can build toybox using toybox
<geist>
clever: you can abuse it for fancy shell scripts indeed
<geist>
a make with just a bunch of phony rules to run some premade things. actually not half bad
<clever>
geist: ive also abused make for rc.d init scripts before
<klange>
obligatory `make run` target
<clever>
#!/usr/bin/make
<kazinsal>
I have definitely written makefiles that are more shell than make
<clever>
and then ./foo start, winds up acting like `make start`
<kazinsal>
eventually I realized that was a terrible idea and instead made the build system primarily a shell script that called makefiles based on what you shoved into the args
<geist>
i generally have a token script called `doit` that just does whatever last thing i was working on
<geist>
usually drives make, does whatever configuration i need for whatever
<geist>
i just continually hack it so that i dont generally have to do more than run doit for every cycle
<heat>
omg GNU make as a shebang is so fucking cursed
<clever>
heat: :D
<heat>
#!/bin/gcc -O2 -c on .c files?
<klange>
Don't you need -f on that?
nyah has quit [Ping timeout: 272 seconds]
<klange>
heat: can't have multiple arguments in a shebang, that's a no-no
<heat>
as usual, afaik it depends on the POSIX system
<heat>
because everything in posix is consistent
<GreaseMonkey>
i used to make C files have a bit of shell at the start, and the second line was #if 0
<Griwes>
<heat> auto lck = std::lock_guard(mtx);
<Griwes>
no, better, auto _ = std::lock_guard(mtx);1
<klange>
shebangs aren't posix
<Griwes>
s/1/!/
<Griwes>
it's great
<Griwes>
come to the auto side, we have auto
<heat>
#!/usr/bin/env -S gcc -O2 -c should work on freebsd/linux I think
<klange>
just wrap it in a shell script that adds the other args
<heat>
Griwes, what's the next way of creating a lock guard? std::make_lock_guard()?
<Griwes>
wdym "next way"
<heat>
well C++23 ought to add a new way to do things of course
<heat>
it's the C++ way
<Griwes>
lol
<Griwes>
we are not *quite* that bad yet
<Griwes>
it's only make_pair that has been touched every (I think) revision so far
<Griwes>
but that's because make_pair is ridiculous
<heat>
something something break the ABI and make an incompatible c++ version that doesn't need all these hacks
floss-jas has quit [Quit: Leaving]
moatx has quit [Quit: Leaving]
dra has quit [Remote host closed the connection]
wxwisiasdf has quit [Ping timeout: 240 seconds]
Ali_A has joined #osdev
bxh7 has joined #osdev
<kingoffrance>
i always use #!<space> because it is some apparently ancient allowed thing, live dangerously seeing if it will break