[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: silent semantic changes with reiser4

On Thu, 26 Aug 2004, Jan Harkes wrote:
> (btw. the same could be implemented completely in userspace, for
> instance in glibc. Whenever an open call gets an EISDIR error, simply
> retry the open, but this time with /_contents appended).

Yes, and no - just to make it obvious before people jump on this, a lot of
things can be prototyped in user space with things like this, but once you
have to deal with races and mixed tool environments, user space suddenly
doesn't work so well any more.

I think Jan understands this distinction, I just wanted to make sure
everybody else is aware of the _one_ thing that kernel land does well:

- safely synchronize globally visible data structures

That's quite fundamental. 99% of what a kernel does is exactly that. TCP
would be in user space too, if it wasn't for _exactly_ this issue. A lot
of people think that kernels are about hardware access, and yes, that's
the other 99% of the picture (I see the _big_ picture, remember?), but the
"safe access to common data" is really very fundamental.

The kernel is literally the thing that makes sure that you don't have -
and _cannot_ have - user programs that confuse each other by modifying
data unsynchronized.

For example, a filesystem is really nothing but a way to access a disk in
a controlled manner - it's not so much about hardware access, as it is
about maintaining a coherent view of how some shared data (disk or
whatever) is maintained.

Same goes for caches. We could cache things in user space, but if you want
to _share_ your caches (so that you don't have to re-load them for every
new application), you need some entity that manages those shared data
structures in a secure manner. In other words, you need the kernel.

The same goes for something like a "container file". Whether you see it as
"dir-as-file" or "file-as-dir" (and I agree with Jan that the two are
totally equivalent), the point of having the capability in the kernel is
not that the operations cannot be done in user space - the point is that
they cannot be done in user space _safely_. The kernel is kind of the
thing that guarantees that everybody follows the rules.

Imagine the security problems if a set-uid program were to (unwittingly)
depend on a user-space library that implements what Jan's prototype
library would do? Races galore, since a user-space implementation wouldn't
have _any_ way to do tests like the above atomically.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.526 / U:6.068 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site