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.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
