Hi, Is it possible to build an SMP module on a machine running a UP kernel (or vice versa)? We of course get unresolved symbols during module load due to the smp prefix on the ksyms, and haven't seen how to get around it. (Defining __SMP__ does not cut it, though I believe this used to work a while ago). Please reply to me as well as to the list. Thanks, -mark
Rafael Herrera wrote:
>
> Mark Mokryn wrote:
> > Is it possible to build an SMP module on a machine running a UP kernel
> > (or vice versa)? We of course get unresolved symbols during module load
> > due to the smp prefix on the ksyms, and haven't seen how to get around
> > it. (Defining __SMP__ does not cut it, though I believe this used to
> > work a while ago).
>
> Yes. It does not matter what kernel you are running. What's important is
> that you configure your sources. Configure your kernel for SMP and do a
> 'make dep', then compile your module.
> --
> Rafael
Is this the only way - to keep two separately configured kernel source
trees? No way to do it via some flag?
thanks,
-mark
Mark Mokryn wrote:
> Is it possible to build an SMP module on a machine running a UP kernel
> (or vice versa)? We of course get unresolved symbols during module load
> due to the smp prefix on the ksyms, and haven't seen how to get around
> it. (Defining __SMP__ does not cut it, though I believe this used to
> work a while ago).
Yes. It does not matter what kernel you are running. What's important is
that you configure your sources. Configure your kernel for SMP and do a
'make dep', then compile your module.
--
Rafael
On Wed, 13 Jun 2001 16:42:54 +0300,
Mark Mokryn <mark@sangate.com> wrote:
>Is it possible to build an SMP module on a machine running a UP kernel
>(or vice versa)?
Build - yes. Load - no. Not unless you like your kernel exploding
into a million tiny pieces. You can compile anything from anywhere,
you can even compile the kernel from other operating systems. But
loading an SMP module into a UP system or vice versa guarantees data
mismatches.
On Wed, 13 Jun 2001 17:43:54 +0300,
Mark Mokryn <mark@sangate.com> wrote:
>Is this the only way - to keep two separately configured kernel source
>trees? No way to do it via some flag?
With 2.4, yes. You need a complete set of kernel source for every set
of config files you use because the object code is written to the
source directory. With 2.5 you can have a single source tree and
multiple object trees, one for each config that you are working on.
In either case you must keep separate sets of objects for each config,
mixing objects from different configs in a single tree is a recipe for
disaster.
Mark Mokryn wrote:
>
> Hi,
>
> Is it possible to build an SMP module on a machine running a UP kernel
> (or vice versa)? We of course get unresolved symbols during module load
> due to the smp prefix on the ksyms, and haven't seen how to get around
> it. (Defining __SMP__ does not cut it, though I believe this used to
> work a while ago).
>
Why not just run an SMP kernel on UP machine? Yes, there may be minor
performance penalty but that may be irrelevant for you if it lets you
build and load SMP modules on that machine. With a UP kernel running,
you will be able to build SMP modules but not load them.
--
Khalid
====================================================================
Khalid Aziz Linux Development Laboratory
(970)898-9214 Hewlett-Packard
khalid@fc.hp.com Fort Collins, CO
[-- Attachment #1: Type: text/plain, Size: 1437 bytes --] On Thu, Jun 14, 2001 at 02:50:35AM +1000, Keith Owens wrote: > On Wed, 13 Jun 2001 17:43:54 +0300, > Mark Mokryn <mark@sangate.com> wrote: > >Is this the only way - to keep two separately configured kernel source > >trees? No way to do it via some flag? > > With 2.4, yes. You need a complete set of kernel source for every set > of config files you use because the object code is written to the > source directory. With 2.5 you can have a single source tree and > multiple object trees, one for each config that you are working on. Use cp -al to replicate your kernel source tree before configuring. It creates a tree with hard links, so you don't waste disk space. Just don't forget to unlink() the files, if you edit them manually. (*) garloff@garloff:~/Physics/numerix $ type unlink unlink is a function unlink () { for name in $*; do test -f $name && { mv $name $name~$PPID; cp -pd $name~$PPID $name; rm $name~$PPID }; done } (*) If you use emacs, you don't need to unlink before edit. The backup file will stay linked, but the edited is unique. patch does unlink, so patching is no problem. vi does NOT unlink. Regards, -- Kurt Garloff <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]