Date: Tue, 10 Mar 1998 09:48:29 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dima@tejblum.dnttm.rssi.ru (Dmitrij Tejblum) Cc: tlambert@primenet.com, current@FreeBSD.ORG Subject: Re: vnode_pager: *** WARNING *** stale FS code in system Message-ID: <199803100948.CAA14218@usr09.primenet.com> In-Reply-To: <199803092359.CAA03508@tejblum.dnttm.rssi.ru> from "Dmitrij Tejblum" at Mar 10, 98 02:59:01 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Most assuredly, at some time *after* a skeleton versions of FS specific
> > getpages/putpages have been written. Organizationally, the patches I
> > gave *do* move toward that goal.
>
> Before these changes, simple grep for getpages_desc gave the list of
> real getpages implementations. The tool in src/tools/tools/vop_table
> also could be used to find such list. Now you succefully created
> illusion that all filesystems already have own specific getpages
> implementation. The "organizational" side of these changes, as I
> already stated, is trivial.
If it's trivial, why wasn't it already done?
You have to start somewhere. You touch the world in a tiny way,
and then you touch each of the FS's individually, and then you
remove the bogus code that is no longer depended upon.
Hopefully, some people will pitch in on doing the per FS code.
I could do the NFS and FFS code pretty trivially. I've held off
so far, both because John has been (thankfully!) touching NFS
code, and because I don't want to compound a possible political
problem by adding more wood to the fire.
I've spent more time defending the incremental implementation
than it would take to do something about it (I could do a hell of
a lot all at once if a megacommit was feasible, which it isn't
because of the complexity of the code review that would be needed;
I'd have to pay Kirk or someone else that was trusted by core, and
sufficiently knowledgable about everything that got touched, to vet
the code for me).
> > If you insist, I can duplicate the generic code into the FS's themselves
> > immediately, and remove it from the generic location. I don't see this
> > action as being useful.
>
> Me too. Please don't duplicate it.
The NFS/non-NFS split is pretty easy. The other splits, less so.
> Desired organization was obvious. You made the organization more
> complex without a real advantage.
Without immediate advantage. The difference from previous treks
down this same track is that at least the light at the end of
the tunnel can be seen without binoculars. I fully intend to
get to the end of the tunnel if I can avoid being sidetracked
into dicussing whether the correct way to build a railroad is
to manufacture the ties, the locamotive, or the rails first,
before anything gets shipped to where it's going to be used.
> > I would cetrainly welcome your assitance in unstubbing the local media
> > getpages/putpages, if you were willing to give it. This would resolve
> > your implementation issues, without stepping on my organizational issues.
>
> Thanks. It is hardly possible since I know almost nothing about VM.
Well, then *anybody's* assistance. Like I said, I can do it myself
if I can free up some cycles from places like this thread.
> I don't see what force stacking layers to access bypass explicitly.
> Look:
>
> int
> vop_defaultop(struct vop_generic_args *ap)
> {
> return (VOCALL(default_vnodeop_p, ap->a_desc->vdesc_offset, ap));
> }
>
> Does your stacking layer modify ap->a_desc->vdesc_offset?
Maybe. It depends on what it does.
> If yes, how and why?
It may add a new VOP.
Initially, adding VOP's can be made more dynamic by turning vfs_op_descs
into a linker set. This will at least handle the "new FS, new VOP" case.
Then you would want to sort it, and eliminate duplicates.
> >
> > Here's my preferred soloution, since it will pacify you as well: make
> > the warning non-fatal *for now*; ie:
> > [...]
>
> This looks even worse. And no, it will not pacify me :) To pacify me,
> either remove msdosfs_getpages and msdosfs_putpages, or make them real
> msdosfs-specific implementation. These two dumb functions without any
> purpose irritates me. Actually, all functions without a purpose irritates
> me. (Well, actually I am already almost pacified :)
I'll see what I can do about them. 8-).
> > I don't know how many times I should have to repeat this, but the code
> > *should not be in vnode_pager.c* and was, in fact *designed to not be
> > in vnode_pager.c*.
>
> And here is my usual answer: you did *nothing* to remove the code.
My usual answer: "yet".
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
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?199803100948.CAA14218>