Date: Sun, 8 Oct 1995 17:32:43 +0300 (MSK) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) <ache@astral.msk.su> To: Bruce Evans <bde@zeta.org.au>, current@freebsd.org Subject: Re: procfs LKM broken now! Message-ID: <AjB4-TmCJ1@ache.dialup.demos.ru> In-Reply-To: <199510071907.FAA00629@godzilla.zeta.org.au>; from Bruce Evans at Sun, 8 Oct 1995 05:07:50 %2B1000 References: <199510071907.FAA00629@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199510071907.FAA00629@godzilla.zeta.org.au> Bruce Evans
writes:
>>It calls _divdi3 function (procfs_vnops.c) and fail to load,
>>because can't find it. Also libkern have such function, it seems
>>that procfs_vnops.c is only file which call it, so, it isn't
>>picked from libkern to kernel.
>>Workaround is to add 'options PROCFS' to kernel config file.
>>In this case _divdi3 picked from libkern.
>This shows that a kernel library shouldn't be used if there are
>lkm's. The whole point of the library is to avoid linking to
>unused functions, but lkms might use anything in the library
>and this use is not detected when the kernel is linked.
>Also, when individual .o's are used instead of a library, the
>list of .o's must be bloated to include everything that an lkm
>might need.
LKM bulding can be fixed by adding divdi3.c module from libkern
directly to LKM Makefile, but I don't shure what happens if
some kernel module will use divdi3 too (in future f.e.) and LKM
tries to load function with same name.
--
Andrey A. Chernov : And I rest so composedly, /Now, in my bed,
ache@astral.msk.su : That any beholder /Might fancy me dead -
FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead.
RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AjB4-TmCJ1>