2002-11-01 00:48:03

by Andries E. Brouwer

[permalink] [raw]
Subject: mount

(i) I just tried 2.5.45 - CLONE_NEWNS is indeed wrong,
and the indicated patch fixes this. Will submit it to
Linus one of these centuries unless you object -
assuming that I can convince myself of the correctness.

(ii) The reason I write is that it will soon be time
for util-linux 2.12. Mount still lacked syntax for
MS_REC, and a moment ago I made it --rbind
(for MS_REC|MS_BIND).
Please complain if MS_REC should remain undocumented
and inaccessible.

Andries


2002-11-01 01:04:23

by Alexander Viro

[permalink] [raw]
Subject: Re: mount



On Fri, 1 Nov 2002 [email protected] wrote:

> (i) I just tried 2.5.45 - CLONE_NEWNS is indeed wrong,
> and the indicated patch fixes this. Will submit it to
> Linus one of these centuries unless you object -
> assuming that I can convince myself of the correctness.

Proposed fix is, indeed, correct. I'll feed it to Linus.

> (ii) The reason I write is that it will soon be time
> for util-linux 2.12. Mount still lacked syntax for
> MS_REC, and a moment ago I made it --rbind
> (for MS_REC|MS_BIND).
> Please complain if MS_REC should remain undocumented
> and inaccessible.

No problem with me. While we are at it, mount(8) detection of loop
is, er, odd:
return (loopmajor && stat(device, &statbuf) == 0 &&
S_ISBLK(statbuf.st_mode) &&
(statbuf.st_rdev>>8) == loopmajor);
^^^
Tsk, tsk... Seriously, switching to major(statbuf.st_rdev) would probably
be a good idea.

2002-11-01 20:52:20

by Andries E. Brouwer

[permalink] [raw]
Subject: Re: mount

> I'll feed it

OK

> statbuf.st_rdev>>8
> ^^^

> switching to major(statbuf.st_rdev) would probably be a good idea

Now that you suggested this, done.
But a good idea?

Since 1995 I have off and on run a system with 32-bit or 64-bit dev_t.
But <sys/sysmacros.h> has
# define major(dev) ((int)(((dev) >> 8) & 0xff))
# define minor(dev) ((int)((dev) & 0xff))
and I really mean
statbuf.st_rdev>>8
not
(statbuf.st_rdev>>8) & 0xff
so a private macro major() is needed, different from the glibc one.

Andries


[You must have seen my setup a few times: if all nonzero bits
are among the last 16, then read it as 8+8, otherwise, if
all nonzero bits are among the last 32, read it as 16+16,
otherwise read it as 32+32. That way old device numbers
do not change when dev_t grows. That way some ambiguity in
isofs mastering is resolved cleanly.]