Hi,
On Thu, 21 Nov 2002, Petr Vandrovec wrote:
> > Indeed, rmdir should probably also remove the control file.
>
> Actually I was thinking in opposite way: requiring user to create
> "control", instead of creating it automatically.
>
> And more I think about it, why there is one "control" for each
> directory? Is not one "control" for whole modfs sufficient?
> fs is then just mounted with existing control, and unmount
> gets rid of it.
I'd rather create a central control file (which might be really the
cleaner solution), than let the user create it.
> And after implementing releasing of .init as truncate() on
> module file, you can remove directories from modfs completely,
> even more simplifying it.
Directories are likely required, e.g. symbols have to be added and I'm
still thinking about how to represent the module arguments.
> > module_dir->module is an optimization to get quickly to the module file
> > created by sys_create_module().
>
> Ok, I'll try something else. If you'll create module through
> sys_create_module, and remove using echo/rm/rmdir, will not it leak
> dentry?
I noticed that too, but it's easy to fix and not the only leak, as you
probably noticed. :)
> > > It has unfortunate feature that sys_create_module();
> > > sys_delete_module() (without suceeding sys_init_module between
> > > them) will return -ENOENT, and you'll have to use rm/rmdir to get
> > > rid of module :-(
> >
> > As the system calls are only temporary, they don't have to be perfect, but
> > why should it return -ENOINT, AFAICS it should fail for other reason.
>
> Your current implementation will return -ENOENT because of moddir->module
> will be NULL: but it is not critical error, it just means that
> sys_create_module() was called, but sys_init_module() was not, and
> you should not fail cleanup for such case.
moddir->module is initialized in sys_create_module, so this shouldn't be a
problem.
> I think that you should not be too clever in insmod/rmmod. Just code
> them like userspace clients will do: open "control", write "exit module"
> and "unmap module" into it, and then unlink "module" and remove
> that directory...
Well, first I have to see if I have to emulate these system calls at all.
I still have to see how much work it will be to reimplement the magic
do-it-all module load syscall on top of modfs, it probably will be easier
to keep them separate.
> And do we need separate map/init and exit/unmap? I do not think that
> it should be supported to do map/init/exit/init/exit/unmap...
You first have to map the module into the kernel (or at least reserve the
space), so you know the address the module has to be relocated to.
> And because of you do not allow unlink() on mapped module,
> what about doing implicit exit/unmap on unlink, removing exit/unmap
> operations from control completely?
For now I'd rather keep a fine grained interface, it can still be
simplified later.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:37 EST