On Wednesday 14 February 2007 19:13, Andreas Gruenbacher wrote:
> So here is how this could be implemented. See the lengthy explanations in
> the patch headers, too.
Turns out I messed up with one of Neil's review comments. Here is yet another
update.
With this fix, everything works as expected
On Thursday 15 February 2007 04:53, Jan Engelhardt wrote:
> What's the point in changing pipefs... you can *never*
> reach it *anyway*, even if it was a /-style path, since
> pipefs is a NOMNT filesystem.
The point is that we could then get rid of the special case for MS_NOUSER
filesystems like p
Hi,
On Feb 14 2007 14:57, Andreas Gruenbacher wrote:
>[2]
>
>pipe: "pipe:[439336]" (or "pipe/[439336]")
>
>[3] Always make disconnected paths double-slashed:
>--
>pipe: "//pipe/[439336]"
>
On Wednesday 14 February 2007 14:57, Andreas Gruenbacher wrote:
> [1] Always make disconnected paths relative:
>
> From all these choices, I actually like [1] best, together with hiding
> unreachable mount points in /proc/$pid/mounts and /proc/$pid/mountstats:
> there is no real point in pretending
On Sunday 04 February 2007 16:15, Neil Brown wrote:
> The behaviour in the face of a lazy unmount should be clarified in
> this comment.
Done.
> If sys_getcwd is called on a directory that is no longer
> connected to the root, it isn't clear to me that it should return
> without an error.
> Witho
On Wednesday 14 February 2007 11:39, Andreas Gruenbacher wrote:
> On Wednesday 14 February 2007 07:37, Linus Torvalds wrote:
> > We could prepend another '/' (so that you'd have a path that starts with
> > "//"). That's still a legal path, but it's also somethign that even POSIX
> > says is valid t
On Wednesday 14 February 2007 07:37, Linus Torvalds wrote:
> We could prepend another '/' (so that you'd have a path that starts with
> "//"). That's still a legal path, but it's also somethign that even POSIX
> says is valid to mean something else (eg "//ftp/.." or "//socket/.." to
> escape into a
On Wed, 14 Feb 2007, Andreas Gruenbacher wrote:
>
> Mountpoints are reported relative to the chroot if they are reachable from
> the
> chroot, and relative to the namespace they are defined in otherwise. This is
> big nonsense, but it's unclear to me how to best fix it:
Well, it's also what
On Wednesday 14 February 2007 00:29, Olaf Hering wrote:
> On Wed, Feb 14, Andreas Gruenbacher wrote:
> > What's the point in reporting the rootfs at all -- it's never reachable
> > to an ordinary process?
>
> /init and its childs has it as root, until it passes control over to
> /sbin/init
Yes, th
On Wed, Feb 14, Andreas Gruenbacher wrote:
> What's the point in reporting the rootfs at all -- it's never reachable to an
> ordinary process?
/init and its childs has it as root, until it passes control over to
/sbin/init
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Monday 05 February 2007 00:32, Andreas Gruenbacher wrote:
> Here is an updated patch that also catches this special case.
> [...]
The d_path change was to not start unreachable paths with slashes. In the
extreme case, this leads to an empty string. As it turns out, we are
reporting meaningles
On Friday 02 February 2007 19:23, Andreas Gruenbacher wrote:
> Hello,
>
> here is a bugfix to d_path. Please apply (after 2.6.20).
>
> First, when d_path() hits a lazily unmounted mount point, it tries to
> prepend the name of the lazily unmounted dentry to the path name. It
> gets this wrong, and
On Friday February 2, [EMAIL PROTECTED] wrote:
> Hello,
>
> here is a bugfix to d_path. Please apply (after 2.6.20).
Looks good! Just a couple of little comments (to prove that I have
really read it and thought about it :-)
>
> Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Reviewed-b
13 matches
Mail list logo
