LittleFox has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
LittleFox has joined #osdev
c2a1 has joined #osdev
<c2a1>
murderers live on irc
ecs has quit [Remote host closed the connection]
ecs has joined #osdev
<moon-child>
why do they call it oven when you of in the cold food of out hot eat the food?
<Mutabah>
moon-child: what did my brain do to you?
<moon-child>
every thing
dutch has quit [Quit: WeeChat 3.8]
mctpyt has joined #osdev
<mrvn>
it should be called pizza finisher
mctpyt has quit [Ping timeout: 248 seconds]
gog has quit [Quit: byee]
nyah has quit [Quit: leaving]
<kaichiuchi>
someone explain this to me, like I'm 5
<kaichiuchi>
why do I need to define _POSIX_C_SOURCE just because -std=c90?
<kaichiuchi>
I cannot understand the reasoning behind that at all
<kaichiuchi>
that... seems to be a POSIX requirement
<kaichiuchi>
I don't get it
<mrvn>
you don't. What gave you that idea?
<mrvn>
why would you even want such an outdated C standard?
<kaichiuchi>
"If you compile your programs using ‘gcc -ansi’, you get only the ISO C library features, unless you explicitly request additional features by defining one or more of the feature macros. See GNU CC Command Options in The GNU CC Manual, for more information about GCC options. "
<kaichiuchi>
you need _POSIX_C_SOURCE to be defined to get any of the fancy POSIX calls
<kaichiuchi>
and that gets defined if you use every goddamn -std flag other than c90/ansi
<klange>
Feature test macros are a standard thing. The default configuration of GCC uses a non-standard standard that predefines _POSIX_C_SOURCE (*depending on the target platform)
<mrvn>
yes. But a) you don't need those fancy functions and b) as you saw that problem exists without -std=c90
<kaichiuchi>
i do need those fancy functions
<kaichiuchi>
because I need clock_gettime
<kaichiuchi>
can't use clock_gettime without it
gildasio has quit [Remote host closed the connection]
<kaichiuchi>
and maybe I want to use -ansi for this project
<klange>
Actually, _POSIX_C_SOURCE should not be enabled by default in any configuration?
<mrvn>
kaichiuchi: that's your choice but not a requirement.
<kaichiuchi>
klange: i don't understand
<mrvn>
and if you define it you need to define it to some date
<kaichiuchi>
what you're telling me is everyone and their mother defines _POSIX_C_SOURCE even if -std=gnu17?
<klange>
I believe there's a specific header somewhere that does it based on certain configurations.
<mrvn>
kaichiuchi: gnu17 is new enough I believe to have all your fancy posix functions
<klange>
But yes, you should not give a rats ass what -std is, you should define what you need.
<kaichiuchi>
so you're saying I should just -D_POSIX_C_SOURCE=200809L and be done with it
<kaichiuchi>
because that's what I'm doing now
<mrvn>
kaichiuchi: that's a possibility. But what I'm saying is that you should use a modern C standard where you don't need that.
<mrvn>
where possible
<kaichiuchi>
can't
<klange>
under the -std=gnu options, there are some default defines that will be picked up _by glibc's headers_ and enable _POSIX_C_SOURCE by default.
<kaichiuchi>
vomit inducing
<kaichiuchi>
you can't tell the compiler to enforce standards compliance *and* allow POSIX calls
<mrvn>
kaichiuchi: it explains all the defines you can do and what their values mean.
<klange>
that's "whatever the platform is supposed to have by default, just give me that, none of this _POSIX_C or _GNU or _BSD bullshit I have to deal with otherwise"
<klange>
I linked that already!
<kaichiuchi>
klange: that's PERFECT
wgrant has quit [Quit: WeeChat 3.5]
<mrvn>
klange: It's best to remmeber that POSIX is documentation of existing insanity. :)
<klange>
half that, half "the existing insanity is too insane, so here's new insanity you can strive for to replace it"
<klange>
(there's plenty of stuff in POSIX that was designed just for the standard and _then_ implemented)
<gorgonical>
I just played with the ggtags emacs frontend to global and it's really good
<gorgonical>
I have been using cscope for years
<gorgonical>
is there a better way to associate sdcards with /dev/* identifiers? I get fear everytime I write images to sdcards because I'm worried Linux has re-assigned the drive letters without telling me and I'm about to nuke something
<gorgonical>
I compulsively check dmesg to see what the sdcard registers as
elastic_dog is now known as Guest7591
Guest7591 has quit [Killed (cadmium.libera.chat (Nickname regained by services))]
elastic_dog has joined #osdev
<ddevault>
I just do dmesg | tail when I hotplug a storage device, gorgonical
<gorgonical>
Yeah
<gorgonical>
I've tried some kind of rules for fstab but they aren't as reliable as I'd like
<ddevault>
maybe use UUIDs
<ddevault>
/dev/disk/by-uuid if you have (e)udev going
<klange>
Depending on your configuration, there's also alias that go by hardware in 'by-path'.
<klange>
so you can see like pci-xxxx:xx:xx.x-usb-x:x:x.x-scsi-x:x:x:x or wahtever.
<kazinsal_>
we had to deal with a weird hypervisor/LVM issue recently that involved SCSI LUNs changing out from underneath us, and the solution involved an extremely early bootup script before LVM started to parse /dev/disk/by-uuid and change the LVM metadata cache
<kazinsal_>
fucking acropolis
bauen1 has quit [Ping timeout: 260 seconds]
gorgonical has quit [Remote host closed the connection]
fedorafan has joined #osdev
AttitudeAdjuster is now known as aoei
danilogondolfo has joined #osdev
doppler has quit [Ping timeout: 265 seconds]
mlombard has quit [Remote host closed the connection]
dminuoso has left #osdev [WeeChat 3.7.1]
bauen1 has joined #osdev
gog has joined #osdev
danilogondolfo has quit [Remote host closed the connection]
<mrvn>
kazinsal_: I find anything but disks UUID is fragile.
<mrvn>
if the NIC breaks all your by-path can change
<clever>
mrvn: similar for NIC names, i find mapping eth0 to a given mac far more reliable
<clever>
my nas is nasty, and the "predictable" inteface names change if i add a sas card
gog has quit [Quit: Konversation terminated!]
<ghostbuster>
nasty nas would be a good rapper name
gog has joined #osdev
bauen1 has quit [Ping timeout: 256 seconds]
xenos1984 has quit [Ping timeout: 260 seconds]
gog has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
gog has joined #osdev
dude12312414 has joined #osdev
masoudd has joined #osdev
immibis_ has quit [Ping timeout: 252 seconds]
unimplemented has quit [Remote host closed the connection]
immibis_ has joined #osdev
immibis_ has quit [Remote host closed the connection]
immibis_ has joined #osdev
unimplemented has joined #osdev
gog has quit [Ping timeout: 256 seconds]
<raggi>
i map my network devices by mac to meaningful names, so on my router i have `internet` and `lan` and `backup` and so on, and no 0 suffixes because i can always add a suffix if i ever add a duplicate of something
slidercrank has quit [Ping timeout: 260 seconds]
micttyl has quit [Quit: leaving]
gog has joined #osdev
foudfou has quit [Ping timeout: 255 seconds]
Vercas has quit [Remote host closed the connection]
gabi-250 has quit [Remote host closed the connection]
gildasio has quit [Remote host closed the connection]
gabi-250 has joined #osdev
foudfou has joined #osdev
gildasio has joined #osdev
bauen1 has joined #osdev
Vercas has joined #osdev
qubasa has joined #osdev
masoudd has quit [Ping timeout: 252 seconds]
gorgonical has joined #osdev
unimplemented has quit [Read error: Connection reset by peer]
aejsmith has joined #osdev
srjek has quit [Ping timeout: 252 seconds]
epony has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
slidercrank has joined #osdev
xenos1984 has quit [Ping timeout: 260 seconds]
foudfou has quit [Ping timeout: 255 seconds]
foudfou has joined #osdev
DanielNechtan is now known as bombuzal
dutch has joined #osdev
spikeheron has quit [Ping timeout: 252 seconds]
xenos1984 has joined #osdev
<ddevault>
arguing with a dimwit in a local hackerspace channel over how "disruptive" ChatGPT will be
<ddevault>
told him to pose it a problem I recently dealt with and see how it fares
<FireFly>
(even though the latter was a png it seems, lol, either way it works)
<Bitweasil>
Oh, neat, that's good to know. Thanks!
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
<kof123>
that's good, it means the art has advanced over the centuries. "pray, if i put the wrong figures in, will the right answer come out?" <face palm> "i am unable to comprehend what would lead to this line of reasoning" </face palm> (babbage paraphrase)
bgs has quit [Remote host closed the connection]
SGautam has quit [Quit: Connection closed for inactivity]
\Test_User has quit [Remote host closed the connection]
vdamewood has quit [Remote host closed the connection]
\Test_User has joined #osdev
vdamewood has joined #osdev
<x8dcc>
hello, I added and IDT and keyboard interrupts to my kernel, and now I can read keys when they are pressed. I wanted to add a simple getchar function but I am not sure what's the best way. Any ideas or resources?
<geist>
yay. well generally the simple idea is build some sort of queue of N chars
<x8dcc>
I can share the repo link in case anyone is interested, but for now it only displays the chars being received
<zid`>
yea make it read a dude from the buffer
<geist>
and have teh interrupt handler put new keys in the queue, and getkey reads out of the queue
<zid`>
the 'edge' case is empty buffer, where you 'wait'
<geist>
obviously you can run out of space, etc, but functionally that's what happens when yo uhave a device that you can't apply back pressure to (ie, can't stop the user from typing)
<zid`>
if(empty()) hlt(); or whatever if you've not got multiple tasks yet else yield()
<x8dcc>
well I thought about that, but I would need 2 buffers, right? fill the getchar buffer when the user presses return
<zid`>
getchar doesn't care about \n
<zid`>
if you're used to thinking it does, that's because you're playing around in line buffered terminals
<x8dcc>
what I mean is that when a program calls getchar, the program waits for input until the user sends return
<zid`>
that's get..string
<x8dcc>
the program doesnt wait, but you know what I mean
<zid`>
line
<geist>
or you can call it something else (keyboard_get_char()) or something and layer some sort of buffering on top of it
<geist>
but the gist is the lowest level is keyboard puts keys in a queue, something else reads from it
<geist>
if you want to add more layers, that's fine, but the basic mechanism is the same
<x8dcc>
I dont mean that, zid`
<x8dcc>
when you call getchar from a c program, and type from the terminal, the program doesnt receive the first key press of the user, it receives the first char that the user typed once the user ends the line with return
<x8dcc>
afaik thats not related to the program but to the terminal or something like that
<geist>
yeah, but that's because of higher level line buffering. you'll eventually want to do that
<zid`>
yes exactly like I mentioned
<zid`>
getchar() does't care about \n, if you're used to experiencing it as though it does, it's because you're using line buffered terminals
<geist>
but i'd take it one step at a time, the first step is to queue the keyboard events
<x8dcc>
hmmm I see
<x8dcc>
I might be getting ahead of myself
<x8dcc>
I just wanted to add it this way for consistency, so I can use the getchar I am used to
<geist>
that line buffering stuff (and line editing capability) is the terminal emulation ish layer. it's complicated, so a bit hard to describe in one line, but it's basically 'user space'
<heat>
or kernel space in unix
<geist>
yeah, for right now that's a lot more work than you probably want, so you'll most likely have to deal with not having any of that line buffering, but you can at least buffer the kernel
<x8dcc>
I didn't want to add line editing, but I see what you mean
<heat>
praise be the TTY
<geist>
heat: yeah that's why i put it in quotes, so as not to confuse. idea is it's 'user space' in the sense that it's in the service of user programs
<x8dcc>
well I also made other functions for getting held keys, disable character output, etc. so I am pretty happy for now
<heat>
cool
<geist>
x8dcc: yeah basically think of line editing (handing backspaces, etc) as part of the same mechanism that usually the tty/pty/etc subsystems handles
<x8dcc>
I will try to add the simple queue system and then I will worry about line buffering
<x8dcc>
which by the way I didn't know it was its own concept, so thank you
<geist>
x8dcc: if you dont want to confuse, i'd start by calling it not getchar() like, keyboard_getc() and then you can build your getchar() queue on top of it later
<x8dcc>
yeah, I already wanted to do that
<x8dcc>
It's how I did my malloc and free
<x8dcc>
just simple wrappers for the kernel stuff
<zid`>
super distantly eventually mega not-now you will eventually convert it to a file
<x8dcc>
what do you mean?
<zid`>
getchar is a macro for fgetc(stdin)
<x8dcc>
oh yeah, add stdin
<x8dcc>
I am scared of that, obviously
<geist>
sounds good, yeah thats a good way to think. a common problem folks bump into when they first get started is trying to accomplish user sace level things they're used to in one layer
<heat>
getchar is not a macro
<zid`>
Description
<zid`>
2
<zid`>
The getchar function is equivalent to getc with the argument stdin.
<x8dcc>
geist: yeah, although I try to not get ahead of myself, I also want to add a lot of stuff :)
<heat>
that is not a macro
<zid`>
yes it is
<heat>
it is not
<zid`>
not a literal C macro, but it's still a macro
<heat>
it is a function
<heat>
you can't legally implement functions as macros
<zid`>
okay?
<zid`>
now read what I just said
<heat>
ok
<geist>
it's kinda an important distinction, especialyl when talkig around folks that want to implement it
<x8dcc>
heat: can you explain that? what do you mean by implementing functions as macros?
<heat>
x8dcc, #define getchar() fgetc(stdin) is illegal
<zid`>
C has macros, you can make function like macros
<x8dcc>
I know about C macros
<heat>
because then e.g &getchar makes no sense and errors out
<x8dcc>
but I didn't know what heat just said was ilegal
<x8dcc>
oh, I didn't think about that...
<zid`>
half the floating point functions *are* macros though afaik
<x8dcc>
I probably used that define method for simple wrappers in the past and I didn't think about that
<geist>
in general it's illegal, because if it's a function someone may want a function pointer to it, but there are a few exceptions where X is traditionally implemented as a macro, and so can be implemented that way
<x8dcc>
not for this os project, tho
<zid`>
and afaik it's legal but you *also* have to provide a function
<x8dcc>
geist: I see now, thanks
<geist>
i forgot the obvious example. is it printf? puts? there was one of them that *was* implemented as a macro back in the day, and thus tends to get mentioned in man pages as 'can be implemented as macro si not valid to take an address of'
<zid`>
and you can suppress with (f)
<x8dcc>
I wanted to add a simple piano program that reads key states to play with the pc speaker frequencies :^)
<zid`>
&(f) gives you the function, f gives you the macro
<x8dcc>
the real osdev spirit if you ask me
<zid`>
so yes, both is a macro, and it's also legal for it to be a macro :P
<heat>
does qemu even emulate the pc speaker?
<zid`>
in C terms
<x8dcc>
yes, heat
<x8dcc>
you might have to do some tweaking if you don't use pulseaudio, but it's just a line in my makefile
<zid`>
spec even talks about doing #undef abs and stuff
<zid`>
and whether function-like macros are allowed to different in sequence pointing wrt real functions
<zid`>
He un-singed it too btw, so it's recovered from its nasty burns
Piraty has quit [Remote host closed the connection]
<geist>
also realloc can take a null
gxt has quit [Ping timeout: 255 seconds]
<heat>
the point is that abort is void abort(void); and your thing is a panic function and not abort
dra has quit [Ping timeout: 246 seconds]
Vercas has quit [Remote host closed the connection]
Vercas7 is now known as Vercas
<geist>
suggestion: when doing low level bringup and starting to implement things that are C standard lib, either follow them to a T, or use a different name. mostly because compilers like to do builtin stuff
LittleFox has joined #osdev
<geist>
which is basically what heat is saying
<x8dcc>
yeah, I don't know why I forgot about that
<geist>
i prefer, panic(str, ...) personally
Piraty has joined #osdev
<x8dcc>
I forgot that abort is it's own thing outside my os
<x8dcc>
I should add a separate panic, I agree
<geist>
one that bit me early on, for example, was puts() and printf()
<x8dcc>
I know my printf probably sucks but please don't bully me
<geist>
since compilers know about puts they like to replace printf calls with puts if what your printing is simple, etc
Piraty has quit [Client Quit]
<geist>
so then you find out that puts() sticks a \n at the end, because.
<heat>
yeah, all these names are reserved for the impl and the toolchain can safely assume its behavior
<geist>
obviously you can (and maybe should) compile with -fno-builtins, but then that can leave some performance on the table
<heat>
-fno-builtin* btw
<heat>
I disagree. -fbuiltin is universally good
<gog>
explain
<heat>
else the compiler can't even assume memset, memcpy, memmove are sane
<gog>
o
<x8dcc>
I feel like I am being judged by the old shamans of the tribe
<geist>
agreed. my point was when you first get started you might want to do -fno-builtin, but then probably want to eventually make sure your stuff is safe
<gog>
but then it wasn't invented here
<x8dcc>
isn't puts supposed to add a newline? :((
<geist>
it does, so for example compiler can replace printf("what what\n"); with puts("what what")
<x8dcc>
oh, okay okay
<heat>
also fwiw memset, memcpy, memmove and some other are explicitly required to be sane and with standard semantics by gcc/clang
<acidx>
it saves a byte in the .rodata section, look at that!
<geist>
a winnar is you!
<geist>
everyone gets a winrar
Piraty has joined #osdev
moberg1 has quit [Ping timeout: 264 seconds]
moberg has joined #osdev
<x8dcc>
heat: I don't know what you are saying but I am sorry D:
<heat>
acidx, the big win is that you avoid going through printf machinery
<acidx>
heat: I know :)
gxt has joined #osdev
<geist>
x8dcc: you'll want to implement at least unoptimzed memset/memcpy/memove routines fairly soon, but when you do they're super implrtant you get absolutely correct
<geist>
including things like the memcpy/memmove overlap semantics, etc
<heat>
oooh TIL __builtin_clear_padding
<acidx>
implement memmove() correctly and alias memcpy() to it
<acidx>
worry about perf later
<geist>
right, that's an example of implementing it correctly
<heat>
x8dcc, " GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp. Finally, if __builtin_trap is used, and the target does not implement the trap pattern, then GCC emits a call to abort. "
<x8dcc>
mand I just wanted a piano this is depressing me slowly lol
<x8dcc>
heat: thanks I will do my best
<gog>
there are short public domain implementations in the libgcc source
<geist>
x8dcc: aww, no we're saying this cause we're excited for you
<geist>
seems like you're making good progress so it's exciting to see someone else join the club
<x8dcc>
I know, I was *kinda* joking
<x8dcc>
I rather know my mistakes, obviously
<kof123>
" and type from the terminal, the program doesnt receive the first key press of the user" yes, this buffering is explained in a unix manual as a gnome, deep in the system, takes your characters and stores them in a safe place
<x8dcc>
yeah, is what I have been thinkng about, but I didn't exactly know how to implement this line buffer system
<x8dcc>
as geist said, I need to focus on doing whats important first
<bslsk05>
man7.org: setbuf(3) - Linux manual page
* geist
banishes setbuf
<clever>
x8dcc: at least on POSIX systems, the setbuf() call configures how buffering happens on a FILE*
<geist>
do yo uneed line buffers?
<x8dcc>
clever: oh that's interesting, I didn't even know that existed
<clever>
i think thats implemented within glibc
<zid`>
setvbuf null blah blah
<clever>
where it will read() too much data from the kernel, into a large buffer
<clever>
and then feed lines back to the program
<zid`>
the hard part is tricking isatty
<clever>
yeah, tty's have their own kernel-side buffering and line editing
<clever>
and depending on the smart terminal (emulator), it might be line-editing on the other end of the uart
<clever>
but a lot of things (readline) just turn that off, to have better control
<x8dcc>
very interesting
<heat>
it is interesting
<heat>
but it alo sucks
<heat>
also*
<aoei>
ttys are cursed
<clever>
i dont think arrow keys work on the kernel tty buffering
<clever>
but it echos the arrows back to the client, so it may look like it worked
<heat>
implementing tty and vterm semantics is the least fun i've had doing this shit
<heat>
clever, arrow keys just output cursor up/down/left/right
<x8dcc>
yeah, I thought arrow keys and shifting the buffer and all that would be a mess
<x8dcc>
well at least I don't think thats so important for me atm
<clever>
i think the kernel buffering only supports backspace
<clever>
and when you hit enter, the final line is send to userland, as one read()
<heat>
yes
<clever>
but for readline to implement something better, it turns that buffering off, so read() returns every single key
<heat>
x8dcc, anyway we're being strict because kernel development requires strictness and you don't seem clueless
<heat>
if you were clueless we wouldn't blabber about "hurr durr must not be macro"
<x8dcc>
I always wondered how ncurses stuff worked for example, like raw() and noecho(), guess its something like clever just said
<x8dcc>
heat: I understand, thank you
xenos1984 has quit [Read error: Connection reset by peer]
<clever>
x8dcc: run `stty -a`, that will print every flag you can set on a tty, and the current settings
<heat>
geist, oh yeah btw have you folks tried to get something like user pointer tagging with the compiler itself?
<clever>
ncurses, readline, modify a lot of those flags
<zid`>
WHAT why is there a mosquito in here, it's been in the negatives all week and it's winter
<zid`>
where the hell did it hatch from
srjek has joined #osdev
<clever>
and a common problem, is for them to not be restored if you -9 vim
<heat>
geist, like linux's "void foo(char * __user buf)"
<corecode>
hi
<clever>
which leaves the terminal in a weird state
<heat>
corecode, hello
<x8dcc>
clever: didn't know about `stty -a` :o
<clever>
c2d vm # cat /home/clever/builds/temp_daemon/c2d_fix
<clever>
stty < /dev/ttyUSB0 raw -echo
<clever>
x8dcc: back when i wrote my thermostat stuff, i never figured out the right syscalls, and wound up just using this to fix things
<heat>
I know there's a standard GNU attribute noderef which /helps/, but you can still implicitly convert the pointers I think. linux's sparse adds named address spaces to stop this
<x8dcc>
clever: yeah, killing a ncurses program without endwin()... all makes sense now
<corecode>
every now and then i'm looking for scripting language implementations for embedding into small microcontrollers, and it's always disappointing
<clever>
if i was to improve things more, i would just strace this cmd, and replicate what its doing
<heat>
corecode, how small?
<corecode>
i think it's always down to FORTH
<heat>
lua is pretty small
<corecode>
lua claimed 256KB flash requirement
<clever>
zid`: i had a fly problem a few months ago, tracked it down to some wood rotting in the wall, it looked like a compost bin pouring out of the baseboard