-
Notifications
You must be signed in to change notification settings - Fork 48
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
Comments
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:
I'd expect the interface to easily express following scenarios:
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);
}
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);
}
TODO |
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. |
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.
The text was updated successfully, but these errors were encountered: