klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
<zid`> about spending 80 hours figuring out a bitflip in pipe()
<heat> there's an internal channel of people that really like linux's network stack
<heat> and i love that
<zid`> yea I remember one of their blog posts being about the linux stack.. a couple of times
<zid`> some seq sequence rollover bug or something?
thinkpol has quit [Remote host closed the connection]
thinkpol has joined #osdev
<heat> there are a lot of network stack posts
Burgundy has quit [Ping timeout: 240 seconds]
<bslsk05> ​blog.cloudflare.com: Please Wait... | Cloudflare
<zid`> yea there's a bunch of good ones, I liked this one
<heat> yeah I linked that one here
<zid`> Did you study it as homework for your interview
xenos1984 has joined #osdev
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
<heat_> luv me router
<heat_> no, i'm not touching the network stack
<heat_> i'm on the cloudflare workers runtime team
heat_ is now known as heat
<heat> basically workers takes a bunch of untrusted javascript or web assembly and runs it in cf's edge servers
<mrvn> https://godbolt.org/z/zEzGMrz5K Couldn't I do this without the `T` in List?
<bslsk05> ​godbolt.org: Compiler Explorer
<heat> so you can run your service in every cf datacenter, no need for your own server
<heat> it's pretty cool
floss-jas has joined #osdev
toluene has quit [Ping timeout: 244 seconds]
<heat> and *thankfully* I won't be touching JS ;)
heat has quit [Remote host closed the connection]
genpaku has joined #osdev
gog has joined #osdev
psykose has quit [Ping timeout: 272 seconds]
psykose has joined #osdev
Vercas has quit [Quit: Ping timeout (120 seconds)]
Likorn has quit [Quit: WeeChat 3.4.1]
Vercas has joined #osdev
toluene has joined #osdev
gorgonical has quit [Quit: Client closed]
gog has quit [Ping timeout: 248 seconds]
psykose has quit [Remote host closed the connection]
psykose has joined #osdev
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
MiningMarsh has joined #osdev
gorgonical has joined #osdev
smeso has quit [Quit: smeso]
smeso has joined #osdev
koolazer has joined #osdev
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
terrorjack has joined #osdev
<Jari--> hi all
<mrvn> Can one make std::construct_at a friend of a class so it can call a private constructor?
<Jari--> make it global ;-]
<mrvn> the std::construct_at?
<Griwes> why are you trying to make construct_at be able to call a private constructor?
<mrvn> So you can construct an instance on the heap
<mrvn> std::make_shared()
<Griwes> so you want *some* of the clients of the class to be able to invoke that constructor through stdlib functions? possibly just the class itself?
<mrvn> the class itself, static member function calling make_shared
<Griwes> okay, there's another way
<mrvn> Foo *foo = new Foo(5); return std::shared_ptr<Foo>(foo);
<Griwes> you make the ctor itself public, but accept a private type as one of its arguments
<mrvn> That's a stupid hack and has overhead. :)
<Griwes> then only specific users can invoke it, as if it was private, but you can invoke it through stdlib wrappers
<Griwes> lol.
jjuran has quit [Ping timeout: 256 seconds]
jjuran has joined #osdev
<mrvn> Griwes: While I don't need it here can you make the same thing work with making construct_at a friend function instead of struct key?
<Griwes> I don't know, I don't think you can reliably do it since you can't depend on specific function overloads of stdlib functions
<Griwes> but if you make construct_at a friend, you may as well make the constructor public because it would be public at that point
<mrvn> It should be as simple as copying the function definition and adding friend.
<Griwes> you can't reliably know what the signature of stdlib functions are
<Griwes> sd-8 tells you that if you depend on it, you don't get to complain if your code breaks because a stdlib or the standard change
<mrvn> Should still work right now.
<mrvn> I tried adding a template specialization for construct_at too and making that friend. But it doesn't even get used.
<Griwes> trying to do things with function specializations is bound to cause you more pain than anything else
<mrvn> but so much fun
_xor has joined #osdev
bradd has quit [Remote host closed the connection]
xenos1984 has quit [Read error: Connection reset by peer]
bradd has joined #osdev
vdamewood has joined #osdev
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
MiningMarsh has joined #osdev
xenos1984 has joined #osdev
<Jari--> good brains wasted on migraines
<Jari--> its over now
<Jari--> TempleOS developer I heard had some similar symptoms
bauen1 has quit [Ping timeout: 240 seconds]
wand has quit [Remote host closed the connection]
FatAlbert has joined #osdev
wand has joined #osdev
the_lanetly_052 has joined #osdev
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 255 seconds]
<kazinsal> RTX 3080 go brrrrrrrrr
<kazinsal> actually it goes more "whooooosh". way quieter than my 1080 Ti was
<Jari--> hmm
<klange> Other things in the vicinity of my desk are far louder and I don't really notice the sounds of my 1080 FE.
<kazinsal> yeah, even with max fan speed my server and layer 3 switch are much louder
<Jari--> In my opinion, VirtualBox should scale, stretch, the view.
<klange> Host key + C will switch to scaled/stretched.
Likorn has joined #osdev
Vercas has quit [Quit: Ping timeout (120 seconds)]
Vercas has joined #osdev
eroux has joined #osdev
bauen1 has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
_xor has quit [Ping timeout: 256 seconds]
_xor has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
gog has joined #osdev
pie_ has quit []
vancz has quit []
xenos1984 has quit [Read error: Connection reset by peer]
vancz has joined #osdev
pie_ has joined #osdev
bauen1 has quit [Ping timeout: 246 seconds]
Goodbye_Vincent has quit [Quit: Ping timeout (120 seconds)]
Goodbye_Vincent has joined #osdev
GeDaMo has joined #osdev
xenos1984 has joined #osdev
<FatAlbert> is experimenting with os stuff that can potentially break the OS best than in containers ?
<FatAlbert> s/than/done
<mrvn> no, that's boring
<FatAlbert> the only problem i have with that approach is that containers are not really full OS'es
<mrvn> they aren't oses at all. they are containers
<FatAlbert> but i guess that bare minimum will do for explroing OS stuff at least funtionality wise
pretty_dumm_guy has joined #osdev
<mrvn> editors aren't OSes too if we are listing things that aren't OSes
<FatAlbert> editors ARE os'es what you talking about ?
<FatAlbert> i have a full IDA PRO license for free
<FatAlbert> mrvn: ^
<FatAlbert> it's an OS
<FatAlbert> mrvn
<FatAlbert> mrvn:
<FatAlbert> mrvn:
<FatAlbert> mrvn:
<kazinsal> pinging someone five times in as many minutes is not a good way to make them want to interact with you
<kazinsal> just a pro IRC tip
<kazinsal> slash human interaction tip
<FatAlbert> kazinsal: it's a punishment for being an asshole
<dminuoso> 11:15:20 mrvn | editors aren't OSes too if we are listing things that aren't OSes
<dminuoso> mrvn: emacs users would disagree with you here.
<dminuoso> :>
<kazinsal> also not a good way to win you any friends
<FatAlbert> kazinsal: you are under the impression that i need frinends
<FatAlbert> why is tat ?
<FatAlbert> dat
<FatAlbert> i don't
<FatAlbert> i gave up on this idea on the age of 13
<FatAlbert> im flying solo
<kazinsal> it is a figure of speech
<dminuoso> Surely someone here has administrative powers to remove this hostile troll.
<FatAlbert> dminuoso: you have the power with /ignore add <name here>
<FatAlbert> if you don't like what i have to say yo ucan ignore it in two ways:
<kazinsal> pretty much the wrong time zone in general for someone around who has buttons I think
<FatAlbert> 1. read my messages and ignore them ..
<FatAlbert> 2. read my second last statement before rule 1
vancz has quit [Read error: Connection reset by peer]
pie_ has quit [Remote host closed the connection]
<FatAlbert> kazinsal: i think deep inside i never gave up on the idea of friendship
<FatAlbert> infact .. i never give up
<FatAlbert> in a sense ..
jafarlihi has joined #osdev
<FatAlbert> the only circles that im being accepted is with gays and in the peace core .. both communities which im scared to death with
<FatAlbert> so im still solo
<kazinsal> good news, I'd wager half of the modern tech sphere is gay
<kazinsal> be careful or we might infect you
<kazinsal> the infosec sphere is also primarily gay *and* furries
<FatAlbert> it's not going to happen
<FatAlbert> im staying strong
zaquest has quit [Remote host closed the connection]
<kazinsal> (it's impressive, a bunch of my friends' customers who they build fursuits for are in infosec)
<GeDaMo> All the colours of the rainbow :P
<kazinsal> I was over at their house the other night having a few beers and one of them handed me a fursuit head
<kazinsal> put the thing on and it was actually surprisingly comfortable
<kazinsal> decent airflow, alright vision although I had to take my glasses off
zaquest has joined #osdev
<FatAlbert> kazinsal: ok quiet
<kazinsal> neat little plastic hinge mechanism attaching your jaw to the fursuit head's jaw so really emotive talking moved the jaw
<FatAlbert> are you sure they didn't try the reverse bear trap on you ?
<kazinsal> I joked that if I rebuilt their website I'd accept a discount on one if I could hang out behind the table with them at some cons
<FatAlbert> you should be careful who you socialize with .. an advice that i myself need to embrace but in my desperation ...
<kazinsal> so now I'm poking around at building a new website for a fursuit studio
<FatAlbert> GeDaMo: mute him
<kazinsal> I've known these cats for like, 20+ years, they're some of the best people I've ever hung out with
<FatAlbert> he's way pass the wierdness of this chat
<kazinsal> anyways I've spent probably a decade and a half in this IRC if you count the freenode era
<FatAlbert> geist: mute him
<FatAlbert> hallo !?
<kazinsal> and a lot of the people who run this place are not straight
<kazinsal> so take your weird shit elsewhere
<FatAlbert> geist: ???!?!?!?!?!?!?!?
<FatAlbert> ok im going
<kazinsal> this is and always has been an inclusive space
FatAlbert has quit [Quit: WeeChat 3.5]
<kazinsal> fuck that was fun
<FireFly> ..wat
<kazinsal> nothing better than literally recounting my tuesday evening to troll a homophobe out of an IRC channel.
<dminuoso> Okay, so has anyone attempted to run emacs on bare metal?
<dminuoso> (Trying to shift the focus back on *serious* topics)
<mrvn> obviously
<kazinsal> emacs seems like waaaay too much of a mess to run on bare metal
<kazinsal> at least, gnu/emacs
<kazinsal> I'm sure you could probably reimplement classic TECO macro set emacs on top of bare metal
<mrvn> be sure to write systemd.el
<kazinsal> but considering gnu emacs is a combination of a bunch of things including a whole lisp virtual machine and a bunch of crazy gnu stuff I would not consider it bare metal portable
<dminuoso> Really? Id say that makes it bare metal portable in the first place. Your kernel just needs to provide the exact lisp functions that emacs needs.
<kazinsal> once upon a time the gnu/emacs build system involved "core undumping"
<dminuoso> (The kernel being the C-shell around emacs)
<klange> I think the preferred term was "unexecing"
<kazinsal> it was, yeah
<kazinsal> imo, "core undump" conveys a deeper sense of "oh no, that doesn't sound right at all"
<GeDaMo> There's an Emacs for DOS, presumably that wouldn't need much support
<jjuran> mrvn: You probably want to define construct_at() for your type in the same namespace in which the type is defined, and rely on two-phase lookup.
<jjuran> For generic code, you can preced with `using std::construct_at;` so both will be candidates.
<jjuran> *precede
<jjuran> Extending std:: is usually UB
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
heat has joined #osdev
<heat> >fursuit
<heat> >I've known these cats
<heat> hehehehehehe
<mrvn> the squirrels will be pissed for not getting metnioned.
<kazinsal> I should ask them if they've ever done a squirrel fursuit
<bslsk05> ​en.wikipedia.org: Squirrel Girl - Wikipedia
<heat> sooo i've recently learned that freebsd also does weird stuff with processes and threads and rfork() so it works similarly to linux and nptl and clone(2)
<mrvn> rfork?
<heat> makes me wonder if it's actually a totally valid idea
<bslsk05> ​www.freebsd.org: rfork(2)
<heat> comes from plan9, it's pretty old
<heat> they even have a clone(2) emulation that uses rfork
<heat> like in reality do people really need the fine-grained sharing stuff
<mrvn> do you really need more than pthread_create and posix_spawn?
<heat> seems so
<heat> well, you need fork at least
<mrvn> what for?
<heat> creating processes
<mrvn> That's what posix_spawn is for
<heat> and/or doing the classic fork() server strategy
<heat> posix_spawn is limited
<mrvn> ok, you neede daemonize too
<kazinsal> rfork seems to be a rather bizarrely implemented system call for "create a new thread, and often other stuff too"
<heat> in fact, I would say any spawn() function is inherently limited
<mrvn> Although with systemd that's kind of dying out.
<heat> kazinsal, see: clone(2)
<kazinsal> eg rfork(NULL) seems to fork a new thread
<kazinsal> whereas rfork(FRPROC) forks a new process
<mrvn> heat: if you give users too many options then they will stgart abusing them.
<heat> passing NULL for an int should be a war crime
<mrvn> NULL could be an int
<heat> yes, it's valid C
<heat> still against the geneva convention
<kazinsal> I'm assuming rfork without RFPROC means "create thread" since it literally means "fork execution but the changes affect the current process"
<mrvn> it's valid either way. pointer or int. But NULL can be an int
<kazinsal> so it's either "fork thread" or "do absolutely nothing"
<heat> even microsoft doesn't defend spawn() anymore
<kazinsal> also it looks like rfork is a bsd backport of a plan9 thing, hrm
<heat> kazinsal, "The flags argument iseither RFSPAWN orthe logical OR of some subset of"
<mrvn> HTTP request sent, awaiting response... 403 Forbidden
<kazinsal> thus ends my quasiauthoritative knowledge
<heat> mrvn, weird, looks good here
<kazinsal> so I guess rfork(RFTHREAD) is the formal call for "create thread"
<mrvn> are you in de?
<heat> no
<kazinsal> seems weird for "create process" and "create thread" to be the same syscall with different int flags
<heat> does video game censorship affect process creation whitepapers now? :P
<mrvn> heat: imagine the chaos it would cause if US papers could be read outside the US. Oh no.
<heat> kazinsal, that's how it works on most modern UNIXes
<heat> mrvn, i'm in portugal, not the US
<heat> there's no geoblocking at play here
<heat> kazinsal, fyi, for more insanity: linux's clone syscall's signature is different from the library function clone()
<mrvn> like half the syscalls
<heat> the library clone is thread-oriented (you even give it a function pointer)
<heat> the syscall is a fancy fork
<heat> if you want the fancy fork, you use syscall()
<heat> also for even more insanity: the libc writers need to do special hacks in assembly so vfork() can be entirely defined
<heat> and IMO it's still not entirely defined because who knows what the compiler is doing
<heat> (reminder: never use vfork() in not-C)
jafarlihi has quit [Quit: WeeChat 3.5]
dennis95 has joined #osdev
<heat> mrvn, anyway, if you could read the paper (pretty weird you're getting a 403), you'd see they discuss multiple alternatives to fork, like posix_spawn/CreateProcess and cross-process operations
<heat> but the underlying tone is that spawn() is limited and thus not a full fork replacement
<heat> personally I think that cross-process operations (like Fuchsia) is a super interesting option
<heat> more flexible at the very least
Burgundy has joined #osdev
pie_ has joined #osdev
vancz has joined #osdev
pie_ has quit [Ping timeout: 256 seconds]
vancz has quit [Ping timeout: 256 seconds]
Matt|home has quit [Ping timeout: 258 seconds]
vancz has joined #osdev
pie_ has joined #osdev
foudfou has quit [Remote host closed the connection]
sympt3 has joined #osdev
sympt has quit [Ping timeout: 260 seconds]
sympt3 is now known as sympt
foudfou has joined #osdev
<ddevault> getting closer
<ddevault> my ISRs work in kernel space but GP fault when returning to userspace
<j`ey> so EFLAGS was the issue?
<ddevault> yeah, it was part of the issue for sure
<Jari--> retrying chat
<heat> ddevault, how does your stack look before iret?
<ddevault> that's what I'm looking into now
<ddevault> what confuses me is the stack looks wrong even when it does work
<gog> stacks always look weird
<gog> but if it looks wrong even when it's working maybe you have a sneaky problem there
<ddevault> nevermind, I was reading the stack fine
<ddevault> wrong*
<ddevault> it was fine
<gog> oh good :þ
<zid`> if you read that kaomoji do you get "thrrhrhhhhpppp"
<gog> yes
<ddevault> hrm
<ddevault> the cs on the stack when iretq is run is 0, not 8
<zid`> that's good
<zid`> cus 8 is ring0 in most setups
<ddevault> right
<zid`> were you the pmode guy?
<mrvn> but 0 is the null segment iirc
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
<ddevault> I am not the pmode guy, at least so far as I'm aware
<zid`> so this is long mode?
<zid`> oh I guess so with iretq actually
<ddevault> and yeah, I would expect cs to be 0x10
<ddevault> for userspace
MiningMarsh has joined #osdev
heat has quit [Read error: Connection reset by peer]
<zid`> there's some weirdness with long mode where usermode doesn't actually give a shit about setting some selectors to 0
<zid`> I forget exactly how it works
heat has joined #osdev
<ddevault> or... 0x13? wut
<zid`> 13 yes
<heat> cs should be 0x1b
<zid`> it should be 0x23 fite me
<heat> syscall will fite u
<ddevault> in any case, it's set to 0 on the stack when the interrupt fires
<heat> s t a c k c o r r u p t i o n ?
<zid`> I have.. cs=23, es/ss/ds = 1b
<ddevault> I highly doubt that this is stack corruption
<zid`> dunno if that's backwards
<heat> zid` sucks, I want zid back
<ddevault> let me see what it looks like when the ISR begins, rather than ends
<heat> zid would have cs = 1b
<zid`> well it works
<zid`> and has always workied
<heat> cringe
<zid`> I think that's because compat mode is not used so I get to shift down by 1 set or something? idk
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mrvn> SASCALL/SYSRET needs the cs/ds in the proper order
<ddevault> my sysret works fine
<heat> actually I feel stupid now
<heat> i'm on 0x28 and 0x30
<heat> :(
<zid`> get rekt
<mrvn> cs32/ds32?
<zid`> and is 23 the compat mode cs?
<heat> I have NULL - Kernel CS - Kernel DS - 32 bit user CS - 32 bit user DS - User CS - User DS - TSS
<zid`> I have.. null, kcs, kdata, udata, ucs
<zid`> cus I am weird apparently
<zid`> I have no idea if I intentionally put them that way around
<heat> knowing you, you probably did that just to fuck with people
<ddevault> ah, my kernel was interrupted during a syscall, not userspace
<ddevault> that explains cs being weird
<ddevault> still no closer to an answer, though
<zid`> I don't enable interrupts during a syscall yet, sounds scary
<ddevault> I have ruled out stack corruption
<ddevault> well, I also get a GP fault when the interrupt occurs in userspace
<zid`> (I don't wanna write all the code for figuring out how many swapgs to do)
* ddevault shrugs, disables interrupts in syscalls
<ddevault> well, actually
<ddevault> how else am I going to get reports about kernel faults
<zid`> They start disabled
<heat> traps work with interrupts disabled
<zid`> exceptions are NMIs aren't they
<heat> traps are not interrupts as far as I understand it
<ddevault> ah
<heat> you can disable NMIs and the I flag and you'll still have them
<zid`> I think that's what the NM stands for :P
<heat> you can disable NMIs tho :)
<ddevault> okay, so I have disabled interrupts in syscalls and the behavior is the same (except that the interrupt only ever comes from userspace)
<heat> in the CMOS
<ddevault> but I may as well leave them disabled for now
<heat> code?
<zid`> soo.. how's your TSS looking?
<ddevault> I had that thought as well, let's see
<ddevault> this interrupt does not have IST set, for a start
<ddevault> which makes sense that it's still on the same stack
<ddevault> this is long mode btw
<zid`> rsp0 gets loaded from the TSS in an IRQ
<zid`> also what's your fault like? pf? gp?
<zid`> etc
<ddevault> gp
<zid`> error code, decoded address?
<ddevault> error code 16
<ddevault> decoded address?
<zid`> as in, what does the address mean
<ddevault> cs:rip is 0x8:0xffffffffc0024235
<ddevault> which is the location of the iretq
<zid`> and that's the iretq from the syscall, or from the irq?
<ddevault> the latter
<ddevault> my syscalls use syscall/sysret
<zid`> error code 16 means selector 0x10
<zid`> 0 means not selector related and "could be any fucking thing" :P
<heat> it can also mean "null selector" afaik
<zid`> right, 0 means not "positive selector value related" :P
nick64 has quit [Quit: Connection closed for inactivity]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat_ is now known as heat
xenos1984 has quit [Read error: Connection reset by peer]
qubasa has quit [Remote host closed the connection]
eroux has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
xenos1984 has joined #osdev
<ddevault> I wonder if my %ss is not being set correctly when entering userspace
<ddevault> I don't think that makes sense, how would my syscalls be working correctly ordinarily if this were not correct
<zid`> because the syscall abi doesn't use the user stack
<zid`> ss only matters if you do pushes in usermode
<ddevault> well, I have a working stack in usermode
<ddevault> in any case, messing with IA32_STAR causes the gp fault to occur in the same place, but with different error codes, which is suggestive
<ddevault> definitely do not understand what I'm supposed to put in this MSR
<zid`> lemme see what I do
<bslsk05> ​github.com: Onyx/cpu.cpp at master · heatd/Onyx · GitHub
<zid`> star has 8<<32 | 10<<48, LSTAR has syscall_handler
<ddevault> thanks, heat
<zid`> and my cs selectors are 8 and.. 0x20
<ddevault> USER32_CS, is that for compatibility mode?
<zid`> I think it adds 16 to the latter or something?
<zid`> yea compat mode
<zid`> I don't have those so mine are probably lower than heat's
<ddevault> can I see your GDT, heat
<ddevault> page 232 of AMD manual vol 2
<ddevault> I think I need to reverse my user cs and ss in my GDT because sysret sets cs to the STAR value + 16 and ss to + 8
blockhead has quit []
<ddevault> which is the reverse of the kernel mode selectors it uses
<ddevault> this is dumb -_-
<ddevault> why didn't I stick with riscv64
<zid`> yea it's weird that they decided to hardcode this in weird ways
<Mutabah> x86_64 keeps the x86 tradition of having some good ideas, and others that make you go "dafuq?"
<zid`> like, why have a bizzare offset, surely it's *more* work to add a random value to the msr internally
<zid`> than to just not bother and allow people free reign
<ddevault> this shit is going to drive me up the wall
<zid`> oh right FMASK exists
<ddevault> this is a nightmare architecture from hell
<zid`> had completely forgotten about that
<zid`> amd64's actually nice
<zid`> the braindamage is minimal and easy to work around
<ddevault> there is braindamage everywhere I look on this damn thing
<ddevault> a castle built on a house built on a shack built on sand
<Mutabah> zid`: That MSR (iirc) is used to derive all segment selectors
<Mutabah> and yeah, FMASK is also important
<bslsk05> ​github.com: rust_os/start.asm at master · thepowersgang/rust_os · GitHub
<bslsk05> ​github.com: rust_os/start.asm at master · thepowersgang/rust_os · GitHub
<Mutabah> ^ my GDT, note the order and commnets for the user segments
ethrl has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
Likorn has joined #osdev
<ddevault> thanks Mutabah
bauen1 has joined #osdev
<ddevault> hrm
<ddevault> I don't have the PIT turned on and I haven't even configured the PIC
<ddevault> but when IT is enabled in userspace, I get a double fault some non-deterministic amount of time after jumping to userspace
<ddevault> during that time several syscalls work successfully
<ddevault> what's weird is I don't even get the first fault
<ddevault> and the error code is non-zero, which I wouldn't expect for a double fault...
<ddevault> the fuck
<Mutabah> have you disabled the PIC?
<Mutabah> i.e. masked every interrupt off
<ddevault> ah, no, that's it
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ddevault> okay, that fixes it
<ddevault> so now I'm back to the original problem, thankfully, which is that iretq from a PIC interrupt causes a GP fault
<ddevault> only from userspace, that is
<heat> ddevault, sorry, wasn't here
<ddevault> np heat
<heat> hopefully you got that fixed
<ddevault> well, at least I have ruled out some things
<heat> I think _STAR does +16 on each for the 64-bit segment and the 32-bit segment (?)
<heat> idk
<heat> it's been a long time since I touched that stuff
<zid`> This just reminded me *why* I spent ages fixing a stupid self inflicted bug
<zid`> I was going to get MSI working wasn't I
<heat> damn right
<heat> go get em girl
<ddevault> yes, I think I have my STAR set up right
<ddevault> wrmsr(msr::IA32_STAR, (seg::UCODE_32 << 16 | seg::KCODE) << 32);
<zid`> should just be a case of enabling them in the pci-e config space, masking the PIT, and checking my ioport acks to mmio acks I think
<ddevault> then my GDT is, in order, KCODE, KDATA, UCODE_32, UDATA_32, UCODE, UDATA
<ddevault> and UDATA_32 and UDATA are identical
<ddevault> the GP fault is on the IRETQ instruction and sets error code to 10
<zid`> then you loaded ucode32 as your selector for the stack maybe
<zid`> or kdata
* zid` forgets about null
<zid`> or kdata for cs
<ddevault> nah, because it adds 16
<ddevault> so it ends up being UCODE
<ddevault> AMD manual vol 2 page 172
<bslsk05> ​paste.sr.ht: paste.txt — paste.sr.ht
<ddevault> 0x0000000000405504 is an address in the userspace's .text section, so presumably the return address
<ddevault> 0x00007fff8003fc68 is a userspace stack address
<zid`> and what's the exact value in _STAR?
<ddevault> 0x3000100000000
eroux has joined #osdev
<zid`> so 0+16 for cs
<zid`> 0+8 for ss
<zid`> That's why my data/code are swapped and I load 0x18 into 47:63 of _STAR
<ddevault> did you ever link to your code?
<ddevault> curious to see your GDT and _STAR setup
<zid`> wrmsr(IA32_STAR, 0x8UL << 32 | 0x10UL << 48);
<bslsk05> ​github.com: boros/gdt.c at master · zid/boros · GitHub
<ddevault> lemme try just dropping that in and see what happens
<ddevault> aaaand it just werks
<ddevault> well, good enough for me
<ddevault> thanks zid`!
zid` is now known as zid
<zid> Upgrade complete.
<zid> idk how people are supposedly having code, data, ???, code, data
<zid> I don't see how you achieve that given sysret loads ss=n+8 and cs=n
<zid> wait yes I do :D
<zid> basic addition is harrrrd
<zid> I just intended to move these around if I ever wanted 32bit selectors
<heat> zid` is evolving!
<ddevault> yeah I don't really see any point in having 32 bit support
<Ermine> ddevault: congrats
<ddevault> especially given that the language I'm writing this in doesn't even support 32-bit targets
<zid> yea not unless you have any legacy stuff to run
<heat> smaller pointers without x32 efforts
<zid> I wouldn't add it until I added a full x32 mode
<zid> and that isn't going to happen
<heat> or if you need to run native 32-bit code
<zid> or wine support I guess, which also not going to happen
<heat> yes but for example, what if you want to run a vbios
PapaFrog has quit [Read error: Connection reset by peer]
<zid> Did you not remember my JIT
<zid> that I never wrote
<heat> that's 32-bit code that you could then easily trap with signal handlers
PapaFrog has joined #osdev
<zid> oh right there's a 32bit extension mode thing isn't there
<zid> I completely forgot about that
<zid> what was it called?
Ram-Z has quit [Ping timeout: 240 seconds]
<zid> My fuzzy ass memory suggests there's a like, int 10h,4C for pset for real mode, but int 10h,4200 is the pmode version, or just returns a function pointer for it
<zid> or does VBE 3.0 just mandate the entry point is polyglot
<heat> no clue
<zid> found the name at least
<heat> but most of it needs to be pmode
<zid> vesa 3.0 protected mode interface
<heat> a real mode driver can't touch PCI space
<zid> vbe*
<zid> My plan was just going to be to JIT it to amd64
<heat> lol
<heat> use the CPU's internal JITter, ez
<zid> I usually just write interperting emulators
<zid> but a JIT sounded more fun
<ddevault> nice how the only way to do graphics in long mode is to write a GPU driver
<heat> s/in long mode//g
<heat> :)
<ddevault> haha yeah
<ddevault> still, basic framebuffer drivers don't seem like too much work on most GPUs once you have PCI working
<heat> though you do have EFI's GOP
<heat> they're not what?
<heat> hahaahahahahahaahaha
<ddevault> when I boot from EFI my #1 goal is to make EFI fuck off as soon as possible
<ddevault> well, 9front's ihd driver is pretty small, a few hundred lines
<heat> 9front's code is all horrible
<heat> and there's no way you can do that
<heat> like no way
<heat> in < 1000 lines
bauen1 has quit [Ping timeout: 272 seconds]
gorgonical63 has joined #osdev
<heat> ihd encompasses at least 11 gens, each gen has a different sequence to drive the display engine, each gen supports different outputs (HDMI, DP, eDP, VGA, DVI)
<ddevault> well, fair
<heat> each output requires its own multi-thousand-line code
<ddevault> still, only a few thousand lines tops
<ddevault> you don't have to, like, reimplement mesa or KMS from scratch
<heat> mesa isn't part of the kernel
<ddevault> aware
<ddevault> but it is necessary to do, say, OpenGL
<heat> the GPU kernel drivers are a good chunk of the linux kernel
<ddevault> given that I just got interrupts working properly I would say I'm some ways off from OpenGL support though
<zid> good news though, nvidia have made writing drivers even easier lately
<j`ey> heat: 90% of the kernel is AMD headers :P
<heat> and they're only good for power management, display, command submission
<heat> yup
<zid> the latest cards put the kernel driver into firmware on the card instead
<ddevault> on the one hand, that's fucking awful
<zid> so now the DRI interface is tinier than ever
<ddevault> on the other hand, nice for os devs
<heat> amdgpu's headers should maybe be firmware :)
<ddevault> I was thinking that it would be cool to port KMS/DRM to my kernel in The Future
<zid> The main idea is that updating drivers in a huge gpu cluster is a pain in the dick
<ddevault> it is at least somewhat isolated into a silo in linux
<ddevault> and has been ported to other kernels before
<j`ey> $ du -sh drivers/gpu/drm/amd/
<j`ey> 313M drivers/gpu/drm/amd/
<heat> you can totally do that
<j`ey> oof
<zid> so they just flash the card with the driver instead
<heat> j`ey, having the linux kernel checked out on your machine is such a kernel dev move from you :P
<ddevault> who doesn't have a copy of linux on their machine
<ddevault> have any hobby OSes ported KMS/DRM? maybe haiku has
<j`ey> how else am I going to build it!
<heat> ddevault, haiku is not a hobby OS
<heat> managarm might
<ddevault> yeah, but it is a niche OS at least
<zid> j`ey: I email my config to redhat
<heat> netbsd is also a niche OS
<ddevault> and it's at least as buggy as any hobby OS ;)
<zid> and they post me back a CD-ROM with my new krnel on it
<j`ey> zid: haha
<j`ey> 16M arch/x86 90M arch/arm64
<heat> that settles it
<heat> arm64 < x86
<j`ey> but 90 > 16
<ddevault> at least x86 has a standardized boot procedure
<ddevault> a stupid boot procedure, but standardized nevertheless
<zid> arch/x86_64 is 8k though
<j`ey> (arm64 includes all the .o, so not a fair comparison)
<zid> it contains boot/ and a symlink to bzImage :p
_xor has quit [Quit: bbiab]
dude12312414 has joined #osdev
<ddevault> hm, any reason not to just use setjmp for context switching
<zid> Try it and find out, I'm interested in the answer
<ddevault> well, I'm a little ways from being able to try it, I actually have to prepare a second task to jump to in the first place
<ddevault> will let you know
<zid> same
<zid> I have one process happily running away
<zid> but its kernel stack is just a page out of my boot-time .bss and stuff, so I'd struggle to run two of them and schedule and stuff rn :P
<heat> why would you?
<heat> you need to save the context when entering the kernel
<zid> why would you want
<zid> words, geez
<zid> 'why would you?' what?
<heat> what if you setjmp inside a constructor or dtor
<heat> will bjarne bust my kneecaps
<heat> "<ddevault> hm, any reason not to just use setjmp for context switching"
<ddevault> I think I'm going to use my own setjmp-equivalent so that I can access its registers directly rather than work with the opaque jmpbuf
<zid> I mean, that's preferable, but I do wonder if anything would go wrong if you tried to use longjmp
<heat> like, context switching just uses what you pushed
<ddevault> only if your kernel is not preemptable, heat
<heat> you need to save more regs than setjmp
<heat> ddevault, no.
<ddevault> you don't longjmp to userspace
<ddevault> you longjmp to somewhere else in the kernel, but on a different stack
<ddevault> the rest of the registers are at the bottom of said stack
<heat> this seems like an extremely obtuse way of doing context switching when you can just use the things you've pushed
<ddevault> it allows you to have the kernel yield from anywhere
bauen1 has joined #osdev
<heat> I can also yield from anywhere
<heat> how bout that
<ddevault> so what does your context switch look like
<ddevault> say, from kernel thread to kernel thread
<bslsk05> ​github.com: Onyx/interrupts.S at 6c51faf98d17eb298844aaccbdf1ad9ba7e4274f · heatd/Onyx · GitHub
<ddevault> so you just push an entire IRQ frame to the stack
<zid> I mean, in long mode you sort of have to
<zid> iret is the only op that can reload cs
<heat> ddevault, yes, that's how it usually works
<heat> you use what you push
<ddevault> call me crazy but I think the setjmp approach is simpler
<heat> you're crazy
<heat> :P
<ddevault> if (setjmp()) { /* got control back */ }; /* longjmp to next thread */
<ddevault> ez
<heat> the debugger wants to inspect the register state
<heat> what now
<zid> how come your .S is intel but not noprefix btw heat
<ddevault> heat: it just looks up that thread's kernel stack and pulls the registers off of it?
<ddevault> the debugger has no business inspecting the kernel's registers
bauen1 has quit [Ping timeout: 260 seconds]
heat_ has joined #osdev
<heat_> this fuckign router ahhhhhhh
<heat_> <heat> it's not intel
<heat_> <heat> this is raw, hardcore, at&t asm
heat has quit [Read error: Connection reset by peer]
heat_ is now known as heat
<heat> ddevault, you'll need to debug your kernel too :)
Ram-Z has joined #osdev
ethrl has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ethrl has joined #osdev
<ddevault> heat: aye
mimmy has joined #osdev
<zid> heat: but it has no size affices!
heat has quit [Remote host closed the connection]
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 246 seconds]
heat has joined #osdev
blockhead has joined #osdev
nvmd has quit [Quit: WeeChat 3.5]
ethrl has quit [Ping timeout: 240 seconds]
eroux has joined #osdev
vdamewood has joined #osdev
the_lanetly_052_ has joined #osdev
nyah has joined #osdev
the_lanetly_052 has quit [Ping timeout: 244 seconds]
elastic_dog has quit [Ping timeout: 255 seconds]
gorgonical63 has quit [Quit: Client closed]
elastic_dog has joined #osdev
dennis95 has quit [Quit: Leaving]
elastic_dog has quit [Ping timeout: 248 seconds]
mimmy has quit [Ping timeout: 246 seconds]
elastic_dog has joined #osdev
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mimmy has joined #osdev
wootehfoot has joined #osdev
pretty_dumm_guy has joined #osdev
mahmutov has joined #osdev
wootehfoot has quit [Ping timeout: 246 seconds]
k8yun has joined #osdev
FreeFull has joined #osdev
sonny has joined #osdev
wootehfoot has joined #osdev
<sonny> For people using rust, was there any hitch in setting up paging?
<j`ey> is there something in particular you think would be an issue?
<sonny> j`ey: no tbh
<sonny> I also just realized I can check that rust OS tutorial
Brnocrist has quit [Ping timeout: 246 seconds]
FreeFull has quit []
Brnocrist has joined #osdev
* mjg_ wonders how many people think learning rust by writing an os in it is a good idea
FreeFull has joined #osdev
* vdamewood raises his hand sheepishly
* mjg_ glares at vdamewood
<mjg_> how is it going
the_lanetly_052_ has quit [Ping timeout: 256 seconds]
<vdamewood> I gave up after 2 minutes.
<vdamewood> With C, when the compiler complains that symbol foo is missing, I know how to implement foo. With rust, not so much.
<vdamewood> (where foo is part of the standard library or language internals)
<vdamewood> oh, also s/compiler/linker/
gorgonical26 has joined #osdev
gorgonical26 is now known as gorgonical_
<gorgonical_> Porting is not exactly elegant work
wootehfoot has quit [Ping timeout: 248 seconds]
<gorgonical_> I feel like I'm chasing continual build errors and fixing things where they aren't right and hoping this will be enough
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
* moon-child hands vdamewood libgcc and a set of strings functions
<vdamewood> gorgonical_: Just like Sam Beckett
<GeDaMo> "Sam Beckett never returned home" :|
kingoffrance has quit [Ping timeout: 265 seconds]
vancz has quit [Remote host closed the connection]
pie_ has quit [Remote host closed the connection]
sonny has quit [Remote host closed the connection]
kingoffrance has joined #osdev
<geist> Wait, what was this mute him crap from 10 hours ago?
<geist> I didn’t see anything. Maybe i had someone locally muted?
terminalpusher has joined #osdev
<geist> oh never mind, read more backlog
* geist shrugs
<geist> Anyway, hows everyone’s Friday. It’s Friday!
<geist> Unless it’s Saturday because you’re in another time zone
<geist> In which case, yay it’s Saturday!
<mrvn> Still 2 hours of friday left to celebrate
<geist> yay
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
wootehfoot has joined #osdev
mimmy has quit [Ping timeout: 248 seconds]
terminalpusher has quit [Remote host closed the connection]
<heat> had a nice day off here :)
<geist> yah i need one. been working on this fairly stressful project at work the last few weeks that has mostly drained me
<geist> that combined with summer allergies has been an un-fun last few weeks
<heat> :/
<heat> any details you can share?
<heat> or is it Top Secret(tm)
<mrvn> I could tell you -- but then I would have to k-line you. :)
<geist> oh nothing interesting, or it wouldn't be a slog
<geist> one of those 'need to frob all of this X into Y and a bunch of people are waiting on you'
<geist> so just stressful and un-fun with no redeeming quality
<heat> sucks
<geist> mostly out of my wheelhouse but they needed someone to thelp
<geist> help, so i pitched in
<zid> muhahaha someone linked a test rom and was like "bet you won't pass this one" and passed it
<heat> gameboy emulation dick measuring?
<zid> yup, it's fun sport
<zid> it's like code golf but you get a gameboy emulator at the end instead of a segfault
mimmy has joined #osdev
<gorgonical_> Is this typical: allocate a page for the task_struct and then use the difference between where the task_struct ends and the end of the page as the kernel stack?
<zid> could do I suppose, but why not just allocate a page?
<heat> gorgonical_, task_structs are big
mimmy has quit [Ping timeout: 276 seconds]
<geist> can put the task struct at the top of the page and then start the stack just below it, if you want
<zid> you're going to trash your task struct eventually doing that
<zid> and it's going to be NOT FUN to debug
<gorgonical_> or I mean the other way around
<gorgonical_> My point being: you use the remainder of the minimum allocable size as the stack
<geist> i think some of the older unices did that for a while. you can also swap it out (though i dont thik most most modern kernels do that)
<geist> but in the Old Days when you fully swapped out a task, you could actually write out the kernel stack and it's TCB as well
<geist> but in general i'd just allocate the task struct out of your heap/slab/etc for other stuff
<geist> and then allocate 1 or more pages for the kernel stack out of the pmm
<gorgonical_> In the source I'm working with task_struct is actually in a task_union which is 4KB with the stack which is overall 4KB. The stack then should know how big it is and the difference between the bottom of the stack and the end
<geist> okay
<gorgonical_> I mean I agree with you fundamentally
<geist> it works, dunno precisely what the dsign goal there is, but if thats what they chose to do it works
<gorgonical_> It took me like 30 minutes to really understand where the kernel stack was, because it's sort of mushy
<geist> and yeah if the TCB is at the bottom of the page then if the stack overflows it'll cause havok
<heat> i remember x86 linux has something on top of the stack that points to the current thread
<geist> but it probably calls havok any way you cut it
<heat> then to get the current thread they do some bitops on the stack pointer and access it
<geist> if i were doing that i'd put the TCB at the top of the stack (higher addresses) and then start the SP just below it (aligned of course)
<geist> so the stack grows downwards, away from the TCB
<geist> and yeah that too. the only problem with the 'use the stack pointer to find some critical data structure at the top of it' strategy is it forces you to use a fixed size stack size
<geist> and it must be aligned on that boundary too. so a 16KB stack has to be 16KB aligned, etc
<geist> but if you're willing to live with that restriction, it works well
<gorgonical_> just to be clear because this confuses me a lot: growing downwards means e.g. 0x1000 is the end, then 0xfff?
<heat> 0x1000 is the top
<heat> 0xfff is the first usable byte
<geist> iirc that's part of how linux solves the ARM stack overflow problem: it fixes the stack size at say 8K, and always puts a guard page off the bottom that's 8K as well, so it can easily do pointer math in the first few instructions of the fault function to determine if it overflowed
<gorgonical_> Right yes
<gorgonical_> I said that wrong
<geist> yah i keep saying 'top' to mean 'higher address'
<geist> and virtually all arches out there (and any one you'll fiddle with) grow the stack downwards
vancz has joined #osdev
pie_ has joined #osdev
<geist> except for things like safe stacks which may grow upwards, because they're software constructs
<gorgonical_> So then to e.g. the task goes at 0xff80 or something so that the task_struct ends at 0x1000?
<heat> we need an arch that starts in the middle and grows both ways
<heat> gorgonical_, seems about right yes
<heat> geist, btw why exactly do stacks grow downwards?
<geist> if you allocated a page that was from 0 - 0x1000, then you could put the task struct at 0xff0 (if it were say 0x10 bytes long) and then start the stack at 0xff0 so it grows downwards, 'away' from the task struct
<gorgonical_> Yes so this stack appears to grow upwards. regs = task + TASK_SIZE - 1
<geist> heat: good question, i think it's mostly because in the early single tasking days it was generally convenient to put the stack at the end of memory and grow it downwards, whereas the program and it's data grew upwards
<heat> oh and with all this, don't forget to align the stack!
<geist> still somewhat convenient, though in modern virtual memory it kinda doesn't matter
<geist> but pre-virtual memory it helped
<heat> cpus bend to the will of the mighty program - brk - stack layout!
<geist> so if you had a cpu with say 32KB ram, and 32KB rom with basic in it or something, you could put the stack at 0x8000 and grow downwards, and load your basic program and its heap at 0x1000+, etc
<geist> and then when segmentation and multitasking came along that still made sense
<geist> then when paging came along it sort of made it less important, but still useful
<heat> maybe paging makes it more important?
<heat> because you can kinda infinitely grow your stack that way
<geist> depends, with modern paging there's no distinction between stack and data, so it's all just regions of memory that you allocate in your VM
* heat laughs in linux vm
<geist> you can reserve space off either end in a modern VM. a bit more convenient to grow it upwards too, since usually it's easier to extend an existing region upwards
<geist> but stuff in the 70s and 80s still had stacks vs data heavily baked in. PDP11 segmentation knew about stacks directly, even VAX paging had two separate page tables per process, split in half, one grows upwards, one grows downwards
<geist> and of course x86 segmentation even has grow downwards segments
mimmy has joined #osdev
<geist> kinda makes 68k look even more modern in retrospect: in 1979 it was simply flat memory model, period. none of the extra stuff
<mrvn> Even with virtual memory it still makes sense to grow the stack down IF you only have one. You still have address space and you put heap at one end and stack at the other and never they shall meet in the middle.
<geist> and then a few years later it's paging chip and then integrated in 030 was also intrinsically flat
<mrvn> But with modern multithreading or even just sigaltstack you have to define how large the stack is and reserve the address space. Then it kind of becomes moot.
<geist> mrvn: sure. main downside nowadays is with multithreaded programs you can't just grow downwards forever, sinc eyou'll probably hit another thread's stack
<geist> yah
<geist> OTOH with 64bit we have space again
<mrvn> And stack is usualy limited in size anyway to prevent run-away recursion.
<geist> yah. modern code relatively speaking leans on the heap/secondary allocations more than ever before
<geist> some sort of chart of heap vs stack usage over time woud probably show something like that
Likorn has quit [Quit: WeeChat 3.4.1]
<mrvn> One day I still want to try out just going back to the good old days. Just give the process the whole address space with demand paging. No brk, sbrk or mmap needed to allocate memory. Just have malloc use it as needed.
<mrvn> Optionally free() can have a syscall to unattach physical pages from a memory range.
<heat> that's how my vm worked in the beginning, before brk or mmap!
<mrvn> I've been using this intrusive linked list. Any way to get rid of the `typename T` without loosing the type safety? https://godbolt.org/z/zEzGMrz5K
<bslsk05> ​godbolt.org: Compiler Explorer
bxh7 has joined #osdev
bxh7 has quit [Client Quit]
wootehfoot has quit [Read error: Connection reset by peer]
<mrvn> I need a covariant or contravariant thing in c+.
<mrvn> c++.
<mrvn> https://godbolt.org/z/98oxd3v7G I want both getters and setters.
<bslsk05> ​godbolt.org: Compiler Explorer
terminalpusher has joined #osdev
sortie has quit [Ping timeout: 272 seconds]
sortie has joined #osdev
mimmy_ has joined #osdev
mimmy has quit [Ping timeout: 246 seconds]
terminalpusher has quit [Remote host closed the connection]
sortie has quit [Ping timeout: 240 seconds]
sortie has joined #osdev
rustyy has quit [Quit: leaving]
Gooberpatrol66 has quit [Quit: Leaving]
rustyy has joined #osdev
<qookie> mrvn: what's the purpose of the U arg?
<mrvn> qookie: so you can inherit more than one List
<mrvn> just a tag
<qookie> ah
<qookie> tbh, for an intrusive list I'd make the class inherit the list node and not the whole list
<bslsk05> ​godbolt.org: Compiler Explorer
<mrvn> doesn't change the question though, just adds another class to the problem.
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
mahmutov has quit [Ping timeout: 248 seconds]
nyah has quit [Ping timeout: 256 seconds]
<qookie> Hm I suppose I am a bit confused
<qookie> MyFoo is a member of a list and also has a list of children (forming a tree)?
<mrvn> each node in the tree has siblings and children
<mrvn> Could be Tasks with a list for task in the same process group and task that are threads of the same process
<mrvn> really just an example of inheriting more than one list
<qookie> yeah I don't think you can get around the T arg
<qookie> you could add a typedef to partially specialize it as not repeat it explicitly
<qookie> but as far as I can tell that's about it
<heat> list_head goes brrrrrrrrrrrrrrrrrrrrrrr
<mrvn> You mean like this? struct MyFoo; template<typename U> using FooList = List<MyFoo, U>;
<qookie> yeah
<geist> yah i worked on a bit of one of those a while back too
<geist> i really dont like the result, but it's The Way
<mrvn> I like it more than the way the STL is build. Trying to combined STL containers means you have to store iterators left and right in your data. And then half the time they invalidate.
heat has quit [Remote host closed the connection]
heat has joined #osdev
sortiecat has joined #osdev
sortie has quit [Ping timeout: 248 seconds]
zaquest has quit [Ping timeout: 248 seconds]
zaquest has joined #osdev
<geist> yah not a big fan of that stuff indeed
<mrvn> the thrid option is the C way with container_of macro thats UB / implementation defined with &(nullptr->member)
dude12312414 has joined #osdev
Vercas has quit [Quit: Ping timeout (120 seconds)]
Vercas has joined #osdev
<geist> yah worse, the copiler actually generates a warning about it that you have to squelch
FreeFull has quit [Quit: sleep]
<mrvn> I wonder why C++ still doesn't have a standard container_of
<heat> container_of is not defined for non-POD types
<heat> even if you use offset_of
<mrvn> so make it fail to compile when it makes no sense
<mrvn> As is the macro gives some result that may or may not work on non-POD types by chance.
<heat> no
<heat> it gives you a warning
<mrvn> Latest C++ also has a well defined order for all member variables in a class so I think it can work on more types now.
Burgundy has quit [Ping timeout: 246 seconds]
<mrvn> container_of should work on all standard layout classes, right?
<heat> yes
<heat> i believe so
<mrvn> and POD < standard layout iirc
<mrvn> is_pod is deprecated in c++20. What's the replacement? is_trivial? is_trivially_copyable?