<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]
<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
<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?
<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
<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
<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
<heat>
also HOLY SHIT I COULD FINALLY DO STREAMS
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
<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