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.
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
