> 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/