You can also test my OS now that I've fixed it 
#Nyaux
flat nymph
wide nexus
you can also test my OS (I dont have an OS)
flat nymph
Please don't abandon Nyaux again
flat nymph
(smp is kinda complicated)
surreal path
how
flat nymph
Race conditions (Rust kinda makes it easier) and cache-coherency (TLB issues)
surreal path
i have locks on everything that is unsafe
flat nymph
The goal is to have no locks
Also my kernel was full of reference counting pointers, and I'm getting rid of them since they become very anoying quite quickly
flat nymph
The goal is to have no locks
In the sense that it kills the performance
surreal path
The goal is to have no locks
I have it on my MemoryManager and terminal
molten grotto
its not worth completely avoiding locks either, making everything lockless can also kill performance
flat nymph
I have it on my MemoryManager and terminal
That is fine
flat nymph
its not worth completely avoiding locks either, making everything lockless can a...
But there is RCU and you can try and make things CPU-local
molten grotto
yeah
flat nymph
Race conditions (Rust kinda makes it easier) and cache-coherency (TLB issues)
(I still don't have a system to properly wait for munmap to invalidate TLB on other cores)
molten grotto
I just realized some day that I have accidentally effectively serialized interrupts on my kernel 
I have global random pools that are locked inside the irqs and then also a global lock protecting the irq handler list that is locked inside the irq handler 
(I should really get rid of that because removing/adding irq handler is very rare and I can just make making sure that the irq is not getting triggered anymore when deregistering the handler the caller's responsibility)
and the random pools should just be cpu local
flat nymph
Just ignore us, you will feel the pain later
flat nymph
I just realized some day that I have accidentally effectively serialized interru...
My irq handlers (dispatchers) are per-core and have no locks 😎
(in kernel)
surreal path
where in the sdm does it take abt getting the cpuid using the cpuid instruction
which chapter
flat nymph
Just take lapic id from lapic...
Just use this?
surreal path
Just use this?
but what about the core number
for funny prints
also cause more information = pro
its fine i just wont have that
molten grotto
but what about the core number
you should make that up yourself
surreal path
ok lol
molten grotto
giving the cores numbers starting at 0
because the lapic id's may not be contiguous
flat nymph
and may not start at 0
and may be different from cpuid
or msr
(one of two I don't remember)
surreal path
hehehaha
yummm
ummmm
why is the lapic address the exact same
im using read msr
to get the lapic addr
surreal path
that font is ugly
give me better one then :)
cinder plinth
the default flanterm one is good enough
molten grotto
where do you get it from
flat nymph
Oh, that is not normal
finite summit
give me better one then :)
surreal path
Oh, that is not normal
yea wtf
finite summit
flat nymph
You are using at mut again (?)
surreal path
whats wrong
cinder plinth
damn nice
molten grotto
no its not ub
cinder plinth
where is it from
surreal path
rdmsr
finite summit
nyaux thread is almsot at 20000 messages
surreal path
lol
finite summit
and you mask the bits
surreal path
yes
surreal path
what i do
let addr = rdmsr(0x1b);
let shit = (addr & 0xfffff000) + HDDM_OFFSET.get_response().unwrap().offset();
okay sec pushing
surreal path
lol
surreal path
yes
finite summit
iretd
surreal path
```c
let addr = rdmsr(0x1b);
let shit = (addr & 0xfffff000) + HDDM_OFFS...
is this wrong
cinder plinth
idk if his github is iretq
finite summit
```c
let addr = rdmsr(0x1b);
let shit = (addr & 0xfffff000) + HDDM_OFFS...
print shit
surreal path
print `shit`
okay sdc
flat nymph
It looks normal
flat nymph
On which CPU are you reading those?
surreal path
On which CPU are you reading those?
oh
LMAO
😭
i forgot
im doing this on the bootstrap cpu
surreal path
yea
flat nymph
(except when it's not (I had a bug in my kernel because of that))
finite summit
where scheduler
finite summit
lies
surreal path
(im scared of scheduler cause now hardmode with smp)
flat nymph
Time has the same frequency on all CPUs btw
flat nymph
but it's a rewrite
finite summit
and this one was may 3rd
*2nd
surreal path
ur scheduler looks extremely hard mode lol
finite summit
I only started copying code in june
finite summit
ur scheduler looks extremely hard mode lol
it's pretty basic
cinder plinth
I think the code is just messy
finite summit
my code indeed is messy
finite summit
((my scheduler is as well))
flat nymph
(((oh)))
finite summit
((((I have barely modified it since the day it was committed)
(((((only reason I did is because of api changes and bug fixes)))))
surreal path
anyone have GOOD scheduler code thats simple and supports smp i can read?
finite summit
can probably look at like any project here and find that
cinder plinth
good code or good scheduler
cinder plinth
good scheduler look at freebsd's ULE
cinder plinth
for now just do round robin on each cpu
cinder plinth
that is not simple
it is pretty simple
flat nymph
just do round robin
flat nymph
global lock
flat nymph
or per-cpu queues
cinder plinth
nah no need for global locks
flat nymph
or both
cinder plinth
pre-cpu queues are better
yea
choose a cpu sequentially at first
then in the future you can do load balancing
flat nymph
Like you probably don't need more than that for most uses
finite summit
// choose a cpu to run
// todo: better
int cpu = rand() % cpu_count;
I did that because I wanted my drivers to be able to preempt everything else
cinder plinth
```c
// choose a cpu to run
// todo: better
int cpu = rand() % cpu_count;
```
no
curr_cpu++;
if curr_cpu >= cpu_len-1 { curr_cpu = 0}
molten grotto
what should it store
process stores things like the pagemap, handle table and threads
flat nymph
```c
// choose a cpu to run
// todo: better
int cpu = rand() % cpu_count;
```
managram does that (?)
surreal path
process stores things like the pagemap, handle table and threads
handle table sorry?
finite summit
table of handles
surreal path
??
molten grotto
a handle table == a table that maps eg. fd's to actual kernel objects
surreal path
what is an fd again
molten grotto
an opaque integer handle to a open file
surreal path
an opaque integer handle to a open file
what object
struct process {
...
handles: HashMap<usize, ?>
...
}
should it map to
surreal path
i like hashmaps they are easy :)
molten grotto
what object
```rs
struct process {
...
handles: HashMap<usize, ?>
...
}
```
whatever you need, likely you want to make it a variant
flat nymph
can be an array
probably should be an array
surreal path
whatever you need, likely you want to make it a variant
variant?
should it be a dyn vnode or smthin
cinder plinth
an enum
surreal path
oh
cinder plinth
just a fd table
surreal path
but rather generic handles which can be fds
what handles can it also be
what handles also exist
other then fds
cinder plinth
in UNIX, nothing
surreal path
i see
surreal path
can there be multiple handles to the same thing
cinder plinth
handles are actually a much better design but don't tell that to unix people
surreal path
or only one
surreal path
but they are the same handle id or no
oh okay
so if its an fd
it should be pointing to a dyn vnode
which can be whatever
cinder plinth
nah
surreal path
huh
surreal path
whats posix::file??
molten grotto
an open file ™️
surreal path
cursor?
molten grotto
the write/read position within the file
cinder plinth
cinder plinth
that's just a class which implements the Stream 'trait', meaning you can read, write and seek on it
surreal path
and that contains the offset in file?
cinder plinth
yea
surreal path
i see
cinder plinth
I forgot why I have a stream trait but it's useful
oh yeah
I remember now
for loading elfs for example
you can pass a Stream&
meaning you could pass a byte stream or a vnode stream and it'd work the same
surreal path
trait Stream {
fn read
fn write
fn seek
}
struct VNodeStream {offset: usize};
impl Stream for VNodeStream{...};
struct PosixFile {
vnode: Rc<RefCell<dyn vnode>>,
flags: VNODEFLAGS,
stream: VNodeStream
}
something like this?
surreal path
```rs
trait Stream {
fn read
fn write
fn seek
}
struct VNodeStream {offset...
can yall pin this for me so i dont forget
surreal path
thanks
enum HandleType {
File(*mut PosixFile)
}
struct cpu_context {
frame: *mut Registers,
// fpu_state: todo!
}
struct perthreadcpuinfo {
kernel_stack_ptr *mut u8,
user_stack_ptr: *mut u8,
}
struct process {
vfs: *mut vfs,
pagemap: u64,
cwd: Rc<RefCell<dyn vnode>>,
pid: u64,
handles: HashMap<usize, HandleType>,
name: String,
threads: Vec<Thread>
}
struct Thread {
name: String,
tid: u64,
gs_base: *mut perthreadcpuinfo,
context: *mut cpu_context
}
tell me if theres anything else i need to add
?
finite summit
```rs
enum HandleType {
File(*mut PosixFile)
}
struct cpu_context {
frame: *mu...
where is the thread contex tinfo
*context info
surreal path
perthreadcpuinfo
molten grotto
tbh you don't really need that inside the thread
surreal path
okay i added
surreal path
tbh you don't really need that inside the thread
wym
molten grotto
well it depends on how your scheduler works, if you eg. use the irq handler to save the user regs and your scheduler only switches between kernel mode threads (and saves the callee saved registers on the stack) then you might not need it inside the thread struct
cinder plinth
You need it for syscall
surreal path
You need it for syscall
yea i want syscall
molten grotto
You need it for syscall
eh, still it doesn't have to be inside the thread
though ig if you don't want to pass the context ptr around manually then it might be nice
but like you usually don't have to pass the whole context that deep anyway
(unless you like store the syscall context inside the thread itself instead of the thread's kernel stack or smth)
cinder plinth
eh, still it doesn't have to be inside the thread
I do because I store the current thread in gs
molten grotto
how does that affect it tho
cinder plinth
yeah nvm
thorn bramble
idk if his github is iretq
sadly no, its 48cf (the encoding for iretq;’))
cinder plinth
adverb
From where; from what place.
"Whence came this traveler?"
From what origin or source.
"Whence comes this splendid feast?"
surreal path
okay
surreal path
man seek
man seek doesnt exist lol
for some reason
im probs missing a package but i dont know what it is
im on popos
sooo
cinder plinth
man fseek
surreal path
okay there
molten grotto
because its from the end of the file
surreal path
what
molten grotto
Whence::END
means that its an offset from the end of the file
and end of the file == size of the file
surreal path
why would u want that
surreal path
no to add an offset to the end of the file
molten grotto
the offset can be zero
cinder plinth
can also be negative
surreal path
i see
surreal path
```rs
trait Stream {
fn read
fn write
fn seek
}
struct VNodeStream {offset...
shouldnt shouldnt vnodestream also have vnode
or how is it gonna get the vnode
surreal path
okay makes sense
surreal path
why
cinder plinth
doesn't matter really
elder shoal
Open it
Opening a directory is a valid operation because you can then use getdents or whatever
elder shoal
Open a file using a path relative to that directory
surreal path
yea i see
thorn bramble
or using a sentinel value to represent the current working directory
cinder plinth
if off>attr.size then resize
cinder plinth
no
surreal path
why is this not good
surreal path
okay
i did that
is that good
also
why do u do tn->attr.size
that wasnt modified?
so why are you reallocing the exact same size
cinder plinth
oh this is in read
cinder plinth
i have no idea why I even realloc there
surreal path
lmao
cinder plinth
i think I mustve copy pasted write
surreal path
😭
surreal path
alr
surreal path
remove that realloc thing
fn read(&self, buf: &mut [u8], offset: isize) -> Result<usize, UNIXERROR> {
let mut count = buf.len();
if buf.len() == 1 {
return Err(UNIXERROR::EINVAL);
}
if (offset + buf.len() as isize) as usize >= self.data.len() {
if self.data.len() <= offset as usize {
count = (offset - self.data.len() as isize) as usize
}
}
if self.data.len() == 0 {
return Err(UNIXERROR::EPERM);
}
let dest = unsafe {buf.as_mut_ptr().offset(offset)};
let src: *const u8 = self.data.as_ptr();
unsafe {
core::ptr::copy_nonoverlapping(src, dest, count)
}
return Ok(count);
}
fn write(&mut self, buf: &[u8], offset: isize) -> Result<usize, UNIXERROR> {
let size = (offset + buf.len() as isize) as usize;
if (offset + buf.len() as isize) as usize > self.data.len() as usize {
self.data.resize((offset + buf.len() as isize) as usize, 0);
}
if self.data.len() == 0 {
return Err(UNIXERROR::EPERM);
}
self.data.resize(size, 0);
let src = buf.as_ptr();
let dest = unsafe {self.data.as_mut_ptr().offset(offset)};
unsafe {
core::ptr::copy_nonoverlapping(src, dest, size);
}
// SO EASY
return Ok(size);
}
these 2 funcitions look good?
cinder plinth
idk try them
flat nymph
Shouldn't you follow symlinks in a loop?
flat nymph
In Vnode::Type::LINK
surreal path
this is in tmpfs
fn read(&self, buf: &mut [u8], offset: isize) -> Result<usize, UNIXERROR> {
let mut count = buf.len();
if buf.len() == 1 {
return Err(UNIXERROR::EINVAL);
}
if (offset + buf.len() as isize) as usize >= self.data.len() {
if self.data.len() <= offset as usize {
count = (offset - self.data.len() as isize) as usize;
}
}
if self.data.len() == 0 {
return Err(UNIXERROR::EPERM);
}
let dest = unsafe {buf.as_mut_ptr().offset(offset)};
let src: *const u8 = self.data.as_ptr();
unsafe {
core::ptr::copy_nonoverlapping(src, dest, count)
}
return Ok(count);
}
fn write(&mut self, buf: &[u8], offset: isize) -> Result<usize, UNIXERROR> {
let count = buf.len();
if (offset + buf.len() as isize) as usize > self.data.len() as usize {
self.data.resize((offset + buf.len() as isize) as usize, 0);
}
if self.data.len() == 0 {
return Err(UNIXERROR::EPERM);
}
let src = buf.as_ptr();
let dest = unsafe {self.data.as_mut_ptr().offset(offset)};
unsafe {
core::ptr::copy_nonoverlapping(src, dest, count);
}
// SO EASY
return Ok(count);
}
i dont know what im doing wrong
to be honest
im trying to read it but it seems fine
like if offset is anything other then 0
no data is given
cinder plinth
```rs
fn read(&self, buf: &mut [u8], offset: isize) -> Result<usize, UNIXERROR> ...
your read is wrong
surreal path
your read is wrong
how lol
surreal path
oh
that solved nothing
assertion left == right failed
left: "ello world!\n"
right: ""
cinder plinth
also read should take a count
surreal path
really?
cinder plinth
assertion `left == right` failed
left: "ello world!\n"
right: ""
well yeah cuz you don't handle offsets
cinder plinth
mhm well I guess if you can get the size of &[u8] then its fine
but then that won't work for syscalls
because you can't take a &[u8] from syscalls
surreal path
still fails
cinder plinth
also on read you don't want to allow reads on greater than length
you wanna read maximum len bytes
surreal path
you wanna read maximum len bytes
what
surreal path
so if offset is bigger then data.len
what do i do
like im so confused rn lol
fn read(&self, buf: &mut [u8], offset: isize, count: usize) -> Result<usize, UNIXERROR> {
let mut count = count;
if buf.len() == 1 {
return Err(UNIXERROR::EINVAL);
}
if (offset + buf.len() as isize) as usize > self.data.len() {
if self.data.len() <= offset as usize {
count = (offset - self.data.len() as isize) as usize;
}
}
if self.data.len() == 0 {
return Err(UNIXERROR::EPERM);
}
let dest = unsafe {buf.as_mut_ptr().offset(offset)};
let src: *const u8 = self.data.as_ptr();
unsafe {
core::ptr::copy_nonoverlapping(src, dest, count)
}
return Ok(count);
}
like
this is my read function rn
surreal path
okay
cinder plinth
if self.data.len() <= offset as usize { that's wrong
surreal path
i see
cinder plinth
apart from that no idea
surreal path
what should it be then
surreal path
okay
cinder plinth
this isnt a very complex function lmao
surreal path
if (offset + buf.len() as isize) as usize > self.data.len() {
count = (offset - self.data.len() as isize) as usize;
}
buf.len() == 1 is also wrong, what if I want to read 1 byte
surreal path
something like this
cinder plinth
yes try it
surreal path
okay
cinder plinth
if self.data.len() == 0 {
return Err(UNIXERROR::EPERM);
}
shouldnt be an error
just return 0
surreal path
cinder plinth
bro
buf+offset
that's wrong
you read N bytes from file at offset O
why are you putting N bytes in buffer at offset O
surreal path
what
cinder plinth
at this point im not gonna spoonfeed
cinder plinth
does it make sense to write data from the beginning of the file to a buffer + offset?
surreal path
no
cinder plinth
when what you really want is to read bytes from file+offset?
surreal path
yes
cinder plinth
then fix that
cinder plinth
what is offset
surreal path
1
cinder plinth
is there a copy_unaligned
surreal path
lemme check
surreal path
let mut buf = "hello world!\n".as_bytes();
thats src
i cannot print dest
as this is running in a test
so an std enviroment
cinder plinth
idk can't you do println!("{} {}", dest src)
surreal path
no
surreal path
is there a copy_unaligned
no
surreal path
here
fn read(&self, buf: &mut [u8], offset: isize, count: usize) -> Result<usize, UNIXERROR> {
let mut count = count;
if buf.len() == 0 {
return Err(UNIXERROR::EINVAL);
}
if (offset + buf.len() as isize) as usize > self.data.len() {
count = (offset - self.data.len() as isize) as usize;
}
if self.data.len() == 0 {
return Ok(0)
}
let dest = unsafe {buf.as_mut_ptr()};
let src: *const u8 = unsafe {self.data.as_ptr().offset(offset)};
unsafe {
core::ptr::copy_nonoverlapping(src, dest, count)
}
return Ok(count);
}
no clue then
cinder plinth
I shall ask mr.gpt
surreal path
lmao
cinder plinth
// Copy the data safely using slices
let src = &self.data[offset..offset + read_len];
buf[..read_len].copy_from_slice(src);
try this
I actually did think of that but i wasn't sure if slices worked
surreal path
I actually did think of that but i wasn't sure if slices worked
not possible cause offset is of type isize
you cannot index slices with isize
cinder plinth
well
you can do
offset as usize...(offset + read_len) as usize
or something
that won't work for negative offsets yet but it's a start
cinder plinth
well negative offsets wont work if you dont have a cursor anyway
cinder plinth
I don't see you modifying it
surreal path
im implementing that
cinder plinth
well then easy
surreal path
its not pushed
cinder plinth
(self.cursor + offset) as usize...(size)
surreal path
okay and how do i make negative reads working
cinder plinth
well cursor+offset is always going to be positive
if you check for it ofc
you can't do a read at absolute -10
it's always relative to the cursor
cinder plinth
when you get read(-10) then you do cursor+-10
cinder plinth
idk what a shangain is
cinder plinth
// Copy the data safely using slices
let src = &self.data[offset..offset + r...
do this
it'll work
you can make offset usize
surreal path
you can make offset usize
okay is this good
fn read(&self, buf: &mut [u8], offset: usize) -> Result<usize, UNIXERROR> {
let mut size = offset + buf.len() as usize;
if buf.len() == 0 {
return Err(UNIXERROR::EINVAL);
}
if (offset + buf.len()) >= self.data.len() {
size = self.data.len();
}
if self.data.len() == 0 {
return Err(UNIXERROR::EPERM);
}
let pro = &self.data[offset..size];
buf[..pro.len()].copy_from_slice(pro);
return Ok(size);
}
why is it useless?
cinder plinth
you can just do size-offset
cinder plinth
yea
surreal path
okay
cinder plinth
same as (offset..size).len()
surreal path
same as (offset..size).len()
fn read(&self, buf: &mut [u8], offset: usize, count: usize) -> Result<usize, UNIXERROR> {
let mut size = offset + buf.len() as usize;
if buf.len() == 0 {
return Err(UNIXERROR::EINVAL);
}
if (offset + buf.len()) >= self.data.len() {
size = self.data.len();
}
if self.data.len() == 0 {
return Err(UNIXERROR::EPERM);
}
let pro = &self.data[offset..count];
buf[..count - offset].copy_from_slice(pro);
return Ok(count);
}
does THIS function look good now
cinder plinth
try it
surreal path
wait i think i fixed a bug
fn read(&self, buf: &mut [u8], offset: usize, count: usize) -> Result<usize, UNIXERROR> {
let mut size = offset + count as usize;
if buf.len() == 0 {
return Err(UNIXERROR::EINVAL);
}
if (offset + count) >= self.data.len() {
size = self.data.len();
}
if self.data.len() == 0 {
return Err(UNIXERROR::EPERM);
}
let pro = &self.data[offset..size];
buf[..(size) - offset].copy_from_slice(pro);
return Ok(size);
}
yea this is better
wait no i did not
sec
surreal path
```rs
fn read(&self, buf: &mut [u8], offset: usize, count: usize) -> Result<usiz...
wait why offset + count
@cinder plinth
cinder plinth
no that's wrong
surreal path
yea
surreal path
no that's wrong
should it be buf.len? orrrr
cinder plinth
size should be count
surreal path
just
size = count;
?
cinder plinth
nvm
cinder plinth
just
```rs
size = count;
```
?
yea
surreal path
yea
buf[..size - offset].copy_from_slice(pro);
what about size - offset
like what if size was 1
and offset is 1
it would be 0
and you would be indexing 0
which makes sense.?
i suppose it does
no cause
if size is 2
and offset is 1
it will index 1 of the slice
so not good
what should i do then
cinder plinth
true
surreal path
lma
cinder plinth
dont do it then
surreal path
yea
cinder plinth
mr.gpt was wrong
surreal path
clearly
mr gpt is stupid
fn write(&mut self, buf: &[u8], offset: usize, count: usize) -> Result<usize, UNIXERROR> {
let size = count;
if buf.len() == 0 {
return Err(UNIXERROR::EINVAL)
}
if offset + buf.len() > self.data.len() as usize {
self.data.resize((offset + buf.len()), 0);
}
if self.data.len() == 0 {
return Err(UNIXERROR::EPERM);
}
let pro = &buf[offset..size];
self.data.copy_from_slice(pro);
// SO EASY
return Ok(size);
}
i think this is also correct
cinder plinth
great
surreal path
when you get read(-10) then you do cursor+-10
one sec
for WHENCE::END what should i do
trait Stream {
fn read<T>(&self, buf: &mut [u8], sizeofbut: usize) -> Result<usize, UNIXERROR>;
fn write<T>(&self, buf: &mut [u8], sizeofbut: usize) -> Result<usize, UNIXERROR>;
fn seek(&mut self, offset: isize, wh: WHENCE) -> Result<usize, UNIXERROR>;
}
struct VNodeStream {
offset: usize,
vnode: Rc<RefCell<dyn vnode>>
}
enum VNODEFLAGS {
None,
DIR,
SYMLINK,
FILE
}
enum WHENCE {
CURRENT,
SET,
END
}
impl Stream for VNodeStream{
fn read<T>(&self, buf: &mut [u8], sizeofbut: usize) -> Result<usize, UNIXERROR> {
let res = self.vnode.borrow_mut().read(buf, self.offset, sizeofbut);
return res;
}
fn seek(&mut self, offset: isize, wh: WHENCE) -> Result<usize, UNIXERROR> {
match wh {
WHENCE::CURRENT => {
self.offset = (self.offset as isize + offset) as usize;
},
WHENCE::SET => {
self.offset = (self.offset as usize)
},
WHENCE::END => {
self.offset = (self.vnode.borrow_mut().get_attrib().unwrap().size as isize + offset) as usize
}
}
Ok(self.offset)
}
fn write<T>(&self, buf: &mut [u8], sizeofbut: usize) -> Result<usize, UNIXERROR> {
let res = self.vnode.borrow_mut().read(buf, self.offset, sizeofbut);
return res;
}
}
struct PosixFile {
vnode: Rc<RefCell<dyn vnode>>,
flags: VNODEFLAGS,
stream: VNodeStream
}
is this good
i think it looks good
okay so now we have a PosixFile
surreal path
eh its fine
surreal path
i finished implmenting PosixFile
its time...
for the scheduler
BUM BUM BUM
yall ready?
edgy pilot
write a completely fair scheduler implementation from linux
surreal path
lmao
elder shoal
once I get to rewriting my scheduler I will likely make it inspirted by ULE
surreal path
once I get to rewriting my scheduler I will likely make it inspirted by ULE
mathew if i get bash working tonight
will you be proud of me
😎
cinder plinth
i doubt you will
surreal path
watch me
cinder plinth
you need to implement a scheduler, syscalls, tty, port mlibc
you cant do that at the time it is atm
surreal path
im not sleeping
:)
so um
hahah
idc if i have school tmrw to be honest
i just do my classes and get home
then go sleep
then work
elder shoal
mathew if i get bash working tonight
no because you'd be rushing everything and thats bad
surreal path
no because you'd be rushing everything and thats bad
okay fair
ill just work what i can
surreal path
is that a good cpu queue
surreal path
why
surreal path
```c
// choose a cpu to run
// todo: better
int cpu = rand() % cpu_count;
```
^
:)
do yall think i should get dev devices working before scheduler
or like xsave and friends
edgy pilot
do yall think i should get dev devices working before scheduler
yes
molten grotto
because you can't take a &[u8] from syscalls
you can if you create a new in-kernel buffer that you copy the data to/from (like you pretty much want to do)
molten grotto
and tbh even if you don't you can create a slice from userspace ptr + size
cinder plinth
True
edgy pilot
I'm not very good at explaining things
molten grotto
how do they even work lol
they are just files with the vnode ops being set to whatever device specific fns
surreal path
they are just files with the vnode ops being set to whatever device specific fns
okay so if u wanted to implment a dev device for like a ps2 driver
you would just create a struct that implments the vnode ops and have that deal with the driver
?
edgy pilot
A better example would be disk access
surreal path
struct PS2Driver;
impl vnodeops for PS2Driver {
...
}
write to that file, disk gets written
read from it, you are directly reading from the storage
edgy pilot
tty
elder shoal
Tty demistified
surreal path
thank u
okay before i implment tty lets implment /dev/null
:)
fn read()
{
// we do nothing :)
}
is this how /dev/null works
elder shoal
bytes read = 0
return success
surreal path
bytes read = 0
return success
molten grotto
and for write just return the amount of data that it tried to write
surreal path
should i make a dev fs init function
surreal path
and for write just return the amount of data that it tried to write
i see
elder shoal
Im planning on putting all filesystems in a special section that gets initialised in vfs_init
But for now a devfs_init works
surreal path
should a devfs have a directory like tmpfs
molten grotto
yes that would work
elder shoal
Yeah you can have subdirs like pts
surreal path
i see
so just same implmentation as tmpfs
for directorys ig?
also im gonna need some way to get drivers to hook into the read() write() functions
molten grotto
you already have the trait?
surreal path
fair
molten grotto
just make a function to register a trait object to the devfs
surreal path
so just same implmentation as tmpfs
??
surreal path
just make a function to register a trait object to the devfs
wdym
molten grotto
as in a function that the driver can use to create a file in the devtmpfs with a file that contains its own ops
surreal path
as in a function that the driver can use to create a file in the devtmpfs with a...
how would that look like, explain further. i really gotta understand this so i dont make a shitty implmentation as with old nyaux
molten grotto
fn devtmpfs_register(parent_dir: &Arc<Mutex<Box<dyn VNodeOps>>>, file: Arc<Mutex<Box<dyn VNodeOps>>>) {
// ...
}
struct Ps2Device;
impl VNodeOps for Ps2Device {
fn read(&mut self, buf: &mut [u8]) -> Result<usize, Error> {
buf.fill(0xFF);
Ok(buf.len())
}
}
``` something like this I'd imaginewell yeah it could also just be a plain arc lol
molten grotto
why under an arc
that's not the important part, but you have to protect the vnode against concurrent access somewhere, either within the higher level or in the vnode fns itself
surreal path
that's not the important part, but you have to protect the vnode against concurr...
i see
surreal path
```rust
fn devtmpfs_register(parent_dir: &Arc<Mutex<Box<dyn VNodeOps>>>, file: A...
how would bro add the file to the parent dir if the only ops u can do is read write lookup and stat
molten grotto
you make a new op to create a file?
surreal path
wait create() exists nvm
surreal path
yea makes sense
fn create(&mut self, name: &str) -> Result<Rc<RefCell<dyn vfs::vnode>>, UNIXERROR> {
let dir = &mut self.files;
let ifeelsick = Rc::new(RefCell::new(tmpfsfile::default()));
dir.insert(name.to_string(), ifeelsick.clone());
return Ok(ifeelsick);
}
how my create looks anyway
molten grotto
though idk if that's what you would use in this case because you don't want to create a new vnode for every on-disk file you create right away or you are going to be running out of ram
surreal path
though idk if that's what you would use in this case because you don't want to c...
what
okay should i add a new op or smthin
create_from_file or smthin
idfk
molten grotto
though idk if that's what you would use in this case because you don't want to c...
or actually nvm, for an on-disk file the vnode would just die immediately if there are no references to the returned vnode
molten grotto
okay should i add a new op or smthin
no I think the existing one is fine
I just had to stop thinking about what happens for a second lol
surreal path
no I think the existing one is fine
how would i make it use my file i already have created or smthin
surreal path
```rs
fn create(&mut self, name: &str) -> Result<Rc<RefCell<dyn vfs::vnode>>, UN...
since its just gonna do devfsfile::default
or idfk
molten grotto
you could probably proxy the ops like astral does, as in the devfsfile would contains a field with devfsops trait object that the vnodeops fns would then call
surreal path
you could probably proxy the ops like astral does, as in the devfsfile would con...
i see
struct devfsfile {
ops: Rc<RefCell<dyn devfsops>>
}
something like this?
also should i replace all my usage of rc with arc?
and refcell with mutex?
or no
because i have smp now and like im gonna be implmenting scheduler soon ™️
molten grotto
maybe it could be a good idea then yeah
surreal path
maybe it could be a good idea then yeah
as well with tmpfs?
molten grotto
yeah with everything
surreal path
okay
molten grotto
something like this?
something like that yeah and in this case the ops don't need to be arc<mutex> because the upper vnode already is
you don't need to lock twice
surreal path
something like that yeah and in this case the ops don't need to be arc<mutex> be...
what should the ops be then
Arc<dyn devfs>?
molten grotto
Box<dyn devfsops> would probably do
surreal path
okay
surreal path
```rust
fn devtmpfs_register(parent_dir: &Arc<Mutex<Box<dyn VNodeOps>>>, file: A...
wait qwinci, how do i assign the ops to the file????
molten grotto
wdym
surreal path
like, theres no function to attach ops to a devfsfile
its initally none
its wrapped in an option
molten grotto
the devfsfile create function can take the ops?
surreal path
but that wont follow the vnodeops trait
molten grotto
follow in what way
surreal path
fn create(&mut self, name: &str) -> Result<Arc<Mutex<dyn vfs::vnode>>, UNIXERROR>
i cant just add another parameter
because in vnode ops ive defined fn create as that
and if i add an ops field thats like really dumb
cause most fs's wont use that parameter
molten grotto
ah
I'd probably just make a new separate create function specifically for the devfs that can take the ops
molten grotto
it doesn't have to be inside vnodeops at all
surreal path
wym
molten grotto
well like you could do the create stuff directly inside the function that's used to register something to the devtmpfs and that function doesn't have to be a part of the vnode trait
and I don't see why you couldn't make it work using the existing create fn as well, call that inside the devtmpfs create wrapper function and then assign the ops
fn devtmpfs_register(parent_dir: &Arc<Mutex<Box<dyn VNodeOps>>>, name: &str, ops: Box<dyn DevFsOps>) {
let mut node = parent_dir.create(name);
node.ops = Some(Box::new(DevFsNode::new(ops))));
}
``` if this is how it works (?) (idk if you actually have ops as a box but you get the idea anyway)yea thats a good way
thanks qwinci :)
surreal path
```rust
fn devtmpfs_register(parent_dir: &Arc<Mutex<Box<dyn VNodeOps>>>, name: &...
wait no
its not
in create i return a arc mutex dyn vnodeops
fn create(&mut self, name: &str) -> Result<Arc<Mutex<dyn vfs::vnode>>, UNIXERROR> {
return Err(UNIXERROR::EISFILE);
}
so like
😭
yea i have no idea either
😭
how we should design this like
molten grotto
ig the devfsnode could have a member function for the creation of a new file and then you have the logic there
surreal path
ig the devfsnode could have a member function for the creation of a new file and...
member function?
molten grotto
impl devfsnode {
fn dev_create(&mut self, name: &str, ops: Box<dyn devfsops> {}
}
then you do the hashmap stuff in there inserting a new vnode to the map
elder shoal
```rust
fn devtmpfs_register(parent_dir: &Arc<Mutex<Box<dyn VNodeOps>>>, name: &...
wtf is a
&Arc<Mutex<Box<dyn
ik 😭
molten grotto
wtf is a
```rust
&Arc<Mutex<Box<dyn
```
atomically reference counted mutex of heap allocated object implementing VNodeOps
surreal path
:)
thorn bramble
a reference to one*
surreal path
for some reason
molten grotto
oh yeah
thorn bramble
reference to a reference
surreal path
lmao
molten grotto
I mean it can avoid one refcount increment/decrement
molten grotto
what did you try
surreal path
one sec
surreal path
what did you try
molten grotto
and what is the problem
molten grotto
oh yeah its the ops itself that are returned from create lol
surreal path
again that breaks vnodeops
okay actually wait i have an idea
i know how to do it lol
dwdwdw
molten grotto
well you could have the devfs ops field as none initially and otherwise populate the ops inside create() and then inside that dev_create downcast the vnode
molten grotto
you can downcast a trait object to the actual underlying object (like to a reference to an actual struct) though you do need a little helper method for that
surreal path
you can downcast a trait object to the actual underlying object (like to a refer...
thats with box right?
so i need to wrap everything under a box?
molten grotto
no it doesn't matter where its stored
but anyway there are probably other solutions in this case
surreal path
it wont let call downcast
molten grotto
yeah because you need a helper method inside the trait that returns &mut dyn Any
surreal path
how to do implment that
molten grotto
and the impl for that can be self
surreal path
oh i see
molten grotto
then you can do let a: &mut mystruct = node.as_any_mut().downcast_mut().unwrap() or whatever
surreal path
gotcha
molten grotto
well it depends in what trait you put that method into
surreal path
i put vnode
molten grotto
like if you want to be able to cast a vnodeops then its in vnodeops
surreal path
so vnodeops for Self?
molten grotto
you probably already have an impl block for vnodeops
molten grotto
just put it there
surreal path
molten grotto
ah yeah you literally created a new trait for it
probably best to just move the decl inside vnodeops
surreal path
what
molten grotto
trait vnodeops {
// ...
fn as_any_mut(&mut self) -> &mut dyn Any;
}
oh hell naw
surreal path
oh hell yes :)
molten grotto
impl vnodeops for devfsfile {
// ...
fn as_any_mut(&mut self) -> &mut dyn Any {
self
}
}
i see
molten grotto
but yeah I am pretty sure there would be ways to do what you want without needing to do it like this
surreal path
oh hell naw
whats wrong with downcasting
thorn bramble
im not even joking
this is just
you dont write codel ike this
if you do
you fucked up terriblyu
surreal path
broski u have any other ideas
thorn bramble
no i cbf reading all of ur code
molten grotto
I already said one idea to you, you could just move the logic from inside create to that fn
surreal path
I already said one idea to you, you could just move the logic from inside create...
yea and implment downcast
molten grotto
you wouldn't need downcast if you'd move the logic there as you'd have access to the new devfsnode object you create
surreal path
you wouldn't need downcast if you'd move the logic there as you'd have access to...
in the create function?
but that cant take ops
molten grotto
its why I said that move the code from the create function to the devfs_register or whatever fn
molten grotto
though then it also means that the parent dir vnode would have to not be a trait object and instead it would be a complete type (and you'd need a new non-vnodeops lookup fn that returns that complete type), though then you could reuse that to implement the vnodeops lookup fn
thorn bramble
its not a pointer cast
surreal path
what is it then
surreal path
how is it cancer
thorn bramble
this turns rust into python
surreal path
theres no performance hit anyway
surreal path
wait what
thorn bramble
what the fuck did you think it was doing?
surreal path
how big is the perfomance hit
thorn bramble
well it has to check that the object is actually what youre trying to cast it to?
and if not then panic
lol
surreal path
and that is a lot of perfomance loss?
thorn bramble
every time you call the downcast method
edgy pilot
I don't think that's "a lot of performance loss"
but if the rust masters say it's bad, do it the correct way
surreal path
every time you call the downcast method
and im only calling it ONCE in the entire kernel
for making devfs
thorn bramble
ah i thought
u were calling it
on every like
idk devfs operation
or whatever
but still this is bad lol
fix it
thorn bramble
but if the rust masters say it's bad, do it the correct way
pub trait Any: 'static {
// Required method
fn type_id(&self) -> TypeId;
}
A trait to emulate dynamic typing.```i mean.. yes it is bad lol
langauges are typed for a reason
statically typed*
edgy pilot
I don't type my languages
I just speak them and computer executes
surreal path
though then it also means that the parent dir vnode would have to not be a trait...
wdym
im a bit confused
edgy pilot
statically typed*
I guess that's something like dynamic_cast in c++
the thing he's doing
thorn bramble
well c++ has std::any
molten grotto
I guess that's something like dynamic_cast in c++
basically but with less performance overhead (or at least I'd hope so, it wouldn't be that hard to beat c++ dynamic cast because of all the things it has to take into account 
)
I mean ofc its still a little even if its just a single if but its not like that bad
molten grotto
I meant that the devfs_register function would take in a parent as an Arc<Mutex<Box<devfsnode>>> or whatever so then you cna directly insert the new node into the parent's hashmap
but if you already got it working then it works™️
edgy pilot
I understand Mutex but what's Arc or Box
molten grotto
arc is an atomically reference counted object and box is just a heap allocated object
edgy pilot
so is that like atomic shared_ptr with a lock on it
molten grotto
arc is basically like std::shared_ptr from c++
molten grotto
so is that like atomic shared_ptr with a lock on it
with a lock on the object that it holds yeah
molten grotto
why does it have to be an arc
molten grotto
why does it have to be an rc either? wouldn't a box do?
surreal path
why does it have to be an rc either? wouldn't a box do?
no
cause borrow rules
wont let me
molten grotto
what are you doing that needs this
surreal path
what are you doing that needs this
getting the cpu context
nvm a box works fine
alright
surreal path
what are you doing that needs this
how would i store the current thread thats running?
i need this to be per cpu
im unsure of how to do that
flat nymph
Too much messages; do you have TLS already?
surreal path
tls?
flat nymph
"it depends"