<immibis>
gorgonical: unix domain sockets are IPC, not networking, and there are a lot more networking tutorials than IPC tutorials
<immibis>
gorgonical: pipe is for "read from another program's stdout" and unix sockets are for proper IPC
<immibis>
everything that isn't a fake stdin/stdout stream
<immibis>
you CAN make a program's stdin/stdout be a socket, and it CAN even actually work, but there are so many subtle differences you shouldn't do that if the program is going to do anything more complicated than read and write and only with small buffers.
PapaFrog has quit [Ping timeout: 272 seconds]
<immibis>
extra credit: find some combination of setuid program and weird FD type that gives you root
<immibis>
does su crash if you connect its stdin to an epoll connected to its stdout? who knows? (probably not)
PapaFrog has joined #osdev
foudfou has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
heat has joined #osdev
Matt|home has quit [Quit: Leaving]
nyah has quit [Quit: leaving]
dhs has quit [Quit: Leaving]
dhs has joined #osdev
<gorgonical>
could someone familiar with netbsd briefly explain this: files have the file_data union which is either a vnode or a socket (or many other things), but the vnode itself can also have a socket in its union. So... what's the vnode union socket for?
<gorgonical>
an alternate but related question: what is a socket's inode on linux? is that an alloc'd struct file somewhere that has no path? because /proc/1234/fd/socketfd always points you to /proc/net/whatever and that's not the "real" file is it?
<heat>
socket inodes are made up, and so are struct files and dentries
<heat>
they have no path
<gorgonical>
that's what i thought
<gorgonical>
because the bookkeeping symlink is just telling you that it's as ocket
<heat>
i don't remember how linux works exactly in the socket area, but it's more likely than not that you'll see anon_inode:[socket] or so
<heat>
actually seems that it's socket:[some number]
<gorgonical>
it could notionally have a path if you wanted if the socket kernel code exposed a /sys/kern/socket path or something like that, though
<gorgonical>
right?
<heat>
sure
<heat>
don't give them more ideas
<heat>
thanks!
<heat>
e v e r y t h i n g i s a f i l e
<gorgonical>
so it's just an unfortunate case where linux has decided that inode is just "file metadata"
<heat>
well... because it is?
<gorgonical>
yes but isn't the notion less well-defined when you describe a socket?
<gorgonical>
or at least the *word* itself is less good
<gorgonical>
for context: something about the way netbsd's code describes files as having file_data unions, one of the types of which can be a vnode, makes more sense to me
<heat>
sure
<heat>
but then it's like
<heat>
well, sockets aren't files, so let's stop calling them file descriptors
<heat>
socket descriptors?
<gorgonical>
hmm
<gorgonical>
but they aren't really files on the kernel-side anyway. you just use the vfs to route operations to the right code
<gorgonical>
only the program really considers them files
<heat>
the vfs does too
<gorgonical>
i mean in the sense that read always calls file->f_ops->read
<heat>
sure, but it's operating on a *file*
<zid>
I think file is just overloaded to mean 'entity'
<zid>
and lots of things are entities
<heat>
how the read happens (if it uses an inode, if it just copy_to_users "hello") is a detail
<zid>
but all entities are 'things you can read and write'
<gorgonical>
i suppose in my mental model that vfs interface layer is just awfully small when a file may be a socket under the hood that's routed to a tcp connection. There's considerably more code in making read do what you want it to do
<heat>
and it's all silly namecalling when inodes are inodes and files are files and dentries are dentries and that's that. most files are some sort of filesystem, inodes are the generic entities, usually arranged in some sort of directory tree (hence dentries), and files represent opened inodes with dentries attached to them
<zid>
just s/vfs/ECS
<heat>
whether you call shit vnode or inode makes no difference in the long run
<gorgonical>
sure but files don't represent opened inodes when the file's a socket is my point
<heat>
sure, they represent a made up inode
<heat>
and a made up dentry
<heat>
in theory you could have a socketfs for that too
<gorgonical>
right
<gorgonical>
then at least the inode would have some attachment to an actual dentry/"real" filesystem
<gorgonical>
even if it were just in ram
<heat>
are you going to argue that procfs inodes are not real inodes? or, for that matter, that FAT inodes are not inodes, because there's no concept of an inode?
<zid>
see this is why they should just all be called 'entity'
<zid>
no more arguments, it's a bad name for everything
<gorgonical>
i think now that I'm less confused I'm just complaining that linux uses inode for the concet
<heat>
inodes are things that hold data, size, permissions, etc. data + attributes basically. traditionally, in UNIX
<heat>
sockets have all those things, so they are also inodes
<zid>
inode "entity which acts like a file, but may not be"
<zid>
socket "entity which acts like a file some of the time, but has packet loss"
<zid>
file "entity that acts like a file all of the time, but has corruption"
<heat>
wait until you figure out what linux uses to represent mounted filesystems :v
<zid>
is it
<zid>
a cheese collage
<heat>
close! it uses superblocks
<zid>
really good mutexes?
<gorgonical>
file "the kernel's view of a thing you can read/write". file_data "what that shit is on the backend" vnode "some in-memory version of a filesystem location information" etc
<heat>
completely made up 100% in memory "file""systems" have superblocks
<gorgonical>
makes sense to me but I see now how it's just naming
<zid>
not sure what mutexes have to do with mount points
<gorgonical>
I dislike the ideological impurity
<gorgonical>
If sockets have inodes they should be somewhere in my filesystem
<heat>
what filesystem?
<gorgonical>
/
<heat>
you have like 10 mounted
[_] has joined #osdev
<heat>
most of them are fake
<zid>
yea it makes sense like that
<gog>
/prock/socket
<gorgonical>
that's fine, it's just a way of organizing data relationships
<zid>
but I also hate that about networking too
<zid>
that 'the network stack' both handles fake devices, packets, and fake routing, and real routing
<heat>
tmpfs is completely fake (doesn't even have backing data structures! just page cache baby), procfs is fake, devfs is fake, sysfs is fake, tracefs is fake
<zid>
I want pin routing for networking heat
<zid>
can you make onyx do this
<heat>
what's pin routing?
<gorgonical>
I mean arguably anything at all that in the kernel has a struct file* should be somewhere in an fs that's moutned
<zid>
Imagine like.. a phone exchange? You wire jack into different ports to let things talk to each other.
<heat>
ah yes
<heat>
i'm afraid that's manual?
<zid>
Linux just disappears all packets into "THE CLOUD" and they reappear magically.. or disappear.. or not
<heat>
gorgonical, gosh no
<gorgonical>
if I can have named pipes
<heat>
do you want epoll files to be in a filesystem?
<zid>
like, I can have 10 'networks' on my machine, but they all share the same network stack internally
<zid>
and I have to be very careful with very complex networking rules to stop them intermixing
<gorgonical>
yes
<heat>
yes??
<zid>
and write arcane iptables rules, and invoke brctl in bizzare ways etc to do things
<gorgonical>
why not??
<gorgonical>
open file descriptors exist under /proc/pid/fd
<heat>
because it's inherently a local-process thing
<gorgonical>
so are ordinary file descriptors!
<zid>
that means it's on a filesystem though
<zid>
already
<zid>
omg
<heat>
they are not
<zid>
*spooky music*
<gog>
but who was inode
<heat>
an epoll file represents a bunch of shit you're listening to, that you can do epoll calls to
[itchyjunk] has quit [Ping timeout: 260 seconds]
<gorgonical>
wait zid did you just gotcha me
<heat>
it's local state, process state
<zid>
gog: the inode was coming from INSIDE the filesystem
<gorgonical>
how is that different conceptually from an open file as a file descriptor though?
<gorgonical>
like a literal txt file I mean
<heat>
a file is not process state
<gorgonical>
the fact that it's *open* is though
<gorgonical>
for reading
<heat>
if you close it, it doesn't go away
<gorgonical>
or whatevering
<gorgonical>
sockets do
<heat>
right, which is why they have no name
<gorgonical>
but they have fds
<heat>
thank you for listening to my ted talk
<heat>
so does epoll
<gorgonical>
fair enough
<gorgonical>
I think
<zid>
gog: Can you make the new factorio version come out
<heat>
in fact, per POSIX all files are kinda *required* to have inodes
<zid>
for my brithday
<heat>
because fstat(fd, &statbuf); needs a statbuf.st_ino
<gorgonical>
okay then why give sockets an inode at all?
<heat>
<heat> in fact, per POSIX all files are kinda *required* to have inodes
<gorgonical>
otherwise is there a reason to disallow anonymous files?
<heat>
wdym?
<gorgonical>
if a socket has a fd and the kernel knows about it and its in the process's fd table, why even give it an inode?
<gorgonical>
you have the fops and the fd and the file object already
<gorgonical>
does it *need* an inode to work as a socket in this case?
<heat>
1) posix requires an st_ino, so you at least need a ino number 2) you want some convenient place to store convenient info for the VFS, hence struct inode
<heat>
in theory you could have like an all-knowing .getattr callback. but it's just slower
<gorgonical>
right okay. yes inode/file_data in this case. But that's again just the semantic difference
<heat>
and clunkier
<gorgonical>
yes I suppose if the socket fops get called it would not be obvious how you identify the socket without the inode info
<heat>
and fwiw, you're not the first person that thinks struct inode and struct superblock, etc are silly
<heat>
hence vnode and <whatever the BSDs/solaris use for superblocks>
<zid>
"For various arcane reasons, some entities, which are pretending to be files, need certain metadata that is available in the 'inode' form"
<zid>
is my take
<gorgonical>
I like that explanation a lot
<heat>
yeah
<gorgonical>
wait then why have a private_data
<gorgonical>
if you are a socket then it is unused
<heat>
per-open() data
<zid>
It's hacks all the way down!
<gorgonical>
I have used private_data before as tokens for ioctl tricks but I'm not competent
<bslsk05>
docs.google.com: The OSI Deprogrammer - Google Docs
netbsduser`` has joined #osdev
netbsduser`` has quit [Ping timeout: 255 seconds]
<kof123>
well, it is not a real standard because there is no reference implementation </some rustaceans>
<kof123>
https://cybersect.substack.com/p/a-computer-history-deprogrammer > There is a standard history of computers evolving from 32-bit mainframes (mostly IBM) to 16-bit minicomputers (mostly DEC) to 8-bit microcomputers (Apple, PET, TRS-80) in the late 1970s.
<bslsk05>
cybersect.substack.com: A computer history deprogrammer - by Robert Graham
<kof123>
he says he doesn't buy that per se, because IBM made mini and micro-like things, that were not in "competition with" but complimented mainframes.
<kof123>
i find it funnier than it went 32 -> 16 -> 8 and then back up lol
<kof123>
i'd also say multiple types of "logic" is still a giant problem (referred to in the above) ...not that all should be one, but failing to recognize them
SGautam has joined #osdev
masoudd has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
goliath has joined #osdev
Celelibi has quit [Read error: Connection reset by peer]
Celelibi has joined #osdev
zxrom has quit [Quit: Leaving]
danilogondolfo has joined #osdev
GeDaMo has joined #osdev
colona has quit [Ping timeout: 240 seconds]
vdamewood has quit [Remote host closed the connection]
vdamewood has joined #osdev
moberg has quit [Quit: Disconnecting]
moberg has joined #osdev
netbsduser`` has joined #osdev
gbowne1 has quit [Quit: Leaving]
pretty_dumm_guy has joined #osdev
bauen1 has quit [Ping timeout: 258 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
awita has joined #osdev
colona has joined #osdev
Burgundy has joined #osdev
pretty_dumm_guy has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
nyah has joined #osdev
Left_Turn has joined #osdev
bauen1 has joined #osdev
gog has joined #osdev
* kof123
stares https://gcc.gnu.org/legacy-ml/gcc/1999-10n/msg00380.html >> The 34k was bit-addressable. Perhaps this is still the only port of GCC to a bit-addressable architecture? > If it worked it is the maybe the only _working_ port.
<bslsk05>
gcc.gnu.org: Re: GCC museum?
<kof123>
this is perhaps why the console versions were generally never as good (except PC nba jam was more like the arcade) > including Mortal Kombat and NBA Jam
<vaxuser>
bit-addressable?
<vaxuser>
i concede i never heard of something like this being a thing
<moon-child>
just have CHAR_BIT=1 4head
<kof123>
well for C it is probably not "a thing" :D i think there were some older mainframes
<kof123>
really the rest...types and such, look "standard" so i'm not sure it is worth my time/finding an emulator/etc.
<kof123>
it does let you point to bitfields it says though lol
<kof123>
and implies 1-bit enums are possible ...but then sizeof() it says will always "round"
<kof123>
or that is a pdf i found ...not sure about this gcc port. i think most use was asm, and not sure any of the c compilers are "good"
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<kof123>
i wondered if maybe the interface would be something to "borrow" or "inspire" from, but did not look yet > The TIGA standard is independent of resolution and color depth which provides a certain degree of future proofing.
<kof123>
i.e. for "bytecode instructions"
<kof123>
"Then we can make all sorts of crazy laws!" "Now you're catching on!" </schoolhouse rock parody, probably from an old daily show> so it is with bytecode...you can simulate anything, as long as you are willing to write code to implement it
<kof123>
coulda been simpsons, don't recall
GeDaMo has joined #osdev
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
GeDaMo has joined #osdev
vai has joined #osdev
pretty_dumm_guy has quit [Ping timeout: 255 seconds]
heat has joined #osdev
muxelplexer has joined #osdev
<immibis>
zid: learn network namespaces
<immibis>
someone who doesn't /ignore me: relay that message to zid - he needs it
<immibis>
gorgonical: you see a price of abstracting: the more things you put in one bucket, the less they have in common
<immibis>
and then yes, you may end up with this "everity" that contains all possible fields but only some of them are relevant and you don't know which ones - the union of all the abstracted things - or you may end up with a small object that doesn't do very much - their intersection
[Kalisto]2 has joined #osdev
[Kalisto]2 has quit [Read error: Connection reset by peer]
<immibis>
file descriptors abstract a few things: they're "kernel-managed objects", like HANDLEs on windows, or generically "capabilities"; they also abstract byte streams in many but not all cases. Windows does this differently - a file and a mutex are both HANDLEs, but you still can't ReadFile from a mutex - you have to use the mutex functions.
<immibis>
windows doesn't conflate kernel managed objects with byte stremas
<immibis>
streams*
[Kalisto]4 has joined #osdev
[Kalisto] has quit [Ping timeout: 258 seconds]
[Kalisto]4 is now known as [Kalisto]
pretty_dumm_guy has joined #osdev
muxelplexer has quit [Quit: leaving]
Left_Turn has quit [Ping timeout: 264 seconds]
<zid>
Apparently it's also windows XP's 22nd birthday today, I've been overshadowed
<mcrod`>
hi
<heat>
no
<mcrod`>
heat
<mcrod`>
HI!!!!!!
<heat>
zid, wow so I have a friend with the exact same age and birthday as windows XP
<heat>
that's 1) pog 2) LAME AS FUCK
<heat>
IMAGNE SHARING A BIRTHDAY WITH WINDOWS EKS PEE
<bslsk05>
discourse.llvm.org: libLLVM-16.so might be creating too many page faults - LLVM Project - LLVM Discussion Forums
<heat>
>In 1992, a Sun SPARC workstation with a spinning hard drive could service 50 page faults/second. Today’s SSD are something like 10 times faster than a spinning harddrive: 500 page faults/second. That’s how I estimated 1 to 3 seconds of wall-clock time during initialization
<heat>
some people use bad benchmarks, other people use microbenchmarks, other people use real workloads, other people measure using real workloads
<heat>
this fella uses maths based benchmarking using made up maths relative to a 1992 Sun SPARC
<vaxuser>
look acurrate to me
<vaxuser>
between checking what happens and speculating, always do the latter
<vaxuser>
this is the common geezer attitude
<vaxuser>
also note they are confalting minor and major faults
<heat>
at least on linux this is also definitely not what happens
<heat>
if you get a page fault it'll try to map "around" the fault with shit it can pull from the page cache without blocking
awita has joined #osdev
<vaxuser>
lol
<vaxuser>
perf stat echo
<vaxuser>
78 faults
<vaxuser>
perf stat clang --version
<vaxuser>
3943 faults
<vaxuser>
perf stat gcc --version
<vaxuser>
97 faults
<vaxuser>
should probably compile a hello world instead
<heat>
page faults get roughly halved if you use a statically linked clang
<heat>
which is super recommended tbf
Vercas1 has joined #osdev
<vaxuser>
is it?
<vaxuser>
benching that sucker is on my todo list
<heat>
yes
<vaxuser>
but i'm unaware of anyone making a claim here
<heat>
you have to go out of your way to build LLVM dynamic libraries
<vaxuser>
claim motherfucker
<vaxuser>
where is it
Vercas has quit [Ping timeout: 256 seconds]
Vercas1 is now known as Vercas
<vaxuser>
stracing clang --version is something for sure
<vaxuser>
newfstatat(AT_FDCWD, "/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../x86_64-linux-gnu/lib/../lib64", 0x7ffda8705a18, 0) = -1 ENOENT (No such file or directory)
<heat>
If enabled, the target for building the libLLVM shared library is added. This library contains all of LLVM’s components in a single shared library. Defaults to OFF.
<bslsk05>
lists.llvm.org: [llvm-dev] Why are LLVM releases statically linked against LLVMlibraries?
<vaxuser>
openat(AT_FDCWD, "/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
<vaxuser>
openat(AT_FDCWD, "/usr/bin/../lib/gcc/x86_64-pc-linux-gnu", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
<vaxuser>
openat(AT_FDCWD, "/usr/bin/../lib/gcc/x86_64-redhat-linux6E", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
<vaxuser>
openat(AT_FDCWD, "/usr/bin/../lib/gcc/x86_64-redhat-linux", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
<vaxuser>
openat(AT_FDCWD, "/usr/bin/../lib/gcc/x86_64-suse-linux", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
<vaxuser>
openat(AT_FDCWD, "/usr/bin/../lib/gcc/x86_64-manbo-linux-gnu", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
<heat>
>The guidance for maximizing performance of the generated compiler is to use LTO, PGO, and statically link everything. This will result in an overall larger distribution, and it will take longer to generate, but it provides the most opportunity for the compiler to optimize.
<heat>
oh riiiiight, gcc compat!
* vaxuser
burps
<vaxuser>
also notice while the guy measured startup time of 0.4s or whatever
<vaxuser>
it was never reproted how much of it is these page faults
<vaxuser>
i suspect other idiocy like above lookups accounts for a big chunk of the problem
<heat>
all of those are bound to be cached though
<vaxuser>
they are also bound to cost more than 0
<vaxuser>
unless these are 0 cost abstracton lookups
<vaxuser>
apologies if so
<heat>
they are not
<heat>
you would need C++ for that!
<vaxuser>
or RUST
<heat>
but srsly probably decently cheap
<heat>
particularly when clang is this thicc
<vaxuser>
lmao plz
<vaxuser>
i had seen what this fucking compiler does while trying to do actual work
<vaxuser>
it is mind-boggling
<vaxuser>
utter waste
<Ermine>
I've figured out who is vaxuser only when he burped
<vaxuser>
that was a decoy message
<heat>
vaxuser, ok idiot
<heat>
50.31 0.001315 4 324 futex
<heat>
14.42 0.000377 4 79 54 openat
<heat>
12.89 0.000337 4 84 29 newfstatat
<vaxuser>
ye tehse futexen are also hilarious
<vaxuser>
but possibly a bug in glibc
<heat>
first col is %, second col is seconds
<vaxuser>
you may also notice these futexes are not the page faults
<heat>
keep going with your fstatat optimization, you might shave off 377uS
<vaxuser>
i think i was pretty clear clang keeps doing stupid shit
<vaxuser>
with path lookusp just being an example
<vaxuser>
besides fstat is fast on sparc so this can't be the factor
<Ermine>
vaxuser: some reply to your tweet got into meme channel I'm happened to be suscribed to
<vaxuser>
i am *not* mjg59
<Ermine>
how come
<vaxuser>
idk ask heat
<vaxuser>
heat are you matthew garrett this week
<Ermine>
Also I didn't say which reply it was
<Ermine>
So you kinda disclosed yourself
<heat>
no im mateusz guzik
<heat>
you are matthew garrett
<heat>
PESSIMAL KURWA
<heat>
patchen
<Ermine>
mofo
<heat>
mon
flom84 has quit [Ping timeout: 258 seconds]
linear_cannon has quit [Read error: Connection reset by peer]
<bslsk05>
www.theguardian.com: What goes meow and glows in the dark? A cat, obviously | Science | The Guardian
heat has quit [Remote host closed the connection]
heat has joined #osdev
<heat>
vaxuser, i see u in the scheduler timeslice thing
<heat>
i like the idea but OH GOD WHY DO THEY HAVE TO BRING UP RSEQ
<heat>
i was considering replying to peter to say that rseq has a shit SMAP penalty
bauen1 has quit [Ping timeout: 240 seconds]
gorgonical has quit [Ping timeout: 245 seconds]
<moon-child>
vaxuser: do you happen to have numbers on how bad reloading after failed cas is vs using the value you get for free?
<moon-child>
obv better to use it if you have it but seems to me it shouldn't be _that_ bad?
<moon-child>
as you have exclusive access after, so no coherency traffic, so you just add a 5-cycle timing window for somebody to steal it. Which is not nothing, but not huge either considering the cost of a cas
CaCode has joined #osdev
<vaxuser>
moon-child: i had numbers somewhere
<vaxuser>
moon-child: why would you even ask tho
<moon-child>
I was curious about how much java loses here
<moon-child>
as its cas just returns success/failure
<vaxuser>
huh where tf is it
<vaxuser>
diff was pretty big
* geist
yawns
<moon-child>
huh
<vaxuser>
give me 10
<moon-child>
no pressure
<vaxuser>
wtf, not only i can't find it but also relevant commits i made to freebsd somehow don't have these numbers (lol)
<vaxuser>
(lol at me)
<vaxuser>
but it was low double digit % for 20 cores afair
<moon-child>
for what access pattern? Worst-case contention?
<vaxuser>
a lol read lock/unlock loop
<vaxuser>
where lock cas bumps by 1 and unlock cas drops by 1
<vaxuser>
all this is masively slower than xadd on both ends
<vaxuser>
vast majority of the slowdown comes from initial read
<vaxuser>
so what exactly are they casing like that
<vaxuser>
rw locks?
<moon-child>
java? No that's just what the cas primitive of the language does
<moon-child>
so everything has to do it like that
gorgonical has joined #osdev
<gorgonical>
Here's a question, why did we decide to use the word "virtual" for simulated versions of things?
<gorgonical>
Why not "imaginary" or some other word like maybe simulated?
gbowne1 has joined #osdev
<gog>
i prefer vice reality
<gog>
vice machine
<gog>
vice memory
<gog>
virtual signalling smh
gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
<gorgonical>
smh my head
<gog>
lol out loud
<heat>
virtual memory, virtual signalling
<heat>
these kernel people can't be stopped
<heat>
just bullshit peddlers
<heat>
gorgonical, virtual: almost or nearly as described, but not completely or according to strict definition.
<moon-child>
signals is just virtual interrupts
<moon-child>
smh
<gorgonical>
The use of the word "virtual" or "virtually" is very second-nature now but I wonder if in the 40s and 50s when they pioneered it if that's what it was
<gorgonical>
it's virtually memory, but not quite
<vaxuser>
nedless to say i don't have to remind you
<geist>
well, i think in the case of virtual memory, or virtual machines, it's not necessarily simulated
<geist>
simulated/emulated/etc is an implementation detail. more specific
<geist>
virtual is less strong, only implies it's not the Real Thing directly
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<Bitweasil>
And I'd argue in the case of memory addresses, it's the right term. It *is* an address space. But coming from the world of physical addresses being the only valid addresses, the "virtual" address space is... more or less what that word implies.
<Bitweasil>
You see it as your real address space, access 0x1000, it goes to 0x1000, it's just that 0x1000 may not be (probably isn't) 0x1000 physically.
<Bitweasil>
In the context of going from physical memory to paged memory, sounds reasonable.
<Bitweasil>
... and then you get paging to disk, which is also overloaded on the term. :/ And that, I'd argue, is less-virtual.
<Bitweasil>
And more "disk based memory," or something.
<gorgonical>
Well why didn't some more mathematical term take over, like projected memory?
<geist>
because what the hell does that mean?
Left_Turn has quit [Remote host closed the connection]
<geist>
(completely unfamiliar with that term)
<gorgonical>
Like a mathematical projection, like a map projection
Left_Turn has joined #osdev
<gorgonical>
Or some kind of set operations are sometimes called projections. We could have just as easily called virtual memory logical memory instead and described it as a projection of physical memory
<gog>
it's not a projection because it's not a function
* gog
fingerguns
<gorgonical>
That's a reasonable point
<gog>
it's technically an 1:m mapping actually ?
<gog>
one linear frame can be mapped to m virtual frames
<gog>
in x86 paging anyway
<gog>
idk about other impls
<gorgonical>
I will not recapitulate my complaints against "linear" memory here
<gorgonical>
Must resist
<geist>
also keep in mind most people are not mathemeticians
<gorgonical>
That's well true but I feel like much of early computer science was math and physics people
<gog>
terminology gets slanted over time
<Bitweasil>
Because math people didn't write the code. :p
<gog>
interactions of the theory and the construct as it actually performs
<gog>
sometimes marketing speak
<Bitweasil>
Oh... what was it for Sega, Blast Processing or something?
<Bitweasil>
Just referred to some internal DMA, I think?
<gog>
so anyway i started blasting
<gorgonical>
We should decide to rename DMA ops to data blasting
<gorgonical>
"You have to set up a data blast from this device to the regular memory"
<geist>
Turbo Mem
<Bitweasil>
Seconded! All in favor of renaming DMA to "Data Blast"? :D
<heat>
gorgonical, you're really on a terminology roll here
<bslsk05>
segaretro.org: Blast processing - Sega Retro
<Bitweasil>
That goes into a bunch of details on it.
Matt|home has quit [Quit: Leaving]
<gorgonical>
heat: words make me angry
<heat>
everything is a file
<Bitweasil>
Roughly, "It's a marketing term, but here are the possibilities... and here's a person who unfortunately feels responsible for feeding it to the marketing sorts."
<heat>
even memory is a file
<Bitweasil>
Plan9, right?
<heat>
if an operating system is made out of files, is it a filesystem?
<geist>
it's all bits at some point
<geist>
so it's all a bitstorm
<gorgonical>
more like shitstorm
<heat>
LINU X KERNAL
<Bitweasil>
You guys see the iLeakage vuln today, how to extract all sorts of good stuff from Safari on A and M series chips?
<Ermine>
there's some documentation drop at drm subsystem of linu x kernal
Left_Turn has quit [Ping timeout: 260 seconds]
<heat>
wow that attack is so fucking nuts
<Ermine>
... going with a patch though
<gorgonical>
"for tech-savvy readers" ... "what is javascript"
<gorgonical>
what did they mean by this
<Bitweasil>
Anyway, just one more reason to browse JITless. :/
<heat>
Ermine, what?
<gorgonical>
It's crazy to me that they also had to reverse engineer the structure of the cache as a first measure
Left_Turn has joined #osdev
<gorgonical>
I mean obviously they had to but props for the extra effort
<Ermine>
heat: I was glad because a patch for drm/doc arrived to my mailbox, but it turned out to be documentation for changes coming with patch series
<Ermine>
Not just someone decided to document something
<heat>
at least it has docs :)
<gorgonical>
At what point are we gonna have to re-design computer systems to create airgaps between "terminals" and the "mainframes" where all our workstations have speculation disabled and only the air-gapped servers have it on
<Ermine>
heat: the patch serirs or drm/* ?
<CompanionCube>
shouldn't it be the other way around
<gog>
XENU kernel
<gog>
UNEX
<gog>
solaris linux
<Ermine>
gog: cursed
<heat>
Ermine, yes
<heat>
there's an oracle linux btw
<Ermine>
A.k.a RHEL for those who don't want to pay
<Ermine>
heat: yes what?
<heat>
i mean, they also have dtrace
<gog>
oracle usually benefits directly from the work of FLOSS developers
<heat>
<Ermine> heat: the patch serirs or drm/* ? <-- yes
<gog>
in the case of oracle linux, they return to FLOSS developers from a company that benefits
<gog>
fun times
<Ermine>
Hm
<heat>
>FLOSS
<heat>
everyone knows linux people don't brush their teeth, much less floss
<gog>
i brushed my teeth
<gog>
guess i'm not really a linux person
<heat>
how many commits u have in linox
<Ermine>
I'm brushing my teeth, am I windows proprietary?
<heat>
yes
<gog>
none actually
<heat>
brushing teeth is the difference between corporate teeth and hippie teeth
<moon-child>
linux is totally corpo though
CaCode has quit [Ping timeout: 258 seconds]
<heat>
you're sounding like a corporate paid chill
<heat>
shill
<heat>
chill shill
<gorgonical>
speaking of american files from yesterday it occurred to me while reading the source code for my kernel's vfs that it's basically an american file
<heat>
how so
<gorgonical>
the inode also contains the dentry information, incl parent inode stuff and the names are all embedded
<gorgonical>
So the inode struct just has all the information you need in it
<heat>
that's not an american fil
<gorgonical>
an american inode then
<heat>
not really
<heat>
the basic unit of a filesystem being a 'thing' with a name attached to it is not novel
<heat>
fat works like this I think?
<gorgonical>
But not separating the dentry and inode information is not that common right?
<Ermine>
and what is european inode then
Left_Turn has quit [Ping timeout: 240 seconds]
<gorgonical>
First things are that I think symlinking/hardlinking is not possible in this design
<netbsduser``>
gorgonical: it is an old approach which has been almost universally rejected
sbalmos has quit [Ping timeout: 245 seconds]
<netbsduser``>
to be found only in the detritus of the past like FAT
<gorgonical>
poignant
sbalmos has joined #osdev
<heat>
DETRITUS OF THE PAST
<gorgonical>
wait can you tell me about why netbsd has a f_socket and v_socket?
<gorgonical>
why can files have a socket or instead a vnode which also contains a socket
yoyofreeman has quit [Read error: Connection reset by peer]
yoyofreeman has joined #osdev
<Ermine>
re ileakage: do apple arm chips have speculative execution?
<moon-child>
they're fast so yes
<heat>
of course
<Bitweasil>
Ermine, anything post... A53 or so is speculative, mostly deeply so, and Apple's cores have been speculative for a long, long while.
<Bitweasil>
But, the approximation of "Is it fast? It's speculative and out of order!" is pretty accurate anymore.
<Bitweasil>
Also, I can't think of any core from the past few years in the mainline x86/ARM realm that isn't.
gorgonical has quit [Ping timeout: 255 seconds]
<heat>
the A53? :P
<heat>
wait, does the A53 count as speculative already?
<Bitweasil>
Sorry. Perhaps unclear. The A53 is an in-order, non-speculative chip, though I think it's been demonstrated to leak a little speculatively with some branch stuff.
<Bitweasil>
Anything post-A53 is almost certainly speculative/OOO.
awita has quit [Remote host closed the connection]
<heat>
yeah a53 is only dual-issue
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
<Ermine>
well, my previous phone had a53s and it even pulled off gamez
<heat>
a53s are usually coprocessors
<heat>
ie the little cores in big.LITTLE
project10 has quit [Quit: .]
project10 has joined #osdev
sbalmos has quit [Quit: WeeChat 4.0.5]
gildasio has quit [Remote host closed the connection]
gildasio1 has joined #osdev
gildasio1 has quit [Remote host closed the connection]
gildasio has joined #osdev
<immibis>
merged dentry and inode is how FAT works, separate is how ext4 works, adapting one system to another creates incompatibilities
<immibis>
or inconsistencies, rather
heat has quit [Ping timeout: 260 seconds]
CaCode has quit [Quit: Leaving]
Burgundy has quit [Ping timeout: 260 seconds]
pg12 has quit [Ping timeout: 260 seconds]
pg12 has joined #osdev
Terlisimo has quit [Quit: Connection reset by beer]
Terlisimo has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
pg12 has quit [Ping timeout: 255 seconds]
<geist>
to be pedantic, A55 is also the same. you need to get into the a7x class to start getting OOO speculative
<clever>
made a bit of a surprising discovery about the pi5
<clever>
it now has SWD for the cortex-a76, not regular old jtag
<clever>
and the SWD can be muxed onto the same pins as the dedicated uart header
<geist>
the data cache on the a53/a55 can start prefetching ahead though, it has a limited ability to detect load patterns and start prefilling the cache
pg12 has joined #osdev
knusbaum has quit [Ping timeout: 255 seconds]
<geist>
clever: interesting. though honestly i prefer plain old jtag. SWD is a bit harder to futz with all else held equal
<clever>
yeah, i would also expect SWD to have maybe worse datarates? since its not full duplex
<clever>
but i'm not sure how much of jtag can actually take advantage of the full-duplex nature?
<clever>
jtag also seems far better if you want to access many devices at once, though that can harm speed
<clever>
i think the bigger advantage, is not the protocol, but a pre-mounted header that can do the debugging
<clever>
so you can just buy a debug adapter, and plug it in
<clever>
and it wont consume any gpio pins
<clever>
jtag on the rpi had always been a pain, connecting 4-5 pins, randomly scattered over the entire gpio header
<netbsduser``>
gorgonical: unix domain sockets in the filesystem namespace
<netbsduser``>
and the f_socket is because 4.4bsd didn't complete their integration of VFS
<netbsduser``>
so while vnode polymorphism provides some of the varying sorts of files, there is also kernel file descriptor polymorphism (that's where socket operations go, for example)
Gooberpatrol_66 has quit [Ping timeout: 245 seconds]
<geist>
hmm started using --autosquash on git rebase now that heat mentioned it