Date: Sun, 01 Mar 1998 13:30:46 -0800 From: Mike Smith <mike@smith.net.au> To: Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru> Cc: Terry Lambert <tlambert@primenet.com>, FreeBSD-current@FreeBSD.ORG Subject: Re: VM: Process hangs sleeping on vmpfw Message-ID: <199803012130.NAA09796@dingo.cdrom.com> In-Reply-To: Your message of "Sun, 01 Mar 1998 13:32:57 %2B0300." <199803011032.NAA02269@tejblum.dnttm.rssi.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Second, why don't put the operations to default_vnodeop_entries? It is > > > used exactly by local media filesystems. Stacking layers use bypass > > > routines instead (unionfs is an exception). So, filesystems even would > > > not notice this change, until they really want their own implementation > > > of getpages/putpages > > > > > > What is wrong in the above? > > > > Unionfs. Specifically, the point is that the unionfs implementation > > should fan out to the correct underlying implementation. This means > > it shouldn't go into the default. > > But you must write correct getpages/putpages for unionfs in any case. > Or, better, make a bypass routine for unionfs, to avoid similar > problems with future new vnode operations :-). Unless I'm mistaken here the contention is between Terry's point of view where all filesystems should be stackable, and Dima's where filesystems may optionally make themselves stackable. If I'm right, do we have a decision one way or the other? And if so, a *comprehensive* set of patches that cover the conversion> I'm happy to fight the style-nit and getting-it-done wars, but I gotta have the ammunition first. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199803012130.NAA09796>