Date: Sat, 25 Oct 1997 00:45:44 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Terry Lambert <tlambert@primenet.com> Cc: michaelh@cet.co.jp, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG Subject: Re: zipfs filesystem anyone ? Message-ID: <19971025004544.21378@hydrogen.nike.efn.org> In-Reply-To: <199710250113.SAA10113@usr08.primenet.com>; from Terry Lambert on Sat, Oct 25, 1997 at 01:13:43AM %2B0000 References: <19971024114243.36902@hydrogen.nike.efn.org> <199710250113.SAA10113@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert scribbled this message on Oct 25: > > > If it's in there, then this is an important first step. The next step > > > would be to add a special placeholder descriptor that can be replaced > > > in vfs_op_desc for several slots. This would make it so you didn't > > > have to rebuild all of vnode_if.c and vnode_if.h to add new descriptors: > > > you can overwrite the placeholders instead. > > > > or should we simply use the dummy NULL entry (and add some) for the place > > holder? > > The list terminator is still necessary for the population pass, where > the vectors get populated. The VOP_REPLACEME needs to be seperate. I can see on the vnodeopv_desc of the vfs layer, but why does the NULL entry on the array of the vnodeop_desc array in vnode_if.c need the last NULL, that is what vfs_opv_numops is for... (which the population code uses)... so what I'm saying is we make two vars, maxvfs_opv_numops in which we allocate all the memory for that many ops... then as a new op is added we simply increase vfs_opv_numops to keep track of were we add the next op.. when it's equal to (or greater) then we simply disallow adding any new ops... the code to add this will be very minor... while your box is off line you can use http://www.freebsd.org/cgi/cvsweb.cgi to browse the source... > > personally, a possible define that declares I want a possible X extra > > vop vectors... and then have a couple variables that tell you the > > maximum number, and the current last offset... this shouldn't be hard > > to do... > > They kind of need to be static, unless the vector list becomes a linker > set. This can't happen until the linker set can be agregated between I was talking about the size of the list being variable, but that ther be an options like: options "EXTRA_VNODEOPS=5" then we simply do: int maxvfs_opv_numops = (sizeof(vfs_op_descs)/sizeof(struct vnodeop_desc *)) + EXTRA_VNODEOPS; and then the define is like: struct vnodeop_desc *vfs_op_descs[num] = { }; and we simply modify the awk script to properly generate num... which isn't hard... > linker uses. Basically, if you want to be able to pull it back out > later, you have to be able to distinguish it. My plan was to use a > seperate ELF section for each modules contribution to global linker > sets. This lets you use an ELF image archiver to "permanently" add > modules into the kernel (no difference between kld modules and normal > kernel components, except the image file that backs them). ok.. good to hear... > > I guess I should of announced my vfsinit > > patches to hackers instead... basicly, to get ride of LKM's and prepare > > for kld modules, I needed to change the vfs system to initalize on a > > permodule basis instead of a initalize all staticly compiled module > > idea... > > Be very careful here. I did this code under Windows 95. It turns out > that you need to sort the *total* descriptor list, or you will end up > with order of reference problems. I loaded the UFS, then I loaded the > FFS, and initialized them in that order. This includes the NULL ops > that you normally leave of tf the end, and llow to be set in the > population pass (referred to above). arg, I see what you mean.. ffs depends upon some of ufs's functions.. (arg, I was assuming that each module was independant)... right now the only way I can think of preventhing this from being a problem is to add the MOUNT_xxx to the declaration of the vnodeops, and then including in the ffs a dependancy of ufs... > Sorting the list also allows you to reference by index instead of by > descriptor. If you think about it, you won't have a descriptor for > a new VOP, if you dynamically load it, in vnode_if.h. This loses the > little glue function. To fix this, you have to kill the glue functions. > And you can do it if you can indext into the op vector and get the right > function. umm... isn't this already what is done? from vfs_opv_init: opv_desc_vector[opve_descp->opve_op->vdesc_offset] = opve_descp->opve_impl; the above line will set the appropriate vector by the vdesc_offset.. comment from vdesc_offset: /* offset in vector--first for speed */ then at the end, there is a second pass to fill in the remaining entries with the entry from VOFFSET(vop_default) of it's own vector.. hmm... looks like we need to remove this comment: /* * Finally, go back and replace unfilled routines * with their default. (Sigh, an O(n^3) algorithm. I * could make it better, but that'd be work, and n is small.) */ as right now the final routine runs in n as far as I can tell... :) ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971025004544.21378>