Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pseudo filesystem framework #344

Open
coodie opened this issue May 24, 2017 · 2 comments
Open

Pseudo filesystem framework #344

coodie opened this issue May 24, 2017 · 2 comments
Labels
proposal should we spend time on it?

Comments

@coodie
Copy link
Contributor

coodie commented May 24, 2017

At this moment all of our user space programs can only read files from ramdisk. We'd like to have possibility to modify filesystem and its files. We are quite far from getting persistent file system like fat or ext, but at this moment having filesystem existing only in ram should be enough.

@coodie coodie self-assigned this May 24, 2017
@coodie coodie added the feature label May 25, 2017
@cahirwpz cahirwpz changed the title tmpfs Pseudo filesystem framework May 25, 2017
@cahirwpz
Copy link
Owner

Actually there's a need to solve the problem in more generic way. We need to represent many filesystems that have only in-memory representation and are dynamically created at kernel runtime. I could come up with four different classes of such filesystems, namely:

  • devfs, procfs – dynamic filesystems, maintained by corresponding kernel subsystems,
  • driverfs – mostly static filesystems, maintained by device drivers (e.g. vga, uart, etc.),
  • tmpfs - dynamic filesystems, can be read and write by user,
  • initrd – static filesystem, created at kernel bootup time.

I'd expect the interface to easily express following scenarios:

  1. Populate devfs with basic devices:
static vnodeops_t zero_vops = { ... };
static vnodeops_t null_vops = { ... };

extern pseudofs_t *devfs;

void init_basic_devs() {
  vnode_t *root = pfs_getroot(devfs);
  /* fetch default uid, gid, mode, ... for a block device */ 
  vattr_t *defattr = pfs_getdefattr(devfs, V_BLK);
  pfs_register(devfs, root, "null", V_BLK, &null_vops, defattr);
  pfs_register(devfs, root, "zero", V_BLK, &zero_vops, defattr);
}
  1. Populate devfs with video0 device:
static vnodeops_t vga_fb_vops = { ... };
static vnodeops_t vga_palette_vops = { ... };
static vnodeops_t vga_videomode_vops = { ... };

extern pseudofs_t *devfs;

static int stdvga_attach(device_t *dev) {
  /* NULL as a last argument stands for default vnode attributes */
  vnode_t *video = pfs_makedir(pfs_getroot(devfs), dev->d_nameunit, NULL);
  pfs_register(devfs, video, "fb", DT_BLK, &vga_fb_vops, NULL);
  pfs_register(devfs, video, "palette", DT_BLK, &vga_palette_vops, NULL);
  pfs_register(devfs, video, "videomode", DT_BLK, &vga_videomode_vops, NULL);
}
  1. Initial ramdisk filesystem:
TODO

@coodie
Copy link
Contributor Author

coodie commented May 27, 2017

I don't think pseudofs is suitable for tmpfs and ramdisk. It's going to be difficult to come up with perfect pseudofs implementation at this moment, because I don't understand how devfs work exactly and I'd rather devfs to be finished yet.

I'd rather put my efforts to write tmpfs first, wait for somewhat cumbersome devfs and more work with devices to be done and then abstract everything when I can see what's common for devfs, initrd and tmpfs. For this task I think approach of providing prototype first then reworking everything from start is just better. And in case we can't get it perfectly, we'll at least have something that might not be the best solution but it's still better because we have something to work with and can change it later.

@cahirwpz cahirwpz added proposal should we spend time on it? and removed feature labels Jan 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal should we spend time on it?
Projects
None yet
Development

No branches or pull requests

2 participants