taskfs and kernfs

taskfs and kernfs

[Dave Zarzycki]

I got bored this evening and decided to learn more about the Linux kernel
by splitting out procfs into two separate file systems:

taskfs which contains /proc/self and /proc/[1-9]*
kernfs which contains everything else that procfs provides.

You can get the quick hack from here (this patch is against 2.4.0-test10):

http://thor.sbay.org/~dave/taskfs_and_kernfs.diff.gz

I've tested the two file systems on the user-mode-linux kernel. :-)
They both seem to work as expected, even when /proc is mounted.

Alexander Viro, is this kernfs at all useful as a starting point for your
kernfs goals?

davez

-- 
Dave Zarzycki
http://thor.sbay.org/~dave/



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: taskfs and kernfs

[Alexander Viro]

On Sun, 5 Nov 2000, Dave Zarzycki wrote:

> I got bored this evening and decided to learn more about the Linux kernel
> by splitting out procfs into two separate file systems:
> 
> taskfs which contains /proc/self and /proc/[1-9]*
> kernfs which contains everything else that procfs provides.
> 
> You can get the quick hack from here (this patch is against 2.4.0-test10):
> 
> http://thor.sbay.org/~dave/taskfs_and_kernfs.diff.gz
> 
> I've tested the two file systems on the user-mode-linux kernel. :-)
> They both seem to work as expected, even when /proc is mounted.
> 
> Alexander Viro, is this kernfs at all useful as a starting point for your
> kernfs goals?

Not really. Sure, splitting procfs-proper (per-process stuff) is a nice
thing, but it's hardly a real problem. All preliminary work for that
had been done about a year ago - base.c and array.c vs. everything else.

The reason why this splitup didn't happen yet is the lack of union-mount.
IOW, we can split them, but we will not be able to preserve the namespace.
Union-mount is a 2.5 stuff - involves credentials cache and change of
->readdir() prototype, so freeze is not a time for that.

However, kernfs is _not_ procfs \setminus procfs-proper. It's our current
/proc/sys. And here we have an interesting set of problems due to the way
it is populated and accessed. We have sysctl(2) to deal with, we have
static initializers for sysctl tables and we have rather odd combination of
three tree-like structures: dcache tree, proc_dir_entry tree and list
of trees consisting of ctl_table. That's where the problems are. And yes, once
kernfs is split off the rest of procfs \setminus procfs-proper will become
much simpler. Sigh..

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: taskfs and kernfs

[Dave Zarzycki]

On Sun, 5 Nov 2000, Alexander Viro wrote:

> However, kernfs is _not_ procfs \setminus procfs-proper. It's our current
> /proc/sys.

Okay. I didn't realize that's what you had in mind when you wrote
"kernfs." Mind if I ask why you didn't call it "sysctlfs" or "sysfs?"

In you earlier e-mail, you suggested that sysctl(2) would use path_walk().
Would that mean that your kernfs would have to be loaded into the kernel
and mounted for sysctl(2) to work? Or am I missing something obvious?

davez

-- 
Dave Zarzycki
http://thor.sbay.org/~dave/









-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: taskfs and kernfs

[Alexander Viro]

On Sun, 5 Nov 2000, Dave Zarzycki wrote:

> On Sun, 5 Nov 2000, Alexander Viro wrote:
> 
> > However, kernfs is _not_ procfs \setminus procfs-proper. It's our current
> > /proc/sys.
> 
> Okay. I didn't realize that's what you had in mind when you wrote
> "kernfs." Mind if I ask why you didn't call it "sysctlfs" or "sysfs?"

Check *BSD.

> In you earlier e-mail, you suggested that sysctl(2) would use path_walk().
> Would that mean that your kernfs would have to be loaded into the kernel
> and mounted for sysctl(2) to work? Or am I missing something obvious?

Yes. No. Yes.

It doesn't have to be mounted anywhere - we need only dentry tree and some
struct vfsmount to use path_walk(). Said vfsmount doesn't have to be anywhere
near the mount tree.

As for the "loaded in the kernel" - at that point the source of fs-related
part is ~12Kb and sysctl.c is seriously trimmed (sysctl tree traversal is
gone). Moreover, it's going to shrink more when we go for pure dcache variant.
IOW, there is no point in making it modular - no more than doing modular
CONFIG_SYSCTL in the current setup.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: taskfs and kernfs

[Albert D. Cahalan]

Alexander Viro writes:
> On Sun, 5 Nov 2000, Dave Zarzycki wrote:
>> On Sun, 5 Nov 2000, Alexander Viro wrote:
>>
>>> However, kernfs is _not_ procfs \setminus procfs-proper. It's our current
>>> /proc/sys.
>>
>> Okay. I didn't realize that's what you had in mind when you wrote
>> "kernfs." Mind if I ask why you didn't call it "sysctlfs" or "sysfs?"
>
> Check *BSD.

Meanwhile, the FreeBSD people seem to be about to junk kernfs.
One is supposed to use sysctl. (freebsd-hackers or freebsd-arch
just this week)

I didn't know penguins went dumpster diving in Satan's trash.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/