Ragnar Kj�rstad wrote: > > On Wed, Oct 25, 2000 at 09:15:40AM -0700, Hans Reiser wrote: > > Users complained that "reiserfs" was too long, and said they just called > > it "reiser" in conversation > > anyway. I don't really care, I keep changing the name every discussion > > of it, I called it > > reiserfs_sandbox() at one talk..... I have considered calling it name() > > or assign() or namesys(), > > but I don't like those either. sms is an acronym, and I don't like > > acronyms though at least sms() > > is short..... > > Did you ever post your plans for reiserfs_sandbox() to this list? > > I'm sure a lot of people have comments. > > I have four: > 1. The namespace issue should be kept seperate from the > multiple-operations-in-one-syscall issue. In other words, any > namespace that works for open should work for sandbox() and visa > versa. Let me explain the attraction of putting the tweaks to the namespace only in one of the syscalls. Extreme compatibility. Any app which uses the new syscall can be presumed to know how not to break itself on the new functionality. We can completely avoid any namespace crowding issues, program things wholly the right way, and not have compatibility issues restraining us. After we are done doing things right, we can backport features to open() for which there is a consensus they will not break existing apps. Someday open can just fade away.... > > 2. This function is not really reiserfs specific, is it? > It really is just a way to specify multiple operations at once, to > avoid the overhead of multiple systemcalls, right? > It sounds to me that it should be implemented in VFS, not inside > reiserfs. True, once I convince at least one other FS to use it. > > 3. There was a discussion about making a transaction API available > to userspace, and Stephen (I think) commented that this could only > be done if the application submited all data at once, to avoid the > problem of applications keeping transactions open for ever. > This sounds like a perfect interface for userspace transactions! > > 4. Why not use ioctls? > Together with putting this in VFS, it would allow the whole sandbox > "thing" to be a loadable module. It would make development and > maintainability seperate from other parts of the kernel, and thereby > easier and cleaner. Actually, our thought was to implement it both as an ioctl and as a new syscall, and let those who dislike new syscalls strip it out and use just the ioctl(). ioctl is an ugly interface. Try to imagine you are explaining how Linux works to a Mac user, and you start telling him about the really useful Linux ioctl that allows you to effectively write to more than one file at a time and you just write it as.... Do you think he will make you blush if you try to do that.... > > Ragnar Kj�rstad > Big Storage > - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
