hi folks,
I've been discussing a filesystem extended attributes API with Andreas
Gruenbacher (maintainer of the ext2/ext3 extended attributes patch[1])
which is suitable for other Linux filesystems as well, in an effort to
remove the differences between our current implementations and to help
out the people building services layered above this (especially Samba).
In doing so we have reviewed the earlier discussion[2,3] on this topic,
and have attempted to produce a new interface which I believe satisfies
many of the issues and ideas put forward there, while at the same time
ensuring that the interface is simple, and remains true to the design
of extended attributes being name:value pairs.
A manual page describing the system call interface can be found here[4].
We're very interested in feedback on this. In partiular, Linus - would
you consider the patch below, which reserves system call numbers for
this interface? That would be a big help to our collaborative effort.
We have written most of the code for XFS, and Andreas is working away on
the ext2/ext3 version. Switching to a new syscall interface is going to
cause several compatibility issues for our existing users, of course, so
is not something we want to rush into before soliciting feedback and
(hopefully) getting some system call numbers reserved - otherwise we may
find ourselves needing to do a similar transition again later.
As a test case for the interface, we will now be able to use the same
POSIX ACL userspace[1,5] between XFS and ext2 without any on-disk format
changes in XFS - this was an important interface design goal for us XFS
folk, where our format is fixed in stone as it is also used by IRIX.
We have also begun discussions with some of the LSM developers, with the
goal of implementing POSIX capabilities and POSIX MAC (mandatory access
control) security extensions in Linux also, Here we again expect to be
able to provide a filesystem independent view of these attributes, while
still preserving the on-disk XFS format for these attributes using the
simple namespace abstraction mechanism this new interface provides.
I've included some pointers[6,7,8,9,10] to other projects, developers,
discussions, etc. which I've come across who are in some way or another
interested in an extended attributes implementation in the base kernel
- just as examples of how various people are using (or planning to use)
the current ext2/ext3 and XFS interfaces on Linux.
cheers.
--
Nathan
[1] Extended attributes for ext2/ext3 and POSIX ACLs
http://acl.bestbits.at/
[2] fs-devel extended attributes discussion
http://marc.theaimsgroup.com/?l=linux-fsdevel&m=97222475218787&w=2
[3] Andrew Gildfind's interface comparison whitepaper
http://acl.bestbits.at/pre/gildfind-acls.pdf
[4] New extattr(2) system call man pages
http://acl.bestbits.at/man/extattr.2.html
http://acl.bestbits.at/man/extattr.5.html
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/attr2/man/man2/extattr.2
[5] Common POSIX ACL implementation for Linux
http://acl.bestbits.at/pipermail/acl-devel/2001-February/000495.html
http://www.samba.org/samba/whatsnew/samba-2.2.0.html
[6] Andrew Morgan's Filesystem Capability patches
http://www.kernel.org/pub/linux/libs/security/linux-privs/README
[7] LSM - Linux Security Module project
http://www.linuxsecurity.com/articles/forums_article-2854.html
http://mail.wirex.com/pipermail/linux-security-module/2001-October/002310.html
[8] DMAPI/XDSM specification - implemented in XFS via extended attributes
http://www.opengroup.org/onlinepubs/9657099/
http://oss.sgi.com/projects/xfs/dmapi.html
[9] SnapFS snapshot filesystem
http://lwn.net/2001/0308/a/snapfs.php3
[10] Will Dyson's resurrection of BeFS for Linux 2.4
http://cs.earlham.edu/~will/software/linux/kernel/BeFS.html
http://marc.theaimsgroup.com/?l=linux-fsdevel&m=100431033704112&w=2
diff -Naur 2.4.14-pristine/arch/i386/kernel/entry.S 2.4.14-reserved/arch/i386/kernel/entry.S
--- 2.4.14-pristine/arch/i386/kernel/entry.S Sat Nov 3 12:18:49 2001
+++ 2.4.14-reserved/arch/i386/kernel/entry.S Wed Nov 7 10:02:59 2001
@@ -622,6 +622,9 @@
.long SYMBOL_NAME(sys_ni_syscall) /* Reserved for Security */
.long SYMBOL_NAME(sys_gettid)
.long SYMBOL_NAME(sys_readahead) /* 225 */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for extattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for lextattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for fextattr */
.rept NR_syscalls-(.-sys_call_table)/4
.long SYMBOL_NAME(sys_ni_syscall)
diff -Naur 2.4.14-pristine/include/asm-i386/unistd.h 2.4.14-reserved/include/asm-i386/unistd.h
--- 2.4.14-pristine/include/asm-i386/unistd.h Thu Oct 18 03:03:03 2001
+++ 2.4.14-reserved/include/asm-i386/unistd.h Wed Nov 7 10:02:59 2001
@@ -230,6 +230,9 @@
#define __NR_security 223 /* syscall for security modules */
#define __NR_gettid 224
#define __NR_readahead 225
+#define __NR_extattr 226 /* syscall for extended attributes */
+#define __NR_lextattr 227 /* syscall for extended attributes */
+#define __NR_fextattr 228 /* syscall for extended attributes */
/* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
hello again Andi,
On Wed, Nov 07, 2001 at 02:32:18AM +0100, Andi Kleen wrote:
> I think it would be better to have a statefull readdir instead.
> The kernel supports it via the ->private_data field of struct file
> (not through fork,but that looks like a generic vfs bug)
>
> EA_FIRST_ENTRY to reset the fd the first entry, EA_READ_ENTRY to
> read the next one.
I'm not sure this would work for the extattr/lextattr variants where
we don't have an fd to hold the state. Should the list operation
be restricted to the fextattr variant, perhaps? I'm not sure about
all the implications of that, will have to see what everyone else
thinks I guess.
eg. the opening of the file before allowing a list operation could
have implications for XFSs DMAPI support (open might recall data from
tape), where the management tools need to be able to list these DMAPI
related attributes without affecting the backing storage, I believe -
I'll have to ask some DMAPI gurus about that one though.
Thanks for the input.
cheers.
--
Nathan
Hi,
On Wed, Nov 07, 2001 at 02:19:56PM +1100, Nathan Scott wrote:
> On Wed, Nov 07, 2001 at 02:32:18AM +0100, Andi Kleen wrote:
> > EA_FIRST_ENTRY to reset the fd the first entry, EA_READ_ENTRY to
> > read the next one.
>
> I'm not sure this would work for the extattr/lextattr variants where
> we don't have an fd to hold the state.
> eg. the opening of the file before allowing a list operation could
> have implications for XFSs DMAPI support (open might recall data from
> tape),
There are other much more immediate obstacles: opening /dev/* is not
possible if the devices beneath the inodes don't exist.
O_OPENONLY (implying neither read nor write access) to get a stub file
handle for such inodes is possible, if a bit hackish. There's a
problem in the kernel there --- kernel file descriptor operations on
"special" inodes such as named sockets/pipes or device nodes don't
pass file operations on to the underlying filesystem.
As long as you're doing the ACL stuff via inode operations internally,
that's not a problem. However, inode operations generally don't take
a file descriptor as an argument so you don't have access to the
cursor in that case.
The DMAPI and special inode problems go away if you don't demand a
file descriptor to the file. (Having a file descriptor that
specifically belongs to the ACL stream is a different matter
entirely.)
--Stephen
On Wed, Nov 07, 2001 at 02:19:56PM +1100, Nathan Scott wrote:
> I'm not sure this would work for the extattr/lextattr variants where
> we don't have an fd to hold the state. Should the list operation
Right. I forgot that.
Then I guess it is better to use EA_LIST_SIZE / EA_GET_LIST (EAGAIN on race)
Whole point is to just avoid to have an stateless cursor.
-Andi
In http://acl.bestbits.at/man/extattr.5.html there is a statement:
Device special files cannot be associated with extended user attributes
What is the reason for this limitation? Why should there be a difference
between regular files/directories and special files (device files)?
I am also thinking in terms of HSM application (or DMAPI if you want). Where
do you want HSM attributes to be placed? I thought it should be in trusted,
because we might need access to them from user space. Other option is system
(that would require accessing them from kernel code) or user (might be
problematic, since regular user with write permission might remove them...
Actually, where are XFS guys storing DMAPI attributes today?
Regards,
Luka
> -----Original Message-----
> From: Nathan Scott [mailto:[email protected]]
> Sent: Wednesday, November 07, 2001 01:12
> To: Linus Torvalds; Andreas Gruenbacher
> Cc: [email protected];
> [email protected]; [email protected];
> [email protected]
> Subject: [RFC][PATCH] extended attributes
>
>
> hi folks,
>
> I've been discussing a filesystem extended attributes API
> with Andreas Gruenbacher (maintainer of the ext2/ext3
> extended attributes patch[1]) which is suitable for other
> Linux filesystems as well, in an effort to remove the
> differences between our current implementations and to help
> out the people building services layered above this
> (especially Samba). In doing so we have reviewed the earlier
> discussion[2,3] on this topic, and have attempted to produce
> a new interface which I believe satisfies many of the issues
> and ideas put forward there, while at the same time ensuring
> that the interface is simple, and remains true to the design
> of extended attributes being name:value pairs.
>
> A manual page describing the system call interface can be
> found here[4]. We're very interested in feedback on this. In
> partiular, Linus - would you consider the patch below, which
> reserves system call numbers for this interface? That would
> be a big help to our collaborative effort.
>
> We have written most of the code for XFS, and Andreas is
> working away on the ext2/ext3 version. Switching to a new
> syscall interface is going to cause several compatibility
> issues for our existing users, of course, so is not something
> we want to rush into before soliciting feedback and
> (hopefully) getting some system call numbers reserved -
> otherwise we may find ourselves needing to do a similar
> transition again later.
>
> As a test case for the interface, we will now be able to use
> the same POSIX ACL userspace[1,5] between XFS and ext2
> without any on-disk format changes in XFS - this was an
> important interface design goal for us XFS folk, where our
> format is fixed in stone as it is also used by IRIX.
>
> We have also begun discussions with some of the LSM
> developers, with the goal of implementing POSIX capabilities
> and POSIX MAC (mandatory access
> control) security extensions in Linux also, Here we again
> expect to be able to provide a filesystem independent view of
> these attributes, while still preserving the on-disk XFS
> format for these attributes using the simple namespace
> abstraction mechanism this new interface provides.
>
> I've included some pointers[6,7,8,9,10] to other projects,
> developers, discussions, etc. which I've come across who are
> in some way or another interested in an extended attributes
> implementation in the base kernel
> - just as examples of how various people are using (or
> planning to use) the current ext2/ext3 and XFS interfaces on Linux.
>
> cheers.
>
> --
> Nathan
>
>
> [1] Extended attributes for ext2/ext3 and POSIX ACLs
> http://acl.bestbits.at/
> [2] fs-devel extended attributes discussion
> http://marc.theaimsgroup.com/?l=linux-fsdevel&m=97222475218787&w=2
> [3] Andrew Gildfind's interface comparison whitepaper
> http://acl.bestbits.at/pre/gildfind-acls.pdf
> [4] New extattr(2) system call man pages
> http://acl.bestbits.at/man/extattr.2.html
> http://acl.bestbits.at/man/extattr.5.html
>
> http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/attr2/
man/man2/extattr.2
> [5] Common POSIX ACL implementation for Linux
>
> http://acl.bestbits.at/pipermail/acl-devel/2001-February/000495.html
> http://www.samba.org/samba/whatsnew/samba-2.2.0.html
> [6] Andrew Morgan's Filesystem Capability patches
> http://www.kernel.org/pub/linux/libs/security/linux-privs/README
> [7] LSM - Linux Security Module project
> http://www.linuxsecurity.com/articles/forums_article-2854.html
>
> http://mail.wirex.com/pipermail/linux-security-module/2001-Oct
ober/002310.html
[8] DMAPI/XDSM specification - implemented in XFS via extended attributes
http://www.opengroup.org/onlinepubs/9657099/
http://oss.sgi.com/projects/xfs/dmapi.html
[9] SnapFS snapshot filesystem
http://lwn.net/2001/0308/a/snapfs.php3
[10] Will Dyson's resurrection of BeFS for Linux 2.4
http://cs.earlham.edu/~will/software/linux/kernel/BeFS.html
http://marc.theaimsgroup.com/?l=linux-fsdevel&m=100431033704112&w=2
diff -Naur 2.4.14-pristine/arch/i386/kernel/entry.S
2.4.14-reserved/arch/i386/kernel/entry.S
--- 2.4.14-pristine/arch/i386/kernel/entry.S Sat Nov 3 12:18:49 2001
+++ 2.4.14-reserved/arch/i386/kernel/entry.S Wed Nov 7 10:02:59 2001
@@ -622,6 +622,9 @@
.long SYMBOL_NAME(sys_ni_syscall) /* Reserved for Security */
.long SYMBOL_NAME(sys_gettid)
.long SYMBOL_NAME(sys_readahead) /* 225 */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for extattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for lextattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for fextattr */
.rept NR_syscalls-(.-sys_call_table)/4
.long SYMBOL_NAME(sys_ni_syscall)
diff -Naur 2.4.14-pristine/include/asm-i386/unistd.h
2.4.14-reserved/include/asm-i386/unistd.h
--- 2.4.14-pristine/include/asm-i386/unistd.h Thu Oct 18 03:03:03 2001
+++ 2.4.14-reserved/include/asm-i386/unistd.h Wed Nov 7 10:02:59 2001
@@ -230,6 +230,9 @@
#define __NR_security 223 /* syscall for security modules */
#define __NR_gettid 224
#define __NR_readahead 225
+#define __NR_extattr 226 /* syscall for extended attributes
*/
+#define __NR_lextattr 227 /* syscall for extended attributes
*/
+#define __NR_fextattr 228 /* syscall for extended attributes
*/
/* user-visible error numbers are in the range -1 - -124: see
<asm-i386/errno.h> */
On Thu, 8 Nov 2001, Luka Renko wrote:
> In http://acl.bestbits.at/man/extattr.5.html there is a statement:
>
> Device special files cannot be associated with extended user attributes
>
> What is the reason for this limitation? Why should there be a difference
> between regular files/directories and special files (device files)?
This limitation has been introduced since allowing extended user
attributes for special files leads to an awkward semantic mess: Extended
user attributes are in a sense treaded like file contents (concerning
permissions, for example). Now the "contents" of a special file are a
device, really. The device isn't even located on the filesystem the
special file is on. And the device doesn't have extended attributes.
It is possible to have devices on read-only file systems, which are
readable and writeable. It would not be possible to have extended
attributes in that case.
> I am also thinking in terms of HSM application (or DMAPI if you want). Where
> do you want HSM attributes to be placed? I thought it should be in trusted,
> because we might need access to them from user space. Other option is system
> (that would require accessing them from kernel code) or user (might be
> problematic, since regular user with write permission might remove them...
I am not sure about this. Just note that XFS and current ext2/ext3 don't
yet have the owner and trusted namespaces.
--Andreas.
>From: Luka Renko <[email protected]>
>I am also thinking in terms of HSM application (or DMAPI if you want). Where
>do you want HSM attributes to be placed? I thought it should be in trusted,
>because we might need access to them from user space. Other option is system
>(that would require accessing them from kernel code) or user (might be
>problematic, since regular user with write permission might remove them...
>Actually, where are XFS guys storing DMAPI attributes today?
On XFS the DMAPI event mask for that file is kept in a field in the
xfs_dinode_core_t structure--so it's in the inode. On Irix, HSM's store state
info in an extended attribute in the "root" namespace on each file, but they
do it via the appropriate DMAPI calls (which jump to XFS's extended attribute
code) rather than via the extended attribute library.
Dean
On Wed, Nov 07, 2001 at 02:32:18AM +0100, Andi Kleen wrote:
> On Wed, Nov 07, 2001 at 11:12:24AM +1100, Nathan Scott wrote:
> > A manual page describing the system call interface can be found here[4].
> > We're very interested in feedback on this. In particular, Linus - would
>
> The cursor support looks quite complicated. ...
> Stateless cursors are just nasty!
> ...
hi folks,
We've removed the cursor operations, and gone back to Andreas'
original, simpler list approach. Revised versions of the two
extattr man pages are in the XFS CVS repository, or use:
http://acl.bestbits.at/man/extattr.2.html
http://acl.bestbits.at/man/extattr.5.html
I notice that 2.4.15-pre3 doesn't have the patch below - Linus,
Alan, could you please apply it? - it will help us a great deal.
This would be useful to the ext2/ext3, InterMezzo/SnapFS, NTFS,
XFS, JFS and BeFS filesystem implementations for Linux, and to
any other filesystems planning to support extended attributes
in the future as well.
many thanks.
--
Nathan
diff -Naur 2.4.14-pristine/arch/i386/kernel/entry.S 2.4.14-reserved/arch/i386/kernel/entry.S
--- 2.4.14-pristine/arch/i386/kernel/entry.S Sat Nov 3 12:18:49 2001
+++ 2.4.14-reserved/arch/i386/kernel/entry.S Wed Nov 7 10:02:59 2001
@@ -622,6 +622,9 @@
.long SYMBOL_NAME(sys_ni_syscall) /* Reserved for Security */
.long SYMBOL_NAME(sys_gettid)
.long SYMBOL_NAME(sys_readahead) /* 225 */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for extattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for lextattr */
+ .long SYMBOL_NAME(sys_ni_syscall) /* reserved for fextattr */
.rept NR_syscalls-(.-sys_call_table)/4
.long SYMBOL_NAME(sys_ni_syscall)
diff -Naur 2.4.14-pristine/include/asm-i386/unistd.h 2.4.14-reserved/include/asm-i386/unistd.h
--- 2.4.14-pristine/include/asm-i386/unistd.h Thu Oct 18 03:03:03 2001
+++ 2.4.14-reserved/include/asm-i386/unistd.h Wed Nov 7 10:02:59 2001
@@ -230,6 +230,9 @@
#define __NR_security 223 /* syscall for security modules */
#define __NR_gettid 224
#define __NR_readahead 225
+#define __NR_extattr 226 /* syscall for extended attributes */
+#define __NR_lextattr 227 /* syscall for extended attributes */
+#define __NR_fextattr 228 /* syscall for extended attributes */
/* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
Quick follow up - I had to botch _one_ of the CC'd lists I guess...
"[email protected]" -> "[email protected]". *sigh*
cheers.
On Wed, Nov 07, 2001 at 11:12:24AM +1100, Nathan Scott wrote:
> hi folks,
>
> I've been discussing a filesystem extended attributes API with Andreas
> Gruenbacher (maintainer of the ext2/ext3 extended attributes patch[1])
> which is suitable for other Linux filesystems as well, in an effort to
> remove the differences between our current implementations and to help
> out the people building services layered above this (especially Samba).
> In doing so we have reviewed the earlier discussion[2,3] on this topic,
> and have attempted to produce a new interface which I believe satisfies
> many of the issues and ideas put forward there, while at the same time
> ensuring that the interface is simple, and remains true to the design
> of extended attributes being name:value pairs.
>
> A manual page describing the system call interface can be found here[4].
> We're very interested in feedback on this. In partiular, Linus - would
> you consider the patch below, which reserves system call numbers for
> this interface? That would be a big help to our collaborative effort.
>
> We have written most of the code for XFS, and Andreas is working away on
> the ext2/ext3 version. Switching to a new syscall interface is going to
> cause several compatibility issues for our existing users, of course, so
> is not something we want to rush into before soliciting feedback and
> (hopefully) getting some system call numbers reserved - otherwise we may
> find ourselves needing to do a similar transition again later.
>
> As a test case for the interface, we will now be able to use the same
> POSIX ACL userspace[1,5] between XFS and ext2 without any on-disk format
> changes in XFS - this was an important interface design goal for us XFS
> folk, where our format is fixed in stone as it is also used by IRIX.
>
> We have also begun discussions with some of the LSM developers, with the
> goal of implementing POSIX capabilities and POSIX MAC (mandatory access
> control) security extensions in Linux also, Here we again expect to be
> able to provide a filesystem independent view of these attributes, while
> still preserving the on-disk XFS format for these attributes using the
> simple namespace abstraction mechanism this new interface provides.
>
> I've included some pointers[6,7,8,9,10] to other projects, developers,
> discussions, etc. which I've come across who are in some way or another
> interested in an extended attributes implementation in the base kernel
> - just as examples of how various people are using (or planning to use)
> the current ext2/ext3 and XFS interfaces on Linux.
>
> cheers.
>
> --
> Nathan
>
>
> [1] Extended attributes for ext2/ext3 and POSIX ACLs
> http://acl.bestbits.at/
> [2] fs-devel extended attributes discussion
> http://marc.theaimsgroup.com/?l=linux-fsdevel&m=97222475218787&w=2
> [3] Andrew Gildfind's interface comparison whitepaper
> http://acl.bestbits.at/pre/gildfind-acls.pdf
> [4] New extattr(2) system call man pages
> http://acl.bestbits.at/man/extattr.2.html
> http://acl.bestbits.at/man/extattr.5.html
> http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/attr2/man/man2/extattr.2
> [5] Common POSIX ACL implementation for Linux
> http://acl.bestbits.at/pipermail/acl-devel/2001-February/000495.html
> http://www.samba.org/samba/whatsnew/samba-2.2.0.html
> [6] Andrew Morgan's Filesystem Capability patches
> http://www.kernel.org/pub/linux/libs/security/linux-privs/README
> [7] LSM - Linux Security Module project
> http://www.linuxsecurity.com/articles/forums_article-2854.html
> http://mail.wirex.com/pipermail/linux-security-module/2001-October/002310.html
> [8] DMAPI/XDSM specification - implemented in XFS via extended attributes
> http://www.opengroup.org/onlinepubs/9657099/
> http://oss.sgi.com/projects/xfs/dmapi.html
> [9] SnapFS snapshot filesystem
> http://lwn.net/2001/0308/a/snapfs.php3
> [10] Will Dyson's resurrection of BeFS for Linux 2.4
> http://cs.earlham.edu/~will/software/linux/kernel/BeFS.html
> http://marc.theaimsgroup.com/?l=linux-fsdevel&m=100431033704112&w=2
>
>
> diff -Naur 2.4.14-pristine/arch/i386/kernel/entry.S 2.4.14-reserved/arch/i386/kernel/entry.S
> --- 2.4.14-pristine/arch/i386/kernel/entry.S Sat Nov 3 12:18:49 2001
> +++ 2.4.14-reserved/arch/i386/kernel/entry.S Wed Nov 7 10:02:59 2001
> @@ -622,6 +622,9 @@
> .long SYMBOL_NAME(sys_ni_syscall) /* Reserved for Security */
> .long SYMBOL_NAME(sys_gettid)
> .long SYMBOL_NAME(sys_readahead) /* 225 */
> + .long SYMBOL_NAME(sys_ni_syscall) /* reserved for extattr */
> + .long SYMBOL_NAME(sys_ni_syscall) /* reserved for lextattr */
> + .long SYMBOL_NAME(sys_ni_syscall) /* reserved for fextattr */
>
> .rept NR_syscalls-(.-sys_call_table)/4
> .long SYMBOL_NAME(sys_ni_syscall)
> diff -Naur 2.4.14-pristine/include/asm-i386/unistd.h 2.4.14-reserved/include/asm-i386/unistd.h
> --- 2.4.14-pristine/include/asm-i386/unistd.h Thu Oct 18 03:03:03 2001
> +++ 2.4.14-reserved/include/asm-i386/unistd.h Wed Nov 7 10:02:59 2001
> @@ -230,6 +230,9 @@
> #define __NR_security 223 /* syscall for security modules */
> #define __NR_gettid 224
> #define __NR_readahead 225
> +#define __NR_extattr 226 /* syscall for extended attributes */
> +#define __NR_lextattr 227 /* syscall for extended attributes */
> +#define __NR_fextattr 228 /* syscall for extended attributes */
>
> /* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Nathan
On Wed, Nov 07, 2001 at 11:12:24AM +1100, Nathan Scott wrote:
> A manual page describing the system call interface can be found here[4].
> We're very interested in feedback on this. In partiular, Linus - would
The cursor support looks quite complicated. It doesn't even forbid
storing the contents of the cursor buffer somewhere and has all
the standard problems with stateless cursors requiring nasty hacks
with dynamic data structures with parallel modification.
Stateless cursors are just nasty!
I think it would be better to have a statefull readdir instead.
The kernel supports it via the ->private_data field of struct file
(not through fork,but that looks like a generic vfs bug)
EA_FIRST_ENTRY to reset the fd the first entry, EA_READ_ENTRY to
read the next one.
It would not be inherently thread safe, but also not be worse
in this regard than standard readdir (requiring user locks)
It would also be possible to do a threadsafe interface although it would be
a bit uglier: EA_GET_LISTSIZE to get the
size of the buffer required, EA_GET_FULL_LIST to fetch a full
buffer with the names of all EAs, EAGAIN on race.
I think doing it in one of these ways would be far easier for the
user and easier for future kernel implementations.
-Andi
On Wed, 7 Nov 2001, Andi Kleen wrote:
> I think it would be better to have a statefull readdir instead.
> The kernel supports it via the ->private_data field of struct file
> (not through fork,but that looks like a generic vfs bug)
??? fork() just copies references to struct file.