<geist>
haha you have me watching those skits again
bradd has joined #osdev
wand has quit [Ping timeout: 240 seconds]
wand has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
[itchyjunk] has quit [Remote host closed the connection]
k8yun__ has quit [Quit: Leaving]
heat_ has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
k0valski188 has quit [Ping timeout: 256 seconds]
mahmutov_ has joined #osdev
<Griwes>
geist, why do channel writes of handles in zircon consume the handles from the calling thread by default? did you find that most calls of those are immediately followed by a handle close and so it's this way just for ergonomics, or is there a more fundamental reason for that?
heat has joined #osdev
heat_ has quit [Ping timeout: 250 seconds]
ElectronApps has quit [Remote host closed the connection]
<heat>
i'm confused
<heat>
why do I get a \b for backspace instead of DEL
<clever>
heat: there are 2 different character codes for backspace, and which you get depends on your terminal emulator config
<clever>
i run into that all of the time, since i use xterm, and sometimes share a tty (via screen) with somebody that doesnt
<clever>
something auto-configures the tty in linux to know what is "right", and things break if there are 2 differently configured terminal emulators and there is no "right" answer
<heat>
yes but linux has the same config as me (erase = ^?) and it works
<heat>
i'm just getting backspaces
<heat>
erm, \b's
<clever>
what path is the keystroke taking? from keyboard to your program?
CaCode has quit [Quit: Leaving]
<heat>
i'm using qemu with nographic to get input to my OS from the serial port
<heat>
i should've said that lol
<clever>
ah, so it could either be your terminal emulator, or qemu
<heat>
but it works because it works in linux
<heat>
not in my OS though
<clever>
i think qemu has trace options to report what its sending thru the serial port
<clever>
and now you have my curiosity :P
* clever
pulls up qemu src
<clever>
checking this file first, ./chardev/char-serial.c
<clever>
ah no, thats for a host serial port
<clever>
i think so when you map a guest serial to a host serial, it translates ops like baud rate change correctly
<clever>
hw/char/serial.c next
<clever>
yeah, that looks better, `16550A UART emulation`
the_lanetly_052 has joined #osdev
<clever>
recv_fifo_put() pushes a byte onto the receive fifo, for the guest to later read
<heat>
but its not part of any specific uart's emulation I think
k0valski188 has joined #osdev
<clever>
serial_receive1() can call recv_fifo_put()
<clever>
vmstate_serial_recv_fifo describes the fifo to something
<clever>
vmstate_serial refers to that description and describes more hw
<clever>
serial_ioport_read() can pop a byte and return it without translation, so nothing funny on that end of the FIFO
<clever>
recv_fifo_put() is static, so no need to check for it in other files
<clever>
serial_receive1() takes a buffer and size, and is registered as a handler passed outside of the file
<clever>
via qemu_chr_fe_set_handlers()
<clever>
qemu-master/ui/console.c: case '\b': /* backspace */
<clever>
heat: ah, and this is one of those cases i often run into, qemu is ignoring what the tty says backspace is, and just expects it to be \b
<clever>
in this context, its a putchar for a gui console i think, and it just decrements the x axis, so its less in the tty domain
<heat>
waiiit I am getting 7f
<heat>
i was wrong
<heat>
i got confused
<clever>
ah
ravan has quit [Ping timeout: 256 seconds]
ThinkT510 has quit [Quit: WeeChat 3.4]
ElectronApps has joined #osdev
ThinkT510 has joined #osdev
<heat>
ok what
<heat>
somehow, GRUB still gets a framebuffer with -nographic
<klange>
I think the manual is a bit misleading, -nographic does not disable the display device, it is equivalent to -display none (which only affects _output_) plus some options for serial I can't be arsed to look up.
<heat>
i have just learned that booting without a vga device makes my kernel triple fault lol
<klange>
Yarp, you'll still get the default display device with -nographic, you'll just not see it, and VGA text mode gets redirected to stdout.
<clever>
heat: oh, and if your using that stdio<->vga+ps2 routing that klange mentioned, instead of stdio<->uart, youll also have translations from scancode to char to scancode going on
<clever>
as qemu turns a char from stdin back into a scancode for the virtual ps2 device
<heat>
what ps2 routing? I don't want ps2 routing
<clever>
depending on the mode, qemu may route the vga text console to stdout, and stdin to a virtual ps2/usb device
<clever>
for guests that lack a proper serial console
<clever>
it would let you interface with linux/dos in text mode, without having to configure a proper serial console
<clever>
or anything else using the legacy bios IO
<klange>
Does -nographic does that? I know -curses does
<klange>
do* for at least one of those doeses
<klange>
My input went to serial, but maybe that's a multiplexing thing
<clever>
ah yeah, -nographic does monitor+serial on stdin+stdout, with ctrl+a as the escape key to swap between monitor and serial
zaquest has quit [Remote host closed the connection]
<clever>
while -curses does it via vga/ps2 i think
zaquest has joined #osdev
<klange>
I have a bunch of other flags before -nographic, I do know it spits out vga text at least
<klange>
qemu has way too many args with complex interactions
<clever>
ive also configured qemu with both vnc and spice at the same time
<klange>
which the maintainers are well aware of, which is why a lot of the shortcuts are being deprecated slowly
<klange>
which is also kinda unfortunate because it means you need to wire up the complicated stuff yourself
<clever>
yeah, its broken some of my testcase scripts
<clever>
where i had the ability to boot a guest over raw pata, sata or nvme, with or without uefi
<klange>
vnc is fun since it needs a tablet device and the manual would have you believe it only works with the usb-tablet
<klange>
but the vmmouse works
<clever>
i never had to add either, it just works for me
<klange>
vmmouse is enabled by default
<clever>
for both linux and darwin guests
<klange>
vmmouse being enabled by default is kinda weird, especially when it's the vmware backdoor interface
aejsmith has quit [Remote host closed the connection]
<clever>
but i wouldnt expect vmmouse to work on a darwin guest
Coldberg has quit [Ping timeout: 245 seconds]
aejsmith has joined #osdev
<clever>
though, i did see an article about darwin having qemu drivers
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
<heat_>
my os supports multiple ttys now wooohoo
<klange>
ttys ttys or consoles?
<heat_>
ttys ttys
<klange>
excellent, that's helpful when you want a gui with a terminal app ;)
<klange>
or multiple serial ports... or a serial port and a vga console... or [you get the point]
<heat_>
i was mirroring the vterm onto serial but now I have an actual thing and I can use the terminal and test stuff through stdin
<heat_>
i did a huge hack where /bin/login forks and execs itself for every tty
<klange>
not the worst getty i've seen
<heat_>
because my init system doesn't support things like spawning a getty/login per tty
heat_ is now known as heat
<klange>
i just squirrel away a `getty /dev/whatever &` in when I need it, nothing properly automated yet
<clever>
ive done the same in linux before, with usb serial gadgets
<clever>
getty 0 /dev/ttyGS0 &
<klange>
the last script in my init has a set of switches that either starts getty on a qemu-fwcfg-specified tty, starts the vga text mode terminal, or launches the compositor
<clever>
could you feed it a whole script via fwcfg?
<klange>
Possibly, fwcfg does handle files, but usually I'd just slap the script in as an extra -initrd and specify it as either init on its own, or the argument to the compositor which is the general fallback "run this on startup"
<klange>
a lot of this stuff that I implemented ages ago and have avoided touching ever since :D
<heat>
init scripts D:
<klange>
they're not 'proper' init scripts, /bin/init just runs everything in /etc/startup.d one by one in alphanumeric sort order.
<heat>
i like my budget systemd
<heat>
so my budget-budget-launchd
<klange>
doesn't even need to be shell scripts, anything executable, but the shell is reasonably lightweight vs. pulling in kuroko, and the whole point is flexibility over having a C app do the whole thing
<heat>
yeah
<heat>
i've thought about adding init scripts as a wildcard of crap I may want to do and not add a pretty unit file
<heat>
and not have to add*
<klange>
My boot process at the tail end of kernel startup is to mount `root=` if it was set, then run either /bin/init or `init=` optionally with `args=` as the first argument.
heat has quit [Ping timeout: 250 seconds]
<klange>
And then /bin/init opens up three /dev/nulls and runs through /etc/startup.d in sorted order, if it exists; if it doesn't, it tries to run /bin/getty
<klange>
And then my startup scripts start a daemon to dump logs if it takes more than two seconds to get the end, rebuild the ramdisk as a tmpfs (which probably should not be a userspace thing but it is...), sets hostname, mounts more tmpfses, pokes lspci to find things to install kernel modules for...
<klange>
tries to mount the live CD, if a device pops up in /dev/cdrom, does dhcp, queries the package repository if network came up, tries to use a geoip service to get a timezone, tells the log daemon startup is done, and then launches the compositor or vga terminal or getty.
<clever>
klange: was just thinking, a fwcfg script would be simpler then something like an initrd, since you dont have to package it in a cpio
<klange>
i just use ustar archives
<clever>
that also works
<kingoffrance>
" with ctrl+a as the escape key" that's good, gnu screen compatibility ! :D
<clever>
kingoffrance: but now you need ctrl+ a, to send a ctrl+a to qemu!
<clever>
ctrl+a a
<clever>
it gets real fun when your nesting 3 or 4 screen sessions
<kingoffrance>
this is like the 5 volume controls from the unbreakable law :D
<clever>
unbreakable law?
<kingoffrance>
Casey Muratori did a video on conway's law
<clever>
ah
<Griwes>
I've done enough nested tmux/screen sessions that my tmux config has a keybind to disable the top level escape lol
<geist>
Re consuming handles
<geist>
Because if it didn’t consume a handle it’d be implicitly duplicating them
<geist>
And duplicating a handle is not an intrinsic right
<geist>
The model is that you’re placing the handle in the channel, attached to a message, so it’s no longer in the current process. If you want to retain a copy you have to duplicate the handle yourself, but you can only do that if you have the appropriate right to do so
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<heat>
qemu's serial0 monitor (in the GUI) outputs ^H for backspace
<heat>
but my terminal emulator works correctly
<heat>
how am I supposed to autodetect this?
<kingoffrance>
^H^H^H^H^H^H^H^H i thought that was normal for backspace in unixland :/
<kingoffrance>
thats why we snark^H^H^H^H^H make insightful comments using it
<heat>
(actually, linux seems to think otherwise, so I may have a bug somewhere)
<heat>
no, backspace is ^?
<heat>
^H is just "move cursor x backwards"
<heat>
the character isn't actually deleted
<heat>
snark^H^H^H^H^Hb
<heat>
= bnark
gog has joined #osdev
<heat>
this makes no sense, is there some translation I should be doing?
<heat>
doing stty -a on a linux installation through serial says erase = ^?, which makes no sense considering qemu is sending \b which is being interpreted correctly
<gog>
clang is ignoring __attribute__((sysv_abi)) in my build but seems to work correctly in godbolt using --target=x86_64-unknown-windows :\
<gog>
i am confuse
<gog>
same version, same flags
eddof13 has joined #osdev
<gog>
oh
<gog>
i found the problem :|
<gog>
it was me all along
<gog>
no it's still ignoring it :(
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<zid>
"It was me all along!" is gog's evil scientist catchphrase
<gog>
yes
<gog>
also i'm totally stumped here
ravan has quit [Read error: Connection reset by peer]
<gog>
for some reason it's eliding the __attribute__ during preprocessing
<GeDaMo>
You don't have a #define removing it, do you? :|
eddof13 has joined #osdev
<gog>
i'm wondering if the efi headers don't do something to cause this
<gog>
that's the only difference
<gog>
yep found it eficompiler.h:#define __attribute__(x)
<GeDaMo>
That's nice :|
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<gog>
i needed -fno-ms-extensions
<gog>
i swear i've run into exactly this before and forgot lol
<gog>
i hate gnu-efi so much
<gog>
i'm gonna have to write my own headers for this because i want nothing more to do with it
gildasio has quit [Remote host closed the connection]
mahmutov_ has quit [Ping timeout: 240 seconds]
gildasio has joined #osdev
mahmutov_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
<geist>
gog: agreed. i think that makes sense to do it from scratch, especially if you're only going to use a subset of the API
<gog>
yeah i only need it for a very short time and only a few protocols
<gog>
and now that i don't use libefi, don't need the call wrapper, or the ELF bindings for the fudged PE it's all needlessly complicated
<geist>
woot yeah
<moon-child>
I used cefi
<moon-child>
but it had padding bugs lol
<geist>
yah was gonna say we wrote our own custom one for fuchsia, but it's been refactor and turned into a template hell now i think, so not gonna bother trying to find it
<mrvn>
gog: Join us in 2017 and use [[attribute]]
<gog>
mrvn: can't seem to make that work with function pointer decls
<moon-child>
mrvn: [[]] is a lot uglier than the alternative though
<mrvn>
moon-child: ugglier than __attribute__, which then get #defined away?
<moon-child>
contents of [[]] are also subject to pp
<mrvn>
like everything. But efi headers are too old to know about gnu::ms_abi.
<mrvn>
The other thing you should do is turn the herader into c++20 modules.
<mrvn>
or "could do"
<mrvn>
Modules don't allow preprocessor stuff to escape anymore.
<gog>
i'm not currently using c++
<Griwes>
I don't know the full grammar rules for __attribute__, but I have it on good authority that parsing it is hell compared to [[]], because apparently it can appear in most places in the grammar, as opposed to [[]]
<bslsk05>
fuchsia.googlesource.com: zircon/kernel/lib/efi/include/efi - fuchsia - Git at Google
<geist>
looks like they're pretty clean, actually not a template hell
<geist>
and MIT licensed
<gog>
love too see long header guard macros :p
<gog>
#pragma once gang
<geist>
oh dont get me started
<geist>
i fought the pragma once battle and lost
<geist>
but... at least google has some dumbass precommit script or whatnot that'll autogenerate it for you and tell you it's changed because you moved a file (eyes roll)
<geist>
like, put a damn random UUID in it if you really want to do that
<geist>
heaven forbid you have symlinks or hard links to screw up the stupid path in it
<geist>
but those are probably forbidden anyway. not that i disagree with that
<mrvn>
geist: I kind of like "#prgama once" more than #define <something-to-make-this-unique>DIR_DIR2_DIR3_FILE_H 1
<geist>
100%. I've pretty much switched all my personal stuff to pragma once
<Griwes>
there's people who do builds over network shares or over bind mounts for whatever the hell reason who are on a crusade to ban #pragma once and I really want to slap them out of their ridiculous build environments
<geist>
yah it's always the same excuse, with no actual proof that it fails anymore
<geist>
and... i looed into at least how GCC does it, and it's literally the same machinery
<Griwes>
"#pragma once is fundamentally broken on my fundamentally dumb build environment" well then maybe just fix your goddamned environment to be sane
<mrvn>
geist: does one still need #pragma once with c++ modules?
<geist>
basically gcc preprocessor sees pragma once and then remembers in a cache that that file name/state/inode has already been seen
<Griwes>
to use c++ modules, one needs a good implementation of it in both a compiler and a build system
<Griwes>
and that has yet to really materialize
<geist>
the classic header does the same thing
<Griwes>
though we're getting there
<mrvn>
Griwes: yeah. it's on my to-do to test gcc on it.
<geist>
so at the end of the day it ends up with a table indexed by <filename, stat_data> -> <bool can skip> or something
<geist>
and it doesn't matter how you got there, either pragma once or the header guard. same logic
<geist>
it at least proves that the two mechanisms are the same speed but that also means nay sort of bad build environment would affect them the same
<Griwes>
okay. I was correct to write myself a syscall definition DSL when I had just 2 syscalls
<geist>
though i suppose.... if you had a bad build environment that defeated that cache, the old header guard's #ifdef would kick in
<moon-child>
what if they just hashed the file instead
<Griwes>
I'm now adding a third and it's *trivial*
<geist>
moon-child: the point is to avoid re-reading the file
<geist>
it literally skips opening it the next time
<moon-child>
sha is quite cheap
<geist>
sure, but again, trying not to even open the file
<Griwes>
opening a file and reading is much more expensive than not opening it in the first place
<moon-child>
I think main point is to avoid having to actually process the contained code
<moon-child>
cuz that's a lot more expensive
<mrvn>
geist: the path could differ depending in which directory you type "make"
<moon-child>
also you can do both
<Griwes>
no, the point of how it's implemented is to literally avoid opening the file
<geist>
mrvn: this cache is per instance. it starts all over again on the next gcc
<moon-child>
sha only where inode et al doesn't match
<geist>
it's basiclly as it's walking the header include tree, first time it sees it it adds the entry and then skips next time
<mrvn>
geist: but the path could be shorter and then 2 file have the same path while eing different.
<geist>
so doesn't matter how it was invoked, since it starts over again later
<geist>
mrvn: sure, in which case i think it falls back to inode #
<mrvn>
geist: I guess that's what stat_data is for but that could break with strange bind mounts.
<geist>
yeah it has 2 or 3 things it double checks
<geist>
but yes you're basiclaly constructing the crazy bad build environment that maybe defeats it
<mrvn>
nod. My opinion in such cases: Kill the build environment and not everybodies fun.
<Griwes>
yeah
<Griwes>
sadly both wg14 and wg21 have it in their consensus mind that those build environments are sacred and refuse to standardize these semantics
<mrvn>
If my source ever needs a "my_malloc()" to fix some systems broken "malloc" then that system just gets unsupported. period.
<Griwes>
but then thankfully #pragma once is literally supported on every compiler that matters for anything I am personally doing, sooooo
<geist>
agreed
<mrvn>
worst case #prgama once gets ignored and you get the header twice. If you are careful what you put in the header that's irrelevant too.
<geist>
what *doesnt* make any sense is to do both
<mrvn>
geist: urgs.
<gog>
lmao
<gog>
yes
<gog>
defeat the purpose entirely
<Griwes>
there's people who do *both*?!
<geist>
well, there was some point in time where it wa sassumed that some compilers didn't understand it so you can do both
<geist>
since i think an unknown pragma is suppoed to be ignored
<mrvn>
lol: <source>:1:39: warning: 'nodiscard' attribute can only be applied to functions or to class or enumeration types [-Wattributes] 1 | typedef void (*fptr)(int) [[nodiscard]];
<mrvn>
yeah, stupid user, don't discard my void. :)
<Griwes>
well, it's not a part of the type system, so you can't just put it on a type
<geist>
reminds me of another fun one i remember doing: trying to create a volatile function pointer
<geist>
IIRC i think you can't do it
<geist>
(or maybe we found a way and i just forgot)
<Griwes>
you mean having the pointer itself be volatile?
<geist>
yah
<mrvn>
geist: function pointers are highly abstract so hardware shouldn't mess with that. But why can't an interrupt handler change a function pointer?
<geist>
might be able to do it with a typedef but iirc it's one of those cases where you can't do it
<geist>
mrvn: that was the idea, some sort of pointer to a thing that might get switched at runtime
<mrvn>
typedef void (*fptr)(int);
<mrvn>
volatile fptr fn = nullptr;
<geist>
and it'd be okay of another thread was sloppy, but it should find the current pointer
<mrvn>
Not sure what you tried.
<Griwes>
<Griwes> --make-type volatile pointer to a function returning void and taking int
<Griwes>
<geordi> void (*volatile )(int)
<geist>
hmm, maybe that wasn't it
<geist>
it was something funky like that, but stumped a few engineers, so it must have been something trickier than that
<geist>
oh oh i know what it was. an atomic function pointer
<mrvn>
a function returning a volatile function pointer?
<geist>
(short of doing some casting to a uintptr_t and back)
<mrvn>
Urgs, that might not be supported by the hardware at all and C++ didn't have a workaround with locks.
<Griwes>
You mean a *C* atomic function pointer?
<mrvn>
function pointer is larger than uintptr_t.
<Griwes>
Because atomic<fptr> should just work
<mrvn>
Griwes: only recently.
<geist>
a pointer to a function that can also have atomic ops performed on it (cmpxcgh, swap, load with barrier, etc)
<Griwes>
What do you mean by only recently?
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mrvn>
Griwes: the CPU might not have an atomic to handle function pointers and then c++ needs to use a lock around it. That's new.
<Griwes>
C++ atomics always supported trivial types of arbitrary sizes
<geist>
yah but what's not obvious is doing a atomic load on a variable and calling it without writing some helper rouitine to do so
<Griwes>
Non lock free atomics are a c++11 thing
eddof13 has joined #osdev
<mrvn>
Griwes: function pointers aren't trivial types.
<Griwes>
is_trivial says they are
<geist>
bascically doing an atomic function pointer would be the new 'correct' way to have the pointer switched out from underneath the caller
<geist>
(vs a volatile one)
<mrvn>
Griwes: on every architecture?
<Griwes>
It's a type property, that's global
<Griwes>
Trivial just means you can memcpy it around for all ops
<Griwes>
Or rather, that a compiler can replace all ops with a memcpy
<mrvn>
Griwes: I'm pretty sure that wasn't working with c++11 back in the day.
<geist>
sure if that's a far function pointer or something you're in trouble
<geist>
unless of course your arch supports double compare/exchange
<Griwes>
atomic<> will just use a lock if the type is too large
<mrvn>
geist: normal function pointers can already need double compare/exchange.
<geist>
right. so again, i think this was Hard or Impossible to do without badger casting things around
<Griwes>
I don't think I've ever seen a function pointer require that
<mrvn>
Griwes: and my recollection is that c++11 didn't do the lock when the type was too large.
<Griwes>
*member* function pointers are often larger
<Griwes>
But those aren't function pointers (yes the naming is confusing)
<Griwes>
mrvn: maybe an implementation you were trying to use didn't implement that yet
<mrvn>
Griwes: make it worse: lambdas with capture.
<geist>
that's definitely not a function pointer though
<Griwes>
Yeah
<mrvn>
You might want to replace the function pointer with a callable.
xenos1984 has quit [Read error: Connection reset by peer]
<mrvn>
I don't think any system can handle callables without lock.
<Griwes>
Right but you can't do that without erasure and wider locking
<Griwes>
But that's not what we were discussing :p
<geist>
here was the use case: multiple cpus calling through a function pointer to get_current_time()
<geist>
as the system comes up it switches to a new mechanism
<geist>
short of stopping all the cpus, how safe is it to swap the function pointer?
<geist>
defacto it's totally safe, but you could imagine some other cpu that is say calling that in some loop (inside a spinlock or whatnot)
<geist>
and it might cache the old one for a long time
<geist>
of course this is probably just all a Bad Idea and you should not have the fucntion pointer like this to avoid the problem (that's the Real solution)
<mrvn>
geist: if it's just a single word then that's a simple atomic write. Don't even have to guard the read if calling the old function for a while is fine.
<geist>
yes but since the deref is embedded in the functoin pointer call you can't control how it reads it, or if it caches it etc
<geist>
so you can mark the function pointer as volatile so it keeps dereffing it
<Griwes>
That can tear
<geist>
but if you wanted it to actually do a barriered load...
<Griwes>
And is also ub unless you do external sync
<mrvn>
Makes me wonder: is volatile fn_ptr supposed to make an atomic read?
<geist>
becuase it's a true atomic pointer, you can't do it with the language without reinterpret_casting it r whatnot
<Griwes>
Volatile never does atomics in C
<geist>
the real answer is Dont Do This
<geist>
make a function that internally does a switch or whatnot probably
<mrvn>
Griwes: every read is observable. So it shouldn't be allowed to split the operation into 2 opcodes.
<Griwes>
It doesn't have to be split to teat
<Griwes>
Tear
<geist>
Rip and Tear
<Griwes>
It can be split below the opcode layer
<Griwes>
The real answer is don't use volatile for atomic ops
<Griwes>
Because even if it happens to work, it's ub
<mrvn>
Griwes: if that can happen then I could argue the compiler violated the volatile by using the wrong opcode.
<geist>
well, that's typically defined by the architecture (what words are locally atomic)
<geist>
and anything sane should at least in one memory transaction deal with words up through the usual pointer sized, assuming they're aligned, etc
<mrvn>
On the other hand "volatile BigUglyStruct" simply would fail to compile in that model because there is no atomic access to it.
<Griwes>
Volatile doesn't give you atomicity
<Griwes>
You need to get rid of that idea entirely
<geist>
no but it can cause the compiler to not cache local versions of it
<mrvn>
geist: std::atomic<fptr> fn = nullptr;
<mrvn>
geist: seems to work nowadays.
<geist>
rad
<geist>
what does the copiler do if you make a function call on it?
<heat>
is anyone familiar with serial tty that can tell me why \b works when the erase character is ^?
<geist>
ldar is a load with an acquire semantic i believe
<mrvn>
geist: now the fun thing should be playing with the memory model/constraints of that atomic.
<geist>
see in that last one, line 15 and 16?
<geist>
stlr is a store with release semantics
<geist>
and then a ldar right after it with acquire, so yeah
<mrvn>
default model is realease+acquire.
<geist>
yah
<geist>
anyway, so another mystery solved. maybe the problem at the time was we didnt' have std::atomic
matrice64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mrvn>
if you have struct Callback { fn_t fn; void *data; } ... callback.fn(callback.data, ...); then I guess you have to think about the release/acquire
<mrvn>
geist: or std::atomic<> didn't work for function pointers yet.
<geist>
yah if you're willing to use a doubleword atomic you can probably atomic that entire Callback
<mrvn>
imho callbacks always should have a data pointer.
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mrvn>
Can one make an atomic lambda? Some template hell construct because you can't specify the type of the lambda?
<geist>
yah dunno. probalby would have to make some sort of atomic std::funciton or whatnot
<geist>
but my ability to process c++ has hit its threshold today and my brain is shutting down
eddof13 has joined #osdev
xenos1984 has joined #osdev
<jimbzy>
How about some perl, geist?
<jimbzy>
I hear that's all the rage for OS developers...
eddof13 has quit [Client Quit]
kingoffrance has quit [Ping timeout: 240 seconds]
<heat>
ahhhh I see why the misconfigured tty was working
<heat>
busybox uses libedit which interprets both \b and DEL
<heat>
meaning that a misconfigured erase wasn't affecting anything since it wasn't in canonical mode
<Griwes>
mrvn: default for atomics is seq_cst, which is stronger than acq_rel because it requires a global single operation order
<mrvn>
Griwes: sorry, yeah. it's always the strongest by default.
<heat>
ahh okay I see how this works
<heat>
if /bin/agetty, when reading the login name, detects a \b or a DEL, it switches to one of the two when configuring the tty (and does the erase)
<heat>
if not, you're screwed and you need to do stty manually
<heat>
you won't detect that with bash and whatnot because it uses libreadline which handles both \b and DEL
<mrvn>
All that terminal meta programming needs to die out.
<mrvn>
Every programm needs to support 10000 different terminals and 99.9999999% of them only ever see linux and screen.
Raito_Bezarius has quit [Ping timeout: 240 seconds]
<heat>
you have the different variations of xterm, linux, screen, ansi, etc
<mrvn>
heat: do they even differ? In any way that you use more than once a decade?
<heat>
xterm and linux have a few differences
<heat>
ansi is way different from all the above as it only supports the really basic CSI sequences
<mrvn>
never used ansi. I used vt100 on broken systems and dumb.
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
Raito_Bezarius has joined #osdev
Raito_Bezarius has quit [Max SendQ exceeded]
heat has quit [Remote host closed the connection]
heat has joined #osdev
Raito_Bezarius has joined #osdev
Raito_Bezarius has quit [Max SendQ exceeded]
Raito_Bezarius has joined #osdev
GeDaMo has quit [Remote host closed the connection]
<geist>
heh i have a physical wyse50 terminal that thankfully there's still a table for
<geist>
since it's not really vt100 compatible
<mrvn>
I would maybe write a translation layer for that on the driver level so it appears to talk vt100.
<geist>
except there's no driver for it per se
<mrvn>
Not sure how that would work if you want to mix text and data transmission over the device though.
<mrvn>
geist: serial input I assume?
<geist>
yah
<mrvn>
something like "modprobe wyse50 tty=/dev/ttyS1" to add a translation layer over COM1. That would then give you /dev/ttyWYSE0
<mrvn>
But would have to figure out how that would work exactly when I need it.
<geist>
i suppose. seems like progress in a negative direction: adding a bunch of nonsense to thek ernel that doesn't need to be there
<mrvn>
but only when you need it instead of having every user app carry the load all the time.
<heat>
but ncurses works and you'll always have differences in terminals
<mrvn>
It's the software solution to: Stick this arduino between the computer and the terminal so it speaks vt100.
<mrvn>
heat: I would rather have a standard terminal everyone follows.
<heat>
ncurses can also have a better understanding of what you're trying to do, it's not just doing low level stuff
<heat>
that's not how things work
<mrvn>
wishfull thinking, I know.
<mrvn>
Maybe when I reach the stage where I want to port ncurces I will see a use for it.
<mrvn>
So far I've only done graphical apps (render the mandelbrot set) and console without cursor movement (print out dmesg on the screen) type of things.
<vin>
I want to store list pf offsets of a file to a new file. I know the max value fo the offset will be 1e12 so I just require 5B to store it. So here https://godbolt.org/z/TebarcW3v I am trying to convert a 8B uint to a 5B array and back to 8B uint, however converting it back to uint doesn't seem to work.
<bslsk05>
godbolt.org: Compiler Explorer
<vin>
*list of
<vin>
Any suggestions?
<mrvn>
what doesn't work?
<heat>
vin, your xtou64 is completely broken?
<mrvn>
bytes = (char*)malloc(5);
<mrvn>
Don't write C code in C++.
<heat>
1) your bytes array isn't null terminated but since you're testing for the null char it will stop at the first index
<heat>
2) what kind of math are you doing in char v =
<mrvn>
vin: Why do you want to convert a 5 byte integer to uint64 by assuming it's a hex string? That makes no sense.
<mrvn>
heat: magic for 0-9 and A-F conversion without branch.
<heat>
mrvn, but the bytes are being saved raw, no ascii
<mrvn>
heat: sure, totally the wrong function to call.
<mrvn>
vin: 1) replace char by uint64_t or bytes. 2) write the reverse of convert_off_to_charA
<vin>
Thanks! but what was wrong with usign char* ?
<mrvn>
vin: much more to type.
<vin>
Haha, okay
<mrvn>
+ it's an integer type with odd implicit conversions
<mrvn>
clang convert_off_to_charA is much longer than gcc. Both don't optimize convert_charA_to_off
<mrvn>
It's always surprising how different gcc and clang are for such trivial code examples.
SikkiLadho has joined #osdev
<mrvn>
what does "bfi" do on aarch64?
<mrvn>
bit field insert, nice.
X-Scale` has joined #osdev
<mrvn>
I wonder if gcc doesn't honor avoiding unaligned load/store while clang does.
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
* mrvn
adds -mstrict-align to the kernel CFLAGS.
<geist>
note that that will generally cause it to emit fairly suboptimal code
<geist>
arm64 code just implicitly assumes unaliged accesses, basically similar to x86, and will happily do so
<geist>
what you use strict-align for is when running in environments where the cache is disabled or whatnot (say pre-kernel boot) and you want it to be extra careful
<mrvn>
geist: isn't there a bit to make it fault on unaligned access like in 32bit?
<geist>
i think so but why do you want this?
<geist>
are you interested in reliving the 80s?
<mrvn>
gcc seems to assume that bit is off while clang assume the bit is on.
<geist>
sounds ike one is taking an optimization path and the other one isn't
<geist>
so it goes.
<mrvn>
with strict-align they produce the same code
<geist>
which is?
<mrvn>
the strb
<geist>
right, but that's the point. you've turned off the optimization on the one that was doing str
<geist>
you forced it to emit the lamer version of the code
<geist>
one was taking the optimization, one wasn't. now both aren't
<mrvn>
but one that works if the cpu fauls on unaligned access
<geist>
sure. but do you actually want to set that bit?
<mrvn>
yeah. I think I do.
<geist>
ARM64 pretty much assumes it's on. as you should too
<geist>
why?
<geist>
armv8 is designed to efficiently implement unaligned accesses. the bit is mostly there for backwards compatibility purposes, i suspect
<mrvn>
aligned access is faster and the compiler generates that per default. You have to do something UB or __packed__ to get unaligned access.
<geist>
not anymore. that was 1995 thinking
<geist>
modern cpus just do fine with unaligned stuff
<mrvn>
it's still (sometimes) slower.
<geist>
the only reason the bit exists is if you have to implement some sort of older mode, i guess. wouldn't be surprised if it's simply removed
<geist>
in future specs
<mrvn>
the deciding point for me is that it's UB.
<geist>
perhaps, but then that's probably mitigated by the fact that in all the other places the equivalent codegen would be worse to tiptoe around it
<geist>
alright. i've said my peace
<geist>
if you wanna run that way, go for it. while you're at it i think the bit is in SCTLR_EL1
<j`ey>
yeah, .A
<mrvn>
probably the same bit as in 32bit, just with ELx register.
pretty_dumm_guy has quit [Quit: WeeChat 3.4.1]
<geist>
yep. I think SCTLR is basically the same, though there may be more available in the 64bit version
elastic_dog has quit [Ping timeout: 250 seconds]
<j`ey>
MTE bits are in there too
<mrvn>
geist: if I see the code gen suffer for portable code I will drop it. But I like to start of with everything turned up to the strictest checking and only relax if needed.
<mrvn>
Other than extracting unaligned stuff from disk or network buffers this really shouldn't happen so I like to make sure.
<geist>
okey dokey. keep in mind you'll be using poptentially a less tested path in the compiler
<geist>
but you should really know the unalignment rules of arm64. it's slightly complicated
<mrvn>
will have to look that up. Wasn't bad for ARMv6.
__xor has quit [Read error: Connection reset by peer]
elastic_dog has joined #osdev
__xor has joined #osdev
<SikkiLadho>
I'm working on forwarding trapped SMCs to secure monitor/TF-A. When I just eret and smc, it goes into into infinite loop. By looking at the halfnium code[0], I learned that we have to increment elr_el2 to skip the smc call and then eret. I did the same and I get this error " Unable to handle kernel paging request at virtual address" from linux.
<bslsk05>
github.com: Leo/utils.S at 277fb982c638206126ee1fbda61a2f99fa26a41e · SikkiLadho/Leo · GitHub
<j`ey>
get_next_pc might clobber stuff
<j`ey>
which means when you eret back some register has incorrect state
<SikkiLadho>
let me write an assembly code for that and let's try again
<SikkiLadho>
thank you
<mrvn>
The way I write such code is to dump all registers to the stack. Then the values on the stack can and must be manipulated. To return everything is restored from the stack. Changes to registers have no effect then.
<mrvn>
once it works you can optimize to not save everything and manipulate registers directly.
__xor is now known as _xor
wootehfoot has quit [Quit: Leaving]
<Griwes>
I thought "oh I can rewrite this thing that currently works to allow me to write the code I want for the next thing I need to write, should be simple"
<Griwes>
well turns out that this "simple" rewrite now requires me to actually implement avl_tree::erase now
heat_ has quit [Remote host closed the connection]
heat_ has joined #osdev
<mrvn>
your choice of tree?
<klange>
Sakura would be the cliché answer here, or maybe bonsai, but I'm partial to baobabs.
<mrvn>
klange: we are talking about avl here
<klange>
That was a joke.
<mrvn>
my choice is walnut.
<klange>
I like the wood, but the trees themselves are kinda boring.
<mrvn>
isn't erase basically identical to insert? Find place, do op, rebalance on the way back.
* mrvn
looks ups avl trees for the details... The condition when rebalancing is done differs for insert and delete. too bad.
heat_ has quit [Remote host closed the connection]