klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
[itchyjunk] has quit [Ping timeout: 264 seconds]
[itchyjunk] has joined #osdev
SpikeHeron has quit [Quit: WeeChat 3.6]
gog has quit [Quit: byee]
<moon-child> heat: pls no ioctl
<moon-child> make an actual interface
<heat> bpf + io_uring it is
<moon-child> no dtrace?
<heat> this is the linux school of API design
<heat> dtrace = cringe, downvoted, bluepilled
gog has joined #osdev
<moon-child> :\
<moon-child> io_uring is cool tho
<moon-child> and so is dtrace
<moon-child> why can't we just all get along
<heat> people say ioctls are bad but I haven't seen any alternatives
<mjg_> based and red pilled
<CompanionCube> that 'dtrace for windows' is more of an official thing than on linux will never not be funny
<heat> seriously though, what alternative do you have for ioctls?
<heat> i cannot think of any that doesn't involve adding arbitrary system calls (doesn't replace ioctls in the slightest) or write structured records to magic fds (horrible interface, not UNIXy at all)
<mjg_> depends, any specific ioctlds you have in mind?
<mjg_> key problem with ioctls is utter lack of type checking
<moon-child> who says we have to be unixy?
<heat> lets say DRM syscalls
<moon-child> but yes, even within the land of unix, the main problem is that ioctl is not really an interface
<mjg_> which would be solved even with json :p
<moon-child> rather, like syscalls, it's something that can be used to _implement_ an interface
<moon-child> the problem is that people never actually spec out and implement that interface
<mjg_> created a structured key-value crapper to pass around, provided it does not have high call rate, would be fine
<heat> s/syscalls/ioctls/
<moon-child> greenspun claims another victim!
<mjg_> then you could validate the caller passed eerything as needed, pretending this is a higher level lang
<heat> I cannot think of a world where you would convert "do a function call and pass a pointer to a struct" to something else
<heat> json would not work because that's slow and then you can't play vidya games
<moon-child> heat: well take efi as one example
<moon-child> is it good? Pretty? Hell no
<moon-child> but it does a way better job of service discovery than unix
<heat> i would say its both of those things
<heat> its good because it gets the job done
<heat> and the design is elegant and solves the problem quite effectively
<heat> ioctls arent elegant, but they also get the job done
<heat> could you do some sort of weird argument marshalling? maybe? but that is weird
<moon-child> you said 'what's the alternative to ioctls? I can't think of anything' so I provided one example
<heat> you did?
<moon-child> didn't I?
<moon-child> the efi uuid thing
<heat> but it doesn't work across a privilege boundary
<heat> if you did something EFI-like, you'd need to at the end of the day, use something ioctl-like
<moon-child> again: the problem is not using ioctl to implement interfaces, the problem is when ioctl _is_ the interface
<heat> yes it is
<heat> it's not just ioctl being a bad interface
<heat> linux security modules have real issues cracking into ioctls
<heat> seccomp ebpf can't effectively inspect ioctl arguments because who knows what underlying fd that fd is?
SpikeHeron has joined #osdev
<heat> who knows if a magic ioctl number conflicts with anything else?
AndroUser2 has quit [Ping timeout: 264 seconds]
AndroUser2 has joined #osdev
<heat> I could see some sort of interface-description API (filesystem? syscall for every fd?)
<heat> but I don't know how effective that would be
<moon-child> 'seccomp ebpf can't effectively inspect...' yep. And there you see the cracks start to form. For the syscall interface _is_ an interface, so you can't avoid making ioctl part of it
nyah has quit [Ping timeout: 268 seconds]
joe9 has joined #osdev
<mrvn> You kind of need DTTI
<mrvn> RTTI
<mrvn> .oO(Lets rewrite linux as c++)
AndroUser2 has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 268 seconds]
\Test_User has quit [Quit: .]
AndroUser2 has joined #osdev
\Test_User has joined #osdev
<bslsk05> ​en.wikipedia.org: Greenspun's tenth rule - Wikipedia
[itchyjunk] has quit [Remote host closed the connection]
<moon-child> how do I tell the compiler to just emit a damn cmov, I promise I know what I want? :P
AndroUser2 has quit [Ping timeout: 264 seconds]
AndroUser2 has joined #osdev
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #osdev
<zid> -march=prescott? :P
<moon-child> nah I found the problem
<moon-child> I was saying cas(p?a:&(int){0},...)
<moon-child> swapped out for int tmp;cas(p?a:&tmp,...) and got what I wanted
<moon-child> stupid, but it does make sense
<zid> is there a reason you're writing it like an IOCCC entry
<moon-child> oh, just codebase convention
<bslsk05> ​github.com: jsource/ct.c at master · jsoftware/jsource · GitHub
<zid> the codebase convention is that spaces are illegal?
<moon-child> hey, vertical whitespace is a precious commodity
<moon-child> and when you're conserving vertical space by expanding horizontally, horizontal whitespace becomes precious too
smach has joined #osdev
smach has quit [Client Quit]
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #osdev
<dh`> in bsd all ioctl numbers are system-wide unique and not per-device
<dh`> (the number also encodes some minimal information about the typing)
<moon-child> Interesting, how does that work? Like, bottom n bits are a serial number, top n bits encode argument/result types?
<clever> dh`: ive seen linux not doing that back fire hard, i was poking around with the vc4 driver on a desktop with amdgpu, and the userland mesa code tried to query the vc4 version with an ioctl
<clever> dh`: but that ioctl clashed with an amdgpu ioctl, which then dereferenced a null-ptr in kernel mode!
smeso has quit [Quit: smeso]
smeso has joined #osdev
<JerOfPanic> hi
<linkdd> considering this linker script: https://bpa.st/GYQA is it normal that the symbol `kernel_section_end` has the value 0x4000002bb ? it seems too big...
<bslsk05> ​bpa.st: View paste GYQA
<zid> what's the value of sbss and ebss
<linkdd> let me check
<linkdd> sbss is 0x0, and ebss is equal to kernel_section_end
<zid> then .bss is that big
<zid> and that's why kernel end is that big
<linkdd> >16GB?
<zid> apparently
<linkdd> the binary of my kernel is only 45kb
<zid> well bss is specifically not binary, but sbss being 0 is also odd tbh
<zid> because it should be say, 45kB
<zid> what are you using to show these values, nm?
<linkdd> i just print them in my kmain function
<zid> yea I'd go with nm
<clever> linkdd: do you have a map file? -Wl,-Map=foo.map
<linkdd> clever: no
<linkdd> i have debugging symbols though
<linkdd> -g
<clever> linkdd: be careful, `printf("%d\n", sbss);` will re-reference the sbss addr, and print the int at the front of .bss
<clever> linkdd: try adding a map file to the linker args, and then pastebin that
<zid> which is why I'd go with nm, rather than relying on potentially unreliable code
<zid> also printf might just be buggy
<linkdd> clever: i `itoa()` the uintptr_t value into a buffer and print that buffer, i have not yet implemented printf
<zid> linkdd: just run nm real quick?
<zid> `nm kernel.elf` or whatever is all you need to do
<bslsk05> ​bpa.st: View paste 2EQA
<zid> 000000000010e002 B ebss
<zid> 000000000010e002 B kernel_section_end
<clever> linkdd: how is sbss defined in the .c/.h file?
<zid> it's fine, your printf or whatever is buggy
<zid> not doing &sbss, or a bug in the conversion, etc
<zid> like clever said
<clever> and how exactly are you running itoa on it
<linkdd> extern uintptr_t sbss;
<clever> linkdd: that tells gcc, that you have a pointer located at the front of .bss
<linkdd> char buf[128]; // memset, then: itoa(buf, (uint64_t)sbss, 16);
<clever> and you then read a pointer, fron the start of .bss
<zid> You need to take the *address* of symbols, it's kinda weird
<clever> your not getting the address of bss, your getting the first 64 bits in the bss
<linkdd> oh
<zid> but makes sense if you think about it
<linkdd> yes, that's like symbol vs [symbol] in asm
<linkdd> lol
<linkdd> i should go to bed
<clever> yep
<zid> [04:55] <zid> not doing &sbss / <clever> linkdd: be careful, `printf("%d\n", sbss);` will re-reference the sbss addr
<zid> Also I recommend running nm *first* next time, rather than trying to from the top of the stack (your printf'd output), go from the start/middle to find *when* the issue occurs
<zid> you were acting like it was definitely broken inside the ELF, but hadn't actually tested it
<linkdd> &ebss: 0x10r002 / &sbss: 0x104000
<linkdd> seems legit
<linkdd> ah nono, i was just questioning the values i had and the process i followed to get those values
<zid> yea but you didn't check whether the process was giving the right numbers yet
<zid> so questioning the process was pointless
<linkdd> s/process/workflow
tarel2 has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
scoobydoo has quit [Ping timeout: 248 seconds]
scoobydoo has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
FatAlbert has joined #osdev
nj0rd has quit [Quit: WeeChat 3.6]
nj0rd has joined #osdev
scoobydoo_ has joined #osdev
moberg has quit [Ping timeout: 248 seconds]
scoobydoo has quit [Ping timeout: 268 seconds]
scoobydoo_ is now known as scoobydoo
scoobydoo_ has joined #osdev
scoobydoo has quit [Ping timeout: 244 seconds]
scoobydoo_ is now known as scoobydoo
FatAlbert has quit [Ping timeout: 264 seconds]
tarel2 has quit [Ping timeout: 252 seconds]
krychu has joined #osdev
moon-child is now known as deepa
deepa is now known as moon-child
darkstardev13 has quit [Remote host closed the connection]
bauen1 has joined #osdev
darkstardev13 has joined #osdev
bauen1 has quit [Read error: Connection reset by peer]
darkstardev13 has quit [Max SendQ exceeded]
darkstardev13 has joined #osdev
darkstardev13 has quit [Max SendQ exceeded]
darkstardev13 has joined #osdev
darkstardev13 has quit [Ping timeout: 265 seconds]
potash has quit [Excess Flood]
potash has joined #osdev
darkstardevx has joined #osdev
darkstardevx has quit [Remote host closed the connection]
darkstardevx has joined #osdev
epony has quit [Ping timeout: 252 seconds]
FatAlbert has joined #osdev
Irvise_ has quit [Quit: Bridge terminating on SIGTERM]
Killy has quit [Quit: Bridge terminating on SIGTERM]
chibill has quit [Quit: Bridge terminating on SIGTERM]
jack_rabbit has quit [Quit: Bridge terminating on SIGTERM]
junon has quit [Quit: Bridge terminating on SIGTERM]
chibill has joined #osdev
gog has quit [Ping timeout: 268 seconds]
tarel2 has joined #osdev
Irvise_ has joined #osdev
Killy has joined #osdev
jack_rabbit has joined #osdev
junon has joined #osdev
CryptoDavid has joined #osdev
GeDaMo has joined #osdev
netbsduser has joined #osdev
epony has joined #osdev
gog has joined #osdev
AndroUser2 has quit [Ping timeout: 264 seconds]
AndroUser2 has joined #osdev
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #osdev
genpaku has quit [Remote host closed the connection]
gog has quit [Ping timeout: 252 seconds]
genpaku has joined #osdev
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #osdev
AndroUser2 has quit [Ping timeout: 265 seconds]
AndroUser2 has joined #osdev
netbsduser has quit [Remote host closed the connection]
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #osdev
freakazoid332 has quit [Ping timeout: 250 seconds]
AndroUser2 has quit [Ping timeout: 264 seconds]
darkstardevx has quit [Read error: Connection reset by peer]
FatAlbert has quit [Ping timeout: 250 seconds]
tarel2 has quit [Quit: Client closed]
tarel2 has joined #osdev
gog has joined #osdev
tarel262 has joined #osdev
tarel24 has joined #osdev
tarel2 has quit [Ping timeout: 252 seconds]
tarel262 has quit [Ping timeout: 252 seconds]
tarel2 has joined #osdev
tarel24 has quit [Ping timeout: 252 seconds]
tarel263 has joined #osdev
tarel2 has quit [Client Quit]
tarel263 has quit [Ping timeout: 252 seconds]
gog has quit [Read error: Connection reset by peer]
gog has joined #osdev
SpikeHeron has quit [Quit: WeeChat 3.0]
xenos1984 has quit [Read error: Connection reset by peer]
heat has joined #osdev
nyah has joined #osdev
carbonfiber has joined #osdev
xenos1984 has joined #osdev
vdamewood has joined #osdev
nvmd has joined #osdev
SpikeHeron has joined #osdev
nvmd has quit [Read error: Connection reset by peer]
nvmd has joined #osdev
ALowther has joined #osdev
<ALowther> What kind of overhead is there in persistent network connections? For the network is it just whatever is required by the transport layer? ie TCP=keep alive packets UDP=none? Then for system resources the main thing is just the system preserving the IP:PORT binding for that connection?
frkazoid333 has joined #osdev
muffin has joined #osdev
muffin has left #osdev [#osdev]
divine has joined #osdev
seer has quit [Quit: quit]
seer has joined #osdev
xenos1984 has quit [Ping timeout: 250 seconds]
xenos1984 has joined #osdev
antranigv has quit [Quit: ZNC 1.8.2 - https://znc.in]
gdd1 is now known as gdd
antranigv has joined #osdev
pieguy128_ has quit [Ping timeout: 265 seconds]
pieguy128 has joined #osdev
FatAlbert has joined #osdev
d5k has joined #osdev
d5k has quit [Quit: leaving]
d5k has joined #osdev
<FatAlbert> im back
xenos1984 has quit [Ping timeout: 268 seconds]
d5k has quit [Quit: leaving]
<FatAlbert> i have something to say ...
xenos1984 has joined #osdev
<FatAlbert> we need to stay connected
ALowther has quit [Remote host closed the connection]
gog has quit [Read error: Connection reset by peer]
tarel2 has joined #osdev
tarel2 has quit [Ping timeout: 252 seconds]
sonny has joined #osdev
gog has joined #osdev
netbsduser has joined #osdev
GeDaMo has quit [Quit: Physics -> Chemistry -> Biology -> Intelligence -> ???]
sonny has quit [Quit: Client closed]
FatAlbert has quit [Ping timeout: 264 seconds]
gareppa has joined #osdev
gareppa has quit [Quit: Leaving]
FreeFull has joined #osdev
<bslsk05> ​paste.debian.net: debian Pastezone
<maksy> why does this break in the line 59?
<maksy> here's the output by qemu
<heat> what's your gdt?
<maksy> check_exception old: 0xffffffff new 0xd
<heat> it's definitely broken
<maksy> 1: v=0d e=0082 i=0 cpl=0 IP=0008:00007cf0 pc=00007cf0 SP=0010:0008ffd8 env->regs[R_EAX]=00000e24
<heat> yes, I know how to read
<maksy> something about idt but no idea what
<heat> what's your gdt
<bslsk05> ​paste.debian.net: debian Pastezone
<heat> ... does your print overwrite ax?
<heat> 0xe24 does not have the 0th bit set
AndroUser2 has joined #osdev
sonny has joined #osdev
<maksy> ah print uses al
<maksy> I commented it out and I won't get the exception anymore
<maksy> however, my kernel isn't loaded either
<maksy> or jumped into
<maksy> at least some progress
sonny has quit [Quit: Client closed]
AndroUser2 has quit [Ping timeout: 265 seconds]
AndroUser2 has joined #osdev
<bslsk05> ​www.phoronix.com: IO_uring Continues To Prove Very Exciting: Promising io_uring_spawn Announced - Phoronix
<heat> why is everything getting put under io_uring
<heat> spawn() now?
<heat> other people: "add spawn" kernel devs: "noooo, just vfork and execve, its the UNIX(tm)(c)(R) way"
<heat> kernel devs: "what if we spawned processes in io_uring"
<heat> *thunderous applause*
<pitust> why do they do this
<pitust> its stupid as hell
<pitust> like fr
<heat> it's not that io_uring is stupid, or innovations are stupid
<heat> but that everything is getting stuck inside io_uring
<heat> it just stopped being io
<heat> just a uring now
<pitust> at this point they should just put all the syscall params in io_uring
<pitust> so you can just make whatever syscalls you want
<pitust> and you can put an io_uring in your io_uring
<pitust> does io_uring just make everything magically faster?
<heat> probably
<heat> it's not that io_uring is a bad idea - it's actually great
<pitust> yeah i know but like
<heat> but maybe drop the io_? and/or acknowledge innovation besides io_uring and eBPF
<heat> why did they never add this before?
<pitust> eBPF is the best kernel feature
<heat> (this = spawn())
<pitust> combined with userfaultfd
<pitust> isnt that how all good linux exploits work
<heat> with what?
<pitust> with userfaultfd and eBPF
<pitust> possibly replace eBPF with io_uring
<heat> no
<pitust> oh okay so i dont like them
<CompanionCube> fix explots with shiny new rust kernel drivers!
<heat> oh yeah did you see the news?
<heat> they have an NVMe driver and a 9P client driver
<pitust> okay... how much worse is the performance?
<pitust> also is it just me or is adding rust a HORRIBLE idea because now to build linux you need llvm for your target
<heat> that's in-progress
<klange> There's a gcc rust frontend.
<heat> there's an in-progress gcc rust frontend, and a rustc gcc backend using libgccjit
<heat> but they're both very much under progress
<gog> if you like it then you should of put io_uring on it
<gog> (all the single threadeds)
<klange> woah oh oh
<heat> lol
<pitust> rust with iouring???
<linkdd> CompanionCube: how much "unsafe" code in those drivers?
<heat> >how much worse
<heat> not much
<CompanionCube> linkdd: i haven't looked lol
<heat> super comparable to the C one, just less optimized
<linkdd> unsafe { main(); } // better write C at this point
<heat> linkdd, there's some unsafe code, but it's under progress
<heat> they are actively going to remove it still
<heat> but most of it is actual rust apparently
<linkdd> heat: i'm just kidding, nicely wrapped unsafe code under a safe API is definitely better
<heat> (not that I can judge it, I'm not a rust dev, I just follow the news)
<heat> but they appear to be quite happy with it
<linkdd> rust succeeded where c++ could not: entering the kernel
<heat> mesa is also going to write the new opencl thing in rust, rusticl I think
<pitust> linkdd: from what i've heard rust in linux is mostly just a few very vocal people
<linkdd> pitust: "in linux" is not required in your sentence
<pitust> fair
<linkdd> i've been writing rust for nearly a year now, and when you're in the community you get a feeling that rust is everywhere
<linkdd> then you look at job offerings and realize that rust is still a niche
<heat> it's new
<heat> you've got a lot more C++ and C code out there
<pitust> also apparantly rust in linux is like an experiment, not a permanent thing (at least right now)
<heat> yes, for now
<linkdd> heat: i believe C will live another 50 years
<linkdd> many tried to "kill it", C outlived them all
<heat> will it?
<pitust> probably
<heat> I think it will stay, but starting projects in C is not a good idea
xenos1984 has quit [Read error: Connection reset by peer]
<linkdd> looking at the amount of C code out there, yes i think
<linkdd> COBOL is still running
<heat> and hasn't been for like what, 10-15 years?
<j`ey> pitust: it's not in torvald's linux yet
<linkdd> why isn't it a good idea? not every projects is critical
<pitust> i love how people brand it!
<heat> you can always use a restricted set of C++ instead of C - much safer if you use the right constructs, usually much faster to write and less verbose
<gog> i write c# now
<heat> (and I mean *restricted*)
<gog> let's get c# in the kernel
<pitust> you aren't the first
AndroUser2 has quit [Read error: Connection reset by peer]
<klange> [Microsoft wants to know your location.]
AndroUser2 has joined #osdev
<linkdd> the "writing C is not a good idea" narrative implies that every single software can kill people if there is a single byte of memory leaking
<pitust> itay and staticsaga from the osdev discord are working on a kernel called pentagon: https://github.com/Itay2805/pentagon
<bslsk05> ​Itay2805/pentagon - An experimental dotnet based kernel (2 forks/26 stargazers/MIT)
<heat> COM objects in the kernel when???
<gog> think about how easy life would be if you could have LINQ enumerables in a kernel
<pitust> hmm, how do COM objects work...
<heat> linkdd, no it doesnt. memory leaking is objectively sloppy software design
<heat> s/design/development/
<linkdd> it's an oversimplification, i do not adhere to the whole "C is evil, no one should be writing it" narrative
<gog> C is good and more people should write it and learn its pitfalls
<heat> yes, write it, learn its pitfalls and fallback to less hardcore languages after that
<gog> exactly
<linkdd> there is nothing wrong in starting a new project in C
<heat> there is
<linkdd> why
<gog> don't start new projects
<gog> finish your old projects
<pitust> i agree
<heat> it's less maintainable, harder to write, harder to read, harder to code review
<linkdd> debatable
<linkdd> sqlite manages it pretty well, and i have many more examples
<heat> do you find code full of gotos easy to prove as correct?
<pitust> pro tip: dont fill your code up with gotos
<heat> or code that reinvents std::vector for the 100th time in your project
<pitust> my code is just fine with almost 0 gotos
<clever> pitust: or setjmp? :D
<linkdd> heat: i can write non-idiomatic rust code that will be unmaintainable as well
<linkdd> that's not an argument
<heat> pitust, show me how to do easy, safe and correct resource management without gotos in C
<pitust> heat: what about [[gnu::cleanup]]
<gog> don't manage resources
<gog> don't write software
<linkdd> separation of concerns: don't allocate all your resources in the same function
<heat> pitust, GNU C extension, also requires a new function to free things
<gog> don't create a needlessly complex society that depends on programmers of all people for its orderly functioning
<gog> i'm a programmer and i do not function
<gog> you have made a mistake entrusting business processes to my tender mercies
<heat> linkdd, and how do you plan on doing that?
<linkdd> also, you can do it like rust/erlang/... crash early
<heat> i.e implement fork() pls, don't allocate everything in that function
<pitust> Arc<Mutex<T>>
<pitust> i love Arc<Mutex<T>>
<pitust> it makes performance go down the drain
<pitust> because now i have a lot of pointless mutexes
<pitust> but who cares!
JerOfPanic has quit [Ping timeout: 252 seconds]
<linkdd> pitust: not as much as Arc<Mutex<T>> where Mutex is from tokio instead of std
<pitust> linkdd: oh of course i didnt say where my mutex came from
<pitust> my mutex is from async_std not tokio though, so it doesnt work with tokio
<pitust> (does async_std have a mutex?)
<pitust> yes it does
<linkdd> heat: i terms of performance and platform availability, nothing beats C yet, not even C++
<heat> oh for sure
<heat> not debating that
<pitust> my favorite language is still objective-c though
<linkdd> and when you're not writing software to monitor some nuclear reactor, i think C is fine
<pitust> if you are
<pitust> please please please use a language which is not relatively in its infancy
<linkdd> (exagerating to make my point, which is: not every software is critical to require the proofs that compilers like rust will give you)
<pitust> use something that the industry has tested for decades
<pitust> like ADA
srjek has joined #osdev
<heat> linkdd, yes, but I personally believe C scales horribly
<linkdd> if you want a langage that scales, look at erlang/elixir.
<heat> as in, large projects take exponentially more effort to review and prove correct
<gog> ada is pretty cool
<heat> gog, i also think you're cool
<gog> eeee
<linkdd> large projects should not exists and be splitted in more little projects. because no matter the language, large codebases are harder to maintain, review, etc...
<linkdd> even rust
<linkdd> and i will even say this: rust is not a GENERAL purpose language
<heat> write a game engine without a large project
<heat> or an OS
<linkdd> heat: you can have modular monoliths
CryptoDavid has quit [Quit: Connection closed for inactivity]
<linkdd> look at bevy (in rust) for example
<heat> or a OpenGL/Vulkan/OpenCL implementation
<gog> what about monolithic modules
<pitust> heat: an OS in rust is plagued no less by memory corruptions and use-after-frees
<linkdd> also this
<heat> why so?
<pitust> and depending on your poor code, also undefined behaviour
<pitust> heat: because an OS needs to manage resources on a low level
<linkdd> heat: because an OS is required to do some unsafe operations that cannot be prooved safe
<heat> yes, but those are few?
<pitust> well, they can, at least somewhat
<pitust> heat: but those few are the ones that cause a lot of memory corruptions
<heat> can you give me an example?
<linkdd> memory management is unsafe
<pitust> and proving that sounds quite difficult
<gog> we've been over this
<gog> don't manage things
<heat> linkdd, memory management isn't unsafe
<linkdd> gog: go back to DOS, let the program take over the computer entirely, mouhahahaha
<gog> yes exactly
<heat> you can write a virtual memory manager in javascript even
<pitust> heat: really? okay, can you implement a malloc in purely safe code in rust?
<pitust> (no)
<heat> purely safe? probably not
<gog> you can probably tie up the unsafest parts into a single block though
<linkdd> physical memory is what we called "a shared mutable resource", this is by definition unsafe
<heat> do you need the malloc.rs wrapped in an unsafe{}? no
<heat> linkdd, is it?
<linkdd> it is
<pitust> well then the unsafe part is the one that WILL have memory corruption
<heat> why so?
<pitust> at least in my experience
<pitust> memory corruption sucks
xenos1984 has joined #osdev
<heat> alloc_page gives you a struct page*. free_page(page*) gives the page back to the page allocator. you own the page in between that
<linkdd> heat: in rust you can't have shared mutability for that very reason, this is why you have things like Arc<Mutex<T>>, or RefCell<T>
<pitust> when i was working on my rust kernel a while ago it was full of memory corruption, and also it was really fucking big, and also it used about 40 crates
<heat> you know, I hate to defend rust, but you're attacking it unfairly here
<linkdd> who is attacking rust?
<heat> pitust is correlating the fact his kernel was written in rust with the size of the thing, the crate usage, and the memory corruption
<linkdd> he correlated the memory corruption with his usage of unsafe{}
<linkdd> and yes rust debug symbols occupy more space than C debugging symbols
<linkdd> and yes, crates.io is the new NPM (but it's a bit better since the unused symbols are stripped out)
<pitust> not that much better
<pitust> because instead, you have generics
<pitust> and macros
<heat> no one is forcing you to use crates, as proven by lots of people here that succesfully write OSes in rust without them, and without huge size issues
<linkdd> reinventing the wheel is boring
<linkdd> you complained about not having std::vector in C
<pitust> rust without crates is prooobably fine, but a lot of rust kernels don't do that
<linkdd> so you get that one would want to use crates
<heat> I reinvented std::vector for my kernel, because getting someone else's would be boring and a poor idea
<heat> I don't think you understand you're in #osdev
<heat> this is literally NIH.org
<pitust> max NIH is not good either though
<heat> (also crate/module culture is kinda harmful to software IMO)
<linkdd> that's another debate
<linkdd> i agree partially
<linkdd> having your problem solved by a pip install is a nice developper experience
<linkdd> not having curated/audited repositories like most linux distros have, is a problem
<klange> make your own language and write your os in that
<klange> anyway here's a kuroko release https://github.com/kuroko-lang/kuroko/releases/tag/v1.3.0
<bslsk05> ​github.com: Release Kuroko v1.3.0 · kuroko-lang/kuroko · GitHub
<heat> good shit
<heat> tri-monthly reminder that you should look at my (now outdated) meson patch
<linkdd> klange: i'm writing a language AND an os, but writing an OS in my language would be too difficult
AndroUser2 has quit [Ping timeout: 265 seconds]
AndroUser2 has joined #osdev
<gog> nice
<gog> like how you did the sex number to the power of the weed number
<klange> The arbitrary precision integer type is the key user-facing feature for this release, though lots of interpreter speed improvements are in there, too.
<klange> This was the one thing I would still crack open Python repls for, so it's great to finally have it myself.
<heat> the key user-facing feature here is how you can do the funny sex number to the power of the funny weed number
<heat> for maximum funnynness
<gog> yes
<gog> also is the arbitrary precision type distinct from a fixed precision type
<gog> or is it all wrapped inside int
<gog> same as with python
<klange> Yeah, there's a `long` type distinct from `int`, and I have reasons to keep them separate that CPython did not have.
<gog> makes sense
<klange> Specifically, I have non-object values, and ints fit in those, so small ints will remain a separate type from longs, though long subclasses int and there's seamless conversion.
<heat> how long are longs?
<heat> erm sorry
<heat> ints
<klange> The cutoff is 48 bits, due to how the value boxing works.
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #osdev
<klange> They used to be 32, were expanded to 48 as the largest thing that would fit, and I was going to reduce them back to 32 with longs, but didn't see any performance gains on the platforms I target, so they get to stay 48.
AndroUser2 has quit [Ping timeout: 250 seconds]
AndroUser2 has joined #osdev
nvmd has quit [Quit: WeeChat 3.6]
* Ermine throws release confetti
* heat checks his releases
<heat> >empty
<heat> can i get confetti as well?
kroney has joined #osdev
<Ermine> I can throw some serpentine
<heat> i want a new idea for a os/firmware level project
<heat> pls send suggestions
<klange> Attached the x64 EFI build and a only-tested-in-wine 64-bit windows build to the release; will poke the windows build again the Surface later, probably has some broken file stuff I forgot to merge...
<kroney> @heat ext filesystem?
<klange> I should make a aarch64 deb...
<heat> kroney, i've done that
<heat> i want a new project, not an idea for my project
<heat> right now i'm thinking of a world where I just embed a bytecode VM in a kernel
<heat> like v8
<heat> that would be both funny and an interesting experiment
frkazoid333 has quit [Read error: Connection reset by peer]
<Ermine> Yet another JsOS?
<heat> oh
<heat> fuck
<heat> scrap that then
<heat> i could do a microkernel but that seems done to death
frkazoid333 has joined #osdev
<CompanionCube> revive the attempt at osdev with Squeak Smalltalk?
<heat> that's too esoteric isn't it
<CompanionCube> (related to the 'kernel bytecode vm' idea is the way the System/38 and successors work, where your applications target a virtual machine and are compiled into native instructions at installation time or when otherwise appropriate. This still exists today in the form of 'IBM i'.)
<heat> what about adding an SVR4 emulation mode to my OS
<heat> or adapting it into a microkernelish fork
<heat> im not great with ideas
<heat> thinking in general, really
<CompanionCube> maybe combine that with targeting some retro SVR4-running hardware?
<bslsk05> ​en.wikipedia.org: Blit (computer terminal) - Wikipedia
<bslsk05> ​en.wikipedia.org: 3B series computers - Wikipedia
<bslsk05> ​en.wikipedia.org: Multi-Environment Real-Time - Wikipedia
<gog> hey can i get some confetti?
<gog> i didn't do anything special i just want to feel special
* CompanionCube confettis gog
<gog> thank you
<CompanionCube> funnily enough given you mentioned adapting it into a microkernelish fork: 'One interesting feature that DMERT – UNIX-RTR introduced was the notion of kernel processes. This is connected with its microkernelish architecture roots. In support, there is a separate command (/bin/kpkill) rather than (/bin/kill), that is used to send signals to kernel processes. It is likely there are two different system calls
<CompanionCube> be that the UNIX-RTR developers implemented an entire signal and messaging application programming interface (API) for kernel processes. '
<CompanionCube> also (kill(2) and kpkill(2), the first to end a user process and the second to end a kernel process). It is unknown how much of the normal userland signaling mechanism is in place in /bin/kpkill, assuming there is a system call for it, it is not known if one can send various signals or simply send one. Also unknown is whether the kernel process has a way of catching the signals that are delivered to it. It may
* Ermine throws confetti above heat and gog
<heat> sounds like STREAMS with extra steps
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #osdev
<heat> CompanionCube, I don't think SVR4 ran on super weird hardware
<heat> at least not the one I've used, the x86 one
<heat> doing something to honor legacy UNIX sounds fun
<heat> like, legacier
<heat> replacing the UNIX kernel of one of the open old ones with my own
<CompanionCube> how old?
<heat> research unix? or one of the old BSDs
* Ermine failed to find X and TCP/IP diskette images for SVR4
<CompanionCube> iirc there's source out there for sunos 4.1.4
<heat> Ermine, see UnixWare
<heat> unfortunately you can't get the SVR4 source
* gog streams on heat
<heat> I mean, you can, it's in archive.org, but it's not legal so not a good idea
<heat> gog, oh yeah stream all over me
<gog> what are they gonna do, sue youÐ
<heat> lets make a stream tape, then blackmail me when I'm the president
<heat> erm yeah I don't know
<CompanionCube> iirc SCO bought the SVR intellectual property, and they're too busy with their undead linux lawsuit
<heat> who holds UNIX copyright now? Novell?
<Ermine> Wow, UnixWare is even alive
<heat> it used to be Caldera
<CompanionCube> ah 'The Santa Cruz Operation (SCO), owners of Xenix, eventually acquired the UnixWare trademark and the distribution rights to the System V Release 4.2 codebase from Novell, while other vendors (Sun, IBM, HP) continued to use and extend System V Release 4. Novell transferred ownership of the Unix trademark to The Open Group. '
<heat> and that died right?
<heat> "sold off Unix assets" says wikipedia
<heat> yes, sold them to caldera
<heat> but then became SCO again? what the fuck
<Ermine> Now it's the open group which slaps Unix(tm) badges
<CompanionCube> oh huh
<CompanionCube> apparently the SCO lawsuit actually fucking finished
<CompanionCube> 'On November 8, 2021, the settlement was so made under those terms, with IBM paying the TSG bankruptcy trustee $14.25 million and the trustee giving up all future claims and with each party paying their own legal costs. After 18½ years, SCO v. IBM was finally over'
<gog> whaaaat
<gog> i guess settling was cheaper than continuing the battle of "motion to dismiss" and "motion for summary judgement" forever
<CompanionCube> so who actually *owns* the SVR4 intellectual property?
<gog> you can't like own intellectual property, man
<heat> CompanionCube, i dont fucking know
<bslsk05> ​en.wikipedia.org: SCO Group, Inc. v. Novell, Inc - Wikipedia
<heat> Novell? No one?
<Ermine> Oh those convoluted IP schemes
epony has quit [Quit: QUIT]
<CompanionCube> at least that article is about SVR4 and not 4.2
<heat> i think it's Novell
<linkdd> https://wiki.osdev.org/File:64-bit_page_tables1.png i'm confused as to why the 4 layouts are exactly the same
<bslsk05> ​wiki.osdev.org: File:64-bit page tables1.png - OSDev Wiki
<linkdd> why the need to call them differently if they are the same
<heat> linkdd, welcome to x86
<CompanionCube> heat: novell's kaput, it's https://en.wikipedia.org/wiki/Micro_Focus now
<bslsk05> ​en.wikipedia.org: Micro Focus - Wikipedia
<CompanionCube> don't they also own the POSIX copyright or something?
<heat> UNIX is british now?
<heat> proper OS innit lads
<heat> linkdd, also there are a few differences IIRC
<heat> at least a quick one is that the huge page bit doesn't exist in PML5 and 4 entries
<CompanionCube> ah no, open group have POSIX
<linkdd> i feel like in an implementation of a virtual memory manager, with no huge pages, i should care only about the bits 0 to 5
<heat> I treat them all similarly
<heat> but when using huge pages I take into account the page table level
<linkdd> is it reasonable to not support huge pages?
<linkdd> what are the consequences?
<heat> yes but they're handy sometimes
<heat> mostly kernel-internally
<heat> you may want to get some pretty big mappings going
<CompanionCube> and microfocus is being acquired by https://en.wikipedia.org/wiki/OpenText, so it's gonna be canadian
<bslsk05> ​en.wikipedia.org: OpenText - Wikipedia
<heat> ok so what you're saying is: give up and just don't touch the unix IP hell?
<CompanionCube> the real question is if they would actually care?
<heat> maybe?
<heat> I assume there's a reason they're not on tuhs
<CompanionCube> aww, the ancient unix license explicitly excludes System V.
<heat> yes
<CompanionCube> and opensolaris code from 2005 is way too different from actual system v
<heat> I know
<heat> I think they try to avoid System V in general because they don't want to piss off SCO again
<heat> there's no reason why it should be closed source
<heat> it's a pretty big historical artifact
<linkdd> https://bpa.st/ATNA is this really all i need to implement a basic virtual memory manager?
<bslsk05> ​bpa.st: View paste ATNA
<CompanionCube> https://www.nordier.com/ apparently someone ported V7 to x86, huh
<bslsk05> ​www.nordier.com: Home | Robert Nordier
<heat> linkdd, no, that's just the mmu code
<heat> well, not code, but structures
<heat> also, tip: dont use bitfields but defines
<linkdd> of course, what i mean by "all i need" is about the bits
<linkdd> heat: why should i not use bitfields?
* CompanionCube is surprised that the SVR4 code has been there since 2013 though
<linkdd> *souldn't i
AndroUser2 has quit [Read error: Connection reset by peer]
<heat> linkdd, you cant write or control when bits are written back, and that's not particularly great if you want to atomically change permissions
AndroUser2 has joined #osdev
<linkdd> heat: i can cast the struct to an uint64_t and do the operation atomically here. (even simpler with an union), that's not my question here, my question is about my `unused : 57`
<heat> that looks fine
<heat> although it's not unused, and you have less than 57 bits
<heat> more like 64 - 12 - 1
kroney has quit [Ping timeout: 250 seconds]
<linkdd> it's not unused by the CPU, but should my virtual memory manager care about it?
<heat> how do you map pages or add a new page table without it?
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<linkdd> https://bpa.st/TTIA i currently have this, and i cast the address of those labels to a page_table_dir_t*
<bslsk05> ​bpa.st: View paste TTIA
<heat> ok
<heat> and?
<heat> you do realize you need more than a page table for each level (except the top one naturally)?
<linkdd> yes, yes, i see it now, i should stop working during the night lol
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #osdev
<kof123> heat: just read story of mel over and over until it osmoses into you, and you will know what to do
frkazoid333 has quit [Ping timeout: 244 seconds]