<bslsk05>
en.wikipedia.org: Plan 9 from Bell Labs - Wikipedia
<kingoffrance>
In the same manner, a distributed computing network can be composed with a union directory of /proc hierarchies from remote hosts, which allows interacting with them as if they are local.
<heat>
well yes and no
<heat>
look at sysfs :)
<heat>
the everything is a file thing is definitely not dead
<kingoffrance>
there is no single definition of "file". there is : 1) different charsets (or whatever you want to call them, "encodings") 2) see above -- some files more equal than others
<bslsk05>
stackoverflow.com: c - How can `fsetpos()` be used to "allow random access on files that are too large to handle with `fseek()`?" - Stack Overflow
<kingoffrance>
not advocating that, but: File access mode flag "b" can optionally be specified to open a file in binary mode. This flag has no effect on POSIX systems
<kingoffrance>
some files more equal than others, again
<kingoffrance>
nor am i saying that was a "wrong" move. simply noone agrees on what a "file" is, or ever did, or ever will
<geist>
heat: good question. probably not since the memory barrier already happened
<geist>
but how much less of a hit is hard to quantify
<geist>
also arch specific i assume
<geist>
oh weird. there was a gap in time on my irc client where what heat had said like 7 hours ago was the last thing
<heat>
I have invented time travel
<heat>
or I broke TCP
<heat>
either one is fine with me :P
<geist>
but yeah my general model of atomics like that is based on some idea that the cpu is weakly ordered (ie, ARM) and it's basically yolo until a barrier comes along
<geist>
and then there's some zero-to-nonzero hit where it has to establish a before/after barrier which reduces its ability to yolo
<geist>
so in your case where you have a spinlock/atomic/spinlock, the first spinlock is presumably the real barrier
<geist>
how much of a hit that is is dependent on the yolo factor the cpu was enjoying before
<heat>
yes but for example I was imagining you'd still need to pay for things like the lock prefix on x86
<geist>
and how much you crimped its style
<geist>
i'm guessing x86 has fundamentally the same inner model, its just got less ability to yolo
pieguy128 has quit [Ping timeout: 240 seconds]
<geist>
but yeah that's a good question. i've always *assumed* that the first atomic after a series of non atomics is more expensive than a series of atomics
<geist>
but i dont really know
<heat>
otoh x86 spinlocks don't need a barrier
<geist>
sure but it's implied
<geist>
well it's implied in the sense that the memory model is in order
<heat>
an atomic compare exchange with acquire semantics doesn't generate a memory fence
<geist>
but i am guessing there's still a certain amount of yolo going on but atomics act as a fence
<heat>
which was the scary thing in my head
<heat>
tho lock is also scary
<geist>
yah crazy that arm has full relaxed atomics
<geist>
ie, no barrier in either direction
<geist>
which it's kinda a brain teaser when yuo think about it
<heat>
how does that work?
<geist>
wel, i guess it tosses it in the queue and does the atomic transaction but it just doesn't order it relative to any other memotry transactions that are in flight (aside from usual rules like reads after writes)
<geist>
it's great for things like bumping a counter
pieguy128 has joined #osdev
pieguy128 has quit [Ping timeout: 250 seconds]
pieguy128 has joined #osdev
aejsmith has joined #osdev
pieguy128 has quit [Ping timeout: 250 seconds]
kspalaiologos has joined #osdev
ZombieChicken has quit [Quit: WeeChat 3.4]
heat has quit [Ping timeout: 250 seconds]
anandn has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dennis95 has joined #osdev
lleo has joined #osdev
pretty_dumm_guy has joined #osdev
GeDaMo has joined #osdev
pretty_d1 has joined #osdev
pretty_dumm_guy has quit [Ping timeout: 240 seconds]
pretty_d1 has quit [Quit: WeeChat 3.4]
pretty_dumm_guy has joined #osdev
mahmutov has quit [Ping timeout: 240 seconds]
kspalaiologos has quit [Quit: Leaving]
biblio_ has joined #osdev
biblio has quit [Ping timeout: 250 seconds]
Burgundy has joined #osdev
anandn has joined #osdev
lleo has quit [Ping timeout: 256 seconds]
heat has joined #osdev
anandn has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
heat has quit [Ping timeout: 256 seconds]
ElectronApps has joined #osdev
mahmutov has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
kori has joined #osdev
Sos has joined #osdev
ElectronApps has quit [Remote host closed the connection]
Jari-- has joined #osdev
orthoplex64 has quit [Remote host closed the connection]
orthoplex64 has joined #osdev
dude12312414 has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
[itchyjunk] has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
[itchyjunk] has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dennis95 has quit [Quit: Leaving]
dude12312414 has joined #osdev
srjek has joined #osdev
freakazoid333 has joined #osdev
nyah has joined #osdev
jborgner has joined #osdev
heat has joined #osdev
pieguy128 has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
biblio_ is now known as biblio
heat_ has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 250 seconds]
heat_ is now known as heat
<heat>
ok so I was trying to fit my ported packages inside CI and I just found out ncurses does really insane stuff with /usr/include inside configure
<heat>
they _pass it as an include directory_
<heat>
--sysroot goes out the window
<heat>
now I don't know what to do
<heat>
the build fails in non-trivial multilib configurations because my toolchains simply don't grok that
<heat>
such as, erm, every debian/ubuntu system
<sortie>
heat, damn, that kinda stuff happens :| Generally my philosophy is to patch stuff like and fix it.
<zid>
and now we know why gentoo patches everything and builds inside a chroot
<sortie>
The weirdest stuff I ever saw was a port that put the compiler and settings inside an installed header so dependencies could get it
<sortie>
heat, generally patching stuff to use PKG_CONFIG / PKG_CONFIG_FOR_BUILD etc. is the cleanest solution
<sortie>
Things like running custom foo-config programs from $PATH (except pkg-config) is verboten as it doesn't cross-compile
<heat>
yes but I don't understand at all why they do -I/usr/include
<heat>
it makes no sense
<sortie>
It's some shit reason. It happens now and then. You gotta go and patch it out
<heat>
they want to test if the C++ compiler works, they never add -I/usr/include in ANY OTHER COMMAND
<heat>
just that one
<heat>
for some reason
<heat>
autoconf is cursed
<heat>
ncursed
<sortie>
In autoconf's defense, this is ncurses' own doing I imagine
xenos1984 has joined #osdev
<heat>
sortie, what does --with-sysroot do when you already have (C/CXX/LD)FLAGS properly set?
<sortie>
heat, to be honest that option doesn't really work
<heat>
hmm actually didn't it do something totally different to what gcc does
<sortie>
It's a libtool thing and it does a bunch of shit libtool stuff involving .la files and what not
<heat>
>run
<sortie>
Packages in general simply does not have support for injecting a --sysroot parameter to the compiler
<heat>
yeah
<clever>
nix solves this kind of problem, by wrapping the compiler, and injecting flags via a second set of (C/CXX/LD)FLAGS vars
<sortie>
The solution I use is have the cross-compiler have a default sysroot set. Ports can detect that if they absolutely must but usually that's a bad thing.
<heat>
i'm injecting --sysroot and for clang, --target, in all the flag variables
<clever>
so even if the package explicitely sets CFLAGS, the NIX_CFLAGS still get mixed in
<heat>
sortie, but that doesn't work if you want to try to provide prebuilt toolchains
<sortie>
When I build ports, my tix-build(8) program essentially wraps the compiler binary and injects whatever --sysroot value onto it, and also wraps pkg-config with all the variables
<heat>
which I do because things like LLVM are slooooooooow to build
<sortie>
The pkg-config stuff is super important and a key part of it
Tangent-Man has joined #osdev
<heat>
i dont have any of that yet
<sortie>
A whole bunch of stuff needs to run pkg-config to figure out dependencies on the build machine too, and also needs pkg-config for doing the cross-compilation
<sortie>
pkg-config(1) has a lot of useful environment variables that means you can us the distro binary to cross-compile with
<sortie>
I essentially emit a cross-pkg-config that cross-compiles using my sysroot (and turns on static linking, aetc.)
<sortie>
Plus a pkg-config for the build system that's set in PKG_CONFIG_FOR_BUILD
<sortie>
Ports are then supposed to use $PKG_CONFIG and $PKG_CONFIG_FOR_BUILD appropriately, just like they should use CC and CC_FOR_BUILD etc.
<sortie>
(I might emit a plain pkg-config script that fails the build if it's invoked, to make sure the variables are respected)
<heat>
i feel like that should all be python
<heat>
and i also don't know how to feel telling people to use python
<heat>
am i a bad person
<heat>
probably
Teukka has quit [Read error: Connection reset by peer]
<sham1>
Perl
Teukka has joined #osdev
<heat>
we should make a build system that's entirely shell scripts with macros on top
<heat>
then we just copy it from project to project
<heat>
but slightly differently each time
<GeDaMo>
I wonder if you could write it in UEFI shell
<clever>
heat: sounds similar to the unholy mess that is gnustepbase
<heat>
GeDaMo, I don't think it's turing complete, it's just a way to execute commands
<heat>
clever, is that a rich man's autotools
<GeDaMo>
Pity OpenBoot isn't more widespread, it has Forth :P
<heat>
pity efi bytecode failed
<geist>
hmm reminds me, i should actually try to package up that e1000 patch i did and see abot pushing it upstream
<heat>
we could all be writing firmware and bootloaders in bytecode
Tangent-Man has quit [Quit: Leaving]
<GeDaMo>
A build system built on BPF :|
<j`ey>
it'll be JITTed!
<heat>
oh my god ncurses needs a patched version of autoconf 2.11 to get a working configure script
<heat>
this is so fucking ncursed
<geist>
been writing an ahci driver to finally have done that
<zid>
neato
<kazinsal>
GeDaMo: wow, I actually recoiled reading that
<geist>
pretty straightforward. but now i'm at the part where you have to start talking real ATA. does not look pretty
<GeDaMo>
:D
<geist>
well not ugly per se, but ATA is just not a 'clean' design from a first glance
<heat>
geist, how so? simple ATA is pretty simple
<geist>
yah probably no biggie
<heat>
3 commands and you're done
<kazinsal>
ATA has a whole bunch of legacy cruft just because of how old it is
<kazinsal>
thankfully you can ignore most of it
<heat>
IDENTIFY, READ_DMA48, WRITE_DMA48
<kazinsal>
but the design is clearly a case of several specs being stacked together to make one grand unified spec
<heat>
no u
<sham1>
Sounds a lot like BIOS
<heat>
huh?
<heat>
the BIOS doesn't even have a proper spec
<geist>
yah i thin it's a mistake to read the ATA or SATA spec from the looks of it
<geist>
since it covers the nitty gritty deails, eve at the command level, of how the state machine works, etc
<geist>
and from the looks of it AHCI handles a lot of those details for you
<kazinsal>
yeah, the whole spec is definitely overkill
<kazinsal>
probably just want to read the command set document more than anything else
<geist>
like theres a whole thing about how you need to query the shadow BSY register on the device in a command slot before you issue a command
<geist>
and then mentions 'host controllers may have additional mechanisms such that you dont have to'
<geist>
and that's probably one of the many things AHCI seems to track for you
<geist>
and then there's the whole NCQ tagging. which i also think AHCI handles for you
<geist>
i get the vibe taht by issuing a command in one of the 32 slots, it handles matching up device responses with the 0-31 tags with all the outstanding buffers/FIS receive slots/etc for you
<geist>
i *think* there's even a whole DMA buffer FIS descriptor that you have to send. perhaps before the actual command transmission? Either way i dont think the programmer has to do that with AHCI
<geist>
so maybe it's handling all the DMA NCQ setup/teardown for you by sending these hidden commands
<geist>
ooooh i see. neat: there's a DMA descriptor FIS that the device sends back to the host with { tag, offset, length, data } as it comes up with blocks of data. it's apparently allowed to return stuff out of order even
<geist>
so presumably AHCI consumes those and lines them up with the DMA descriptors you set up for the transactions
<geist>
so if you have 5 transactions outstanding, tag 0-4, it can just start feeding th ehost back arbitrary blocks out of those 5 transactions in any order.
<geist>
hmm, so i think i screwed up when i set up my home network a while back
<geist>
i left the default lan vlan as untagged
<geist>
and then set up some additional vlans for private stuff
<geist>
i probably should have set the default lan as another tag itself
Tangent-Man has joined #osdev
GeDaMo has quit [Remote host closed the connection]
mahmutov has quit [Ping timeout: 250 seconds]
<sham1>
<heat> the BIOS doesn't even have a proper spec