On Thursday 14 May 2009 08:34, Roland Arnold wrote: > On Thursday 14 May 2009 00:12 Denys Vlasenko wrote: > >> This is a patch to mount.c to allow the file-system caching 'fsc' flag > >> for NFS mounts. FS-Cache is new in the 2.6.30 kernel. Note that this > >> changes the behaviour of the mount sys-call to pass through a string > >> and not a struct anymore; it makes the code match what nfs-utils does > >> - at least for NFS3. > > > > AFAIKS this works only starting from 2.6.23. If you want to use that > > anyway (which is a good idea, this struct nfs_mount_data > > mustn't be invented in the first place), you need > > to read /proc/version and do it conditionally. > > > > Otherwise you'll make life of 2.4.x people miserable. > > Fair enough - knowing that helps - I don't want to break this for anyone. > > >> --- orig/util-linux/mount.c 2009-05-09 13:35:41.854799281 +0200 > >> +++ mod/util-linux/mount.c 2009-05-09 13:33:23.147299934 +0200 > >> @@ -991,8 +991,9 @@ static int nfsmount(struct mntent *mp, l > >> mclient = NULL; > >> > >> /* NB: hostname, mounthost, filteropts must be free()d prior to > >> return */ > >> - > >> - filteropts = xstrdup(filteropts); /* going to trash it later... */ > >> + > >> + free(mp->mnt_opts); > >> + mp->mnt_opts = xstrdup(filteropts); /* going to trash it later... */ > > > > Why? > > mp->mnt_opts holds the original options string from the user (so it's > close), except this includes things like 'noatime', 'rw', etc. that > must be filtered out in the options string we send through in the > mount() call. filteropts is exactly the string I want, but it gets > trashed by strtok later on, before I can use it. Based on the comment > at the top of this function '// NB: mp->xxx fields may be trashed on > exit', I figured that changing mp->mnt_opts was acceptable, rather > than introducing a new variable, but it is slightly obscure, and I can > see how you might not like it.
This whole mess with sometimes-malloced members of mp needs to be fixed. I will try to do it today. > At this stage, what would be best? I can make a new patch that > implements the /proc/version test you mentioned, but it will probably > only be over the weekend. That's a good plan. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
