Date: Wed, 08 Aug 2001 23:19:39 -0400 From: "Brian F. Feldman" <green@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: Brian Feldman <green@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf kmod.mk Message-ID: <200108090319.f793JgS63297@green.bikeshed.org> In-Reply-To: Message from Bruce Evans <bde@zeta.org.au> of "Thu, 09 Aug 2001 00:42:25 %2B1000." <20010809001222.Y8028-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans <bde@zeta.org.au> wrote:
> On Wed, 8 Aug 2001, Brian Feldman wrote:
>
> > green 2001/08/08 06:51:10 PDT
> >
> > Modified files:
> > sys/conf kmod.mk
> > Log:
> > In the KLD "load" make target, don't load using the "absolute" path of
> > "./foo.ko". Use "/full/path/foo.ko" instead so that when the path is
> > reported as being an absolute path to the "shared library", at least
> > it's not really a relative path.
>
> But "./foo.ko" is a relative path. What doesn't understand this?
GDB, the only thing that really matters.
> kldload(2) adds mostly-undocumented prefixes and suffixes to the path,
> so it is hard to tell exactly which file is unloaded, unlike for
> properly designed syscalls like open(2). The actual search in
> kern_linker.c:linker_search_path() seems to be:
>
> o If the path contains a slash, don't try anything else.
> o Otherwise:
> for each prefix in the kern.module_path sysctl tunable string
> for each suffix in fixed set { ".ko", "" }
> try the path with this prefix and suffix
> endfor
> endfor
>
> kldload(8) documents this superfically to the point of being mostly wrong.
> It says that "kld filename" converts the non-file name "filename" to the
> file name "filename.ko" and loads that. In particular, it says that
> ".ko" in the arg is an error. But actually, ".ko" in the arg is correct
> if and only if the arg doesn't contain a slash.
>
> Bruce
I'm extremely unhappy with the state of kldload(8) and all this. It's so
amazingly inconsistent... I can kldload ./file.ko, but not kldload file.ko,
though those are both correct relative paths. kldload(8) should have
absolutely no trouble checking the cwd for existence of a path before giving
up. Why don't we just replace that search algorithm with one less broken?
I'll do the work...
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
green@FreeBSD.org `------------------------------'
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108090319.f793JgS63297>