Oy. An argument where bth sides are making some sense.. :-)

On Mon, 13 Mar 2000, Jaromir Dolecek wrote:

> Martin Husemann wrote:
> > In my view the question is: is there any chance, this VFS op routine is 
> > going to be called outside the LKM unload context. If the answer is true,
> > then of course the right thing to do is create that VFS op routine.
> > 
> > If we can't come up with an example for this, then I would opt for the LKM
> > unload cleanup function - but thats just a matter of taste.

I tend to agree that this kind of cleanup is what that lkm routine is for.
:-)

> The routine would be needed whenever vfs_detach() is needed. vfs_detach()
> is currently only called from kern_lkm.c:_lkm_vfs(), though.

That would be another way to do it too.

> There is little difference in implementing the cleanup as "independant"
> function callable from outside or a VFS op routine.
> 
> But as it's not a LKM cleanup function per se, I'd prefer adding it as
> a VFS op. This would make it possible to do the global fs cleanup
> in vfs_detach() where it logically belongs, and avoid silly
> pastos in respective syssrc/sys/lkm/vfs/*/lkminit_vfs.c.

Sounds good.

> Since we broke VFS LKM ABI at least once between 1.4 and upcoming
> 1.5, I don't think breaking it once more would cause (m)any

True..

> additional problems. Furthermore, this particular change would
> only bite people who attempt to _unload_ "older" VFS LKM (reboots
> are fine).

No, it (running an old LKM) would bite them squarely all the time. :-)
You're talking about (or SHOULD be talking about :-) adding a VFS routine.
These routines are exported by explicit jump vectors in the vfsops
structure. By adding one, you move everything after it, which includes the
handle to the VOP descripter table. :-)

But the interface changed enough that you have to recompile anyway.. :-)

Go for it.

Take care,

Bill