Date: Mon, 16 Feb 1998 23:42:27 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: se@FreeBSD.ORG (Stefan Esser) Cc: hasty@rah.star-gate.com, hackers@FreeBSD.ORG, se@FreeBSD.ORG Subject: Re: PCI LKM Drivers ? Message-ID: <199802162342.QAA10261@usr05.primenet.com> In-Reply-To: <19980216221754.09856@mi.uni-koeln.de> from "Stefan Esser" at Feb 16, 98 10:17:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> #ifndef LKM
>
> DATA_SET (pcidevice_set, bktr_device);
>
> #else
>
> bktr_load(struct lkm_table* lkmtp, int cmd)
> {
> return pci_register_lkm(&bktr_device, 0)
> }
Ick.
#ifdef LKM
#define DEVICE_PCI(name) \
DATA_SET(pcidevice_set,name ## _device);
#else /* !LKM*/
#define DEVICE_PCI(name) \
static __inline int name ## _load(struct lkm_table* lkmtp, int cmd) \
{ \
return pci_register_lkm( & name ## _device, 0); \
}
#endif /* !LKM*/
In reality, a single linker set structure should be used instead to
identify the device on static linking, and the linker set should be
identified via -e (and -A should likewise not attempt to agregate
linker set symbols with the existing linker set symbols in the symbol
file being linked against). This is, in effect, how kld is intended
to operate.
The intent of the macro above is to require no source changes when
kld comes into common use (ie: a kld version of DEVICE_PCI is possible).
If the object is identical in the linked vs. loaded case (caveat: if
an _entry is a linker set symbol, regular linking should ignore the
_entry directive to allow regular linking to occur), then through the
use of seperate ELF sections (assumming run-time agregation of linker
sets instead of link-time agregation is performed by the loader), it
should be possible to statically configure/desconfigure devices in a
kernel image by archiving/dearchiving them in a seperate ELF section
of the kernel image (the seperate section allows them to be seperable).
> I did not do this, yet, because I expect the changes to the
> FreeBSD device driver code to require an interface change,
> and there has not been much demand for the LKM feature ...
I think this is perhaps wise. I'm surprised that there has not
been wider adoption of the kld mechanism as the logical replacement
for the lkm mechanism. The lkm mechanism was intentionally built
as a near-clone of the SunOS kernel module mechanism, and at the
time, it was not resonable to have dual function objects (even for
static linking, in the pre-ELF days) because of the policy decision
to not put a link-loader in the kernel of the time. With this
decision reversed, there is a much larger possibility space available
to us.
In any case, the kld code implements a kernel link-loader, which
cleans up these issues significantly. This is probably where any
module work should be targetted.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802162342.QAA10261>