mavhq has quit [Read error: Connection reset by peer]
dzwdz has joined #osdev
gog has joined #osdev
X-Scale has joined #osdev
mavhq has joined #osdev
X-Scale has quit [Ping timeout: 256 seconds]
adev531 has quit [Quit: Client closed]
cow321 has quit [Ping timeout: 276 seconds]
netbsduser`` has joined #osdev
orccoin has quit [Ping timeout: 252 seconds]
emntn has quit [Ping timeout: 252 seconds]
emntn has joined #osdev
<the_oz>
welcome
hwpplayer1 has joined #osdev
Left_Turn has quit [Ping timeout: 245 seconds]
hwpplayer1 has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
cow321 has joined #osdev
npc has joined #osdev
<netbsduser``>
this weekend's work, getting as much of my mlibc port to m68k upstreamed as i can
<nikolar>
neat :)
<netbsduser``>
i wrote up the sysdeps for linux/m68k and i just have to deal with three problems (the broken __fpclassifyl() from musl, implementing fenv, and figuring out why one symlink test doesn't work - i hate symlinks)
emntn has quit [Ping timeout: 252 seconds]
<nikolar>
lol
frkzoid has joined #osdev
<nikolar>
i wonder why it wouldn't work though, i don't think there's anything arch-dependant there
emntn has joined #osdev
<netbsduser``>
nikolar: i haven't looked closely at it yet but probably endian difficulties
<nikolar>
ah that's possible
<nikolar>
i keep forgetting big-endian exists and m68k is be
heat_ has joined #osdev
<heat_>
sysdeps? intense glibc-core
X-Scale has joined #osdev
<Ermine>
netbsduser``: did you report broken __fpclassifyl thing to musl?
<netbsduser``>
Ermine: they've since fixed it for big-endian boxen, i just found out
<heat_>
Ermine, where? on the bugtracker?
Turn_Left has joined #osdev
<Ermine>
heat_: of course!
<Ermine>
wait, bugtrackers BLOATED
heat_ has quit [Read error: Connection reset by peer]
heat__ has joined #osdev
<Ermine>
anyway, stirring up some shit on irc would be fun too
<heat__>
maybe if the bugtracker had a single thread allocating and giving out memory to worker threads, your performance wouldn't be so bad
heat__ is now known as heat
<heat>
one notable example of crap software that doesn't do this is pkg-config
Left_Turn has quit [Ping timeout: 244 seconds]
<Ermine>
I'm not sure pkgconf even multithreads
<heat>
shut up i'm doing an all time musl jerk remix
<netbsduser``>
freedesktop pkg-config or the new bsd-associated pkgconf?
<heat>
wdym bsd associated?
<Ermine>
it's not bsd-associated
<heat>
literally everyone uses pkgconf now
<netbsduser``>
i was sure it was invented by openbsd in protest at pkg-config being in pwerl or something like that
<Ermine>
it's written by Ariadne Conill, which does Alpine
<heat>
yep
<heat>
pkg-config is in C
<heat>
the fdo one
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
<sham1>
pkgconf isn't affiliated with any of the BSDs, FYI
<netbsduser``>
sham1: that's already been confirmed by Ermine
<heat>
ariadne is also the one that wrote the kqueue hitpiece that changed my views on epoll vs kqueue
the_oz has quit [Remote host closed the connection]
<bslsk05>
github.com: pkgconf/libpkgconf/bsdstubs.c at master · pkgconf/pkgconf · GitHub
the_oz has joined #osdev
<heat>
actually no
<heat>
all of those functions are present in linux atm
<netbsduser``>
that must be because they got rid of ulrich drepper
<heat>
musl always had strlcpy and strlcat and strndup, reallocarray was added 4 years ago by ariadne
<Ermine>
ariadne is cool
<netbsduser``>
unfortunately her article is full of shit, i remember reading it
<Ermine>
it's fine article, 0% shit
<heat>
oh okay glibc seems to have added strlcat and strlcpy back in 2.38, which is relatively recent
<heat>
(thank you symbol versioning!)
<netbsduser``>
the argument is that epoll is not technical debt because it's based solely around FD readiness; the counter is that while everything should be an FD because that is the most elegant realisation of a "Unix philosophy", it's also a procrustean bed
<Ermine>
fd is basically the unix philosophy
<heat>
pidfds are perfectly natural, signalfds are perfectly natural, eventfds are perfectly natural
<netbsduser``>
she deftly avoids defending what people actually call technical debt in epoll, because that's indefensible (the generation of epoll events for closed FDs if the open file object still exists in the kernel)
<Ermine>
and that's what linux does by exposing everything through fd
<heat>
that's perfectly defensible
<heat>
it simplifies the implementation
<netbsduser``>
pidfds should be good but linux messed them up when it copy-catted them from freebsd's capsicum (they don't act as real FDs, i.e. things which have a credential attached to them by whoever created them initially)
<Ermine>
kqueue in its turn needs to know about every type of event it works with
<netbsduser``>
signalfds are a tolerable attempt to integrate signals; eventfds, no one really knows what they do, but they are probably fine
<heat>
if you close a fd while another thread is poll()'ing, the behavior has always been unspecified (and very frequently you just don't see the close on the poll side)
<netbsduser``>
Ermine: no, it has as much power as epoll in this regard
<netbsduser``>
use kqueue with only EVFILT_READ/EVFILT_WRITE/EVFILT_EXCEPT and you get BSD flavoured epoll
<Ermine>
no, epoll and *fd are untied, which is not the case for kqueue
<Ermine>
and linux *fd work with select/poll as well
<heat>
but kqueue fans cream themselves over the thought of waiting on a file and a pid and a signal and my mom's cooking, all at the same time
<netbsduser``>
Ermine: they are not tied, you implement the kqfilter() fileop to support EVFILT_READ/WRITE/EXCEPT
<netbsduser``>
there are other event filters available when you want more rich semantics than readable/writeable/exceptional or on a non-file
<Ermine>
oh, so you need a special fileop for kqueue
<netbsduser``>
much as you need for poll()/epoll()/select(), it doesn't magically work
<netbsduser``>
openbsd or dragonfly or possibly both have abolished the old poll fileop and now solely use the kqfilter one
<Ermine>
this fileop is generic
<Ermine>
.poll, that is
<netbsduser``>
.kqfilter is too when poll/select are converted to use it
<heat>
>or on a non-file
<heat>
make it a file kthx
<netbsduser``>
everyone wants processes to be referred to by capability FDs and not by shit PIDs
<netbsduser``>
i've been saying that for 10 years
<the_oz>
Good luck with convincing anyone to actually follow the actual preach
<Ermine>
so you need to bend everything to serve kqueue needs
<netbsduser``>
it's not really bending anything, it's just deduplicating logic
<heat>
like, there's absolutely nothing kqueue can do, that epoll + the various fds can't
<heat>
but it turns out that the epoll + fds is just way more elegant than hardcoding event types in your interface
<Ermine>
logic duplication was introduced by kqueue
<netbsduser``>
they are not hardcoded, but abstract like a vnode
<netbsduser``>
you implement filter routines
<heat>
they are hardcoded
<heat>
want a new event type? add a new flag, new interface to kqueue(2)
<the_oz>
that doesn't sound hardcoded
<netbsduser``>
if you wanted to monitor the competion of individual AIO requests (for example) in gnu/linux, you'd have to define a new aioreqfd and implement its .poll op. (you could do the same on bsd, or you could use EVFILT_AIO)
<netbsduser``>
it's not as clear how you might (say) implement a futexfd that isn't broken (linux did, it was), but you have a bit more of a chance of getting it right with an EVFILT_FUTEX because you don't have to try to fit it to the procrustean bed of a file
<heat>
epoll is objectively the more unixy interface and objectively cleaner
vdamewood has joined #osdev
<heat>
it turns out the unix people of old meant "everything is an fd", not quite "everything is a file"
<netbsduser``>
and no one favours files more than i do, but sometimes a memory address is more appropriate than a file, as with futexes
<the_oz>
>max copium
<nikolar>
heat: I don't think that's remotely controversial lol
<netbsduser``>
heat: well, it's the only reasonable interpretation, if you actually do take it as "everything has a path in the filesystem" you end up with plan nein
<heat>
nikolar, it is very controversial
<heat>
people over time brought it to the "everything has a path in the fs" direction
<heat>
plan9, linux
<the_oz>
kek, the originators of the concept assuredly got it wrong when actually implementing it
<the_oz>
which does NOT include linux
<heat>
/proc/$BASHPID/map_files/782f0126f000-782f01275000 this is a real path
Gooberpatrol66 has quit [Quit: Konversation terminated!]
Gooberpatrol66 has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 246 seconds]
Fingel has joined #osdev
Gooberpatrol_66 has joined #osdev
Gooberpatrol66 has quit [Ping timeout: 264 seconds]
<nikolar>
I mean convinced that GCC has some kind of a sat solver
<GeDaMo>
I've seen it turn loops into single calculations
<nikolar>
(I was talking about instruction selection stage primarily)
xenos1984 has quit [Ping timeout: 246 seconds]
xenos1984 has joined #osdev
aethlas has quit [Quit: bye]
aethlas has joined #osdev
xenos1984 has quit [Ping timeout: 246 seconds]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 244 seconds]
xenos1984 has joined #osdev
cow321 has quit [Ping timeout: 255 seconds]
<netbsduser``>
it's done
<netbsduser``>
mlibc/linux-m68k now passes the whole test suite
<gog>
sick
dzwdz has joined #osdev
Fingel has quit [Quit: Fingel]
Fingel has joined #osdev
Fingel has quit [Remote host closed the connection]
Fingel has joined #osdev
Turn_Left has quit [Quit: Leaving]
<nikolar>
Nice
X-Scale has joined #osdev
rorx has quit [Quit: "Quitting.."]
<nortti>
netbsduser``: mlibc as in the one developed by managarm ppl?
<netbsduser``>
nortti: yes, that's the one
<nortti>
nice
<nortti>
how much arch-dependant code is required?
<netbsduser``>
looks like in the region of 800-1000 lines for a port with linux sysdeps implemented
<heat>
i dont want to be that guy but they really shouldn't have rolled their own tests
<heat>
libc-test is libc neutral, then you also have the glibc suite which AFAIK doesn't try to be libc neutral but has some trickier, more glibc specific tests
<heat>
the world doesn't need 3 separate test suites
<heat>
for the fucking libc
<heat>
if there's anything that infuriates me, it's that
<heat>
kernel is full of that. 10 trillion separate tests and test suites, and they all suck
<heat>
something something collaboration
Celelibi has quit [Quit: Quitte]
<MrBonkers>
Oh hmm libc-test sure looks interesting. Might be worth integrating into mlibc
Gooberpatrol_66 has quit [Quit: Konversation terminated!]
Gooberpatrol_66 has joined #osdev
<netbsduser``>
nortti: final tally of 1266 loc for the m68k port, which is now packaged up nicely in a PR
<netbsduser``>
not bad
<nortti>
aye
elderK has joined #osdev
rorx has joined #osdev
jejomews has quit [Quit: Leaving]
<kof673>
> instead of having a single monolithic syscall to handle everything, Linux takes the approach of providing syscalls > epoll can automatically monitor any kind of kernel resource without having to be modified
<kof673>
do you want to add a new EVFILT_XXXXXXXXXX or do you want to add a new xxxxxxxxxxxfd syscall
<kof673>
that is all it is
<heat>
if you're a psycho you can always just add a new filesystem or pseudofile :)
<the_oz>
GEOM is ez
<heat>
also, fwiw: there's a big difference between EVFILT_XXXX and xxxxfd
<heat>
something that works with standard interfaces is powerful and doesn't leak details
<heat>
it's why stuff like sockets responds to read/write, pipe works with read/write. you don't need to tell other users that this is a socket or a pipe
<zid`>
My OS is just going to have every domain as a file
<zid`>
open("/dev/internet/t12.hosting.com/2323")
<zid`>
hard to keep it up to date though
<heat>
ls /dev/internet
goliath has quit [Quit: SIGSEGV]
<heat>
i'm pretty sure one could trivially pull it off with fuse though, and less trivially but more efficiently pull it off in the kernel
<heat>
sounds like a fun exercise actually
<zid`>
can you like, ls all the tlds
<zid`>
the ls output would end up sorted with american somoa first, not aaaa.com first, but ehh
cow321 has joined #osdev
<GeDaMo>
Does ls work on sockets? Or memory map devices?
<zid`>
what sockets
<heat>
ls only works on directories
<sortie>
zid`: Prepare for root zone transfer
Gooberpatrol66 has joined #osdev
Gooberpatrol_66 has quit [Ping timeout: 245 seconds]
<kof673>
> something that works with standard interfaces yes, so the linux syscalls are a standard now?
<kof673>
and bsd must adopt them?
<the_oz>
bsd already implements linux syscalls actually :D
<kof673>
yes :D but this is the switcheroo :D
<the_oz>
:D
<kof673>
just being daemon's advocate
<the_oz>
lol
<kof673>
i think that was a website or newsletter title for bsd news
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<kof673>
> > something that works with standard interfaces that's the whole thing though, if you have those already for other stuff, they are "standard" if not, you have to add them
<kof673>
not arguing which is better
<heat>
read/write/open/close are all standard
<heat>
poll is standard, select is standard
<heat>
you don't need to sendmsg to work with sockets, you don't need fuckin, idk, SendPipeEx to use pipes, you just use write and read and poll and ...
<heat>
i can pass a signalfd to a program or a library and it can poll on it and read and write and it Just Works (actually i don't know if signalfd has read and write functionality, doesn't matter here)
jjuran has quit [Ping timeout: 252 seconds]
eau has quit [Quit: bleh!]
<netbsduser``>
signalfd lets you read() signals from it (the signals are those for the process *from which you are reading*, while for e-Poll the readiness is signalled according to the signal state of the process that opened the signalfd)
<netbsduser``>
possibly it is called "undefined behaviour"
npc has quit [Remote host closed the connection]
jjuran has joined #osdev
Left_Turn has joined #osdev
<netbsduser``>
so signalfd is an evolution but a revolution would be making it so that signals are only for traps like bus fault or divide-by-zero, and everything else that uses signals, uses instead a more well thought-out mechanism, probably some kind of message queue fd
<nikolar>
netbsduser``: so basically a signalfd
Turn_Left has joined #osdev
<netbsduser``>
nikolar: except not bound up with undefined behaviours when it's shared and confusion between thread-directed and process-directed signals
<nikolar>
sure, but essentially, it's the same interface
<nikolar>
just refined a bit
<kof673>
> e are all standard i agree with all that, but if i said onyx lacks zfs, SO MUCH technical debt...doesn't support my little 40M mini pcmcia floppies either, TECHNICAL DEBT
<kof673>
my girlfriend doesn't blindly obey me, she is full of technical debt
<kof673>
i have a shortage of supermodels in my vicinity, labour shortage, the economy is terrible
<kof673>
other fields do this too lol
<netbsduser``>
let me make it abundantly clear for any of you still in doubt
<netbsduser``>
APIs i dislike = technical debt
<nikolar>
lol
<netbsduser``>
APIs i like = technical credit
<kof673>
yes ^^^
<gog>
yes
<heat>
nope, that's not the point, that was never the point
<heat>
different fds are composable interfaces, KQUEUE_DO_MAGIC isn't
Left_Turn has quit [Ping timeout: 252 seconds]
<the_oz>
GEOM
<heat>
you can pick between: 1) undoing the garbage that the unix oldies did, and add fd interfaces for various things 2) keep adding magic flags
<netbsduser``>
they are separate concerns, make everyfd on freebsd if you want and EVFILT_READ/WRITE/EXCEPT them all
<kof673>
^ yes, more technical debt for the non-geom
<heat>
they're not separate concerns, you don't need EVFILT_LIGMA if you have ligmafd
* vdamewood
gives gog a fishy
<netbsduser``>
it may still make sense though, kqueue can deal in so much more than simple "is it readable, writeable, or exceptional"
Dead_Bush_Sanpai has quit [Quit: Dead_Bush_Sanpai]
<the_oz>
you're talking about composable interfaces as if that doesn't exist via your way of implementing via adherance to a fd based.
<netbsduser``>
take the proc filter, which can wait for e.g. the termination of some process, or its forking (and automatically watch the forkee too)
<heat>
that's a separate concern from "haha i can wait for pids and signals and files all at the same time" which is generally what BSD people talk about
<netbsduser``>
procdescs (or "pidfds") aren't enough; you can't express what you're interested in in terms of EPOLLIN/EPOLLOUT/etc; you could perhaps have a procdescwatchfd of course
<netbsduser``>
and then write() to it { some_procdesc, PROCDESC_WATCH_FORK } or whatever, and wait to get some events
cow321 has quit [Ping timeout: 252 seconds]
<the_oz>
heat: you and heat's projection should have the debate and then when you resolve the difference we can talk
<netbsduser``>
is that the superior approach to epoll? i say no
* gog
package fishy for sale to united kingdom
<heat>
that's what they did with inotify and it worked pretty well
<heat>
you just don't need to stash everything in one interface
<heat>
the_oz, you should try reading the article we're discussing, kthxbye
<the_oz>
linux people often get on my nerves talking bullshit
Arthuria has joined #osdev
<heat>
if instead of fds we were talking HANDLEs and instead of epoll it was WaitOnMultipleObjects we'd all be in great agreement
<netbsduser``>
it's a tricky business as waits on multiple objects can have side effects like "acquired a mutex"
<netbsduser``>
and everyone is also in agreement that it's one of the saddest things that you can't wait on a futex together with a socket, pipe, signalfd, eventfd, and userfaultfd
<kof673>
> if instead of fds we were talking HANDLEs yep, but c89 has FILE * ...what's an fd? why should i write everything around these strange fd things
<kof673>
so when in unixland sure, fd
<netbsduser``>
c outside of unixland is a stranger in a strange land
<nikolar>
i mean a good portion of the windows kernel is in c
<netbsduser``>
they even had to put a subset functionality of unix signals as they were in ancient times into the c standard
<heat>
>you can't wait on a futex together with a socket, pipe, signalfd, eventfd, and userfaultfd
<heat>
sadly i don't have a counterpoint to "you can't wait on a futex + something else" but also, there doesn't seem to be much of a usecase for this
<heat>
worst case you can work around it with eventfd
<netbsduser``>
i assume it's useful to have but i also don't immediately have a use case for it
Arthuria has quit [Ping timeout: 252 seconds]
<heat>
at the end of the day the largest consumer of futex() is the libc and other mutex/lock implementations
<netbsduser``>
if you are waiting on a master epoll from multiple threads (that's called the holy grail in linux land, and is now viable with EPOLLET/EPOLLEXCLUSIVE/EPOLLONESHOT) it is harder to square with the FD approach because of the side effect involved in it
<heat>
actually eventfd could probably work as a nice lock
<heat>
read() can have semaphore semantics, poll does not, maybe that could be fixed with a new flag, but i assume it would introduce nasty complications in select/poll/epoll handling
<netbsduser``>
heat: possibly something in a similar spirit to the "edge-triggered" epoll with exclusive delivery
Left_Turn has joined #osdev
<heat>
but what would the proper semantics be?
<netbsduser``>
let the "edge" be the signalling of a semaphore. then with the exclusive delivery of that "edge" to one poller only, so long as she waits the signalled semaphore exactly once, you get something that works
<netbsduser``>
quite fragile though
<heat>
would you only return with the lock held + other events? would you lock, check if other events, if not, unlock?
<netbsduser``>
if we compare to windows, you can wait for all things you're waiting on to be ready at once
<netbsduser``>
but it's demanding to do
Turn_Left has quit [Ping timeout: 246 seconds]
<heat>
last i read (on some ntsync patchset for linux) waitformultipleobjects had a really BS implementation, but you only needed to support a limited set of objects at the same time
<netbsduser``>
the principle is you lock everything you need to hold everything you're waiting for in its current state, then test if each is ready, if so acquire them all
<netbsduser``>
i watched a video by microsofter arun kishan who boasted of sorting each item being waited by address and acquiring them all that way, establishing an ordering
<heat>
in any case when i talked about "waiting for futexes" i meant just waiting, not actually locking
<nikolar>
netbsduser``: not the forst idea ever i guess
<heat>
which gives you the same guarantee that waiting on a fd does
<zid`>
You should be thinking about how to get people to stop writing code that takes locks instead
<zid`>
flamethrowers, water torture, etc
<nikolar>
lol
<heat>
mjg atm has a gun pointed at zid`'s head
Dead_Bush_Sanpai has joined #osdev
<kof673>
i'm just an unfrozen c89 language lawyer, your fds confuse and frighten me
<heat>
inb4 stdc_poll
jjuran has quit [Ping timeout: 245 seconds]
aethlas_ has joined #osdev
aethlas has quit [Ping timeout: 252 seconds]
_ngn has quit [Ping timeout: 260 seconds]
jjuran has joined #osdev
_ngn has joined #osdev
<Ermine>
heat: wine apparently uses futexen too
* Ermine
gives gog a piece of cheese
<heat>
yep
<heat>
for waitonmultipleobjects i think?
<heat>
there's a relatively new futex_waitv syscall to wait on multiple futexen
<Ermine>
which was supposed to improve performance significantly
<Ermine>
in wine
<heat>
ntsync was even better, don't know what happened with that
X-Scale has joined #osdev
Gooberpatrol66 has quit [Quit: Konversation terminated!]
raphaelsc has joined #osdev
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
* gog
fascinated
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpa1 has joined #osdev
Dead_Bush_Sanpa1 is now known as Dead_Bush_Sanpai
MiningMarsh has quit [Ping timeout: 248 seconds]
<kof673>
re: the fd stuff,....what does plan9 do?
Turn_Left has joined #osdev
<kof673>
since at least marketing-wise they would not have "debt"
<kof673>
so a supposed clean slate, what did they do?
MiningMarsh has joined #osdev
cow321 has joined #osdev
Left_Turn has quit [Ping timeout: 260 seconds]
jjuran has quit [Ping timeout: 252 seconds]
jjuran has joined #osdev
cow321 has quit [Ping timeout: 246 seconds]
<the_oz>
instead of "everything has a fd through which you can access it in various ways"
<the_oz>
it's more like everything really is a file
<the_oz>
so, ip sockets, devices are much better at implementing the interface
<the_oz>
the commonalities aren't the point, it's having way fewer exceptions to the rule
cow321 has joined #osdev
* gog
read()s the_oz
elderK has quit [Quit: WeeChat 4.4.2]
<kof673>
yes i'm not qualified but i can see it going either way, i.e. superficial clean API is really a mess internally or code-wise, while exterior less appealing API is cleaner blood and guts
<kof673>
i'm guessing plan 9 is not exactly getting people wanting to write a web server/db/whatever either, could be wrong
<kof673>
or re: code reuse and DRYness, or any other attribute. the API is just what the programmer sees
<the_oz>
generally, the propensity of brains to take the immediate lowest effort path based on grooves worn into the brain previously. It's not surprising that one would use plan9 instead of ... golang...
<kof673>
"just" to a point, data structures are either opaque or not to the caller, etc.
X-Scale has quit [Ping timeout: 256 seconds]
<kof673>
if mjg were here, i think he would allow the possibility of whited sepulchre API, full of dead man geezer code under the hood lol
<nikolar>
now that you mention it, haven't seen mjg in a long while