Re: [patch 25/26] mount options: fix udf

[Cyrill Gorcunov]

[Miklos Szeredi - Fri, Jan 25, 2008 at 04:50:15PM +0100]
| > > > | +	/* is this correct? */
| > > > | +	if (sbi->s_anchor[2] != 0)
| > > > | +		seq_printf(seq, ",anchor=%u", sbi->s_anchor[2]);
| > > > 
| > > > you know, I would prefer to use form UDF_SB_ANCHOR(sb)[2]
| > > > in sake of style unification but we should wait for Jan's
| > > > decision (i'm not the expert in this area ;)
| > > 
| > > I think UDF_SB_ANCHOR macro was removed by some patch in -mm.
| >   Yes, it's going to be removed so don't use it. Actually, basing this
| > patch on top of -mm is a good idea because there are quite some changes
| > in Andrew's queue.
| > 
| > > I'm more interested if the second element of the s_anchor array really
| > > does always have the value of the 'anchor=N' mount option.  I haven't
| > > been able to verify that fully.  Do you have some insight into that?
| >   As Cyrill wrote, it could be zeroed out in case there is no anchor in
| > the specified block. So I guess you have to store the passed value
| > somewhere else..
| 
| But in that case, would the value of the anchor= option matter?
| 
| This is actually a somewhat philosophical question about what the
| mount options in /proc/mounts mean:
| 
|  1) Options _given_ by the user for the mount
|  2) Options which are _effective_ for the mount
| 
| If we take interpretation 2) and there was no anchor (whatever that
| means), then the anchor=N option wasn't effective, and not giving it
| would have had the same effect.
| 
| This could be confusing to the user, though...
| 
| Thanks,
| Miklos
| 

I think _effective_ options is much more important - they could
show you that something bad happened (and if this zeroing of anchor
has been happened udf print debug message) Anyway, Miklos, I think
the options _given_ by a user does not mean anything in that case
because it just doesn't reveal what is being used in _real_.

		- Cyrill -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/