<heat>
we could live in a world of limited unlimited extensibility
<geist>
i dunno, in the twenty something years i've been here no one has ever spoken ill of solaris until recent
<zid>
because nobody cares about it
<geist>
at least not consistently. i remember some grumblings about having to administer a bunch of them
<zid>
(because it's bad)
<mjg_>
geist: in my youth i used to follow pl.comp.os.advocacy
<geist>
but the general idea was they're fairly solid machines at the time
<geist>
if not pricey
<mjg_>
geist: non-linux systems, most notably oslaris, kept being shat on a lot
<geist>
yeah which is IMO lame. shitting on things is like level 1 discussion
<zid>
we were all too busy shitting on windows previously
<geist>
anyone can do it, it's what people do when they have nothing else to do
<geist>
or anything more interesting to contribute
<mjg_>
point being it was spoken ill of
<heat>
haha m$ windoze bad
<mjg_>
heat: high school me would shit on windows a lot man
<geist>
oh yea i was talkinga bout in *here*, as in osdev
<zid>
developers developers develoeprs
<mjg_>
geist: oh ok
<geist>
and yeah i participated in shitting on windows a lot back in the 90s too
<geist>
M$FT was the bad guys
<heat>
ballmer's peak was wrong all along because he used coke, not alcohol
<geist>
microsloth winblowz, etc etc
<mjg_>
$ sign mandatory
<geist>
was of course part of the reason i joined up with Be and worke don BeOS
<geist>
down with microsoft!
<mjg_>
f-you bill
xenos1984 has quit [Read error: Connection reset by peer]
<heat>
how many beekeepers have tried to hire you over the years
<heat>
"you worked with bee? yeah we work with bees a lot here"
<geist>
i like bees
<geist>
i'd like to keep some bees
<mjg_>
bees? geez
<geist>
bees are good
<kof123>
"anyone can do it, it's what people do when they have nothing else to do" eh, i always wonder where did these ppl work as CEO and management where their word got to choose what is used? i always put them in "noob" category until further evidence lol
<heat>
hmmm idunno man
<heat>
they sting
<geist>
kof123: oh heh there's no requirement you know what you're doing when you're a CEO
<kof123>
really, there's a sysadmin company, running the show?
<kof123>
not dictated by application requirements?
<heat>
except pat gelsinger
<heat>
and lisa su
<geist>
I guess what i was really making a point is i pride myself a but on this channel at least having a more ... refined discussion of these opics
<zid>
that's why mjg is ceo of poland!?
<geist>
topics. shitting on things is easy but doesn't bring anything to the table
<heat>
and the man himself mr leather jacket
<geist>
unless it's reasoned and interesting
<kof123>
the wise man will find magical osdev powder in dos, while the fool will not believe it exists in plan9
<kof123>
change to suit tastes lol
<heat>
i find the plan9 circlejerk mildly annoying
<zid>
when am I allowed to dereference pointers to structs with incomplete members in normal C though
<mjg_>
geist: well, modulo certain language choices, i'm pretty sure i can make a solid case for solaris not living up its scalability hype even when adjusted for whatever time period
<zid>
godbolt needs to add plan9 so I can try it
<mjg_>
:>
<geist>
yah it has generally speaking gone away. the plan 9 thing was super strong in the late 90s/early 2000s
<geist>
mjg_: sure but then so what?
<geist>
well i mean it's okay, just trying to balance things a bit
<mjg_>
another me, not familiar with solaris, but familiar with the hype, would find it of interest
Matt|home has joined #osdev
<heat>
solaris in 2000 scaled better than net or openbsd right now
<heat>
osdev hottakes
<mjg_>
than open? probably true
<geist>
yeah it's basically different expectations
<geist>
also nothing else ran on the same hardware at the time, so in general you needed solaris to get advantage of the hardware you bought (some bigass sparc box)
<geist>
so there was nothing to compare it with
<geist>
ergo it was more scalable than anything else on the same hardware
<geist>
since it was a sample size of 1
<zid>
It was the worst OS though
<zid>
slowest, largest install, biggest memory footprint
<zid>
most crashy
<geist>
that's not generally what i remember folks saying at the time
<mjg_>
geist: you could still aks if it was making good use of it, which would be answerable with a profiler :>
<mjg_>
you doing your 20% in marketing dept ?:)
<geist>
in general i remember it being expensive to own the hardware but if you needed it you needed it
<zid>
sadly it was also the fastest, smallest install, least memory footprint, and least crashy
<zid>
via that same sample size
<geist>
and then you put what ran on it because that's what you did. you couldn't directly compare it
<geist>
oh heh okay i get your point zid
<mjg_>
i don't know if the old time solaris was stable
<geist>
i mean i dont know why i'm defending 90s era solaris, i just generally believe it wasn't terribad at the time, and it's a bit unfair to judge things back then based on modern ideas
<mjg_>
i definitely give them props for cming up with dtrace
<mjg_>
not necessraily dtrace as it came out, but a productoin quality instrumentation framework
<mjg_>
years before linux
<mjg_>
which already had way more manpower
<geist>
hell go back to the mid 80s. there were MP machinse that were AMP. by definition that's terrible by todays standards
<heat>
haha ebpf go brrr
<kof123>
well i think tehre was also (right or wrong) bsd linux etc. are hobbies and not Real Enterprise Unix (TM)
<zid>
asymmetrical multipajillion dollar servers
<mjg_>
geist: 2010 solaris was also crap, so... :)
<kof123>
*perception that
<geist>
mjg_: i'm fairly certain by the late 2000s solaris had peaked. i'm not interested in defending that era solaris
<geist>
it was aready dead by then
<mjg_>
kof123: ye there was also a lot of shitting of REAL UNIX admins on the linux and bsd crowd
<geist>
the rigor mortis started setting in in the mid 2000s, especially x86
<heat>
communist unix >> enterprise unix
<geist>
i'm thinking more back in the 90s when it was The Solaris that ran on big sparc boxes
<zid>
communist unix is my favourite unix
<heat>
those damn socialists with their GPLv2 and their patch sharing and their pansy-ass forking
<geist>
i think it's only really fair to compare it up to the point at which it peaked and then from then on out it was not catching up
<geist>
and i'm not sure it ever ran that well on x86. aways a problem for things that lived on non x86 then had to switch to it at the last minute. aside from maybe OSX that almost never works
<mjg_>
geist: i do note there were claims of > 100 thread scalability in mid 2000s or so
<geist>
okay fine. i've said my peace
<mjg_>
and i said mine
<geist>
why i'm defending this i dont know. i really dont care about solaris much at all
<heat>
life is about conflict
<geist>
anu more than AIX or HPUX or TRU64 or whatnot
<heat>
red vs blue, linux vs bsd, solaris vs mjg
<geist>
haha
<mjg_>
would be fun to get an old commerical unix operational
<mjg_>
and bench
<geist>
i mean like i could run solaris 2.7 on my sparcstation 20
<heat>
you know there are unixware images out there
<geist>
works okay.
<mjg_>
imagine booting the different systems which support, say, vax
<mjg_>
and bench them
<mjg_>
:)
<geist>
sure.i have a microvax, it runs things
<geist>
i have a VMS install and a netbsd install
<zid>
Nobody bought me a pencilcase with the xeon logo on it again this year
<geist>
answer is: it's hella slow
<zid>
try again next year
<mjg_>
i have no clue about vms
<geist>
but thats what 1990 era machines were
<mjg_>
is there a way to write a bench which would be fair vs unix?
<geist>
depends on what you're trying to bench
<geist>
and probalby not, not
<geist>
and probalby not, no
<mjg_>
say open, reading and closing a file
<heat>
we've established that isn't fair
<mjg_>
vs vms?
<heat>
(see winblows)
<mjg_>
well ye, part of it would be finding out what profilng tooling is avaiable (if any)
<heat>
microshit winstupid was designed by the same guy
<geist>
it'd probably be slower i suspect. but then it also depnds on what unix you compare it with. may be that VMS is actually more clever about caching
<mjg_>
and getting said profile
<mjg_>
mroe interesting than whatever numbers come out
<geist>
i mean if you run a mid to late 80s unix you're not exactly going to be in the same ballpark as modern stuff
<heat>
did you see the sysv unix profiling article i posted a few weeks back?
<mjg_>
geist: i guess a fun test wold be just syscall performance
<geist>
ie, filesystems were generally intriniscally synchronous, etc
<mjg_>
heat: i don't think so
<geist>
so it's possible VMS would actually do better, since t had a big iron journalled fs, etc
<mjg_>
do you know what would be a dirt cheap syscall to call?
<mjg_>
a'la getpid, getuid etc
<geist>
yeah but what's the point of doing that? you're just testnig the hardwares ability to syscall?
<mjg_>
you don't think the way systems implement it may affect perf?
<geist>
not when the systems are wildly different
<geist>
what if, for example, syscalls were 20% more expensive on system A than B, but system A's syscalls allow you to make 50% less of them to accomplish the same task
<mjg_>
i don't buy that bit for a bare minimum syscall (so to speak), provided one exists
<geist>
most likely the only really interesting benchmarks on two wildly different systems are high level things, like some database's ability to serve data, etc
<bslsk05>
ieeexplore.ieee.org: A performance study of the UNIX® System V fork system call using CASPER | Nokia Bell Labs Journals & Magazine | IEEE Xplore
<heat>
here's the cute profiling system they got
<geist>
sure i mean you can test the bare minimum syscall but it's such a microbenchmark it doesn't really mean much except to establish the baseline for the cost of a syscall
nyah has quit [Quit: leaving]
* kof123
.oO( sees a MISS metric, millions of syscalls/second )
xenos1984 has joined #osdev
* kof123
.oO( that was sarcasm, second geist's comments )
<mjg_>
geist: well the problem with somerthing bigger is that you can easily argue that the software at hand does not utilize the sytsem in an optimal manner
<mjg_>
and so on
<geist>
in the case of comparing unices i think the syscall stuff makes more sense, because yo can generally assume that between any two unix oses the number of syscalls is roughly equivalent
<mjg_>
basically anyhting non-trivial is a huge problem to compare
<geist>
i mean i'm all for benchmarks. you just have to be careful what you read out of em. i think when comparing linux systems or even linux to bsd or whatnot it is a fairly level playing field, so folks have gotten used to the notion that any benchmark is valid
<mjg_>
did they?
<mjg_>
most benchmarks happen to bei nvalid :p
<geist>
but i've also seen microbenchmarks misused constantly, so i'm always aware of making sure the context is fully known
* mjg_
glares at phoronix
<geist>
sure. ie, bad benchmarks
<geist>
but... you did at least get me interested in how fast my vax can context switch, but most likely since it's a low end vax from the late 90s, it's slow as hell
<geist>
much like if you go to say a 386 or 486 and read the cycle count for things you'll be aghast compared to modern stuff
<geist>
one did not generally use IPC as a number, it was CPI
<mjg_>
you reminded me of alpha
<mjg_>
in my youth i heard running i386 binaries on it would kick ass
<mjg_>
excellent claim to test
<heat>
i heard running i386 binaries on itanium would kick ass
<heat>
excellent claim to test
<geist>
yes alpha no itanium
<mjg_>
i never heard anyeone sayanything positive about itanic
<mjg_>
maybe apart frmo it being gone now
<heat>
new 64-bit architecture by intel? more low level so compilers can take advantage of it? what can go wrong
<geist>
the x86 emulator on alpha DEc had written was fantastic. and since early alphas came out the gate really kicking ass they had the headroom
<gog>
it was a cool architecture with good ideas
<mjg_>
so that was real?
<mjg_>
sounded highly suspicious
<geist>
itanium had native x86 compatibility for a few revisions, but it was dreadfully slow
<kof123>
are you guess talking alpha nt running x86 stuff, or for other os?
<geist>
i think more useful for running bioses and whatnot
<heat>
the itanium manual says we'll stop using 4KB pages in a few years
<klange>
> mjg_ glares at phoronix
<klange>
I miss the days when Larabel wrote articles about my OS.
<geist>
yes i've personally seen it. NT for alpha could run x86 binaries, and it did it quite well
<mjg_>
klange: ? :DD
<heat>
oh shit re: phoronix do you want to see the clickest bait article
<bslsk05>
www.phoronix.com: Linux TUN Network Driver May See A "1000x Speedup" With New, One-Line Patch - Phoronix
<mjg_>
heat: the clickbait is from the commit though
<mjg_>
so not his fault on this one
<geist>
"hey i'm just passing the clickbait on!"
<klange>
mjg_: He wrote three articles - in 2014, 2016, and when 1.0 was released in 2017, and they were all quite nice! And he took his own screenshots so I know he actually used it.
<mjg_>
klange: well let me tell you one anecdote real quick
<mjg_>
klange: i was hanging out on #dragoflybsd and prodded dillon about something, then he did it that evening or so
<mjg_>
klange: soon after there was a phoronix article claiming dillon reacted to *their* feedback
<mjg_>
:)
<heat>
and as you and dillon made fun of both phoronix and openbsd, you and him locked eyes, the love was in the air, as you started passionately making out
<kazinsal>
I like reading Phoronix's benchmarks for new CPUs because they tend to be wildly different from other benchmarks because most of their testing software is so terribly specific that the benchmarks end up being meaningless
<heat>
ok fuckers, a real osdev question now
<heat>
how do you effectively quarantine memory in an allocator
<zid>
free it
<gog>
quarantine as in it might contain sensitive information?
<kazinsal>
"hmm yes I'm going to get the new Ryzen 6969X instead of the Intel i9-1337KF because it's 2% faster at LZMA decompression" said no one ever
<zid>
I thought he meant badblocks it
<heat>
quarantine as in "avoid giving it back to the caller as much as possible"
<heat>
for ASAN
<gog>
kazinsal: i was saying because it's 2% faster at LZMA
<kazinsal>
>:(
<gog>
heat: least recently used
<heat>
yea but what's the heuristic
<gog>
idk
gxt has quit [Remote host closed the connection]
<heat>
you know, maybe you could do something stupid like using up 64-bit virtual memory and avoiding reuse until you really needed to
epony has joined #osdev
<heat>
but then shadow memory is an issue, hmm
<gog>
no use as little of the address space as possible
<gog>
never map anything
<heat>
i know that's a joke but it's genuinely the objective eventually
<heat>
just use the direct map and an allocator based on friendship
<gog>
yes
<heat>
or comradery if you're in commie unix
<gog>
worker threads of the world unite
<pounce>
heat: don't think you'd need a heuristic for this
<pounce>
just write the empty page table entry with a quarantine flag
<heat>
what empty pte
<heat>
i give out chunkz in alloc()
<heat>
i get chunkz back in free()
<heat>
i want to avoid giving back the same chunk(z) in alloc while not increasing memory usage by a shitton
<mjg_>
avoid or postpone
<pounce>
err, is this malloc?
<heat>
yes-ish
<heat>
slab
<pounce>
ahhh
<pounce>
sorry thought virtmem
<heat>
but the point stands for any allocator
<heat>
well, i can play around with virtual memory
<heat>
that's the nice part about am become the kernel, the destroyer of worlds
<mjg_>
free to a dedicated bucket
<mjg_>
and dn't alloc from it
<mjg_>
when the time comes you need a newb ucket to alloc from, pick oldest unused free bucket
<mjg_>
as your new alloc bucket
<pounce>
heat: do you only care about sequential alloc() free() alloc()? when would you be ok about getting the memory back
gxt has joined #osdev
<heat>
when i really need to
<pounce>
and you would rather fragment first?
<heat>
but then again i could probably get to allocate some pages from the allocator and keep the memory quarantined in a kasan build
<gog>
just grow the heap's vm size forever
<gog>
pick random addresses in the heap
<heat>
yes
<pounce>
you could map the heap's physical mem to multiple virtmem locations
<heat>
as i was saying, that's not a bad idea
<pounce>
and then always give out the subsequent location
<gog>
yes balloon your page tables
<pounce>
:p
<heat>
like if I had the guarantee the slab is at least 8*page_size sized, this would easily work
<gog>
give all your applications huge pages
<heat>
free slabs would get freed and the virtual memory would remain delay-freed, and its shadow backing would get replaced by a page full of "FREED" bytes
<pounce>
this sounds like a skill issue
<pounce>
why not just stop reusing pointers
<heat>
great idea
<heat>
this will never be an issue if you never reuse anything
<heat>
unlimited memory ftw
<pounce>
sorry, I've run out of useful ideas :p
<gog>
i don't have useful ideas
<gog>
i'm a cat
* pounce
pounces
<heat>
ah ok the comrades seem to have a 1MB quarantine size + a percpu 1MB quarantine
<heat>
idea being that kmem_cache_free "frees" objects to this quarantine which sit until you actually free them
<heat>
due to the q overflowing or memory getting tight
dennisschagt has quit [Quit: No Ping reply in 180 seconds.]
dennisschagt has joined #osdev
* moon-child
pets gog
MiningMarsh has joined #osdev
<klange>
Okay, binutils cross-built... gcc, though, is missing a few things...
<klange>
Going to need to get libstdc++ built, in particular - I removed it from my normal toolchain a long time ago, since none of my own stuff was C++ :)
<klange>
> /bin/bash: ../libtool: No such file or directory
<klange>
whyyy
<klange>
how did you fail to produce a libtool for this...
valerius_ has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<klange>
why the !@#$ do i have ilp32 multilib builds enabled for my aarch64 stack, I don't use that shit...
<klange>
and then none of it works
<geist>
yeah i get the vibe that ilp32 is not getting that muh love
<CompanionCube>
isn't aarch64 ilp32 just armv7?
<CompanionCube>
(renamed to aarch32, of course)
gildasio has quit [Ping timeout: 258 seconds]
gildasio has joined #osdev
gxt has quit [Ping timeout: 258 seconds]
<klange>
I think I will just... not block the 2.1 release on having gcc for aarch64 packaged, because ugh. I'll revisit this later. It's not like these aarch64 builds are useful on real hardware, so having an independent compiler toolchain isn't high priority - you want to code, use Kuroko.
gxt has joined #osdev
<klange>
I'll finish package SDL1.2 + sdlquake, the doomgeneric build, and maybe dash (which I just packaged for x86-64)... I'll see if mupdf builds later this afternoon as well...
gog has quit [Ping timeout: 250 seconds]
mavhq has joined #osdev
gxt has quit [Ping timeout: 258 seconds]
gxt has joined #osdev
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
scoobydoob has joined #osdev
scoobydoo has quit [Ping timeout: 240 seconds]
scoobydoob is now known as scoobydoo
bgs has joined #osdev
epony has quit [Ping timeout: 252 seconds]
<geist>
CompanionCube: no not at all. it
<geist>
it's the arm64 instruction set but with all the addreses limited to 32bit. just like x32 or whatever people call it
<geist>
but the ARM64 ISA is definitely different from arm32/thumb2
epony has joined #osdev
bgs has quit [Remote host closed the connection]
Burgundy has joined #osdev
<CompanionCube>
geist: wait there's genuine toolchain support for that? huh
<CompanionCube>
i knew it was a thing but i would have thought 'ilp32' was something more common
<klange>
And unfortunately it seems to be enabled by default 'cause I know I didn't specifically include it when configuring my aarch64 targets...
<klange>
Maybe it's time for a full toolchain update...
<CompanionCube>
the only other time i heard of 'x32 for aarch64' was a unmerged patch to support it on linux like x32 is supported
<klange>
I am on gcc 10.3, which was outdated almost immediately after I started using it because 11 came out
<geist>
yeah we've talked about it a bit for fuchsia from time to time, but i think clang/llvm has some work
wand has quit [Ping timeout: 258 seconds]
Burgundy has left #osdev [#osdev]
<CompanionCube>
seems kernel still doesn't do it, and i don't think glibc does either
<geist>
yah not sure it's getting a lot of love. may not be as big of a win as x32 (if x32 is that much of a win)
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
<klange>
I did a reconfig with --disable-multilib and I seem to have been successful in building libstdc++, and now my cross-compiled compiler build also looks to be progressing...
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
m5zs7k has quit [Ping timeout: 250 seconds]
m5zs7k has joined #osdev
wand has joined #osdev
gxt has quit [Ping timeout: 258 seconds]
<klange>
I tell this to build shared... and I swear these are all still statically linked to libstdc++ and... ugh. whatever
<klange>
I blame libtool, probably sitting there saying it doesn't know how to do that...
<klange>
Well that was a pain in the ass, but we got there in the end!
<klange>
It did not install any of the crts or libgcc but that's probably my fault, so I just copied them from the host build, and I did need to do one other thing to get gcc to build for an aarch64 host - tell it to include driver-aarch64 which it only does by default on linux/bsd/fuchsia (lol)
<klange>
(despite calling a function in that that isn't guarded behind the same conditions)
gxt has joined #osdev
ChinUndercover has joined #osdev
GeDaMo has joined #osdev
scoobydoob has joined #osdev
gog has joined #osdev
scoobydoo has quit [Ping timeout: 240 seconds]
scoobydoob is now known as scoobydoo
<geist>
ooooh so you are running with arm64 ilp32?
<klange>
no, I am not
<klange>
but it wanted to build for it by default anyway, among other issues
ChinUndercover has quit [Ping timeout: 272 seconds]
gorgonical has quit [Remote host closed the connection]
Burgundy has joined #osdev
epony has quit [Ping timeout: 252 seconds]
Rubikoid has quit [Ping timeout: 260 seconds]
kof123 has quit [Quit: Leaving.]
epony has joined #osdev
Rubikoid has joined #osdev
hmmmm has joined #osdev
gildasio has quit [Remote host closed the connection]
<klange>
packages uploaded, minor changes pushed, cdn cache purged
gildasio has joined #osdev
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
fatal1ty has quit [Read error: Connection reset by peer]
epony has quit [Remote host closed the connection]
epony has joined #osdev
epony has quit [Max SendQ exceeded]
epony has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
Matt|home has quit [Ping timeout: 272 seconds]
epony has quit [Client Quit]
epony has joined #osdev
gog has quit [Quit: byee]
fatal1ty has joined #osdev
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
gildasio has quit [Remote host closed the connection]
Ram-Z has quit [Ping timeout: 272 seconds]
[itchyjunk] has joined #osdev
epony has quit [Remote host closed the connection]
epony has joined #osdev
Ram-Z has joined #osdev
gildasio has joined #osdev
pbx is now known as pbx_linux
pbx has joined #osdev
<pbx>
hello all :)
<pbx>
sending this from my OS
<zid>
neat
<pbx>
my TCP implementation is still pretty half-assed, but aparently good enough to join an IRC room
<j`ey>
pbx: ping
<fatal1ty>
he`y
<j`ey>
hi
<pbx>
does look like it drops some messages on the floor, but that might be the crappy client
eroux has quit [Ping timeout: 272 seconds]
<zid>
channel :P
<pbx>
specifically can't see j'ey's messages
<zid>
haha
<zid>
test
<zid>
I wonder if it's the backtick
<j`ey>
pbx: wait actually?
<pbx>
yeah
<j`ey>
happy to be a test case
<pbx_linux>
test
<pbx_linux>
test 1'2
<zid>
doesn't respond to ctcp either
eroux has joined #osdev
<zid>
:bob!bob@bob.com PRIVMSG #osdev :testing for this specific parse bug
<zid>
non-greedy parsers can fall for that one occasionally
<pbx>
seems like theres definitely some flaking going on
<zid>
missing random messages, j`ey just happened to trigger them by chance?
<pbx>
can't imagine it actually being in the TCP as that would probably result in desynchronization entirely
<pbx>
i think so yeah
<pbx>
although there's definitely parsing weirdness too
<pbx>
(i quickly ported irc.c, a very simple curses irc client)
<bslsk05>
linux.die.net: mcedit(1) - Linux man page
<heat>
see, this is why i use gnu nano
<heat>
fuck your weird editors
<heat>
i'm too young for crippling-depression-caused-by-an-editor
<gog>
i have too much crippling depression caused by other sources to be depressed about my text editor
<clever>
somebody i know has recently gotten into linux, after his all-in-one nas died and you cant access the data without a replacement of the same model
<clever>
he got stuck in vim while i was away, and :q didnt exit, because he had unsaved changes
<clever>
first time somebody i know has gotten stuck in vim, lol
<gog>
i tap escape reflexively in all my text editors
<heat>
:wq gang baby
<clever>
heat: he eventually found :q! on his own
<gog>
i tried to install vsvim but it doesn't work with vs2022
<gorgonical>
it drives sda/scl low when the interrupt flag is set to pause the transaction and let you process. you clear the flag by WRITING ONE back to the control register
<gorgonical>
NOT ZERO???
<heat>
that's not that weird
<heat>
usually there's a good reason for ti
<gorgonical>
i have never seen such an abominable design
<gorgonical>
before
<heat>
ahci interrupts is an example that comes off the top of my head
<heat>
its so you don't lose interrupts in AHCI's case
<gorgonical>
Is the idea that you must write a 1 intentionally?
<gorgonical>
That is, you cant write a zero from e.g. a cached configuration?
<heat>
yes
<gorgonical>
it makes more sense but i am still very angry
<heat>
if 0 cleared it, read(reg), reg &= ~handled; write(reg) could lose interrupts in between
FreeFull has quit []
<mxshift>
W1C is very very common
<klange>
Since my editor is largely a clone of vim (though not really an implementation of vi, my operation syntax is a bit different), it naturally has the same exit pattern, and can also be exited in fun ways such as abusing the fact that the command input mode parses Kuroko, so you can do it to the python-y way and `:import os; os.kill(os.getpid(), 9)`
<heat>
import os; os.kill(os.getpid(), 9) is p y t h o n i c
<klange>
:qa! is still the better choice, though
<heat>
but it's not p y t h o n i c
<klange>
(which, of course, also works in vim as `:py3 import os; os.kill(os.getpid(), 9)`)
<heat>
actually, it's not pythonic
<heat>
the pythonic solution would be an obtuse one-liner