<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
<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
<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>
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
<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
<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>
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?