<zid`>
In other news, there's a Made in Abyss rewatch happening and I just caught this comment: "episode lucky number seven; maybe a wholesome episode today?"
<mrvn>
\Test_User: so I don't have to allocate empty objects to read into
<\Test_User>
you override the >>, you override the =, and you override the []
<zid`>
huge grin ensues
<mrvn>
\Test_User: no override for = or [], that's c++ standard
<\Test_User>
why don't we override the ; as well while we're at it
<zid`>
can you define custom operators yet
<psykose>
that's easy, just replace every ; with ,
<zid`>
I want a greek question mark operator
<\Test_User>
mrvn: you are overriding the =, a, b, c aren't getting returned from cin
<mrvn>
\Test_User: and >> is just an example. it would probably have to be more like: cin.get<int, std::string, double>()
<mrvn>
can't pass types as argument to operators.
<mrvn>
\Test_User: No, that's when you return a std::tuple and unpack it on assignment.
<\Test_User>
but cin >> returns cin
<mrvn>
not for that use case
<\Test_User>
and auto [a, b, c] = cin.get<int, std::string, double>() also looks bad, but at least not as bad as the >>
<mrvn>
First you have to make it valid c++, then you can make it look pretty
<\Test_User>
~~or you could just write it in C to start with~~
<mrvn>
\Test_User: have you ever tried to write a custom scanf plugin for your structures?
<\Test_User>
nope
<mrvn>
probably because C doesn't allow it.
<\Test_User>
...what exactly do you mean by scanf plugin for your structures
<\Test_User>
on a side note, if C has a standard struct version of C++'s std::string that'd be nice
<mrvn>
In ocaml I can say %b (iirc) and then provide a function that reads a struct and returns it.
<\Test_User>
eh what
<mrvn>
Just like in c++ I can write operator>> for a class.
<\Test_User>
I like keeping operators used for their original intention
<\Test_User>
even if no one would sanely use that operator in that place anyways, keeping things the same is more readable
<mrvn>
It's kind of funny. You could write `let ast = Scanf.scanf "%b" parse_ast` for your C compiler.
<mrvn>
Write the whole parser as recursive scanf helper functions.
<\Test_User>
...you're talking about doing what now
<mrvn>
that's ocaml syntax
<\Test_User>
idk ocaml
<\Test_User>
but what's the point of that
<mrvn>
Same point as having operator>> defined for your classes
Likorn has quit [Quit: WeeChat 3.4.1]
<mrvn>
Lets scanf read in arbitrary types.
<\Test_User>
so you're talking about changing syntax from a normal function call to some other format
<\Test_User>
(normal function call = function(arg1, arg2...);)
<mrvn>
\Test_User: in C this would be scanf("%b", fn, &obj); or something.
<\Test_User>
...oh yeah I see what you mean now
<\Test_User>
C++'s overloaded functions iirc it's called
<\Test_User>
those I wouldn't really oppose having in C, though it is a bit odd
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<mrvn>
fn would be `const char * (*)(const char *, void *)`
<\Test_User>
but redefining the >>/etc operator to do it I dislike
<mrvn>
\Test_User: overloading >> wouldn't even work as the use case has to pass types. Needs to use template parameters for that.
<mrvn>
I now c++23 has std::format for printing. Is there also something for scanning input?
<\Test_User>
mrvn: I was taking what you were referring to to be where you can use the same function name for different ones and which one is used is determined by which type you used as args
gog has quit [Ping timeout: 248 seconds]
<\Test_User>
it's kind of odd but has actual sane usages
<\Test_User>
so I don't oppose it
<mrvn>
\Test_User: ocaml does it without overloading.
<\Test_User>
so ocaml renames it or adds an argument so it's the same function but less efficient when run
<\Test_User>
(renames it as in calls it smth other than overloading)
<mrvn>
No, there is only one scanf function but the "format" string gets parsed by the compiler with a bit of blakc magic into a format type that then guides the type for all the other arguments.
<\Test_User>
ah
<mrvn>
bit of syntactic suggar. You can do it fully functional but "format" looks much nicer.
<\Test_User>
so you mean e.g. where scanf(format, arg1, arg2, etc) where the args aren't pre-declared and their type is determined by the format?
<mrvn>
\Test_User: yes
<mrvn>
And you have partial application: # Scanf.scanf "%d %f";;
<mrvn>
That's a function taking a `something (*)(int, float)` and returning something
<\Test_User>
not bad, for C though I prefer having them declared beforehand for clarity to the reader (including me in a few months :P), but for other languages that aren't strict types I'd be totally fine with it
<mrvn>
The comopiler doesn't yet know the type of '_weak1 but it knows you have to provide some type for it later when you use the function.
<mrvn>
I guess you hate "auto" in c++ then
<\Test_User>
somewhat
<mrvn>
ocaml deduces the type for most things. You can annotate your code with types but you don't have to and generally shouldn't. You do specify types for module interfaces and datatypes. But not code.
<\Test_User>
another thing on my list of annoyances at C++ is args being passed with &arg name on the function setup side, where it's not clear on the caller side of the called function can overwrite your variables or not
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<mrvn>
you mean foo(&arg), is that calling foo(const bla&) or foo(bla&)?
<\Test_User>
I mean you call foo(arg);, but the definition of foo is smth like void foo(int &arg) {arg = 3; return;}
<mrvn>
yeah, from "foo(arg)" you don't know if it is pass by value, pass by reference, pass by const reference or pass to move
<\Test_User>
for languages that are intended with automatic types I'm generally fine with it for stuff I want done quickly
<\Test_User>
yeah
<mrvn>
and all of them can be present at the same time and you get a different function depending on what arg is.,
<\Test_User>
yeah when you combine that with overloaded functions it just turns into a total mess
<mrvn>
and don't forget foo(double) can be called as well
<mrvn>
implicit conversion is hell
<\Test_User>
agreed
<mrvn>
\Test_User: how do you multiply 2 uint16_t?
<\Test_User>
with assembly >:)
<\Test_User>
yes I also hate how C/C++/etc can overflow stuff and not tell you
<mrvn>
uint16_t mul16(uint16_t a, uint16_t b) { return a * b; } is UB.
<mrvn>
(well, idb)
<\Test_User>
how is that undefined? it's 2 16-bit unsigned integers returning a 16-bit unsigned integer... there's no possability of getting put into a 32-bit unsigned integer for the return and questioning which step it gets cut at
<mrvn>
uint16_t gets promotes to "int" before the * and then 40000 * 40000 is a signed intreger overflow.
<\Test_User>
smth like uint32_t mul16... would however leave more who-knows-what available to happen
<\Test_User>
...what
<\Test_User>
aaaa
<mrvn>
You have to do return (uint32_t)a * b
<\Test_User>
I want a C without implicit conversion :/
<mrvn>
But now you compute the upper 16 bit of the multiplication and throw it way. Potentially slower.
<\Test_User>
yeah
<mrvn>
\Test_User: at least for the integer conversions. There is no way to disable them.
<\Test_User>
I mean, conversion of the same base type I'm fine with, conversion of one type to another is bad
<\Test_User>
at a minimum I'd want it to ensure unsigned/signed remains
<mrvn>
yeah, I don't get that part eigther. Why not fix that? Only thing it would break are the UB cases I believe.
<\Test_User>
> signed integer overslow is undefined, unsigned is defined
<\Test_User>
wait what
<\Test_User>
*overflow
<\Test_User>
how is signed not defined
<zid`>
because different arches do different things, so it'd cripple whatever arch that is to have to do what the others do
<zid`>
C being portable-80s-assembler
<\Test_User>
ahhhh yes true, the different ways of handling negative numbers
<zid`>
right, so all the one's comp machines would need if(overflow) adjust(); after every signed add
<\Test_User>
I always just think of the modern way it's done
<zid`>
or you just say overflow is UB and skip them all
<\Test_User>
yeah
Burgundy has joined #osdev
CaCode_ has joined #osdev
CaCode has quit [Ping timeout: 248 seconds]
CaCode_ has quit [Quit: Leaving]
sonny has joined #osdev
<sonny>
Does anyone know why windows subsystems are called personalities?
<mrvn>
C++ has stopped supporting anything but two's-complement. But still archs behave differently on overflow. They trap or saturate or just warp arouns.
<mrvn>
sonny: because they are called personalities on unix
<sonny>
unix doesn't have subsystems
<mrvn>
sonny: 64bit linux has the 32bit personality and 32bit int/pointer + 64bit long personalities. BSD has a linux personality.
<mrvn>
man personality
<sonny>
ok, that's cool I didn't know there was a linux thing for BSD
<moon-child>
freebsd has a linux _emulator_
<mrvn>
sonny: there is a debian for bsd
<moon-child>
mrvn: that's different
<moon-child>
afaik
<moon-child>
not using the linux kernel emulation, but compiling debian userland for the freebsd kernel
<mrvn>
Nope, that runs linux code in the linux personality of freebsd. it's not emulation.
<sonny>
mrvn what bsd manual? I just checked freebsd but I did not see anything
<mrvn>
sonny: it's a linux manpage
<moon-child>
mrvn: it's literally called the linuxulator
<sonny>
oh
<sonny>
mrvn: "personality - set the process execution domain" -- this?
<mrvn>
moon-child: debian kfreebsd is between porting to BSD and linuxulator
<mrvn>
sonny: and similat other tools and manpages
<sonny>
tangent, seems like windows put win32 graphics in the kernel since it was one of it's subsystems but ipc was too slow or something
<sonny>
s/windows/microsoft/
<mrvn>
leading to some nice kernel exploits
<mrvn>
NT used to be a microkernel
<sonny>
yeah, seems so
<mrvn>
by the time it was released the micro kernel part of it was 3.5MB, far bigger than all of the linux kernel at the time.
<sonny>
at least before NT 4
<Affliction>
Didn't 9x run parts of IE in the kernel too?
<Affliction>
What could possibly go right
<sonny>
o.O
<mrvn>
9x was a monolithic design
<sonny>
is that why you can't uninstall it? lol
<Affliction>
sonny: Nah, I think that's because trident (its rendering engine) was embeddable, and was used all over the place.
<sonny>
oh
<sonny>
so much for seperation
<sonny>
is posix an abi?
<sonny>
I'm thinking if it's just an api then it doesn't seem like such a big deal to support posix in an OS
* moon-child
hands sonny a fork
<sonny>
oh
<sonny>
right
<moon-child>
(although. cygwin and midipix)
<moon-child>
(midipix has a fork, right? I know cygwin does)
<sonny>
I thought midipix was wip
Burgundy has quit [Ping timeout: 248 seconds]
heat has quit [Ping timeout: 244 seconds]
<mrvn>
sonny: it's not a big deal to be posixish. It's a big deal to do it correctly and even bigger to certify it. The last part because it's a ton of money every time you make an update.
<mrvn>
Windows was POSIX certified, Linux isn't.
<mrvn>
Although in Windows they only implemented the bare essentials, none of the optional stuff that makes it actually usable. But it was certified.
<sonny>
I thought they got some third party thing from someone else
<sonny>
I don't recall it being certified either
GeDaMo has joined #osdev
the_lanetly_052 has joined #osdev
terminalpusher has joined #osdev
sonny has left #osdev [#osdev]
mahmutov has joined #osdev
nur has quit [Remote host closed the connection]
arch-angel has quit [Remote host closed the connection]
arch-angel has joined #osdev
vdamewood has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
Likorn has joined #osdev
Likorn has quit [Client Quit]
the_lanetly_052 has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
terminalpusher has quit [Remote host closed the connection]
the_lanetly_052 has quit [Ping timeout: 256 seconds]
<liz>
ddevault: nice thinkpad, and nice task switching too
<ddevault>
thanks, thanks
<j`ey>
ABABABAB
janemba has joined #osdev
<ddevault>
I'm thinking about doing context switching by setting the IST for the PIT to the thread's context struct
<ddevault>
then the ISR pushes all of the registers there and switches to the kernel stack (non-preemptable kernel)
<ddevault>
saves me copying the context later
<ddevault>
any obvious drawbacks to this approach?
<mrvn>
all the parts where you context switch not in the timer
<ddevault>
these could fall back to the manual approach
<ddevault>
but I'm not sure there will be many of those
<mrvn>
it will be more than 0
<ddevault>
examples?
<mrvn>
sleep
<mrvn>
yield
<mrvn>
read
<ddevault>
this is a micro-kernel, so no read
<ddevault>
but yeah, during some syscalls it would make sense to switch contexts
<ddevault>
I mean, I could also set the syscall stack to the current thread's state
<gog>
a context switch will always happen during your message passing syscalls
<ddevault>
right, but couldn't the syscall handler do something similar
<mrvn>
gog: only if you care about performance
<mrvn>
ddevault: now you have 2 places that context switch
<mrvn>
fork and exit are 2 more
<ddevault>
those are just syscalls, so no additional places
<mrvn>
it realy makes more sense to have code to have a switch_thread function you can call from anywhere in the kernel
<ddevault>
you can - it just updates the active thread's arch context pointer
<gog>
yeah the possibility that a context switch could happen during any system call shouldn't be discounted, because any system call might block the calling process
<mrvn>
ddevault: not the way you described your kernel stack
<ddevault>
syscall/isr stack is set to the thread's arch state
<ddevault>
syscall/interrupt handler pushes all of the registers there and sets %rsp to kernel_stack_top and proceeds
<ddevault>
then the clean-up code sets %rsp to the current task's arch context and pops everything back off
<ddevault>
am I missing something?
<mrvn>
ahh, now I get it.
<mrvn>
You don't have a per task kernel stack at all.
<ddevault>
nope
<ddevault>
one stack per CPU
<mrvn>
Totally the way to go. I do that on ARM where it's even simpler because IRQs and syscalls don't write to the stack at all.
<ddevault>
oh
<ddevault>
great :)
<mrvn>
You might add reloading the page tables to that. Have kernel page table switching for some side channel mitigation.
<ddevault>
not sure
<ddevault>
if I did I'd limit the system to 64G of RAM, or have to allocate new page tables (or just statically allocate more page tables)
<ddevault>
kernel page tables*
<ddevault>
but yeah, I will research that, and other hardening steps, in one fell swoop
<ddevault>
right now it's quite easy to crash the kernel
<mrvn>
Actually make the kernel thread a full task, pinned to each core, and on IRQ/syscall you task switch to the kernel thread and after you task switch back to the next thread.
<ddevault>
there is no kernel thread
<mrvn>
I'm saying make one
<ddevault>
I mean
<ddevault>
what is a thread if not something with CPU time and a stack
<mrvn>
It has a stack, a page table, VM structures, ...
* ddevault
shrugs
<ddevault>
semantics
<ddevault>
I suppose I could work with a fixed number of page tables and just reshuffle them to access different parts of memory
<ddevault>
not sure it would be efficient, though
nur has joined #osdev
wand has joined #osdev
JanC has quit [Remote host closed the connection]
JanC has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
FatAlbert has joined #osdev
<FatAlbert>
where is he
<FatAlbert>
gog: maw
<FatAlbert>
notice im still not giving up o nthe idea of me doing osdev ... i just need a car right now so i web scrape used cars platforms
<FatAlbert>
yeah im broke .. but i know ill do good oen day
<FatAlbert>
i know it
dude12312414 has joined #osdev
SGautam has joined #osdev
sortie has quit [Read error: Connection reset by peer]
sortie has joined #osdev
liz has quit [Ping timeout: 248 seconds]
Likorn has joined #osdev
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Client Quit]
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Client Quit]
heat has joined #osdev
CaCode has quit [Quit: Leaving]
mahmutov has quit [Ping timeout: 240 seconds]
SGautam has quit [Quit: Connection closed for inactivity]
<ddevault>
actually putting that TSS idea into practice was... difficult
<ddevault>
now my kernel does the same thing, but better(TM)
manawyrm has quit [Quit: Read error: 2.99792458 x 10^8 meters/second (Excessive speed of light)]
manawyrm has joined #osdev
liz has joined #osdev
<j`ey>
can I start qemu such that it's serial is output to some tty such that you can run `screen` to connect to it? (rather than serial on stdout)
<clever>
you can route it to a socket, tty, or fifo
<klange>
yeah, run it in screen :smugsipemoteasifthiswasdiscord:
<\Test_User>
you can use unicode emojis on IRC
<j`ey>
clever: whats the syntax for a tty?
<klange>
You probably don't want the tty approach if you want to connect from screen; that's for an _existing_ tty.
<j`ey>
I have a program that opens /dev/ttyAMA0 on my host. I want to run linux in a vm and use the serial port exposed by that, as the serial port for my program