gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
netbsduser has quit [Ping timeout: 252 seconds]
gog has quit [Quit: byee]
lentement has joined #osdev
m5zs7k has quit [Remote host closed the connection]
lentement has quit [Ping timeout: 260 seconds]
npc has joined #osdev
m5zs7k has joined #osdev
sbalmos has quit [Quit: WeeChat 4.2.1]
sbalmos has joined #osdev
Arthuria has joined #osdev
<adder>
Is it ok for now that panic be just "hlt"?
npc has quit [Remote host closed the connection]
<heat>
sure
<mjg>
people like to add an infinite loop "just in case"
<adder>
Okay. What else needs done before going long?
<heat>
oh yeah you totally need an infinite loop due to NMIs
<heat>
oh, you need interrupts and paging
zxrom has quit [Quit: Leaving]
<mjg>
the loop may get optimized away
<heat>
interrupts as in IRQs and a device that generates them
<mjg>
there is some magic to prevent the compiler from doing it
<heat>
no it can't, __asm__ __volatile__("hlt") can't be optimized out, re-ordered, etc
<heat>
it has side effects
<mjg>
i mean a mere while (1) { }
<zid>
(asm statements without clobbers are already volatile)
<mjg>
after hlt
<heat>
oh that's silly
<zid>
clobbers means "I am telling you how to reorder this"
<heat>
for (;;) { hlt; } makes sense, because of NMIs
<zid>
so it makes total sense to me
<mjg>
's literally what people write in my experience
<heat>
hlt; for(;;); is basically "hlt; then at the first sight of an interrupt burn CPU forever"
<heat>
btw C can't eliminate an infinite loop, C++ can
<heat>
zid, fwiw i slap volatile on almost all asm statements i have, for precaution
<zid>
in case
<zid>
the compiler forgor
<zid>
do you write signed int everywhere too, in case it forgot that
<heat>
i don't know tricky inline asm rules by heart
gildasio has quit [Remote host closed the connection]
<heat>
i know int = signed int because its programming 101
<zid>
I mean, you needed to look up the volatile keyword and what it did to begin with, not hard to learn "makes things with clobbers act like things without"
gildasio has joined #osdev
<zid>
instead of whatever the fake thing you learned
<mjg>
heat: you may be right for that one, i'm gonna hvae to think after i wake up
junon has joined #osdev
<junon>
I'm trying to get a barebones in aarch64 running, and I'm a little confused about the MMIO PL011 device I'm targeting for QEMU. Everything works fine on the primary core. But when I use Limine's smp request/response to have the secondary cores jump to the entry point, the PL011 just... stops. I've eliminated the spinlocks and everything on the aarch64 implementation just to test, and eliminated
<junon>
all serial logs except for one where it checks the explicit core ID for one of the secondaries and nothing happens. This code runs fine on x86_64 (albeit with a different serial driver), and logging otherwise works perfectly fine for the primary core. Is there something I'm missing about multicore aarch64 and memory mapped devices (or perhaps specifically the PL011, perhaps more specifically
<junon>
the one QEMU uses) being usable across cores? Or is this a case where it should work and it's probably something else?
<junon>
I even tried re-initializing it on the other core and it still does nothing.
<junon>
I've verified (to the extent I can) that execution jumps to the trampoline and attempts to output via the gdb stubs inside of qemu (with -s -S) and have printed out some of the surrounding locals to make sure it wasn't something with the stack getting mangled.
<heat>
this sounds like some other problem, corruption maybe
<heat>
since this is QEMU this can't really be a caching issue, the pl011 works across cores
<junon>
Should I be DSB/DMB-ing after interacting with the pl011?
<junon>
Oh you said can't be caching.
<junon>
I might ask the Limine folks too if I can't find anything out of the ordinary, will have to investigate a bit more tomorrow first though. Maybe there's something with the SMP mechanism they have that screws something up.
<junon>
Thanks for the answer heat, at least I can rule out that concern :)
<heat>
np. caching isn't really a thing in qemu tcg, and KVM would trap/vmexit because the PL011 is an emulated QEMU device
<heat>
the complicated memory attribute stuff should essentially be a no-op
<junon>
right, makes sense. The MMIO bits on a real system would still need memory barriers though, yeah?
<heat>
cuz they're not real. if you had a real device attached in a KVM instance (say, you're doing passthrough of your GPU), then caching, memory barriers, DMA coherency and all that would matter
<heat>
yeah
<heat>
i mean, you shouldn't need it in this case
<junon>
Good to know, thanks. And yeah, I already thought it might be something else but I just wanted to double check I wasn't missing something fundamental about aarch64.
<junon>
Thanks again :) I'll keep at it.
<heat>
the ARM ARM talks about this kind of stuff in excruciating detail. you don't need barriers/fences for MMIO unless you're doing interleaved writes to different devices, because then the CPU can re-order those at will
<heat>
you can also need memory barriers if you're doing DMA and DMA on that platform is non-coherent, but that's a whole different problem
<heat>
note: MMIO here implies some sort of device-nGnRnE or similar mapping
<heat>
device-nGnRE is IIRC more common but a more relaxed version of device-nGnRnE because it allows early write acks
<junon>
Makes complete sense, also learned something new about ARM :D Cool that you can specify memory op behavior at that granularity. Coming from x86_64 I believe we only have the no_cache flag, unless I'm missing some other thing the MMU can do.
<heat>
x86_64 has uncacheable, write-combining, writeback, write-protect and some slight variations
<junon>
So if something is marked device-nGnR[n]E then memory barriers aren't required whatsoever, right?
<heat>
writethrough!
<heat>
they may be needed, it depends. but my memory is hazy, i haven't looked at this in a while
<junon>
Right okay. Cool stuff, thanks for the info :)
<heat>
i believe the ordering only applies to the exact device, which is why sometimes you need dma coherency barriers even with the proper device-nGnRE stuff
<heat>
but, again, RTFM, it's too much info and i'm in no way a domain expert
<junon>
ahh I see what you mean
<heat>
also keep in mind that having multiple mappings of the same memory with different attributes is IIRC mega UNDEFINED
<heat>
but, uhh, this shouldn't be biting you atm, because its qemu tcg
<heat>
does PL011 stop working on the boot CPU too? if so, i'd advise you to hang the secondary CPUs at the first instruction and see if the PL011 is working or not. if not, it's probably some limine bug
<junon>
let me double check.
<junon>
works fine.
<junon>
Yeah everything is fine there. I just need to break into one of the secondary cores and poke around a bit and figure out what's not working. If all else fails, I'll go talk to the Limine folks.
<junon>
But for now, sleep :D thanks again heat, really appreciated!
<heat>
np :)
junon has quit [Quit: and awayyyy]
netbsduser has joined #osdev
Arthuria has quit [Ping timeout: 256 seconds]
Terlisimo has quit [Quit: Connection reset by beer]
<mjg>
so i'm reading reviews of online fragrance shops, got another one selling fakes
<mjg>
let's say individuals are not happy
<mjg>
i would paste it but none of it is in english
netbsduser has quit [Ping timeout: 240 seconds]
<geist>
mjg: question: what do you think about irix
<mjg>
:]
<mjg>
so there was a day when irix source code fell of the truck
<mjg>
and i had a look to check what it is
<mjg>
4.1 something i think?
<geist>
yah i guess it never got released
<geist>
they got up to irix 6.x i think
<mjg>
anyway *that* code was total crap
<geist>
IIRC it was always BSD based, they didn't do a rebasing of svr4
<mjg>
if you are asking smp-wise
<geist>
no i'm just trying to direct your ire equally to everything
<mjg>
they rolled with usual unix lunacy in the areas i looked at
<mjg>
dude what did i NOT shit on?
<mjg>
systems-wise
<geist>
looks like irix 4.0 was 1991
<mjg>
ops
<mjg>
it is 6.5.5
<geist>
1998
<mjg>
i don't know if there is anything newer
<mjg>
there was an aix 4.1.3 i also found after it fell of the truck
<mjg>
crossed my wires on version numbers
<geist>
according to wikipedia by 2001 they were activiely moving support to other stuff
<mjg>
i thought you are asking because there are people who think it was THE SHIT numa or smp wise
<geist>
nope
<geist>
i was shit posting
<geist>
this is the sort of thing that pops into my head when i'm shopping at the grocery store: i should see what mjg thinks about irix
<geist>
i do remember that some of the gnarly big sgi boxes were really hard to deal with cache coherency wise
<geist>
MIPS 8000 i think in particular
<mjg>
ye i think about the roman empire
<geist>
something like you had a large SMP box with VIVT. oh joy!
<mjg>
(or is that meme stale already?)
<mjg>
all these fuckers are weirdly inefficient in the vfs layer
<mjg>
like for real
<mjg>
for example they start with refing the root vnode, the op being lock-protected, twice
<mjg>
and then ofc you have to backpedal
* geist
throws up
<mjg>
slow af single-threaded and avoidable bottleneck
<geist>
if only those stupid idiots were born in the 2000s
<mjg>
dude this was always bad
<mjg>
you don't need any rcu fuckery to not have the problem
<geist>
it's like when i look at Turing and the first computers. turing machine? come on is he stupid?
<geist>
geez
<mjg>
mon
<mjg>
:]
<geist>
didn't he know c#?
<geist>
cripes
<mjg>
i'm not complaining about the first car being crap
<mjg>
i'm complaining about a car which has exhaust pipe directed into the interior
<geist>
haha
<mjg>
it's literally a problem which should not be there
<geist>
threre was a fun UNIX v6 thread at work the other day where the in kernel putchar() outputs two ESC (0177) after every CR
<geist>
and no one knows why, but the theory is that early teletypes you needed to output two dummy characters while the head of the teletype went back to column 0
<geist>
otherwise it'd print the next character while it's winding back
<mjg>
folks in tuhs should be able to answer that
<mjg>
i mean in the worst case know who to ask
<mjg>
you wait maybe 10 years and there will be no first-hand witnesses ;)
<geist>
well, i mean that's almost certainly what it is, but it was fun posting it on an internal chat and seeing if anyone had any idea what a teletype is
<geist>
it's an Olds nerd snipe
netbsduser has joined #osdev
<mjg>
did you get a spiel how vt100 was the shit and the macbook screens don't have squat on it?
<mjg>
real boomers shit on everything new
<geist>
hmm, no. i *do* get how a vt terminal is a pleasing thing to look at. my vt320 looks lovely
<geist>
though honeslty i havne't looked at a real vt100 in some time. but i remember it being okay
<Mondenkind>
geist: reminds me of how reset has a sleep(1) to this day
<geist>
but personally i like green or orange monitors, and vt100s i think were always white?
<Mondenkind>
for a similar reason
lentement has joined #osdev
<geist>
for some reason i have a fixation on Xenix
Terlisimo has joined #osdev
<mjg>
ey geist
<geist>
i will get it installed on a real machine some day, but it's always picky about my hardware i have
<mjg>
what software project can you honestly shit on?
<geist>
ipod
<mjg>
cop out answer
<geist>
alas it's not open source, but the ipod source is *terrible*
<geist>
like the worst shipping thing i had ever seen
gbowne1 has quit [Quit: Leaving]
<geist>
when i worked at apple i had to deal with it and it was impossible to tell you how badly written and poorly maintained it was *and yet* it made billions of dollars
<mjg>
no relationship between quality and success is pretty well known
<mjg>
if anything they are negatively corelated
<geist>
indeed. a good lesson to learn in the industry
<geist>
the programmer in you wants to make good quality stuff, the world wants you to get it out the door in an acceptable fashion
<geist>
the two rarely line up
lentement has quit [Ping timeout: 256 seconds]
<mjg>
what really matters is marketing and/or dirty trickery like sneaking the product in with unrelated progs
<mjg>
it's how internet explorer won for a time
<geist>
yup
<mjg>
also people just don't know there is a choice
<mjg>
it's how the office won
<mjg>
:]
<mjg>
haha, i googled for that fake fragrance shop some more
<mjg>
found one site with reviews, almost all positive, clearly fake just like products they sell
<mjg>
then found some more, dude claims there are several fake shops all ran by the same person
<mjg>
run
<mjg>
unfortunately he did not list names
<mjg>
i guess this concludes my attempts at not using established chains
netbsduser has quit [Ping timeout: 260 seconds]
<mjg>
of
<geist>
:(
<geist>
but but aliexpress always sells geniune stuff!
gorgonical has joined #osdev
<gorgonical>
I think I'm gonna lose my mind if I try to fully understand the Linux DMA/IOMMU layers
<gorgonical>
Actually incomprehensible
<gorgonical>
I had the idea to look at the original driver code and wouldn't you believe it, it actually makes sense!
<gorgonical>
What a mess this driver is now
<geist>
:(
<gorgonical>
I get why it has to be this way
<gorgonical>
I at least feel better knowing that I have a clear argument for why my research was warranted in the first place
<gorgonical>
specialized kernel -> simple code -> more secure, still with functionality
netbsduser has joined #osdev
netbsduser has quit [Ping timeout: 264 seconds]
netbsduser has joined #osdev
neo|desktop has joined #osdev
xvmt_ has joined #osdev
tomaw_ has joined #osdev
Gooberpatrol_66 has joined #osdev
xvmt has quit [Read error: Connection reset by peer]
randm has quit [Ping timeout: 268 seconds]
xvmt_ is now known as xvmt
slow99 has quit [Ping timeout: 268 seconds]
ecs has quit [Ping timeout: 268 seconds]
Reinhilde has quit [Ping timeout: 268 seconds]
neo has quit [Ping timeout: 268 seconds]
Gooberpatrol66 has quit [Ping timeout: 268 seconds]
raggi has quit [Ping timeout: 268 seconds]
kof673 has quit [Ping timeout: 268 seconds]
Stary has quit [Ping timeout: 268 seconds]
raggi has joined #osdev
randm has joined #osdev
j00ru has quit [Remote host closed the connection]
j00ru has joined #osdev
slow99 has joined #osdev
ecs has joined #osdev
Stary has joined #osdev
Ellenor has joined #osdev
tomaw has quit [Ping timeout: 633 seconds]
tomaw_ is now known as tomaw
zetef has joined #osdev
netbsduser has quit [Ping timeout: 264 seconds]
zetef has quit [Remote host closed the connection]
zetef has joined #osdev
zetef has quit [Client Quit]
zetef has joined #osdev
Yoofie has quit [Read error: Connection reset by peer]
kof673 has joined #osdev
Ellenor is now known as Reinhilde
zetef has quit [Ping timeout: 264 seconds]
netbsduser has joined #osdev
bliminse has quit [Quit: leaving]
bliminse has joined #osdev
netbsduser has quit [Ping timeout: 240 seconds]
lentement has joined #osdev
zetef has joined #osdev
lentement has quit [Ping timeout: 268 seconds]
kfv has joined #osdev
kfv has quit [Read error: Connection reset by peer]
kfv has joined #osdev
kfv has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
netbsduser has joined #osdev
kfv has joined #osdev
GeDaMo has joined #osdev
<kof673>
re: the gui stuff the other day, i know nothing about these things, just knoppix always had something > knoppix 6.0 Adriane - A genuine masterpiece - Dedoimedo www.dedoimedo.com › computers › knoppix-adriane Jan 30, 2009 · Adriane is friendly. This is the first distro that I know of that has a screen reader enabled by default
<bslsk05>
www.dedoimedo.com: Dedoimedo - A Place to Learn a Lot About a Lot
<kof673>
even more amazing, a link is still up after 15 years?
<vykt_>
And when trying to access say, 0xAABBCC, the LAPIC references the internal table instead and doesnt reach out to cache/ram?
<Mutabah>
the MADT just tells you what address to use to reach the LAPIC
<kazinsal>
the LAPIC address is the same on all logical processors
<Mutabah>
(by default - I believe that some CPUs allow you to move the LAPIC by editing a MSR)
<kazinsal>
generally
<gog>
yeh
<Mutabah>
And yes - an access to the LAPIC doesn't leave the CPU core (doesn't go to RAM/bus)
<kazinsal>
the MADT defines stuff like mapping logical processor IDs to LAPIC IDs
<vykt_>
ohhh i see ok
<vykt_>
tysm
<gog>
and so you can tell the bootstrap cpu's LAPIC to wake up its siblings
<kazinsal>
imo the IOAPIC sucks and is garbage you should never have to deal with if you strategically work out your interrupts
netbsduser has joined #osdev
<kazinsal>
MSI/MSI-X through your LAPICs makes life so much easier
<gog>
it's best to configure as much as possible to be MSI
<kazinsal>
anything high performance/low latency is going to do MSI/MSI-X
<kazinsal>
anything that doesn't isn't going to be significantly impacted by 8257 PIC emulation
<kazinsal>
8259*
<vykt_>
MSI?
<Mutabah>
Message Signalled Interrupt
<kazinsal>
eg. I'd personally run anything faster than a 10BASE-T NIC with MSI/MSI-X but a serial port isn't going to go any faster than 112500 baud regardless of your interrupt method
Arthuria has joined #osdev
<kazinsal>
MSI is great. the device writes a magic value to an address on the bus that the interrupt controller latches onto, then interrupts the CPU on a programmed vector. MSI-X makes it nicely parallel by allowing you to map MSI vectors to different processors
<bslsk05>
'Be afraid, be very afraid!' by KazakhdaRusski (00:00:05)
lentement has joined #osdev
lentement has quit [Ping timeout: 268 seconds]
Arthuria has joined #osdev
xenos1984 has joined #osdev
zxrom has joined #osdev
Arthuria has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
xenos1984 has quit [Quit: Leaving.]
xenos1984 has joined #osdev
xenos1984 has quit [Ping timeout: 252 seconds]
xenos1984 has joined #osdev
FreeFull has joined #osdev
zetef has joined #osdev
clever has quit [Ping timeout: 260 seconds]
clever has joined #osdev
gog has quit [Quit: Konversation terminated!]
op has quit [Remote host closed the connection]
<zid>
no idea
op has joined #osdev
op has quit [Remote host closed the connection]
gog has joined #osdev
zetef has quit [Ping timeout: 272 seconds]
simpl_e has joined #osdev
<gorgonical>
kernal outside in the warm spring
dude12312414 has joined #osdev
xenos1984 has quit [Killed (NickServ (GHOST command used by xenos19841!~mhohmann@193.40.12.10))]
xenos1984 has joined #osdev
xenos1984 has quit [Ping timeout: 252 seconds]
Cindy has joined #osdev
<Cindy>
hiii
<Cindy>
nikolapdp: apparently the lookup table method was slower
<Cindy>
24,074,565 opcodes per second for the ifs and switches method, while 21,463,569 opcodes per second for the lookup table method
bauen1 has quit [Ping timeout: 252 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
nur has quit [Remote host closed the connection]
xenos1984 has joined #osdev
<nikolar>
Cindy yeah I could've imagine
<nikolar>
You'd need to optimize it further
<GeDaMo>
Cindy: what's this for?
<mjg>
lookup table as in indirect jumps?
<Cindy>
mjg: yes
<Cindy>
GeDaMo: emulator
<mjg>
that's slow af
<Cindy>
nikolar: i do
<mjg>
what are you if'ing on?
<GeDaMo>
Ah
<Cindy>
mjg: patterns of bits in a opcode
<Cindy>
similar to how a CPU would decode a opcode
<Cindy>
but i'm planning to implement a cache
<Cindy>
for decoded instructions
<Cindy>
to gain an extra performance boost
<mjg>
how many do you have to check for?
<Cindy>
mjg: depends on the first 4 bits of the opcode (aka operation code)
<mjg>
so the indirect jump is grossly slow
<mjg>
however, plausibly it can speed up if you align targets to 16 or more
<Cindy>
yes
<Cindy>
and i literally gave it a easier job than the ifs and switches method
<Cindy>
the ifs and switches method had to loop over the possible 65535 combinations there are
<mjg>
if you have a big enough if-maze it is going to start winning at some point ofc
<mjg>
the jump method
<Cindy>
and the big lookup table only had to loop over a constant stream of instructions
<mjg>
anyway this is just advice from before 2010 or so
<Cindy>
2 move instructions and a branch instruction
<mjg>
where jump tables were all the rage for memset et al
xenos1984 has quit [Quit: Leaving.]
<Cindy>
anyway
<Cindy>
a cache for decoded instructions will greatly speed it up
<mjg>
what cpu are you emulating?
<Cindy>
m68k
<mjg>
klassik innit
<mjg>
call me when you do an itanium emulator running on m68k instead
<Cindy>
i had a set of rules while making the emulator
<Cindy>
like, no dynamic allocation
xenos1984 has joined #osdev
<Cindy>
the structure for the m68k instruction has a enum type
<Cindy>
and a union of all the field structures of all the instructions
<Cindy>
of the instructions*
<Cindy>
and no pointer cast at all
<Cindy>
i can cast values, but no casting pointers
<acidx>
of the tricks people usually use in language interpreters to reduce instruction dispatch, I think that the one that will probably help an emulator like this the most is creating superinstructions for sequences of 2, 3, or 4 instructions that usually happen in sequence, especially if they could be optimized together
<mjg>
fusing uops? :)
<acidx>
kinda
<Cindy>
i've intentionally seperated the executor and decoder components
<Cindy>
so i can decode blocks into blocks of decoded instructions
<Cindy>
and the executor can run over those, maybe with more performance boost because of cache locality
<acidx>
another thing that can be done is a simple jit that only emits calls to functions implementing instructions. that's easy to do for runs of arithmethic things for instance.
heat has quit [Ping timeout: 272 seconds]
heat has joined #osdev
<acidx>
(it's a bit harder if there's control flow involved, either because of a branch/jump in that sequence, or if the sequence is the target of some jump.)
<Cindy>
acidx: i don't wanna do JIT because that involves dynamic memory allocation
<Cindy>
well
<Cindy>
at least not on the same coded
<Cindy>
i would make a JIT version, and a regular interpreter version
<acidx>
a pattern matcher that tries to find common instruction sequences might be useful for some sort of HLA emulator too. like you recognize an unrolled memcpy() that a compiler emitted, and you replace the whole thing with an actual call to the native memcpy()
<acidx>
that's a whole lot harder to do though. but it's kinda fun once it starts working because you can start spotting a lot of stuff like that. :)
<Cindy>
lol
<Cindy>
you know that a part of my emulator is having to also reimplement the system's C library
<acidx>
if you have access to a symbol table then it can probably do quite a bit of thunking
<Cindy>
for the programs that are dynamically linked to that
<Cindy>
you know
<acidx>
why would you have your emulator run a m68k strlen() when you can run a native strlen()? :P
<Cindy>
this is a HLE emulator
<Cindy>
consider it like a program running in a fake OS environment
<acidx>
yeah, so plenty of opportunities to do stuff like this then
<Cindy>
it expects there be a C library hooked up to a TRAP vector
<Cindy>
and that library has a memcpy
<Cindy>
and if it doesn't have memcpy
<Cindy>
then it crashes
<Cindy>
no m68k version :P
bauen1 has joined #osdev
deckard has quit [Quit: l8r]
deckard has joined #osdev
spare has joined #osdev
ski has quit [Ping timeout: 260 seconds]
ski has joined #osdev
gbowne1 has joined #osdev
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
rsjw has quit [Quit: leaving]
spare has quit [Remote host closed the connection]
zetef has joined #osdev
kfv has joined #osdev
kfv has quit [Client Quit]
goliath has joined #osdev
lentement has joined #osdev
Left_Turn has joined #osdev
lentement has quit [Ping timeout: 264 seconds]
<heat>
mjg, you're grossly slow
<sham1>
He's just old, give him some slack
<heat>
PESSIMAL HUMAN
<mjg>
are you ok heat
<mjg>
did you "optimize" with an indirect jump somewhere?
<heat>
i have plenty of indirect jumps like a good VFS has
<mjg>
do you mean func pointers
<heat>
correct
<mjg>
cause you know, cntezt here is kind of different
<mjg>
they are slow af regardless
<sham1>
Why not have an abstract base class? I thought you're in C++
<heat>
some parts of my kernel are more C-like, others are more C++-like
<heat>
i used C++ classes and virtual functions to good effect in my network stack, but the VFS is very C-like
<heat>
that is to say, OOP but with C
<sham1>
SMH my head. Do you even SFINAE?
<heat>
no i do not
<heat>
you can SFINAE my ass
<sham1>
I can't substitute anything with that
<heat>
you sure? ( ͡° ͜ʖ ͡°)
<sham1>
Very
<heat>
jokes aside, C++ abstract classes have a distinct disadvantage: you can't replace the vtable at runtime
<heat>
also hard to do certain stuff like using function X from class A and function Y from class B
<heat>
without multiple inheritance at least, and screw that tbh
<sham1>
Out of curiosity, where is the vtable-replacement useful in your VFS
<sham1>
Because to me it feels like you don't necessarily have the right design pattern
<gog>
kornal
<heat>
device files
<heat>
pipes!
<sham1>
Sounds to me like you'd want some strategy pattern
<heat>
VfsStrategyFacade
zetef has quit [Remote host closed the connection]
linearcannon has quit [Ping timeout: 246 seconds]
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
spare has joined #osdev
linearcannon has joined #osdev
linearcannon has quit [Ping timeout: 268 seconds]
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
rustyy has quit [Ping timeout: 268 seconds]
wgrant has quit [Ping timeout: 272 seconds]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 268 seconds]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 272 seconds]
spare has quit [Remote host closed the connection]
<mjg>
16375 remove SPARC kernel makefiles
<mjg>
end of an era!
<mjg>
(illumos)
<heat>
someone should remove illumos
<heat>
from the world
linearcannon has joined #osdev
<heat>
hey elon this new rocket is going to mars, it's powered by the last copy of illumos in the world, do you want to go too?
<heat>
two birds, one stone
lentement has joined #osdev
linearcannon has quit [Ping timeout: 268 seconds]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
lentement has quit [Ping timeout: 268 seconds]
Vercas9 has quit [Ping timeout: 260 seconds]
linearcannon has joined #osdev
Vercas9 has joined #osdev
linearcannon has quit [Ping timeout: 268 seconds]
rustyy has joined #osdev
<Ermine>
wat
Left_Turn has quit [Read error: Connection reset by peer]