Quote from: nspiredev500 on June 10, 2020, 01:58:34 PM

Quote from: lights0123 on June 09, 2020, 01:45:42 AMI've written Rust bindings to ndless

That's cool, I thought about using Rust myself, and I even saw your project on github. My first memory manager didn't work, and I thought Rust could help with that. I ended up just doing a rewrite and it seems to work now, but for other things Rust could still be helpful. But I don't know enough about Cargo to do what I need. Maybe you can help me. I would need to compile the code like with GCC's -fPIC or -fPIE flag. It has to use the global offset table and link into my ELF file.
The global offset table is important, because it self-relocates to a higher base address, and will be mapped like this into every address space created.

I don't know too much about linking, but I'd be glad to help. rustc does compile with PIC by default:

Quoterelocation-model=[pic,static,dynamic-no-pic]
    The relocation model to use. (Default: pic)

Although apparently you can pass arbitrary arguments to LLVM too.
You'd just need to add
[lib]
crate-type = ["staticlib"]
to your Cargo.toml and make sure that you have a lib.rs instead of a main.rs source file. Building will automatically produce a libyourcratename.a that you can link to.

Quote from: nspiredev500 on June 10, 2020, 01:58:34 PMI looked at your project now, and it looks great . In your book you say "Your program will never segfault". Something like this was one of the motivations for my project.
Creating a user-mode wrapper around the OS and the hardware, so no program can crash or brick your calculator.
What timer do you use for your wrapper? I want to remain compatible to as many community projects as possible.
I use the first timer for my millisecond UNIX time, because the OS doesn't use it. If your Rust wrapper also uses the first timer, both cannot work at the same time.
But I can expose timer functions as syscalls, and detecting OSExt is also easy, so you could just do a runtime check.

I use the same timer as SDL, which is at 0x900C0000. I still use that timer for sleeping, as I get more precision that the millisecond-accurate msleep Ndless function. I don't ever use the timer at 0x900D0000, although I guess I could switch to it as I don't call Ndless's sleeping functions.
I could switch to your timer syscalls if you provide a way to detect it. I'd still like to get the raw ticks if possible, for the nice 30 μs precision. I don't know how much overhead there is in a syscall—would it be worth it replicating vsyscall or vDSO since you apparently already have separate userspace memory?

Quote from: nspiredev500 on June 10, 2020, 01:58:34 PM

Quote from: lights0123 on June 09, 2020, 01:45:42 AMthis is done with fcntl and O_NONBLOCK

Nucleus writes "initializing POSIX layer" on the uart sometime during boot I think, so it should have the fcntl syscall.
The problem is to know which system call number it has and what arguments it takes.
You could assume normal linux arguments and just fuzz all the system calls in firebird until it works.

Any suggestions on how to do that?

On the GitHub page, you mentioned:

Quote from: nspiredev500making a proper file brower, the integrated one is too slow

Do you know if it's possible to do async file I/O at all? I've written Rust bindings to ndless, and one thing I've been playing around with is its zero-cost language-level async/await support. I have basic support for the timer and keypad which lets you write code that compiles to a state machine without having to actually think about it, as if there were threads. Typically, in Linux, this is done with fcntl and O_NONBLOCK, but ndless doesn't have (expose?) that syscall. Do you know if there's any ability to do that? I don't know how far you're looking to write your OS—if that just can't be done with Nucleus RTOS, is there any way to talk to the flash chip directly any do some processing while waiting for the results, like a modern computer?

Basically, I'm trying to figure out how you're going to make a faster file browser, as I'd assume that it's I/O bound and you can't really speed it up.