On Sat, 17 Nov 2007, Peter Teoh wrote:
> Quoted exactly from from Documentation/kbuild/makefiles.txt:
>
> On Nov 16, 2007 4:31 AM, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote:
> >
> > ok, i know what this represents:
> >
> > =====
> > obj-$(CONFIG_RIO) += rio.o
> >
> > rio-objs := rio_linux.o rioinit.o rioboot.o riocmd.o rioctrl.o riointr.o \
> > rioparam.o rioroute.o riotable.o riotty.o
> > =====
> >
> > if the symbol RIO is tristate, then that feature can be selected
> > either as builtin or modular. if builtin, all of those "rio-objs"
> object files will be created and added to the final vmlinux. if
> > modular, then all of those object files are combined to create a final
> > rio.ko loadable module. no problem.
> >
> > but what about this?
> >
> > =====
> > obj-$(CONFIG_CIFS) += cifs.o
>
> > cifs-y := cifsfs.o cifssmb.o cifs_debug.o connect.o dir.o file.o inode.o \
> > link.o misc.o netmisc.o smbdes.o smbencrypt.o transport.o asn1.o \
> > md4.o md5.o cifs_unicode.o nterr.o xattr.o cifsencrypt.o fcntl.o \
> > readdir.o ioctl.o sess.o export.o cifsacl.o
> >
> > cifs-$(CONFIG_CIFS_UPCALL) += cifs_spnego.o
> > =====
> >
> > the CIFS variable is also tristate, so it can be selected as either
> > builtin or modular. but how does "cifs-y" differ from "cifs-objs"?
> > i'm surprised i've never noticed that before, and i'm just trying to
> > appreciate the functional difference. thanks.
> >
>
> Kbuild needs to know which the parts that you want to build your
> module from, so you have to tell it by setting an
$(<module_name>-objs) variable.
>
> Kbuild recognises objects used for composite objects by the suffix
> -objs, and the suffix -y. This allows the Makefiles to use
> the value of a CONFIG_ symbol to determine if an object is part
> of a composite object.
>
> My explanation of your question: basically, depending on the CONFIG
> variable (CONFIG_CIFS_UPCALL), the module cifs.ko will depend or not
> depend on the module cifs_spnego.o - order of the above object files
> are important.
i don't think you understood my question. i'm aware of the standard
technique of using the notation
<modulename>-objs := ...o files ...
to show what goes into a composite module. but if you look at that
cifs entry above, it uses "cifs-y" instead. my question was whether
those two techniques are exactly equivalent. look at the difference
between the rio entry and the cifs entry (both pulled verbatim out of
the tree), and tell me if there's a reason they use different
techniques to define the composite object.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
