Date: Tue, 01 Jan 2002 13:49:42 -0800 From: Mike Smith <msmith@freebsd.org> To: Mike Barcroft <mike@FreeBSD.ORG> Cc: Bruce Evans <bde@zeta.org.au>, Peter Pentchev <roam@ringlet.net>, Mike Smith <msmith@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: kldload(2) family (was Re: loadable aio) Message-ID: <200201012149.g01Lnhr01849@mass.dis.org> In-Reply-To: Your message of "Tue, 01 Jan 2002 16:24:47 EST." <20020101162447.A64468@espresso.q9media.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> Right. I think the searching problem inside the kernel could be
> conquered by requiring that the destination of the kernel modules be
> known at compile-time.
This is absurd. It's (only) known at runtime. The kernel directory can
be (and is) moved aribitrarily. It has to be done inside the kernel to
allow demand-loading by the kernel.
> I was concerned that some people might want compatibility with the
> current behavior, but that doesn't seem to be the case (from this and
> other private e-mails). The interface becomes much simpler without
> kldload(3).
>
> o kldload(2) accepts a file path (similar to open(2))
> o kldunload(2) accepts a filename (no path, eg: "procfs.ko")
> o kldload(8) uses kldload(2)
> o kldunload(8) uses kldunload(2) (this could do extra string
> manipulation for compatibility with `kldunload procfs').
> o Module dependencies are handled by explicitly hardcoding the path to
> the module directory at compile-time.
This demonstrates a basic misunderstanding of how the module system
works; you have not grasped the distinction between "module" and "file"
at all.
The interface, from a userland perspective, is driven by three basic
requirements:
1) Load a named module.
2) Load a named file.
3) Unload a named module.
1) needs to search a database (in this case, built by kldxref) of known
modules to locate the file containing the module. It has a fallback
behaviour of assuming that the module 'foo' is found in the file 'foo.ko'
somewhere on the module searchpath.
2) takes a filename argument. As a convenience to the programmer, it
will append the '.ko' suffix, and search the system default path for the
file if an explicit pathname is not given.
3) is obvious, but misimplemented.
There are a lot of problems with the current implementation, but you are
not addressing them in this thread. Don't butcher what is actually quite
a clean and functional design just because you don't understand it; try
fixing some of the really major conceptual problems, not dumbing it down
to the level of the implementation.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201012149.g01Lnhr01849>