Messages in this thread | | | From | "Khimenko Victor" <> | Date | Fri, 25 Jun 1999 17:05:31 +0400 (MSD) | Subject | Re: (reiserfs) Re: File systems are semantically impoverished compared to database and keyword systems: it is time to change! |
| |
In <14195.30309.956035.447590@reiser.ceic.com> Hans Reiser (reiser@ceic.com) wrote:
> Again, you said it better than me.
Not exactly. In fact we need BOTH. Otherwise will be VERY hard to convinience KDE/GNOME/whatever developers to use such features.
> Albert D. Cahalan writes: >> Acy James Stapp writes: >> >> > "Reparse points" or filters could be even more easily (and perhaps >> > more fruitfully) implemented as part of the standard library. >> >> It is amazing how the sub-file issues resemble sub-process issues. >> Threads could be more easily implemented as part of libc, but >> performance and correctness would suffer. >> And STILL big part of threads support is in libc, not in kernel. And even more: there are quite a few user-level threads packages. So when you use thread-based program (MySQL, for example) you can use user-level version when system does not have kernel-supported threads package.
>> > This introduces another directory access on every open (to >> > see if a directory has an .albod entry and hence should be treated >> > as a file) even for non-albod aware apps. This might be a noticeable >> > performance hit for certain apps. >> >> No kidding. You won't use this. I won't use this. Nobody will use this. >> I think you are proposing "solutions" to brush away the problem. >> I'm really can not see why it's so problematic. You can use file suffix or prefix ( "\albod" or "*albod" ) to mark albod's... Yes, this is ugly but it will work.
>> > Other advantages of a user-space implementation are fewer >> > security concerns and portability to other OSs. >> >> Fewer security concerns? When a setuid app runs a user-space filter... >> (and it must, since the system won't work otherwise) >> Secuority is not a big problem here -- you can make a secuirty holes in user-space solution as well as in kernel solution. Portability is a BIG win. Without portability it will be VERY hard to convinience application developers to use such additions. And kernel version is inherently non-portable.
>> > However, the above directory structure wouldn't allow a file to >> > impersonate a directory. >> >> There goes the correctness.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |