-1

How does the process of creating a file in ext2 file system look like?

I am trying to make a simple syscall which takes a path and creates given file - like touch.

For example, the code:

int main(void)
{
    syscall(MY_SYSCALL_NUMBER, "/tmp/file");
}

Should create a file called "file" in /tmp.

Now how should the syscall itself work?

My work so far (I ommited error checking for readibility here):

asmlinkage long sys_ccp(const char __user *arg)
{
     struct path path;
     struct inode *new_inode;
     struct qstring qname;

     //ommited copy from user for simplicity
     qname.name = arg;
     qname.len = length(arg);

     kern_path(src, LOOKUP_FOLLOW, &path);
     new_inode = ext2_new_inode(path.dentry->d_parent->d_inode, S_IFREG, &qname);
}

This seems to work (I can see in logs that an inode is allocated), however, when I call ls on the directory I can't see the file there.

My idea was to add the new inode to struct dentry of directory, so I added this code:

struct dentry *new_dentry;

new_dentry = d_alloc(path.dentry->d_parent, &qname);
d_instantiate(new_dentry, new_inode);

However, this still doesn't seem to work (I can't see the file using ls).

How to implement this syscall correctly, what am I missing?

EDIT: Regarding R.. answer - purpuse of this syscall is to play around with ext2 and learn about its design, so we can assumie that path is always valid, the filesystem is indeed ext2 and so on.

Josh
  • 121
  • 5
  • Don't re-post a question if you got no answer or the question was closed! Instead edit the original and ask for re-open if it does comply to site-rules now. See [ask]. – too honest for this site Jun 13 '16 at 21:06
  • Adding Linux syscalls is not the way to "play around with ext2 and learn its design". If you want to do that, write a standalone utility that can process ext2 filesystems (either as image files or directly accessing the block device). What you seem to be trying to do is *poke at the kernel-internal programming interfaces for the ext2 fs implementation in the kernel*, which has more to do with how the kernel vfs layer works than how ext2 works. It's not a useful exercise. – R.. GitHub STOP HELPING ICE Jun 14 '16 at 02:21

1 Answers1

1

You're completely mixing up the abstraction layers involved. If something like your code could even work at all (not sure if it can), it would blow up badly and crash the kernel or lead to runaway wrong code execution if someone happened to make this syscall on a path that didn't actually correspond to an ext2 filesystem.

In the kernel's fs abstraction, the fact that the underlying filesystem is ext2 (or whatever it is) is irrelevant to the task of making a file on it. Rather all of this has to go through fs-type-agnostic layers which in turn end up using the fs-type-specific backends for the fs mounted at the path.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • Also, assuming that the path is always ext2 - why would something like this not work, and how to make it work? – Josh Jun 13 '16 at 21:10
  • 1
    @Josh: "why would something like this not work, and how to make it work" - Statement and the contrary in the same sentence. Did you even read what you wrote here? – too honest for this site Jun 13 '16 at 21:45