Jump to content




Cubix - a simple unix-like OS


28 replies to this topic

Poll: Cubix Stuff

Choose one feature that you like in Cubix

You cannot see the results of the poll until you have voted. Please login and cast your vote to see the results of this poll.

Choose features that you would like in the next versions of Cubix

You cannot see the results of the poll until you have voted. Please login and cast your vote to see the results of this poll.

Rate Cubix

You cannot see the results of the poll until you have voted. Please login and cast your vote to see the results of this poll.

Would you complain about the lack of something in cubix?

You cannot see the results of the poll until you have voted. Please login and cast your vote to see the results of this poll.
Vote Guests cannot vote

#21 Piorjade

  • Members
  • 244 posts
  • LocationComputer, Germany

Posted 22 September 2016 - 12:03 PM

AFAIK is editing files / making folders / deleting stuff in the root directory of linux forbidden, as long as you aren't root, which it isn't here (I only tried the stock cubix user, and he was able to do stuff in root)
Well that's at least in Manjaro KDE like that.

#22 lkmnds

  • Members
  • 25 posts
  • LocationBrazil

Posted 24 September 2016 - 12:06 AM

I forgot to implement that the owner of / is root, but I'm making a rewrite of most stuff and most things should be better when I finish(specially the filesystems part)

It would take a long time though

#23 lkmnds

  • Members
  • 25 posts
  • LocationBrazil

Posted 09 October 2016 - 06:11 AM

0.6.0-rc3 released.

Changes from 0.5.3 to 0.6.0-rc3:

This is a RC, pretty unstable
Rewrite of most code(including kernel, modules, and programs, not all of them are working, specially the ones that use a lot of kernel functions)
New VFS layer, it isn't done though
TODO: Finish authentication module
TODO: Finish cshell
TODO: Fix issues with the VFS

#24 Geforce Fan

  • Members
  • 846 posts
  • LocationMissouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension

Posted 19 October 2016 - 10:41 PM

Would you be interested in a custom file system? I've been writing one that goes ontop of CC's existing one, sort of. The benefits to this are:
1. More unix-like filesystem--This filesystem is based on an inode system
2. Ability to create a bunch of floppy drives and write to them as if they where the same filesystem(Useful if you want to hook up 100 floppy drives and create a huge storage disk for your extremely messy development environment server or something)

This does do a couple things in ways that aren't exactly true to real life, such as:
1. Dynamically sized blocks --This is just more effecient to do considering...
2. Each block is its own file -- This is because, if they where one file (along with the inode), I'd have to read() in for loops to get to the stuff I actually want to read(like a tape drive). I estimate that, if a 1KB file had 999KB of stuff preceding it, it would take ~1.5 seconds just to access that file. That is just too slow, and not worth it when splitting it up into files adds..
3. The ability to make new blocks on different storage devices. Yes, this means you can just plug in more disk drives and add blocks to them on your root filesystem.

And many other things, but those are major ones(at least that I know of)

There's 2 abstraction layers necessary for the filesystem, but Ext2CC uses 3.
First is a table containing all the methods of Ext2CC. This is kind-of class-oriented--not that this cannot be changed--but is like that right now for good reason(almost all functions access the inode table, a lot easier to do self.inode rather than passing it to each function). Secondly, is a CC-style FS api that translates the FS calls to Ext2CC calls(you could have this FS library directly call things, but again, for ext2cc it is a translation). Lastly, is an additional FS library that determines which filesystem you are accessing, and returns the values given from calling that function in that fs library. Additionally, it (will) handle coping and moving from filesystem to filesystem. Also additionally, ext2's inode will contain permissions and the final extraction layer will check for permissions.

As you can imagine, this last abstraction layer would also make it much easier to implement a VFS.

The code is here: https://github.com/A...ob/master/start (it can currently be ran on its own and will start a new instance of CraftOS that runs on its filesystem. This is sort of just a cobbled together way of real-world testing my filesystem.). Everything after line 768(at the time of writing this) is debug code. Not all FS things have been implemented, however, I had implemented enough to edit a file, save it, and open it again as well as list the files. I would also like to rework the 2nd abstraction layer -- fs calls to ext2 calls-- to use inodes for reading and writing rather than file names, so that it may access permission. Lastly, upon everything else's completion, I will add methods that deter from CC's standard FS system like getMetadata or something.

To get it up and running right now, just gitget the repo, then rename rootFS_temp to rootFS . Only things I know that are working right now are edit and ls(except in rom and ccFS, everything should work in there).

If you're interested, I can start trying to implemented it into Cubix.

Edited by Geforce Fan, 19 October 2016 - 10:57 PM.


#25 lkmnds

  • Members
  • 25 posts
  • LocationBrazil

Posted 20 October 2016 - 01:55 AM

I'm pretty interested on ext2cc on Cubix, but the VFS layer would need to support inodes in the first place(It has, kinda, but needs more work, documentation and stuff like that)

#26 Geforce Fan

  • Members
  • 846 posts
  • LocationMissouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension

Posted 20 October 2016 - 02:58 AM

Well, the current VFS layer you have should work as long as it re-implements the FS library somewhere. A better explaination of the abstraction is:
A MS-Paint style diagram
The secondary FS really just determines who gets passed what. For example, If I do

fs.list("/rom")

Then the secondary FS determins that the filesystem to use is RomFS. It then hands the full path (probably will change it to the fake path, so "rom/programs" becomes "programs")to RomFS, which then makes the FS call. In this case, it's list, so it returns a list of files.

#27 lkmnds

  • Members
  • 25 posts
  • LocationBrazil

Posted 20 October 2016 - 05:30 PM

What I'm thinking(and what is implemented) is the VFS being implemented in the fs library, calls to fs are being done by the VFS, who then calls other FS modules(like cifs, procfs, tmpfs, etc.)

#28 Cross_Sans

  • Members
  • 122 posts
  • LocationFrance

Posted 03 December 2016 - 05:15 PM

So, you would re-write the fs api to make it runnable and compatible with other programs for VFS?

#29 lkmnds

  • Members
  • 25 posts
  • LocationBrazil

Posted 04 December 2016 - 11:50 PM

If I understood your question correctly, programs would use the FS API as usual, but the VFS redirects those FS calls to the proper filesystem driver(cifs, cbxfs, procfs, tmpfs, devfs, etc.).

What needs work is the specification of FS drivers to communicate correctly with the VFS, but I'm going to have my exams, so no work on that until 9th December or something. For now the VFS can call(https://github.com/l...ase/fs.lua#L242) CIFS(Cubix Integration FS, https://github.com/l...lib/fs/cifs.lua) which redirects those calls to the "old" fs api(the "new" fs api is the VFS), which then communicates to the fs the (real) computer uses to manage the other (computercraft) computer folder.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users