Re: [PATCH] configfs, a filesystem for userspace-driven kernel object configuration
Matt Mackall wrote: > On Sun, Apr 03, 2005 at 12:57:28PM -0700, Joel Becker wrote: > >> An interface in /proc where the API is: >>or an ioctl(2) interface where the API is: >> >>becomes this in configfs: >> >> # cd /config/mythingy >> # mkdir foo >> # echo 1 > foo/index >> # echo 3 > foo/count >> # echo 0x00013 > foo/address >> >> Instead of a binary blob that's passed around or a cryptic >>string that has to be formatted just so, configfs provides an interface >>that's completely scriptable and navigable. > > How does the kernel know when to actually create the object? "actually create", huh? :) In the trivial case Joel describes, the item is almost certainly allocated during "# mkdir foo" when the subsystem will get a ->make_item() call for the 'mythingy' group it registerd. The various attribute writes then find the item by following their configfs_attribute argument to the item that its embedded in. But I bet you're not really asking about creation. I bet you're wondering how the kernel will know when enough attributes have been filled and that it's safe to use the object. Misguided items could assign magical ordering to the attribute filling such that once a final attribute is set, and others have been set, the item goes live. That's what ocfs2 does now, sadly, but certainly not as a long-term solution. The missing piece is the 'commit_item' group operation that is yet to be implemented. The intent is to have a directory of pending items that can have their attributes filled before being rename()ed into a directory of items that are in active use. The commit_item() call that hits at rename() would give the kernel the chance to refuse the item because attributes haven't been filled in or conflict with existing items, or whatever. - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] configfs, a filesystem for userspace-driven kernel object configuration
Arjan van de Ven wrote: > On Sun, 2005-04-03 at 12:57 -0700, Joel Becker wrote: > >>Folks, >> I humbly submit configfs. With configfs, a configfs >>config_item is created via an explicit userspace operation: mkdir(2). >>It is destroyed via rmdir(2). The attributes appear at mkdir(2) time, >>and can be read or modified via read(2) and write(2). readdir(3) >>queries the list of items and/or attributes. >> The lifetime of the filesystem representation is completely >>driven by userspace. The lifetime of the objects themselves are managed >>by a kref, but at rmdir(2) time they disappear from the filesystem. > > > does that mean you rmdir a non-empty directory ?? Yeah, but only attributes and default groups are automatically torn down. You can't rmdir() an item that is the destination of links and you can't rmdir() groups that still contain items. - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] configfs, a filesystem for userspace-driven kernel object configuration
On Sun, Apr 03, 2005 at 12:57:28PM -0700, Joel Becker wrote: > Folks, > I humbly submit configfs. With configfs, a configfs > config_item is created via an explicit userspace operation: mkdir(2). > It is destroyed via rmdir(2). The attributes appear at mkdir(2) time, > and can be read or modified via read(2) and write(2). readdir(3) > queries the list of items and/or attributes. > The lifetime of the filesystem representation is completely > driven by userspace. The lifetime of the objects themselves are managed > by a kref, but at rmdir(2) time they disappear from the filesystem. > configfs is not intended to replace sysfs or procfs, merely to > coexist with them. > An interface in /proc where the API is: > > # echo "create foo 1 3 0x00013" > /proc/mythingy > > or an ioctl(2) interface where the API is: > > struct mythingy_create { > char *name; > int index; > int count; > unsigned long address; > } > > do_create { > mythingy_create = {"foo", 1, 3, 0x0013}; > return ioctl(fd, MYTHINGY_CREATE, &mythingy_create); > } > > becomes this in configfs: > > # cd /config/mythingy > # mkdir foo > # echo 1 > foo/index > # echo 3 > foo/count > # echo 0x00013 > foo/address > > Instead of a binary blob that's passed around or a cryptic > string that has to be formatted just so, configfs provides an interface > that's completely scriptable and navigable. How does the kernel know when to actually create the object? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] configfs, a filesystem for userspace-driven kernel object configuration
On Sun, 2005-04-03 at 12:57 -0700, Joel Becker wrote: > Folks, > I humbly submit configfs. With configfs, a configfs > config_item is created via an explicit userspace operation: mkdir(2). > It is destroyed via rmdir(2). The attributes appear at mkdir(2) time, > and can be read or modified via read(2) and write(2). readdir(3) > queries the list of items and/or attributes. > The lifetime of the filesystem representation is completely > driven by userspace. The lifetime of the objects themselves are managed > by a kref, but at rmdir(2) time they disappear from the filesystem. does that mean you rmdir a non-empty directory ?? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] configfs, a filesystem for userspace-driven kernel object configuration
On Sun, Apr 03, 2005 at 12:57:28PM -0700, Joel Becker wrote: > I humbly submit configfs. With configfs, a configfs > ... > Patch is against 2.6.12-rc1-bk3. Updated for bk5 and the new backing_dev capabilites mask: http://oss.oracle.com/~jlbec/files/configfs/2.6.12-rc1-bk5/configfs-2.6.12-rc1-bk5-1.patch Joel -- "Against stupidity the Gods themselves contend in vain." - Freidrich von Schiller Joel Becker Senior Member of Technical Staff Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] configfs, a filesystem for userspace-driven kernel object configuration
Folks, I humbly submit configfs. With configfs, a configfs config_item is created via an explicit userspace operation: mkdir(2). It is destroyed via rmdir(2). The attributes appear at mkdir(2) time, and can be read or modified via read(2) and write(2). readdir(3) queries the list of items and/or attributes. The lifetime of the filesystem representation is completely driven by userspace. The lifetime of the objects themselves are managed by a kref, but at rmdir(2) time they disappear from the filesystem. configfs is not intended to replace sysfs or procfs, merely to coexist with them. An interface in /proc where the API is: # echo "create foo 1 3 0x00013" > /proc/mythingy or an ioctl(2) interface where the API is: struct mythingy_create { char *name; int index; int count; unsigned long address; } do_create { mythingy_create = {"foo", 1, 3, 0x0013}; return ioctl(fd, MYTHINGY_CREATE, &mythingy_create); } becomes this in configfs: # cd /config/mythingy # mkdir foo # echo 1 > foo/index # echo 3 > foo/count # echo 0x00013 > foo/address Instead of a binary blob that's passed around or a cryptic string that has to be formatted just so, configfs provides an interface that's completely scriptable and navigable. Patch is against 2.6.12-rc1-bk3. http://oss.oracle.com/~jlbec/files/configfs/2.6.12-rc1-bk3/configfs-2.6.12-rc1-bk3-1.patch Joel -- "Not everything that can be counted counts, and not everything that counts can be counted." - Albert Einstein Joel Becker Senior Member of Technical Staff Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/