Date: Sun, 08 Mar 1998 02:54:05 +0300 From: Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru> To: Terry Lambert <tlambert@primenet.com> Cc: current@FreeBSD.ORG Subject: Re: vnode_pager: *** WARNING *** stale FS code in system Message-ID: <199803072354.CAA02807@tejblum.dnttm.rssi.ru> In-Reply-To: Your message of "Sat, 07 Mar 1998 01:54:55 GMT." <199803070154.SAA27728@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > The reason I went the way I did was that putting the vnode_pager.c > code in the defaultops vector does nothing toward making the code > in vnode_pager.c _go away_, which is the eventual goal. Your changes do same nothing toward this goal. Everyone can insert a function into a vnops table. It is trivial. Almost nobody can write a real getpages or putpages routine. For example, you failed even to write a readonly cd9660_putpages, while it would be, apparently, trivial. (I suspect, simple 'return (VM_PAGER_BAD);' would do a right thing.) You also failed to mention this problem in your standard comment. So, when real implementation for getpages and putpages for all these filesystem will written? Filesystem-specific getpages/putpages possible since end of 1995. You saved a filesystem writer from writing 7 obvious lines of each implementations (even these lines contain style bugs, so actual number is slightly less). Is this the big win? > FS's which > can act as backing store need to have FS specific backing store > management, A problem is that every leaf filesystem with 'regular' files may be asked to act as backing store. For example, try cmp /proc/1/map /proc/curproc/map After you 'fix' getpages on procfs with your usual method, you will notice that procfs does not implement VOP_STRATEGY. (and that pfs_type is not a string, like procfs_print thinks). But why something ever try to call STRATEGY on procfs? Because procfs implement BMAP in some 'specific' way. This serves as a little example of usefulness of some filesystem-specific code. > for a large variety of reasons (I can enumerate these > reasons again, if you need me to). Well, actually I don't know any reasons for it, other than reference to John Dyson's authority and complexity of the generic code. So it would be interesting. But it is outside of scope of this discussion. > A secondary reason is that it means I have to make special code in > stacking FS's in order to be able to access the bypass (which I think > should be placed in the defaultops vector instead). I am not sure if I can parse this. Anyway, I claim that my way has exactly same results as your in this aspect. From point of view of a stacking layer, the filesystem below provide a getpages/putpages implementation, and this is all that you want. Also you want that you will get a warning if your stacking layer does not bypass or implement the getpages/putpages correctly. Then make vop_nogetpages and vop_noputpages, which will print the warning and the bad vnode and return VM_PAGER_BAD (which is at least a correct getpages/putpages return value, unlike EOPNOTSUPP), and put vop_stdgetpages and vop_stdputpages to vnops table of affected local medial file systems. > [...] > > A tertiary reason is that if the code is in the defaultops vector, > I can't know when it becomes safe to remove from vnode_pager.c > and the defaultops vector. There's no way to measure usage of > the defaultops code (that's kind of the point, really). OK, don't put it to defaultops vector, put vop_stdgetpages and vop_stdputpages to vnops table of every affected filesystem. I suggest it in every mail on this topic :-). One may say that my complains are more about decorative issues that about real programming issues. Sorry. It is because all discussing changes actually more decorative than real code. And as decorative, they are IMHO bad. Also, unfortunately, most points in this discussion were repeated several times... Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803072354.CAA02807>