On Fri 25-01-08 16:50:15, Miklos Szeredi wrote: > > > > | + /* 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? No, it would not. > 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... Hmm, given that options are modified by remount for some filesystems, it's probably the best to display the effective state. So your code should display the right thing as it is. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
