epony has quit [Remote host closed the connection]
[_] has joined #osdev
[itchyjunk] has quit [Ping timeout: 245 seconds]
<kof123>
> Always, there's only one truth! i would have downvoted the c++ in the linux kernel based on that signature in favor alone
solaare has quit [Ping timeout: 256 seconds]
dude12312414 has joined #osdev
<kof123>
> smart of the C++ advocates to use the recent rustication initiatives as precedent agree, they are like politicians here "at least it is not rust" if it rebounds and the rust people do the same "well, at least it is not c++" it will be even moreso
<kof123>
i do not care either way, it is just conway's law in miniature
dude12312414 has quit [Remote host closed the connection]
epony has joined #osdev
solaare has joined #osdev
<kof123>
*short-term smart to be trapped in the present. long term doom :D
Arthuria has joined #osdev
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
navi has quit [Quit: WeeChat 4.0.4]
<kof123>
> it means tainted as in it needs to be cleansed of sin by baptism and repentance (reboot) that was double though, and only really made sense at equinoxes :D it is off into free association land since forever
<kof123>
(hence 2 fingers) ...anyways.....free association is the norm :D
goliath has quit [Quit: SIGSEGV]
<kof123>
> (signature from c++ linux kernel thread) Always, there's only one truth! obviously there is massive confusion on such issues lol
yo0O0o has joined #osdev
Gooberpatrol66 has joined #osdev
frkazoid333 has quit [Read error: Connection reset by peer]
epony has quit [Ping timeout: 264 seconds]
Gooberpatrol66 has quit [Ping timeout: 268 seconds]
<bslsk05>
thenewstack.io: C++ Creator Bjarne Stroustrup Weighs in on Distributed Systems, Type Safety and Rust - The New Stack
<kof123>
> “This was how I got into it in the first place. I wanted to build what would’ve been the first Unix cluster — if I’d managed to finish it instead of getting distracted by C++. And I would like to see support in the language, or in the libraries, for actually communicating with large groups of computers and cores and such. We’re pretty good at multicore, multithreading, that kind of stuff. But I’d like to get to
<kof123>
t-shared memory.
<kof123>
point being: is that even mentioned in the rust and c++ discussions?
gbowne1 has quit [Quit: Leaving]
gog has quit [Ping timeout: 260 seconds]
Gooberpatrol66 has joined #osdev
heat_ has quit [Ping timeout: 260 seconds]
netbsduser has joined #osdev
beogrif has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
epony has joined #osdev
netbsduser has quit [Ping timeout: 256 seconds]
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
Arthuria has quit [Ping timeout: 245 seconds]
pitust has quit [Ping timeout: 256 seconds]
alecjonathon has quit [Write error: Connection reset by peer]
asymptotically has quit [Ping timeout: 256 seconds]
rselim has quit [Ping timeout: 256 seconds]
alethkit has quit [Ping timeout: 256 seconds]
staceee has quit [Ping timeout: 256 seconds]
vismie has quit [Read error: Connection reset by peer]
patwid has quit [Ping timeout: 276 seconds]
exec64 has quit [Ping timeout: 276 seconds]
ddevault has quit [Read error: Connection reset by peer]
tommybomb has quit [Ping timeout: 256 seconds]
hanemile has quit [Ping timeout: 256 seconds]
sm2n has quit [Ping timeout: 276 seconds]
yuiyukihira has quit [Ping timeout: 256 seconds]
whereiseveryone has quit [Ping timeout: 256 seconds]
listentolist has quit [Ping timeout: 256 seconds]
jleightcap has quit [Ping timeout: 256 seconds]
tom5760 has quit [Ping timeout: 256 seconds]
gjn has quit [Ping timeout: 256 seconds]
lh has quit [Ping timeout: 276 seconds]
noeontheend has quit [Ping timeout: 276 seconds]
epony has quit [Remote host closed the connection]
Gooberpatrol66 has quit [Quit: Leaving]
<kof123>
> https://newcome.wordpress.com/2012/03/06/functional-programming-and-the-death-of-the-unix-way/ Now, on to the concrete solutions. The Viewpoints Research Institute is currently working on a system for personal computing that does nearly all basic computing (desktop publishing + web + email + other things) in 20,000 lines of code (a single book). Including the self-implementing compilers. So I’d say there is hope.
<bslsk05>
newcome.wordpress.com: Functional programming and the death of the Unix Way | Dan Newcome on technology
* kof123
follows link, 404 goes to root page > Viewpoints Research Institute concluded its operations at the beginning of 2018.
<kof123>
oh, so much for hope lol
netbsduser has joined #osdev
<kof123>
> the one and only Rob Pike has been quoted as saying “Those days are dead and gone and the eulogy was delivered by Perl.” that is interesting just because it was 2012
Gooberpatrol66 has joined #osdev
node1 has joined #osdev
netbsduser has quit [Ping timeout: 276 seconds]
Test_User has joined #osdev
\Test_User has quit [Read error: Connection reset by peer]
Test_User is now known as \Test_User
node1 has quit [Quit: Client closed]
\Test_User has quit [Quit: ugh]
\Test_User has joined #osdev
netbsduser has joined #osdev
epony has joined #osdev
epony has quit [Read error: Connection reset by peer]
netbsduser has quit [Ping timeout: 264 seconds]
yoO0Oo has joined #osdev
vdamewood has joined #osdev
yo0O0o has quit [Ping timeout: 268 seconds]
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
netbsduser has joined #osdev
netbsduser has quit [Ping timeout: 264 seconds]
GeDaMo has joined #osdev
sprock has quit [Remote host closed the connection]
sprock has joined #osdev
iamzim has joined #osdev
iamzim has left #osdev [#osdev]
yoO0Oo has quit [Ping timeout: 252 seconds]
gog has joined #osdev
netbsduser has joined #osdev
yoO0Oo has joined #osdev
yoO0Oo has quit [Ping timeout: 276 seconds]
yoO0Oo has joined #osdev
yoO0Oo has quit [Read error: Connection reset by peer]
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
zid has quit [Ping timeout: 256 seconds]
heat_ has joined #osdev
<j`ey>
heat_: hey, aarch64 has instructions like ldrt that can be used at EL1, to do EL0 accesses. does x86 have a similar thing?
<heat_>
j`ey, hai, no i don't think there is. you just need to stac; mov %reg, addr; clac
<j`ey>
my x86 knowledge is so bad.. and I don't intend to improve it D:
<heat_>
yes, and AC was overloaded to mean "can touch user memory from the kernel level" like 14 years ago
<heat_>
*when SMAP is enabled*
<j`ey>
and it uses the user permissions right?
<j`ey>
like if it was marked read-only
<j`ey>
could the kernel write to it?
<heat_>
no. x86 only has a single set of permissions, unlike arm64
<mjg>
kof123: loller
<mjg>
x86 master ra^Warch
<heat_>
you can in theory disable write-protection using CR0.WP = 0, but that affects kernel memory and user memory
<heat_>
god my doctor got me some vitamins and they literally taste like i'm eating iron
<heat_>
i gag every time i have to take them
<kof123>
mjg: the perl quote? it does not interest me so much, just philosophy-wise...the thing that grew up on unix was what killed it (not taking a side, ignoring if the quote is even real). there is unity of opposites/contains the seeds of its own destruction lol
<GeDaMo>
heat_: can you wrap them in a slice of cheese? :|
<heat_>
GeDaMo, yeah i might need to start wrapping these in real food like i'm a cat :/
<mjg>
heat_: iron temple motherfucker
<mjg>
i bet you take dodgy suplements from amazon
<mjg>
but claim it's prescription drugs
Left_Turn has joined #osdev
<heat_>
i get all my suplements from the joe rogan podcast
<heat_>
jamie, pull up that video of a jacked bear eating iron bars
<mjg>
but do they have eficiacious doses of high quality ingredients allowing for supraphysiological outcomes?
<mjg>
btw re that ubuntu vs UBSAN, on closer look they add CONFIG_UBSAN_ONLY_BOUNDS=y which limits fuckery
<mjg>
that is to say deemed not PESSIMAL
<mjg>
just slower
zid has joined #osdev
<heat_>
yes, and they also only trap
<heat_>
anyway can't wait for Ubuntu 25.10 where they'll also enable KASAN
<zid>
good news heat, my PC crashed again, so I wiggled my ram and re-pasted my heatsink and dusted my fans
<mjg>
just buy a new pc when old one crashes
<heat_>
have you tried turning it off and on again
<mjg>
turn life off and on again
<mjg>
no wait
<zid>
I did need
[itchyjunk] has joined #osdev
[_] has quit [Ping timeout: 245 seconds]
<zid>
indeed*
<zid>
Am4 socket is scary socket btw, I took heatsink off and cpu came with it
<zid>
their ZIF is also ZRF apparently
<clever>
zid: i did the same with my fx-8350 system
<clever>
ripped the cpu out of the zif
<clever>
then i had to remove the cpu from the heatsink without bending any pins
<zid>
That's easy, twist
<zid>
the poo-inducing part
<zid>
is that it *might fall off*
<zid>
and if it does fall off, it's going pins first
<zid>
So, you lift heatsink, cpu comes with, but then falls off after a couple of inches
<zid>
destroying cpu
<clever>
heh
<clever>
i just put a screwdriver on the corner of the heatspreader, and whacked it with a hammer
<clever>
and that both twisted and levered it off
<zid>
*what*
<zid>
the fuck did you do, glue it on?
<zid>
mine was just heavy surface tension
<clever>
the thermal paste was that dry
<zid>
ah you accidentally used toothpaste
<clever>
that poor old 8350 is still kicking to this day
<zid>
AM4 is such a pathetic looking socket
<zid>
2011+ is like two big metal things with hinges that go KERCHUNK
<zid>
and am4 is like "pls don't try to put a 478 into me"
<anosdever>
Hello OSDevers! I've been inventing my scheduler. But I've got a big problem. Does anyone here know on this topic?
<zid>
no we don't know what your problem is
<zid>
telepathic hotline maybe?
<anosdever>
Then I will outline it for you zid.
vinleod has joined #osdev
vdamewood is now known as Guest8150
Guest8150 has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
vinleod is now known as vdamewood
<anosdever>
Here is my problem. I have a Thread class with a member "_spinlock" used for short-term manipulations, such as change of state, change of state happens at times which include: You're timeslice expired and you go to the runqueue; you are going to wait; you were waiting but now are being woke, either because wait queue was signalled or you're wait timed out. Do you follow?
<sham1>
Yes, you have a spinlock
<zid>
abbr. ver. "I have a spinlock covering each thread"
<anosdever>
Now here is where the problem begins, my thread timeslice expired, I lock it up, I invoke the switch-to-next-runnable-thread routine, that routine need to lock the runqueue, select a new thread, lock the new thread, put old thread on runqueue, unlock the runqueue, (Old thread has to stay locked until after the switch, because it isn't ready for rescheduling yet), do the switch, and in the context of the new running thread I finally unlock both the old an
<anosdever>
*unlock both the old and new threads.
<anosdever>
There is two problems. First, an arbitary ordering between acquiring thread spinlocks. That would be fine if I never have to acquire more than one thread spinlock at once, outside of the scheduler that is. Can you really say that is true? And second, as you can see, I acquire old thread spinlock then runqueue spinlock then new thread spinlock. If I ever want to acquire a thread spinlock plus the runqueue spinlock elsewhere - NO DEFINED LOCK HIERARCY!!!
<Mutabah>
having just a lock for each queue seems better than locks on the threads
<Mutabah>
So you lock a queue, and move the currently running thread into it, release the lock, then go looking for something else to run
<anosdever>
I think I still needing a thread lock. Because, if I wake up a sleeping thread from two cores at once. Then I am locking Core A's runqueues spinlock to schedule the thread there. And Core B's spinlock to schedule the thread there. And there is an evil race.
<anosdever>
It figures in to waiting logic also. But I think, it might be possible to make the thread-wait-state go under a separate spinlock.
anosdever has quit [Quit: CGI:IRC (Error)]
anosdever has joined #osdev
<Mutabah>
ah, but that thread would be sleeping by being on another queue
<Mutabah>
e.g. the timer queue(s), or on a mutex
<anosdever>
https://www.informit.com/articles/article.aspx?p=2249436&seqNum=3 Look what I am reading in the great FreeBSD Book. (FreeBSD is a good and useful kernel.) It says: The thread is locked depending on his current statum, for example is locked by runqueue lock if in a runqueue; by turnstile lock if waiting for a turnstyle; it does not say where it's locked, if it is running now.
<bslsk05>
www.informit.com: 4.3 Context Switching | Process Management in the FreeBSD Operating System | InformIT
<anosdever>
Mutabah: It can be on multiple wait queues simultaneously, that's for "poll()"/"select()" function. But I think it might make sense in that case and that case only to make the thread lock by its own spinlock.
<anosdever>
And for other cases, maybe I can steal the FreeBSD idea, which I call: Mobile Lock
<anosdever>
How do the OSes of the people here structure locking around scheduling, waiting?
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
anosdever has quit [Quit: IRC]
<mjg>
that's a solaris idea
frkazoid333 has joined #osdev
bauen1 has quit [Ping timeout: 245 seconds]
<kof123>
there was a period where languages would handle all that
<kof123>
it was called "the future"
<kof123>
it never actually arrives always hype lol
<netbsduser>
it was easier to daydream about when locking was trivial and big
<kof123>
yes, that makes sense too. from what people say here...techniques have been refined, moving target, was not quite solidified in the first place to "automate"
<netbsduser>
modern synchronisation is an art not a science and no language can do it for you
<kof123>
:/ conway's law, alchemy makes no distinction :D but yeah
<bslsk05>
github.com: linux/mm/rmap.c at master · torvalds/linux · GitHub
opus has joined #osdev
heat has joined #osdev
heat_ has quit [Read error: Connection reset by peer]
<mjg>
uni courses about multicore are for people who won't be dealing with it
bauen1 has joined #osdev
bitoff has joined #osdev
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
<gog>
leeloo dallas multicore
teroshan has quit [Ping timeout: 260 seconds]
gog has quit [Quit: Konversation terminated!]
node1 has joined #osdev
gog has joined #osdev
netbsduser has quit [Ping timeout: 260 seconds]
netbsduser has joined #osdev
Turn_Left has joined #osdev
xenos1984 has quit [Ping timeout: 264 seconds]
bauen1 has quit [Ping timeout: 264 seconds]
Left_Turn has quit [Ping timeout: 246 seconds]
node1 has quit [Quit: Client closed]
xenos1984 has joined #osdev
<gorgonical>
if I fnctl and lock based on SEEK_END and then add bytes to the file, does my lock apply to what used to be the end, or what the end is now?
<gorgonical>
It seems like fcntl locking applies to a numerical byte range, right?
bauen1 has joined #osdev
gabi-250_ has quit [Ping timeout: 240 seconds]
gabi-250_ has joined #osdev
<geist>
that's a good question
<geist>
i have no idea, but if you figure it out please tell us!
<heat>
gorgonical, i think it's supposed to be what used to be the end
gbowne1 has joined #osdev
<kof123>
fcntl(2) Bytes past the end of the file may be locked, but not bytes before the start of the file.
<heat>
gorgonical, yep, quick check in linux says that the locks just lock a byte range
<geist>
so it's an instantaneous lock of the range up to the end of the file at the time of the call
<gorgonical>
there is a special case where the region len is 0, which does have the "sticky" effect
epony has joined #osdev
gxt has quit [Ping timeout: 240 seconds]
gxt has joined #osdev
<gorgonical>
byte-range locks are messy
<gorgonical>
If I lock bytes (0, 1000) and unlock (500,600) now I have to split the region. The same thing with if I lock (0,550) and then (550,1000) and unlock (500,600), I have to modify two regions
<gorgonical>
gross
<geist>
yeah it's one of those things you really dont want to have to implement
<heat>
it's like mmap but for locks
<gorgonical>
I just did all this work with the aspace system so I could implement map_fixed in mmap
<gorgonical>
and now I have to do it all again
<gorgonical>
:(
<heat>
i haven't needed these locks yet
<gorgonical>
I want to support sqlite which uses fcntl locking
<heat>
oh
<heat>
but sqlite isn't web scale!
<gorgonical>
I reckon every other database also uses file-level locking, too
<heat>
i bet mongodb doesn't use file-level locking
<heat>
that's not web scale
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<gorgonical>
I mean how else do you manage commits to disk then?
<gorgonical>
I am no db expert though so maybe there are some clever techniques to manage this
<heat>
you're in no way shape or form required to use file-level locking for anything that's not sharing a file
<gorgonical>
You're right if you manage it internally
<gorgonical>
Which actually sqlite says it does, but it takes one lock on the file and then all the other locking operations get turned into nops
<gorgonical>
Why then they use fcntl to do this which requires byte-level addressing is beyond me
<gorgonical>
If they are locking the whole file they should just use flock
<heat>
flock() is advisory
<gorgonical>
so is fcntl according to my manpages
<heat>
oh ew
<mcrod>
hi
<gorgonical>
god damnit sqlite actually uses the byte-granularity locking of fnctl
<gorgonical>
wtf man
<gorgonical>
I can't even implement a dumber version of fnctl that is basically flock
<bslsk05>
github.com: mongo/src/mongo/db/storage/storage_engine_lock_file_posix.cpp at c001f431168aca7e0c37e5fa96e9966f3cec93bf · mongodb/mongo · GitHub
<heat>
it is time for gorgonicalOS to go web-skell
<mjg>
are you a webdev if your kernel is webscale? :thinkingface:
<gorgonical>
this gets even worse: are fcntl locks per-pid?
<mjg>
there is a lot of retarded semantics in the area
<mjg>
to the point where i forgot all of them
<gorgonical>
can pid 1 lock bytes 0,100 and then pid 2 unlock 50,60?
<gorgonical>
this sucks lmao
<mjg>
are you implementing this for a real project?
<gorgonical>
yes unfortunately
<gorgonical>
ree surch
<mjg>
god bless your heart
<heat>
it's time for your reesurch to go webskell
<mjg>
maybe there is a rust crate
<mjg>
with 0 cost locking
<geist>
yeah if it's a hobby thing i'd half ass it
<geist>
get it working enough, slowly, and worry about the performance later if it's an issue
<mjg>
it's a research kernel
<mjg>
meaning it in fact does not have to work
<gorgonical>
the power of -ENOSYS is enormous, mjg
<mjg>
return 0; /* fuck this, assume bottlenecks will provide de facto exclusion */
<heat>
radixvm vibes
<heat>
i found out last week that MIT wrote a UNIX in golang
<gorgonical>
i think the simplest version of this may be to represent the lock regions as a set with coalescing. a sorted linked list without overlaps or duplicates
<geist>
yeah that's probably the standard solution
<gorgonical>
and without a notion of per-pid locks
<geist>
you get something that works, maybe has O(N) scalability issues, but only within a single file
<geist>
and then *shrug*
<gorgonical>
so pid2 can unlock pid1's regions
<geist>
and the default situation is a zero length list which is easy to test for
<heat>
easiest solution is an interval tree
<heat>
if you have one
<geist>
i disagree. you need a tree
<geist>
yeah
<geist>
also walking the list and then futzing with it in place is pretty cheap once you've found the spot
<geist>
has a nice O(1) property after the O(N) search
<mjg>
maybe SORTIX has stealable implementation?
<gorgonical>
if an interval tree can be implemented using an rb tree then that may be what I do
<gorgonical>
the manpages for fcntl do in fact state that the locks are per-process
<gorgonical>
christ
<gog>
i have cubic complexity
gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
heat_ has joined #osdev
heat has quit [Ping timeout: 256 seconds]
<sortie>
mjg, O(unreachable), Sortix does not have file locking (big applause from audience when they realize how absolutely terrible the existing semantics are)
<sham1>
That's certainly one of the ways of all time to do this
<sham1>
Just donn't
<heat_>
sortix only runs webscale services like mongodb and redis
<sortie>
heat_, you spin up a Sortix VM for each core, it doesn't get more webscale
<heat_>
but the way containers do allocators is wank, and the way they can't tolerate operator new failures is wank
<heat_>
btw: cool GCC supports std::println!
<Arsen>
that's new :-)
<heat_>
in trunk?
<Arsen>
yup
<Arsen>
iirc jonathan added it just in time for it to make it ino 14
<Ermine>
did they get rust macros?
<Arsen>
no, we still have just crappy C macros :(
<Ermine>
why std::println! then
<heat_>
oh
<heat_>
it's called std::println
<Arsen>
lol
<Arsen>
good one
<Arsen>
oh also, a lot of libstdc++ code (all of it that's currently in the freestanding set, because I wasn't ambitious this release cycle) is completely independent of allocators
<Arsen>
and it's not insignificant
<Arsen>
there's a ton of stuff
<Arsen>
<algorithm> is there even
<mcrod>
i think i'm having a stroke
<mcrod>
i cannot handle more C++ today
<heat_>
Arsen, personally i would not include any of libstdc++ in a kernel
<heat_>
it's big and bloated and has lots of C standard library deps and they do funky shit like C++ header interception
<heat_>
s/C++/C/
<Arsen>
not really?
<Arsen>
but i mean, you do you
<heat_>
yes really
<Arsen>
i put libstdc++ in kernels just fine
<heat_>
i have huge hacks in my build so i can include really standard freestanding headers
<bslsk05>
github.com: Onyx/kernel/Makefile at master · heatd/Onyx · GitHub
<epony>
GOOG is Stanford, West coast so BSD, Berkeley RISC, and proprietary capture Jan11 2130<heat> i found out last week that MIT wrote a UNIX in golang
<Arsen>
interesting
<epony>
also that does not change anything without "re-engineering the system"
<Arsen>
lets see why i don't have this problem
<epony>
they have a lot of PhDs on their portfolio, that is sub-standard on Google's side
<epony>
GOOG could have written 25 UNIX editions if they wanted to and knew what to do with it
<epony>
it's an advertising company with spambot mailer crapware and people doing manual optimisations on top of distributed computing pseudo-Linux sharding type distribution, and.. classical UNIX services workloads
<Arsen>
ah, that's why: <stdin>:1:10: fatal error: stdlib.h: No such file or directory
Yoofie has quit [Read error: Connection reset by peer]
<Arsen>
we just use cstdlib
<epony>
and also.. function as a service model like the AMZN AWS bs productisation
<heat_>
what are you using from the STL?
<epony>
none of that is relevant, as x86 is what people have and BSD and GNU serve if fine
<heat_>
i've found very little use for anything from the STL except <type_traits>
<heat_>
and <source_location>. because those are both automagic headers
<Arsen>
i dont remember what managarm uses
<epony>
so internally GOOG is a "deb" shop coming back from a "rpm" one
<epony>
and that's quite stupid
<heat_>
anything else i've handrolled (vector, string, some basic SFINAE)
<Arsen>
whatver crap was in cxxshim i replaced with libstdc++ stuff
<bslsk05>
github.com: cxxshim/stage2/include at master · managarm/cxxshim · GitHub
<epony>
but so are the other big tech on the inside
<Arsen>
unsurprisingly, iterators, algorithms, and a bunch more stuff works fine
Yoofie has joined #osdev
<heat_>
oh yeah i implemented tuple and pair too
<epony>
pretty lame, Microsoft had leaked documents about their business hosting departments organisations (with a couple of servers per service) some years go, it was pathetic
<Arsen>
ah yeah, those work fine too
<epony>
and the software strength of Microsoft is an order of magnitude more than the other in the bunch
<heat_>
vector i feel has some utility for a kernel, but a limited one because you don't want big allocations
<Arsen>
ah yeah, spans and string views work
<heat_>
and if you want RCU you'll need to handroll your own vector
<Arsen>
bind prob works
<heat_>
What is the run-time cost?
<heat_>
Things like 'smart pointers' are dumb!
<heat_>
CSTRING is an abomination.
<heat_>
lmfao
<Arsen>
unique_ptr works to
<Arsen>
o
<heat_>
no one tell him cstring is string.h
<heat_>
it's funnier and truer this way
<Arsen>
i should prob sub to LKML for the duration of this thread
<bslsk05>
lore.kernel.org: Re: [PATCH 00/45] C++: Convert the kernel to C++ - Arsen Arsenović
<Arsen>
oh was that a response to me?
<Arsen>
i'll fetch the mail
<heat_>
no
<mcrod>
o
<gog>
hey while we're at it let's put a font rendering engine in the kernel
<FreeFull>
The other C-compatible object-oriented programming language
<Arsen>
FreeFull: because it lacks the same features C lacks
xenos1984 has quit [Read error: Connection reset by peer]
<gog>
and then take it out in 5 years
<heat_>
Arsen, anyway.. subbing to linux-kernel@ is nuts
<Arsen>
heat_: yeah, hence 'for the duration of'
<Arsen>
how did you catch that I posted, even?
bitoff has quit [Ping timeout: 252 seconds]
<heat_>
i was reading on lore for updates
<Arsen>
ah
<heat_>
anyway i... i don't think C++ should be added to the kernel. at least not in any meaningful way
<Arsen>
that's ridiculous
<heat_>
for drivers? fuck it, who cares
<Arsen>
it's strictly benefits
<heat_>
C++ has benefits and gotchas
<gog>
kernel python
<gog>
for drivers
<Arsen>
tru
<Arsen>
from actual generics to RAII, to strict type checking, etc
<gog>
no
gbowne1 has quit [Remote host closed the connection]
<gog>
lua
<heat_>
i know it because i wrote a whole kernel in C++ and i kind of regret it
<heat_>
the kernel universe is completely separate from r/cpp
<Arsen>
I'm not sure what r/cpp is
<heat_>
c++ subreddit
<Arsen>
yes, I figured that, but I don't know what it implies
gbowne1 has joined #osdev
<FreeFull>
Rust already is in the kernel, and it has generics, RAII, and strict type checking
<Arsen>
yes, but unlike C++, it won't compile slightly altered C garbage
<FreeFull>
That seems to be an acceptable tradeoff
<heat_>
people that go on and on and on about ranges and all the new C++ features, and abhor stuff like ptr = ptr | LOW_BIT_FLAGS;
gbowne1 has quit [Remote host closed the connection]
<Arsen>
well yeah, that's disgusting
<Arsen>
put it behind a type
gbowne1 has joined #osdev
<Arsen>
you get all the benefits without the part where you must open code using it everywhere
<heat_>
that's not the point
<heat_>
they abhor low level hacks because they don't write low level code
<mcrod>
i'm going to say this, C is going to be a mistake for my emulator project
<mcrod>
and I almost regret not using C++
<mcrod>
not the STL, no, no no no no nothing like that
<mcrod>
but an x86-64 emitter is going to... suck
<mcrod>
and that's just one example
<heat_>
how is C++ helping you with that
<mcrod>
function overloading
<heat_>
an x86-64 JITTer will always suck
<heat_>
EW
<mcrod>
even if it wasn't for that, templates would be nice
<Arsen>
oh yeah
<Arsen>
I wanted to make a case for function overloading
<mcrod>
operator overloading was cool for the gameboy CPU registers
<mcrod>
can't believe I'm saying that
<mcrod>
but, it was beautiful and somehow efficient
<FreeFull>
Operator overloading is different from function overloading
<mcrod>
yes i know that
<mcrod>
i'm just talking something different :p
<mcrod>
more people hark on operator overloading than function overloading, which I get
<heat_>
i hark on both because they're both atrocious ideas
<heat_>
const auto var = foo(); bar(var);
<heat_>
what's bar?
<mcrod>
duh
<mcrod>
it's clearly your mom
<heat_>
fuck you
<mcrod>
I used to be a big auto guy
<mcrod>
but then I stopped doing that
<kof123>
> because it lacks the same features C lacks > Objective-C++ is simply source code that mixes Objective-C classes and C++ classes (two entirely unrelated entities) <runs away and dives off cliff into ocean>
Griwes_ is now known as Griwes
<mcrod>
and my code is better for it
<Griwes>
skill issue
<Griwes>
my editor shows me exactly what type a thing is right next to its name when I use auto
<Griwes>
:P
<mcrod>
that's the problem
<mcrod>
you NEED an editor
<heat_>
that's the joke mcrod
<mcrod>
oh
<mcrod>
right
<mcrod>
sorry, but I hear that much too often in a non funny way
<mcrod>
and people look at me like I have two heads
<Griwes>
(but I often do find code written with auto to be actually more readable than if the types were explicitly written out)
<mcrod>
then you are insane
<Griwes>
lol
<mcrod>
for (const auto i : v) { what's i? }
<FreeFull>
Having to write foo.add(bar); instead of foo + bar is terrible
<Griwes>
mcrod, terrible names are your problem there
<FreeFull>
( Assuming you can even do method calls like foo.add() in some language )
<mcrod>
that's not the problem here
<Griwes>
what's v? I have no clue by the name alone
<mcrod>
for (const auto number : numbers) { is number a string or an integer? }
<Arsen>
00:03:49 <heat_> what's bar?
<Arsen>
who cares?
<Arsen>
give it a better name
<Griwes>
if that number is a string, then your names in this loop are terrible
<netbsduser>
c++ has nice properties for a kernel lang
<Arsen>
if you overload a name with drastically different functionality, that's on you
<netbsduser>
i am liking it more and more
<mcrod>
ok, so we just need to suffix _str
<FreeFull>
Well, I doubt Linus would be in favour of C++
<mcrod>
yes i'm expecting Linus to come down on everyone with full wrath
<Griwes>
I am flabbergasted that he hasn't replied to that patchset yet
<mcrod>
I cannot believe people proposed it
<mcrod>
there are two things he's said, fairly recently about C++
<Griwes>
oh wait, that patchset itself is _old_, just noticed that
<netbsduser>
FreeFull: he has an aversion to it but he's never once presented a concrete argument as to why c++ bad
<Griwes>
then I am _really_ surprised he didn't say anything specifically there lol
<mcrod>
"if you think like a computer, writing C makes sense" and "if I write C, I know what the assembly language will look like; and that's something I care about"
<bslsk05>
harmful.cat-v.org: Linus Torvalds on C++
<FreeFull>
C really doesn't translate directly to assembly language at all, nowadays
<netbsduser>
mcrod: ah, the famous email
<netbsduser>
i have read it
<Griwes>
if I need to know what the assembly generated looks like, I will write with a subset of C++ that just directly translates to it
<mcrod>
FreeFull: tell that to him only a few years ago
<Griwes>
this is not rocket science, just an ability to choose the right subset of a tool for the job
<mcrod>
note I'm not siding with any particular argument, only just stating that Linus will either a) let this die silently, or b) respond with full fury
<FreeFull>
Right now it's looking like a)
<netbsduser>
his complaints are that he doesn't like boost, he doesn't like abstractions because sometimes you might make the wrong abstraction, he thinks exceptions don't work, and that there are secret allocations inserted by the learned elder freemasons of the C++ commitee
<mcrod>
indeed, if this were the old linus it would've been game over
<Ermine>
FreeFull: at -O0 it translates pretty directly, at higher opt levels we assume that compiler doesn't break anyything
<netbsduser>
let's be blunt about it
xenos1984 has joined #osdev
<mcrod>
writing C++, I don't use 98% of the fancy features, or the STL
<heat_>
Griwes, mcrod it was an april fools joke
<mcrod>
i refuse
<FreeFull>
C++ does like to do implicit copies where in Rust you'd have to explicitly write .clone()
<netbsduser>
there is nothing substantial to his criticisms
<mcrod>
i do not use exceptions or RTTI, for example
<Ermine>
netbsduser: exceptions don't work at kernel space unless you implement them
<mcrod>
never have, never will
<netbsduser>
he did complain historically about G++ problems which at least were a practical issue (as G++ was the only free C++ compiler)
<kof123>
i think a long time ago linus said C++ attracts the wrong crowd or similar
<Griwes>
heat_, okay, but there's an actual discussion of sorts going on right now :P
<mcrod>
I had this argument with someone yesterday
<mcrod>
the creator of the STL once stated openly there was an abstraction penalty to using the STL, which was true 20 years ago
<netbsduser>
Ermine: nowadays thanks to a round of work done by an up-and-coming gcc hacker, it's basically as simple as linking libstdc++
<kof123>
new-er-do-wells as it were :D the sketchy shady folks (someone make better puns) :D
<Griwes>
kof123, that's the one argument I can't really argue with, because a lot of C++ devs are full of shit and write it as if it was java or some shit like that
<kof123>
make a pun!
<kof123>
i accept pun arguments
<mcrod>
but that's not quite so true anymore
<Ermine>
netbsduser: will anybody link libstdc++ though?
<mcrod>
so, there's no penalty just for the sake of using it (under certain circumstances), even though the STL is generally inefficient even with optimizations
<Griwes>
I see enough shitty arguments and proposals float at or near the committee that I don't really have that much faith in the general population of C++ devs
<mcrod>
you can write performant software in C++, that much is true
<mcrod>
but the moment you pull in std::map/unordered_map or any of that garbage
<mcrod>
you've lost
<Griwes>
yeah unordered_map has made... mistakes
<mcrod>
the good news is, people know this is a problem, except no one wants to break the ABI
<netbsduser>
Ermine: now that it works freestanding it's the sensible choice to do
<mcrod>
which, sadly, I'm in agreement with
<Griwes>
tho map is fine if you want a binary tree
<Griwes>
thankfully, we've recently got flat_map
<Griwes>
cue screeches from FP crow
<Griwes>
crowd*
<mcrod>
I think my overall point is if you're writing C/C++, you're interested in performance, and you *perhaps* don't want a generic 'something', you want an optimized 'something' tailored to the needs of your application
<netbsduser>
it's a subset of the true and full libstdc++ of course
<mcrod>
and too often people think the STL is some holy relic wrt performance and compilers are wisdom and can never be wrong
<Griwes>
eh, generic data structures are fine, there's a lot of them and you don't have to rewrite then all the time
<mcrod>
right, I'm not trying to argue against generics as a whole, I'm saying like any large scale problem in software, it depends on the context
<netbsduser>
for a kernel it can be fairly said that no one has ever or will ever use any STL container
<Griwes>
the only time I'm really rolling anything special is, well, for the kernel, and for GPU kernels (tho not much need for that, we've got a team doing exceptionally efficient concurrent data structures that follow good C++ practices at work these days)
<FreeFull>
I'm sure someone has tried using STL for a kernel at some point
<FreeFull>
Just because people have done crazier things
<mcrod>
put it this way
<netbsduser>
i did a template version of BSD <sys/queue.h> and <sys/tree.h> instead and these various intrusive lists and trees are sufficient for almost all my needs
<mcrod>
games have to be performant, right? especially AAA games that generate a lot of money, and have to be reasonably performant on even the shittiest of hardware (within reason)
<heat_>
<Arsen> 00:03:49 <heat_> what's bar?
<heat_>
<Arsen> who cares?
<heat_>
<Arsen> give it a better name
<heat_>
i 100% do
<FreeFull>
Often games are pretty badly optimised
<mcrod>
note that in such a case, they're not using the STL
<Griwes>
games are so badly developed almost all of the time
<mcrod>
they're rolling their own (see: EASTL)
<heat_>
i care about knowing more or less what codegen comes out, i care about the source code being explicit, i care about not requiring clangd
<Ermine>
they work somehow though
<Arsen>
heat_: you're doing it wrong then
<Griwes>
but they will wank to their "superfast data structures"
<Griwes>
while making the entire thing run like shit until someone external fixes it one way or the other
<Arsen>
if the work attached to your identifiers changes significantly based on the types passed to them, you screwed up
<heat_>
Arsen, C++ is both a language with explicit [[likely]] and [[unlikely]] attributes, and a language with "who cares?"
<heat_>
and that is objectively wrong
<Arsen>
yes
<Griwes>
lol
<Griwes>
it's a language that allows you to write code at various levels of caring about exact machine code mapping vOv
bitoff has joined #osdev
<mcrod>
modern games do require a good amount of optimization, is what I'm saying, and they're not using the STL for a reason
<mcrod>
these are people who DO NOT, and CANNOT use any of the fancy modern C++ features because of crippling debug performance
<kof123>
if nothing else...games have to strike while a console or other target is hot? i mean, i always heard tight deadlines, long hours, or maybe that was just EA
<mcrod>
and anyone who thinks that debug performance doesn't matter is incompetent and out to lunch
<netbsduser>
mcrod: i have a rule of thumb that if one uses C or C++ but hasn't any need to either interact with the underlying OS very directly, or to do custom memory management, then it is questionable as to whether the software should be written in such
<heat_>
Griwes, and anything kernel-like will care about that mapping, because anything else is a mess
<Griwes>
I wouldn't want to write in a language that doesn't let me jump between levels of abstraction easily
<Ermine>
mcrod: I don't think I'll get pleasant experience on my (mostly) 2012 hardware with more recent titles like cyberpunk or doom eternal
<gog>
i would really like a C-like language with a couple features C doesn't have
<mcrod>
netbsduser: sure, i agree
<mcrod>
Ermine that's why I said within reason :p
<Ermine>
and where's the border of that reason?
<netbsduser>
so kernels and systems software fits the bill; certain games do (the ones that need recent hardware to run acceptably); databases do (they implement their own page caching schemes); that sort of thing
<mcrod>
modern top tier titled games aren't going to care about 12 year old hardware
<mcrod>
because that will add limits on what they can do
<heat_>
Griwes, what you call "versatile", i can call "inconsistent mess", and we're both right
<Griwes>
oh, I don't argue that point
agent314 has joined #osdev
<Arsen>
00:20:58 <heat_> Griwes, and anything kernel-like will care about that mapping, because anything else is a mess
<Arsen>
anything that cares about the mapping is invariably terrible code
<mcrod>
note that when I say "games" I'm talking the blockbusters
<Arsen>
needing to know exactly what's there is a huge red flag
<heat_>
erm, it's not
<Arsen>
it absolutely is
<Griwes>
C++ is the language of getting the defaults wrong by default
<Arsen>
that changes based on the compiler
<mcrod>
"guys, there's a black hole in the ground"
<mcrod>
do you stick your head in there because you're curious
<heat_>
it absolutely is not. there's a real need for optimization and microoptimization of code
<Griwes>
so yeah, there's a whole lot of historical baggage attached to the language
<Arsen>
and I did not say anything else
<Arsen>
but to state that you must know what's there always is false and hugely detrimental
<netbsduser>
heat_: i think for that an intimate familiarity with what your compiler does is always essential
<Arsen>
note that optimization has nothing very little to do with output code too
<netbsduser>
i don't think c++ is much worse in terms of what is supposedly permissible than C
<mcrod>
Griwes: here's the big problem: c++ is the language of bjarne stoustrup not knowing how to say "no" to people
<Arsen>
s/nothing// of course
<Griwes>
anyway, back to trying to get my head aching from the cold I have to actually make progress on my vim config lol
<mcrod>
hell, even he's stated that there's a simpler language waiting to be born from C++
<netbsduser>
mercifully if GCC or Clang were to get bold and try to exploit something that's technically permissible but would defy everyone's reasonable expectations, they would face vengeance at the end of a fork
<mcrod>
there's a reason when someone says they're a C++ expert, they are, almost always, wrong
<Griwes>
mcrod, lol, Bjarne is THE main person arguing against most new additions (and some of the recent tiny ones are **fantastic** to use)
<Griwes>
these days at least
<mcrod>
right
<heat_>
Griwes is a C++ expert
<mcrod>
that's exactly what I'm saying
<Arsen>
I must be getting a stroke
<heat_>
Griwes, did he vote against ranges? please tell me he voted against ranges
<mcrod>
the problem is, to be blunt
<netbsduser>
what are ranges to be?
<mcrod>
people like to masturbate to insane amounts of man-made unnecessary complexity for job security/ego reasons
agent314 has quit [Read error: Connection reset by peer]
<netbsduser>
some sort of view on arrays?
<mcrod>
"hey look, I can understand this big pile of shit"
<mcrod>
the smart one doesn't write a pile of shit in the first place
<Griwes>
heat_, I am not going to comment on how specific individuals voted on specific changes, sorry
<Ermine>
netbsduser: they (gcc devs at least) are actively exploring what standards are allowing them to do
<heat_>
Griwes, oh, that's not public?
<Griwes>
it's their prerogative to reveal that, not mine
<Griwes>
hell no
<heat_>
gotcha, didn't know
<mcrod>
wait Griwes is a voter?
<kof123>
someone told me my code was trivial. yes? that is the point of NIH for me -- so i can understand it, even if it is crap
<heat_>
yeah he's in the committee
<mcrod>
are you kidding me?
<mcrod>
Griwes i have a task for you
<mcrod>
bribe everyone there to vote themselves out of existence
<Griwes>
the minutes of meetings will contain information about who objected to unanimous consent, but not further than that
<mcrod>
(not literal existence)
<Griwes>
but that's only at plenary
<netbsduser>
Ermine: technically the standard will let them emit code which has 0x1234 for the null pointer's integral representation and multiply all addresses by 256
<netbsduser>
they will never do it
<mcrod>
heat_ I get why it's not made public
<mcrod>
the internet is full of crazies
<netbsduser>
it would be the death of GCC
<heat_>
netbsduser, ranges are basically "what if haskell/functional programming, but in C++"
<Griwes>
it's not made public because ISO says that this is information that must not be disclosed without explicit consent of the people involved
<Griwes>
same with attributing quotes from the meetings or internal mailing lists to specific individuals
<netbsduser>
heat_: i thought C++ got over its functional envy
<netbsduser>
functional was the trend a decade ago
<mcrod>
this is what I think of C++, as my mother used to say: give a person an inch they take a mile
<netbsduser>
now rust is
<Ermine>
netbsduser: if your code breaks, they will shrug and say "Your code is UB, fix it", and tecnically they are true
<heat_>
C++ is a lot of things for a lot of people
* Arsen
rolls eyes
<mcrod>
i roll my eyes too at every C++ debate
<mcrod>
for some people, C++ is the god of all programming languages
<Griwes>
I mean, heat_ is right here
<mcrod>
for others, it is a garbage language that should've never been born
<netbsduser>
Ermine: they won't actually do it because if they do, they would be regarded as a danger that had become a threat to everyone who uses linux, and that would be the end of the whole farce
<Griwes>
yes, and for reasonable people it's a tool they understand and can use efficiently while acknowledging its faults and shortcomings
<mcrod>
and the usual reasonable take is
<mcrod>
use the right tool for the job
<mcrod>
and sometimes for easier designs of particular programs, that's C++
<netbsduser>
gcc exists within the living tradition of unix and they cannot escape it
* mcrod
high five Griwes
<heat_>
Griwes, totally
<heat_>
i think the big mistake is that C++ never got, say, "profiles"
<Griwes>
that's called "just use a subset"
<mcrod>
i'm embedded, and we've been talking about using C++
<Griwes>
though freestanding is currently getting more teeth
<heat_>
yes, but that's hard to restrict and keep track, and that's exactly what linus et al have complained about in the future
<mcrod>
and we actually might pull the trigger
<Ermine>
I'm a bit embedded now too
<mcrod>
but, and this is what I was saying last night to someone
<netbsduser>
Ermine: this is what -fwrap-v is for i'm sure
<mcrod>
there's a generational thing here
<Griwes>
and I fully expected that to spill over into the core language with things like actually blessing -fno-exceptions
<mcrod>
a) embedded is, and will probably always be almost entirely dominated by C
<heat_>
they made "Kernel C", but it's somewhat hard to keep track of that. they don't want to make "Kernel C++", because the language is much bigger and harder to keep track of "usable" bits
<mcrod>
b) at least at my company, the people that I work with are much older whereas I am younger, and using C++ might as well be like asking them to look at the sun until they go blind
<Griwes>
so you'll eventually get a "profile" of C++ that's a subset that's suitable for kernel and embedded work + some of the flags we all use being blessed
<mcrod>
generally speaking throughout my travels the younger generation is more likely to adopt C++ in places where C had a stronghold
<mcrod>
like, embedded
<Arsen>
i have no flags that let me pretend code isn't broken
<heat_>
Griwes, how did -fno-exceptions get blessed?
<Arsen>
such as -fwrapv
<mcrod>
and in embedded, we will absolutely use -fno-exceptions and -fno-rtti
<mcrod>
no dynamic dispatch
<Griwes>
it did not yet get blessed, but I see that at the end of the current freestanding journey
<mcrod>
no dynamic memory allocation at ALL, AT ALL, *AT ALL*
<Griwes>
so far the work was focused on getting as much of the stdlib guaranteed in freestanding, and it's being done by embedded people
<netbsduser>
Arsen: that's accusing kernighan and ritchie themselves of writing broken code
<Arsen>
so be it
<Ermine>
netbsduser: yes, gcc devs have a point in that thread (and OP is known for not doing proper error checking to reduce binary size), but the fact is that new version broke the compilation
<mcrod>
no multiple inheritance either
<mcrod>
templates, yes
<Arsen>
how does M-I change anything over just I
<Ermine>
We have our firmware in C and I'll retire if it gets rewritten in C++ tbfh
<mcrod>
bullshit complexity that would be introduced
<netbsduser>
Ermine: regardless of that, it can't have broken linux for long; they must have rectified the situation
<Arsen>
what complexity?
<Arsen>
it acts precisely the same
<Arsen>
in fact, the only way I know of single inheritance rules is as special cases of multiple inheritance ones
<heat_>
Griwes, but at some point they'll hit a roadblock won't they? unless they, say, change containers, std::function, etc to not allocate in ctors, and possibly return expected<> on member functions that do allocate
<netbsduser>
when you break a little trinket program's code, that might be the fault of the trinket's author, but when you break your top customer's code, it's your fault and you've got to fix it
<heat_>
and that'll be a PITA
<Ermine>
netbsduser: linux has a load of flags btw
<Griwes>
multiple inheritance itself is fine, what's not fine is virtual base classes
<Arsen>
that.. also changes nothing?
<mcrod>
ultimately none of the technical aspects are imporant with regards to embedded
<mcrod>
it's not important (read: it is)
<mcrod>
the central core is getting people on board without balking at first sight
<Griwes>
heat_, the goal isn't to get everything, most allocating things probably will never be in the guaranteed freestanding subset
<netbsduser>
Ermine: so do i
<mcrod>
and that's.. a people problem
<heat_>
mcrod, use -fno-strict-aliasing btw
<netbsduser>
fwrapv, fno-strict-aliasing, etc
<mcrod>
we wouldn't do that :p
<Arsen>
use -fmore-strict-aliasing
<Griwes>
std::function is almost certainly out, use std::function_ref
<heat_>
strict-aliasing has had horrendous bugs for many many years
<mcrod>
the moment I'd add those flags, I'd get pushback because I'd be breaking the standard
<heat_>
with no fixes!
<Griwes>
Arsen, with virtual base classes, you need rtti and runtime offsets for downcasting
<heat_>
on both gcc and clang
<Griwes>
it's a mess
<Arsen>
ah, right, I forgot about that
<mcrod>
i've been tasked with trying to move us to gcc
<Arsen>
heat_: like what?
<mcrod>
which, no problem
<Griwes>
without virtual base classes you're fine, because you can cast in all directions with constant offsets
<Ermine>
mcrod: sometimes you can have real-time requirements, like do shitload of stuff in like 100 microseconds
<epony>
C++ it's happening don't ask Jan11 2252<FreeFull> Why not port Linux to Obj-C?
<mcrod>
Ermine yes
<mcrod>
we don't have strict shit like that, but we MUST meet certain deadlines
<mcrod>
or bad things might happen to people's money
<epony>
and not by no arsed men
<mcrod>
the reality is though, I get why fno-strict-aliasing and such exist