免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: compare2000
打印 上一主题 下一主题

linux git常见命令整理 [复制链接]

论坛徽章:
3
天秤座
日期:2013-12-27 13:44:58射手座
日期:2014-05-22 16:52:43天蝎座
日期:2014-08-13 16:03:21
61 [报告]
发表于 2014-07-30 17:08 |只看该作者
如何在android上编译单个modules  在调试阶段,如果仅仅是单个.ko的反复修改和调试,可以通过单独编译modules的方法进行。



1,增加一个makefile



bash代码
obj-m += xxxx.o

KERNEL_PATH=../../../../../out/target/product/xxxx/obj/KERNEL_OBJ

all:
    make -C $(KERNEL_PATH) M=`pwd` ARCH=arm CROSS_COMPILE=arm-linux-androideabi- modules

clean:
    make -C $(KERNEL_PATH) M=`pwd` ARCH=arm CROSS_COMPILE=arm-linux-androideabi- clean


2, 增加对应的xxxx.o的源文件



3, make CFLAGS_MODULE=-fno-pic



4, push 该模块到手机上


5, insmod

【内核翻译】sysfs,附参考代码  sysfs  The filesystem for exporting kernel objects
Documentation/filesystems/sysfs.txt


Patrick Mochel  <mochel@osdl.org>
Mike Murphy <mamurph@cs.clemson.edu>
Revised:    16 August 2011
Original:   10 January 2003


Translator: Bill Wang(Liang) (w00173980)


What it is:
sysfs是一个ram-based filesystem,基于ramfs。用于导出kernel的数据结构,属性以及kernel space和user space之间的联系。


sysfs和kobject紧密相关。请查阅Documentation/kobject.txt来了解kobject的信息。


Using sysfs
sysfs在CONFIG_SYSFS选项打开后,编译到内核。通过mount来挂载:
        mount -t sysfs sysfs /sys


Directory Creation
每一个注册到系统中的kobject都会有一个sysfs的目录。这个目录是对应Koject的父目录的子目录。【译注:这句话有点绕,有点递归的意思,意思是说,每个kobject都有一个目录,如果kobject有一个parent,那么他的目录就是parent对应的目录的子目录,如果么没有parent,那么就是/sys的子目录】


通过目录结构来标示kobject的层次关系。


Sysfs内部持有一个指针,该指针指向一个在sysfs_dirent对象关联的目录中实现目录的kobject【?】。在过去,Kobject pointer被sysfs用来在kobject 打开或者关闭的时候做引用计数。在现在的sysfs实现中,kobject的引用计数仅仅通过sysfs_schedule_callback()来修改。


Attributes
kobject的属性以文件的形式导出到文件系统中。sysfs将文件I/O操作转换为kobject属性中定义的方法。


属性应该是ASCII文件,建议每个文件只有一个值。不过每个文件只有一个值,效率不是很好,所以也可以有一组相同类型的值。


混合类型,多组数据,或者很复杂的格式化数据不是很恰当。


一个属性对的定义很简单:
        struct attribute {
                char                    * name;
                struct module       *owner;
                umode_t               mode;
                };

        int sysfs_create_file(struct kobject * kobj, const struct attribute * attr);
        void sysfs_remove_file(struct kobject * kobj, const struct attribute * attr);


单单一个属性不能够对属性进行读或者写。各模块需要定义自己的attribute结构,添加对应的读写方法。


比如设备模型使用的strcut device_attribute:
        struct device_attribute {
                struct attribute attr;
                ssize_t (*show)(struct device *dev, struct device_attribute *arr, char *buf);
                ssize_t (*store)(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);


同时也定义了宏来简化定义:
        #define DEVICE_ATTR(_name, _mode, _show, _store)\
        struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store)


这样声明一个属性就很简单:
        static DEVICE_ATTR(foo, S_IWUSR | S_IRUGO, show_foo, store_foo);
这句话等同于:
        static struct device_attribute dev_attr_foo = {
                .attr = {
                        .name = "foo",
                        .mode = S_IWUSR | S_IRUGO,
                },
                .show = show_foo,
                .store = store_foo,
        };


Subsystem-Specific Callbacks
当一个模块定义一个新的属性类型,那么就必须实现对应的sysfs操作,这些操作用来读写属性文件。
        struct sysfs_ops {
                ssize_t (*show)(struct kobject*, struct attribute *, char*);
                ssize_t (*store)(struct kobject*, struct attribute *, const char *, size_t);
        }
[子系统应该已经定义了struct kobj_type,这kobj_type中包含了sysfs_ops,参考kobject的文档来查看更多细节]


当一个文件被读写,sysfs就会调用合适的方法。该方法会向通用的struct kobject 和 struct attribute pointers转换为特性的指针类型,然后调用关联的方法。


例子:
drivers/base/core.c


        #define to_dev(obj) container_of(obj, struct device, kobj)
        【译注:返回obj所在的struct device的指针】
        #define to_dev_attr(_attr) container_of(_attr, struct device_attribute, attr)
        【译注:返回attr所在的struct device_attribute的指针】


        static ssize_t dev_attr_show(struct kobject *kobj, struct attribute* attr, char *buf)
        {
                struct device_attribute *dev_attr = to_dev_attr(attr);
                struct device *dev = to_dev(kobj);
                ssize_t ret = -EIO;


                if (dev_attr->show)
                        ret = dev_attr->show(dev, dev_attr, buf);
                if (ret >= (ssize_t)PAGE_SIZE) {
                        print_symbol("dev_attr_show: %s return bad count\n", (unsigned long)dev_attr->show);
                }
                return ret;
        }


【?我的例子里,没有注册设备,只是注册是kobject,为何也能找到对应的show, store,是不是kobject只能用于设备模型,而不能用于其他方面】


Reading/Writing Attribute Data
为了读写属性,show()和store()方法必须在声明属性的时候定义。
        ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf);
        ssize_t (*store)(struct device *dev, struct device_attribute *att, const char *buf, size_t count);
换句话说,这两个方法参数只能有一个对象,一个属性和一个buf。


sysfs申请PAGE_SIZE大小的buffer,然后把这个buf传递给方法。每次读写,sysfs只会调用一次方法。这样在方法实现上就有这些特点:
        ---对于read(2),show应该填满整个buffer。由于一个属性只能export一个值,或者一组同类型的值,所以buffer不会太大。
        这个办法也可以让用户空间进行部分读和seek操作。如果用户空间通过seek到0,或者通过pread(2)时用参数0,那么show()多调用一次。
        ---对于write(2),sysfs会将写buffer传入到store()。
        当写sysfs文件时,用户空间应该先读取文件的值,修改成期望的值,然后把整个buf写回。


        属性的读写操作应该操作同一个buf。
        【???】为何写入writehere时,store()方法调用了两次? echo writehere>/sys/hwobj/write_node
其他需要注意的:
        ---【???】写操作会引起show()的位置回到文件开始。
        ---buffer的大小总是PAGE_SIZE。
        ---show()应该返回写入到buf中的长度,返回值和scnprintf()一样。
        【译注】
        scnprintf -- Format a string and place it in a buffer
        int scnprintf(char* buf, size_t size, const char *fmt, ....);
        buf: the buffer to place the result into
        size: the buffer size, including the trailing null space
        【end】
        ---store()应该返回buffer所用的大小。如果所有的buffer都用完了,只需要返回count参数?
        ---show()或者store()方法可以返回错误。如果一个错误的参数传入,那么可以返回一个错误。
        ---show()或者store()传入的对象,会在sysfs引用的object的内存中(?)。所以,物理的设备可能不会存在,所以,如果需要,要检查物理设备是否存在。


简单的实现可以这样:
        static ssize_t show_name(struct device *dev, struct device_attribute *attr, char *buf)
        {
                return scnprintf(buf, PAGE_SIZE, "%s\n", dev->name);
        }
       
        static ssize_t store_name(struct device *dev, struct device_attribute *attr, const char *buf, size_t count)
        {
                snprintf(dev->name, sizeof(dev->name, "%.*s", (int)min(count, sizeof(dev->name) - 1), buf);
                return count;
        }


static DEVICE_ATTR(name, S_IRUGO, show_name, store_name);


(注意:真实的应用中,不应该通过userspace来设置device的名字。


Top Level Directory Layout
sysfs的目录结构导出了kernel的数据结构关系。
顶层的sysfs目录结构类似于:
        block/
        bus/
        class/
        dev/
        devices/
        firmware/
        net/
        fs/
devices/用一个文件系统标示了设备树。直接映射了内部的内核设备树,也就是struct device的结构。


bus/用罗列了内核中各种bus类型。每一种bus的目录中的都有两个文件夹:
        devices/
        drivers/


/sys/bus/[bus-type]/devices/ 包含了在系统中发现的设备的链接,指向了/sys/devices下的设备。
/sys/bus/[bus-type]/drivers/ 包含了bus上挂在的设备的驱动。


fs/包含了当前系统的filesystem,子目录时名子文件系统想要导出的属性。


dev/包含了两个文件夹,char/和block/。在各自的目录中,分别时用<major>:<minor>命名的符号链接。


更多关于设备模型的特性可以在/Documentation/driver-model/查看。


TODO: Finish this section


Current Interfaces
- devices (include/linux/device.h)
----------------------------------
Structure:

struct device_attribute {
         struct attribute        attr;
         ssize_t (*show)(struct device *dev, struct device_attribute *attr,
                         char *buf);
         ssize_t (*store)(struct device *dev, struct device_attribute *attr,
                          const char *buf, size_t count);
};

Declaring:

DEVICE_ATTR(_name, _mode, _show, _store);

Creation/Removal:

int device_create_file(struct device *dev, const struct device_attribute * a    ttr);
void device_remove_file(struct device *dev, const struct device_attribute *     attr);


- bus drivers (include/linux/device.h)
--------------------------------------
Structure:

struct bus_attribute {
         struct attribute        attr;
         ssize_t (*show)(struct bus_type *, char * buf);
         ssize_t (*store)(struct bus_type *, const char * buf, size_t count);
};

Declaring:

BUS_ATTR(_name, _mode, _show, _store)

Creation/Removal:

int bus_create_file(struct bus_type *, struct bus_attribute *);
void bus_remove_file(struct bus_type *, struct bus_attribute *);


- device drivers (include/linux/device.h)
-----------------------------------------

Structure:

struct driver_attribute {
         struct attribute        attr;
         struct attribute        attr;
         ssize_t (*show)(struct device_driver *, char * buf);
         ssize_t (*store)(struct device_driver *, const char * buf,
                          size_t count);
};

Declaring:

DRIVER_ATTR(_name, _mode, _show, _store)

Creation/Removal:

int driver_create_file(struct device_driver *, const struct driver_attribute     *);
void driver_remove_file(struct device_driver *, const struct driver_attribut    e *);


Documentation
~~~~~~~~~~~~~
sysfs目录结构和属性定义了kernel和userspace之间的ABI。因此上,这些ABI要稳定和恰当的说明。所有新的sysfs attribute要在Documentation/ABI中说明,查看Docomentation/ABI/README来了解更多。

论坛徽章:
3
天秤座
日期:2013-12-27 13:44:58射手座
日期:2014-05-22 16:52:43天蝎座
日期:2014-08-13 16:03:21
62 [报告]
发表于 2014-07-30 17:10 |只看该作者
本帖最后由 compare2000 于 2014-09-12 16:38 编辑

samp_sysfs.c.txt
/*
* sysfs.example.c - sample code for Documentation/filesystems/sysfs.txt
*
* Copyright (C) 2013  Bill Wang(Liang)
*
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
* MA 02110-1301 USA.
*/


#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/types.h>
#include <linux/kobject.h>
#include <linux/device.h>

static struct kobject *hwobj=NULL;

ssize_t show_node(struct device *dev, struct device_attribute *att, char *buf)
{
        pr_info("%s called\n",__func__);
        return scnprintf(buf, sizeof("show_node", "%s", "show_node";
}

ssize_t store_node(struct device *dev, struct device_attribute *att, const char *buf,
                size_t count)
{
        pr_info("%s store value %s\n",__func__, buf);
        return sizeof(buf);
}


static DEVICE_ATTR(write_node, S_IWUSR | S_IRUGO, NULL, store_node);
static DEVICE_ATTR(read_node, S_IWUSR | S_IRUGO, show_node, NULL);

static int __init samp_sysfs_init(void)
{
        int ret = 0;
        pr_info("%s module init\n", __func__);
        hwobj = kobject_create_and_add("hwobj", NULL);
        if (IS_ERR(hwobj)){
                ret = PTR_ERR(hwobj);
                pr_err("object alloc failed\n";
                goto exit_del_kobject;
        }

        ret = sysfs_create_file(hwobj, &dev_attr_read_node.attr);
        if (ret){
                pr_err("create read node failed %d\n", ret);
                goto exit_del_sysfs_read;
        }

        ret = sysfs_create_file(hwobj, &dev_attr_write_node.attr);
        if (ret){
                pr_err("create write node failed %d\n", ret);
                goto exit_del_sysfs_write_node;
        }
        return ret;

exit_del_sysfs_write_node:
        sysfs_remove_file(hwobj, &dev_attr_write_node.attr);
exit_del_sysfs_read:
        sysfs_remove_file(hwobj, &dev_attr_read_node.attr);
exit_del_kobject:
        kobject_del(hwobj);
        pr_info("%s return %d \n", __func__, ret);

        return ret;
}
static void __exit samp_sysfs_cleanup(void)
{
        sysfs_remove_file(hwobj, &dev_attr_write_node.attr);
        sysfs_remove_file(hwobj, &dev_attr_read_node.attr);
        kobject_del(hwobj);
        printk(KERN_INFO "hell_cleanup\n";
}

module_init(samp_sysfs_init);
module_exit(samp_sysfs_cleanup);

MODULE_AUTHOR("Bill Wang(Liang)";
MODULE_DESCRIPTION("sample code for Documentation/filesystems/sysfs.txt";
MODULE_LICENSE("GPL";

external folder中linux kernel header的作用






在Linux中,有一个external/kernel-headers/original,这个文件夹中有很多linux的头文件,与kernel/include/linux有很多重复的文件。


1、Android external folder


External refers to external open source libraries. That means libraries that the Android platform depend upon but that are not primarily developed and maintained by the Android open source project. Typical examples are webkit for the browser, FreeType for fonts, SqlLite for databases and so on. As more features are added to Android, more of these libraries are included in external.


external folder是外部的open source lib,这些lib是android依赖的,但是主要的开发和维护又不是android来做


http://stackoverflow.com/questio ... older-functionality


2,external/kernel-headers/original
(external/kernel-headers/original/README.TXT)
这个文件夹里的头文件是Bionic来用生成一个干净的user-land(user space)头文件。基于GPL2+。




3、Bionic




Bionic libc是BSD standard C library发展而来,最早是Google为Android开发。作用主要有三个:
a,BSD license: 通过BSD license,Android程序就和GPL分隔开来。
b,Bionic比GNU C Library要小的多。
c,Bionic的速度更快。


Bionic也缺少很多完整的libc的特性,比如宽字符和C++的异常处理。一些函数也没有实现。


(http://discuz-android.blogspot.c ... ve-libc-bionic.html)




HAL层,以及除了kernel意外的任意用到的C头文件,都是bionic中的。
./core/pathmap.mk,pathmap_INCL :=    libc:bionic/libc/include
http://www.linuxidc.com/Linux/2011-03/33672.htm )


Android编译环境所用的交叉编译工具链是prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-gcc,-I和-L参数指定了所用的C库头文件和动态库文件路径分别是bionic/libc/include和out/target/product/generic/obj/lib
(http://www.360doc.com/content/09/0624/17/36491_4018938.shtml


kernel中用的头文件在kernel/include中。user space用的头文件在bionic下。


4,Bionic kernel header
(bionic/libc/kernel/README.TXT)
Bionic有一套干净的Linux头文件,这些头文件是通过bionic/libc/kernel/tools解析一份原始的,没有修改过的linux头文件生成的,这份头文件就在external/kernel-headers/original。
干净的头文件只包括类型和宏定义,不过处于效率的考虑,不会生成一些静态内联函数。
这些生成的头文件可以用于编译C++,C,也能够按照ANSI模式编译(linux kernel中用到了大量GNU扩展)。
生成头文件的过程是:
*external/kernel-headers/original
包含通常linux kernel source tree中的include目录。这里仅仅只应该包含android依赖的kernel头文件。


*bionic/libc/kernel/common
包含平台无关的头文件。
TMCC  http://www.broadcast.hc360.com/network/2001-6/35.htm





传输与复用结构控制信号(TMCC)应当包含以下信息:
    ● 用于每一狭槽的调制码组合;
    ● 用于每一狭槽的MPEG-TS识别码;
    ● 其它(例如顺序改变,广播报警、突发事件的旗标比特等)。
    TMCC信号应当比主信号优先传送,因为在没有TMCC信号时,主信号不能解调。TMCC信号恢复的最小间隙应当是一个超级帧的周期时间。接收机应当首先解码每一超级帧的TMCC信号。除了上述信息之外,TMCC信号还应当传送时间基准信号。

repo 备忘  1, repo branch/branches

这两个命令结果和目的一样。显示当前的branch状态和数量。

输出格式:


*P nocolor                   | in repo



输出格式有4列,第一列*显示了当前在用的branch.

第二列,可能是空格,p或者P,取决于upload的状态。

空表示还没有提交发布。

P表示所有提交已经通过repo upload发布。

p表示只有一部分通过repo upload发布。



2,repo diff
查看diff


3,  repo status [<project>...]


比较 工作目录和index,以及HEAD的区别。
结果显示三列,第一列表示index和HEAD的区别,大写。
-表示没有区别。
A:  added         (not in HEAD,     in index                     )
M:  modified      (    in HEAD,     in index, different content  )
D:  deleted       (    in HEAD, not in index                     )
R:  renamed       (not in HEAD,     in index, path changed       )
C:  copied        (not in HEAD,     in index, copied from another)
T:  mode changed  (    in HEAD,     in index, same content       )
U:  unmerged; conflict resolution required


第二列表示working tree和index的区别,小写。
-:  new / unknown (not in index,     in work tree                )
m:  modified      (    in index,     in work tree, modified      )
d:  deleted       (    in index, not in work tree                )




4, repo list
List all projects




5, repo start


Start a new branch for development


Usage: repo start <newbranchname> [--all | <project>...]


'repo start' begins a new branch of development, starting from the
revision specified in the manifest.


一个目录下有一大堆同质或不同质的程序,要测试系统处理并发任务的效率不得不写一个任务分发器(work load manager),用C写对新手来说还是有点大条的,利用make -j可以模拟一个简单的wlm。代码大概如下:
01.binaries := $(foreach ccode, \

02.              $(shell for cfile in `ls *.c`; do echo $cfile; done),\

03.              $(ccode:.c=))

04.$(binaries): %:%.c

05.        @echo BLD        $@

06.        @gcc -o $@       $< >/dev/null 2>&1

07.

08.to_run := $(foreach ccode, \

09.            $(shell for cfile in `ls *.c`; do echo $cfile; done),\

10.            to_run_$(ccode:.c=))

11.

12.run: clean $(to_run)

13.to_run_%: %

14.        @to_run=$@;                         \

15.         echo ${to_run##to_run_};        

16.

17.clean:

18.        @echo -n "-------------------------------- CLEAN "

19.        @echo "--------------------------------"

20.        @echo RMV        $(binaries)

21.        @rm -f                 $(binaries)

22.

23.

24..PHONY: run clean
复制代码运行 make -jN 即可
简而言之就是:
1. default 的 target 是 run,run 依赖于 clean 和 to_run
01.run: clean $(to_run)
复制代码2. to_run 是由一段 shell 产生的
01.to_run := $(foreach ccode, \

02.             $(shell for cfile in `ls *.c`; do echo $cfile; done),\

03.             to_run_$(ccode:.c=))
复制代码3. 假设目录下有 1.c 2.c 3.c 4.c ... 100.c 这100个c程序, 那段 shell 生成的变量 to_run 等于这样的一串: to_run_1 to_run2 ... to_run_100
4. to_run_%: % 那一段 rule 的意思是对于某个目标 to_run_73 依赖于 73,当 73 不存在或者 73.c 被更新过, make 就按照上面声明的 binaries 的规则去(重新)生成它:
01.$(binaries): %:%.c

02.         @echo BLD        $@

03.         @gcc -o $@       $< >/dev/null 2>&1
复制代码5.  73 生成以后就运行它,示例里用的是 echo
01.@to_run=$@;                         \

02.          echo ${to_run##to_run_};   
复制代码实际上可以是
01.@to_run=$@;                         \

02.          ./${to_run##to_run_};   
复制代码这样 73 就在适当的时候被运行了。
假设输入 make -j32 run,结果就是可执行文件 1, 2, 3 ... 32 同时被运行,其中的某个结束后 make 会自动启动后面的 33, 34 ... 直至所有的运行结束,这就模拟了一个简单的本地 work load manager。

这个make脚本的另外一个变种可以是:你有一个程序(假设叫 EXEC0),在一台16核的机器上你希望并行地运行32个带不同参数的 EXEC0 实例,总共运行 1024 个实例来测试系统或者 EXEC0 的运行效率,Makefile大概可以这样写:
01.ifeq ($(MAX),)

02.        MAX=1024

03.endif

04.

05.parameter0=0

06.parameter1=11

07.parameter2=22

08.parameter3=33

09.

10.prerequisites := $(foreach num,                                        \

11.                   $(shell i=0; while [ $$i -lt $(MAX) ];        \

12.                                do                                \

13.                                        echo $$i;                \

14.                                        i=$$((i + 1));                \

15.                                    done),                                \

16.                  target_$(num))

17.run(prerequisites)

18.

19.EXEC0: EXEC0.c

20.        gcc -o $@ $<

21.

22.target_%:EXEC0

23.        @./EXEC0 $(parameter$(shell expr $(subst target_,,$@) % 4))

24.

25..PHONY: run
复制代码一个无聊的EXEC0.c 可以是:
01.int

02.main(int argc, char **argv)

03.{

04.        sleep(atoi(argv[1]));

05.        printf("%s %d\n", argv[0], atoi(argv[1]));

06.

07.        return 0;

08.}
复制代码然后make -j32 MAX=1024

论坛徽章:
3
天秤座
日期:2013-12-27 13:44:58射手座
日期:2014-05-22 16:52:43天蝎座
日期:2014-08-13 16:03:21
63 [报告]
发表于 2014-09-12 16:38 |只看该作者
本帖最后由 compare2000 于 2014-09-12 16:39 编辑

http://bbs.chinaunix.net/thread-1512640-1-1.html
http://blog.chinaunix.net/u/22754/showart_372628.html
=== 1 概述
     === 2 角色分工
     === 3 内核编译文件
        --- 3.1 目标定义
        --- 3.2 内嵌对象 - obj-y
        --- 3.3 可加载模块 - obj-m
        --- 3.4 导出符号
        --- 3.5 库文件 - lib-y
        --- 3.6 目录递归
        --- 3.7 编译标记
        --- 3.8 命令依赖
        --- 3.9 依赖关系
        --- 3.10 特殊规则
     === 4 辅助程序
        --- 4.1 简单辅助程序
        --- 4.2 组合辅助程序
        --- 4.3 定义共享库
        --- 4.4 C++语言使用方法
        --- 4.5 辅助程序编译控制选项
        --- 4.6 何时建立辅助程序
        --- 4.7 使用hostprogs-$(CONFIG_FOO)
     === 5 编译清除机制
     === 6 体系Makefile文件
        --- 6.1 变量设置
        --- 6.2 增加预设置项
        --- 6.3 目录表
        --- 6.4 引导映像
        --- 6.5 编译非内核目标
        --- 6.6 编译引导映像命令
        --- 6.7 定制编译命令
        --- 6.8 预处理连接脚本
        --- 6.9 $(CC)支持功能
     === 7 Kbuild变量
     === 8 Makefile语言
     === 9 Credits
     === 10 TODO
=== 1 概述
Makefile包括五部分:
     Makefile            顶层Makefile文件
     .config                  内核配置文件
     arch/$(ARCH)/Makefile      机器体系Makefile文件
     scripts/Makefile.*      所有内核Makefiles共用规则
     kbuild Makefiles      其它makefile文件
通过内核配置操作产生.config文件,顶层Makefile文件读取该文件的配置。顶层Makefile文件负责产生两个主要的程序:vmlinux (内核image)和模块。顶层Makefile文件根据内核配置,通过递归编译内核代码树子目录建立这两个文件。顶层Makefile文件文本一个名为arch/$(ARCH)/Makefile的机器体系makefile文件。机器体系Makefile文件为顶层makefile文件提供与机器相关的信息。每一个子目录有一个makefile文件,子目录makefile文件根据上级目录makefile文件命令启动编译。这些makefile使用.config文件配置数据构建各种文件列表,并使用这些文件列表编译内嵌或模块目标文件。scripts/Makefile.*包含了所有的定义和规则,与makefile文件一起编译出内核程序。
=== 2 角色分工
人们与内核makefile存在四种不同的关系:
*用户* 用户使用"make menuconfig"或"make"命令编译内核。他们通常不读或编辑内核makefile文件或其他源文件。
*普通开发者* 普通开发者维护设备驱动程序、文件系统和网络协议代码,他们维护相关子系统的makefile文件,因此他们需要内核makefile文件整体性的一般知识和关于kbuild公共接口的详细知识。
*体系开发者* 体系开发者关注一个整体的体系架构,比如sparc或者ia64。体系开发者既需要掌握关于体系的makefile文件,也要熟悉内核makefile文件。
*内核开发者* 内核开发者关注内核编译系统本身。他们需要清楚内核makefile文件的所有方面。
本文档的读者对象是普通开发者和系统开发者。
=== 3 内核编译文件
内核中大多数makefile文件是使用kbuild基础架构的makefile文件。本章介绍kbuild的makefile中的语法。
3.1节“目标定义”是一个快速导引,后面各章有详细介绍和实例。
--- 3.1 目标定义
     目标定义是makefile文件的主要部分(核心)。这些目标定义行定义了如何编译文件,特殊的兼容选项和递归子目录。
      最简单的makefile文件只包含一行:
     Example: obj-y += foo.o
    这行告诉kbuild在该目录下名为foo.o的目标文件(object),foo.o通过编译foo.c或者foo.S而得到。
    如果foo.o编译成一个模块,则使用obj-m变量,因此常见写法如下:
     Example: obj-$(CONFIG_FOO) += foo.o
     $(CONFIG_FOO)可以代表y(built-in对象)或m(module对象)。
      如果CONFIG_FOO不是y或m,那么这个文件不会被编译和链接。
--- 3.2 内嵌对象 - obj-y
    makefile文件将为编译vmlinux的目标文件放在$(obj-y)列表中,这些列表依赖于内核配置。
      Kbuild编译所有的$(obj-y)文件,然后调用"$(LD) -r"合并这些文件到一个built-in.o文件中。built-in.o经过父makefile文件链接到vmlinux。$(obj-y)中的文件顺序很重要。列表中文件允许重复,文件第一次出现将被链接到built-in.o,后续出现该文件将被忽略。
      链接顺序之所以重要是因为一些函数在内核引导时将按照他们出现的顺序被调用,如函数(module_init() / __initcall)。所以要牢记改变链接顺序意味着也要改变SCSI控制器的检测顺序和重数磁盘。
      例如: #drivers/isdn/i4l/Makefile
     # 内核ISDN子系统和设备驱动程序Makefile
     # 每个配置项是一个文件列表
     obj-$(CONFIG_ISDN)         += isdn.o
     obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
--- 3.3 可加载模块 - obj-m
  $(obj-m)表示对象文件(object files)编译成可加载的内核模块。
  一个模块可以通过一个源文件或几个源文件编译而成。makefile只需简单地它们加到$(obj-m)。
      例如:#drivers/isdn/i4l/Makefile
        obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
    注意:在这个例子中$(CONFIG_ISDN_PPP_BSDCOMP)含义是'm'。
      如果内核模块通过几个源文件编译而成,使用以上同样的方法。
      Kbuild需要知道通过哪些文件编译模块,因此需要设置一个$(-objs)变量。
    例如:#drivers/isdn/i4l/Makefile
     obj-$(CONFIG_ISDN) += isdn.o
     isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o
     在这个例子中,模块名isdn.o. Kbuild首先编译$(isdn-objs)中的object文件,然后运行"$(LD) -r"将列表中文件生成isdn.o.
  Kbuild使用后缀-objs、-y识别对象文件。这种方法允许makefile使用CONFIG_符号值确定一个object文件是否是另外一个object的组成部分。
     例如: #fs/ext2/Makefile
        obj-$(CONFIG_EXT2_FS)     += ext2.o
        ext2-y := balloc.o bitmap.o
        ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
     在这个例子中,如果$(CONFIG_EXT2_FS_XATTR)表示'y',则ext2.o只有xattr.o组成部分。
     注意: 当然,当你将对象文件编译到内核时,以上语法同样有效。因此,如果CONFIG_EXT2_FS=y,Kbuild将先编译ext2.o文件,然后链接到built-in.o。
--- 3.4 导出符号目标
      在makefile文件中没有特别导出符号的标记。
--- 3.5 库文件 - lib-y
      obj-*中的object文件用于模块或built-in.o编译。object文件也可能编译到库文件中--lib.a。
      所有罗列在lib-y中的object文件都将编译到该目录下的一个单一的库文件中。
      包含在0bj-y中的object文件如果也列举在lib-y中将不会包含到库文件中,因为他们不能被访问。但lib-m中的object文件将被编译进lib.a库文件。
      注意在相同的makefile中可以列举文件到buit-in内核中也可以作为库文件的一个组成部分。因此在同一个目录下既可以有built-in.o也可以有lib.a文件。
      例如:#arch/i386/lib/Makefile
        lib-y   := checksum.o delay.o
     这样将基于checksum.o、delay.o创建一个lib.a文件。
      对于内核编译来说,lib.a文件被包含在libs-y中。将“6.3 目录表”。
      lib-y通常被限制使用在lib/和arch/*/lib目录中。
--- 3.6 目录递归
     makefile文件负责编译当前目录下的目标文件,子目录中的文件由子目录中的makefile文件负责编译。编译系统将使用obj-y和obj-m自动递归编译各个子目录中文件。
     如果ext2是一个子目录,fs目录下的makefile将使用以下赋值语句是编译系统编译ext2子目录。
     例如: #fs/Makefile
        obj-$(CONFIG_EXT2_FS) += ext2/
     如果CONFIG_EXT2_FS设置成'y(built-in)或'm'(modular),则对应的obj-变量也要设置,内核编译系统将进入ext2目录编译文件。
      内核编译系统只使用这些信息来决定是否需要编译这个目录,子目录中makefile文件规定那些文件编译为模块那些是内核内嵌对象。
      当指定目录名时使用CONFIG_变量是一种良好的做法。如果CONFIG_选项不为'y'或'm',内核编译系统就会跳过这个目录。
--- 3.7 编译标记
  EXTRA_CFLAGS, EXTRA_AFLAGS, EXTRA_LDFLAGS, EXTRA_ARFLAGS
  所有的EXTRA_变量只能使用在定义该变量后的makefile文件中。EXTRA_变量被makefile文件所有的执行命令语句所使用。
     $(EXTRA_CFLAGS)是使用$(CC)编译C文件的选项。
     例如: # drivers/sound/emu10k1/Makefile
           EXTRA_CFLAGS += -I$(obj)
           ifdef
            DEBUG EXTRA_CFLAGS += -DEMU10K1_DEBUG
            endif
     定义这个变量是必须的,因为顶层makefile定义了$(CFLAGS)变量并使用该变量编译整个代码树。
     $(EXTRA_AFLAGS)是每个目录编译汇编语言源文件的选项。
     例如: #arch/x86_64/kernel/Makefile
           EXTRA_AFLAGS := -traditional
     $(EXTRA_LDFLAGS)和$(EXTRA_ARFLAGS)用于每个目录的$(LD)和$(AR)选项。
     例如: #arch/m68k/fpsp040/Makefile
           EXTRA_LDFLAGS := -x
  CFLAGS_$@, AFLAGS_$@
     CFLAGS_$@和AFLAGS_$@只使用到当前makefile文件的命令中。
     $(CFLAGS_$@)定义了使用$(CC)的每个文件的选项。$@部分代表该文件。
     例如: # drivers/scsi/Makefile
           CFLAGS_aha152x.o =   -DAHA152X_STAT -DAUTOCONF
           CFLAGS_gdth.o   = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \
  -DGDTH_STATISTICS CFLAGS_seagate.o =   -DARBITRATE -DPARITY -DSEAGATE_USE_ASM
     这三行定义了aha152x.o、gdth.o和seagate.o文件的编译选项。
     $(AFLAGS_$@)使用在汇编语言代码文件中,具有同上相同的含义。
     例如: # arch/arm/kernel/Makefile
           AFLAGS_head-armv.o := -DTEXTADDR=$(TEXTADDR) -traditional
           AFLAGS_head-armo.o := -DTEXTADDR=$(TEXTADDR) -traditional
--- 3.9 依赖关系
     内核编译记录如下依赖关系:
      1) 所有的前提文件(both *.c and *.h)
      2) CONFIG_ 选项影响到的所有文件
      3) 编译目标文件使用的命令行
     因此,假如改变$(CC)的一个选项,所有相关的文件都要重新编译。
--- 3.10 特殊规则
      特殊规则使用在内核编译需要规则定义而没有相应定义的时候。典型的例子如编译时头文件的产生规则。其他例子有体系makefile编译引导映像的特殊规则。特殊规则写法同普通的Make规则。
     Kbuild(应该是编译程序)在makefile所在的目录不能被执行,因此所有的特殊规则需要提供前提文件和目标文件的相对路径。
     定义特殊规则时将使用到两个变量:
  $(src): $(src)是对于makefile文件目录的相对路径,当使用代码树中的文件时使用该变量$(src)。
  $(obj): $(obj)是目标文件目录的相对路径。生成文件使用$(obj)变量。
     例如: #drivers/scsi/Makefile
     $(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl
        $(CPP) -DCHIP=810 - -objs)包含了所有的用于链接最终可执行程序的对象。
     例如: #scripts/lxdialog/Makefile
        hostprogs-y   := lxdialog
        lxdialog-objs := checklist.o lxdialog.o
     扩展名.o文件都编译自对应的.c文件。在上面的例子中checklist.c编译成checklist.o,lxdialog.c编译为lxdialog.o。最后两个.o文件链接成可执行文件lxdialog。
     注意:语法-y不能用于定义主机程序。
--- 4.3 定义共享库
     扩展名为.so的对象是共享库文件,并且是位置无关的object文件。内核编译系统提供共享库使用支持,但使用方法有限制。在下面例子中libkconfig.so库文件被链接到可执行文件conf中。
     例如: #scripts/kconfig/Makefile
           hostprogs-y   := conf
           conf-objs     := conf.o libkconfig.so
           libkconfig-objs := expr.o type.o
     共享库文件需要对应的-objs定义, 在上面例子中库libkconfig由两个对象组成:expr.o和type.o。expr.o和type.o将被编译为位置无关代码并被链接如libkconfig.so。共享库不支持C++语言。
--- 4.4 C++语言使用方法
     内核编译系统提供了对C++主机程序的支持以用于内核配置,但不主张其它方面使用这种方法。
     例如: #scripts/kconfig/Makefile
           hostprogs-y   := qconf
           qconf-cxxobjs := qconf.o
     在上面例子中可执行文件由C++文件qconf.cc组成 - 通过$(qconf-cxxobjs)标识。
     如果qconf由.c和.cc文件混合组成,附加行表示这种情况。
     例如: #scripts/kconfig/Makefile
           hostprogs-y   := qconf
           qconf-cxxobjs := qconf.o
           qconf-objs   := check.o
--- 4.5 辅助程序编译控制选项
     当编译主机程序时仍然可以使用$(HOSTCFLAGS)设置编译选项传递给$(HOSTCC)。这些选项将影响所有使用变量HOST_EXTRACFLAG的makefile创建的主机程序。
     例如: #scripts/lxdialog/Makefile
           HOST_EXTRACFLAGS += -I/usr/include/ncurses
     为单个文件设置选项使用下面方式:
     例如: #arch/ppc64/boot/Makefile
     HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE)
     也可以使用附加链接选项:
     例如: #scripts/kconfig/Makefile
           HOSTLOADLIBES_qconf := -L$(QTDIR)/lib
     当链接qconf时将使用外部选项"-L$(QTDIR)/lib"。
--- 4.6 何时建立辅助程序
     只有当需要时内核编译系统才会编译主机程序。有两种方式:
     (1) 在特殊规则中作为隐式的前提需求
     例如: #drivers/pci/Makefile
     hostprogs-y := gen-devlist
     $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist
              ( cd $(obj); ./gen-devlist )  产生 .config文件
2) 保存内核版本到include/linux/version.h文件中
3) 符号链接include/asm to include/asm-$(ARCH)
4) 更新所有目标对象的其它前提文件
  - 附加前提文件定义在arch/$(ARCH)/Makefile文件中
5) 递归进入init-* core* drivers-* net-* libs-*中的所有子目录和编译所有的目标对象
  - 上面变量值都引用到arch/$(ARCH)/Makefile文件。
6) 链接所有的object文件生成vmlinux文件,vmlinux文件放在代码树根目录下。
  最开始链接的几个object文件列举在arch/$(ARCH)/Makefile文件的head-y变量中。
7) 最后体系makefile文件定义编译后期处理规则和建立最终的引导映像bootimage。
  - 包括创建引导记录
  - 准备initrd映像和相关处理
--- 6.1 变量设置
  LDFLAGS      $(LD)一般选项
     选项使用于链接器的所有调用中。通常定义emulation就可以了。
     例如: #arch/s390/Makefile
           LDFLAGS   := -m elf_s390
      注意: EXTRA_LDFLAGS和LDFLAGS_$@可以进一步订制使用选项,将第7章。
  LDFLAGS_MODULE       $(LD)链接模块的选项
     LDFLAGS_MODULE通常设置$(LD)链接模块的.ko选项。
     默认为"-r"即可重定位输出文件。
  LDFLAGS_vmlinux   $(LD)链接vmlinux选项
     LDFLAGS_vmlinux定义链接最终vmlinux时链接器的选项。
     LDFLAGS_vmlinux支持使用LDFLAGS_$@。
     例如: #arch/i386/Makefile
           LDFLAGS_vmlinux := -e stext
  OBJCOPYFLAGS      objcopy选项
     当使用$(call if_changed,objcopy)转化a .o文件时,OBJCOPYFLAGS中的选项将被使用。
     $(call if_changed,objcopy)经常被用作为vmlinux产生原始的二进制文件。
     例如: #arch/s390/Makefile
           OBJCOPYFLAGS := -O binary
          #arch/s390/boot/Makefile
           $(obj)/image: vmlinux FORCE $(call if_changed,objcopy)
     在上面例子中$(obj)/image是vmlinux的二进制版本文件。$(call if_changed,xxx)
的使用方法见后。
  AFLAGS   $(AS)汇编选项
     默认值见顶层Makefile文件
     针对每个体系需要另外添加和修改它。
     例如: #arch/sparc64/Makefile
           AFLAGS += -m64 -mcpu=ultrasparc
  CFLAGS      $(CC)编译器选项
     默认值见顶层Makefile文件
     针对每个体系需要另外添加和修改它。
     通常CFLAGS变量值取决于内核配置。
     例如: #arch/i386/Makefile
           cflags-$(CONFIG_M386) += -march=i386
           CFLAGS += $(cflags-y)
     许多体系Makefiles文件动态启动市场目标机器上的C编译器检测支持的选项:
           #arch/i386/Makefile
           ...
           cflags-$(CONFIG_MPENTIUMII)   += $(call cc-option,\
                 -march=pentium2,-march=i686) ...
           # Disable unit-at-a-time mode ...
           CFLAGS += $(call cc-option,-fno-unit-at-a-time)
           ...
     第一个例子当config选项是'y'时将被选中。
  CFLAGS_KERNEL      $(CC)编译built-in对象的选项
     $(CFLAGS_KERNEL)包含外部C编译器选项编译本地内核代码。
  CFLAGS_MODULE      $(CC)编译模块选项
     $(CFLAGS_MODULE)包含外部C编译器选项编译可加载内核代码。
--- 6.2 增加预设置项
     prepare: 这个规则用于列举开始进入子目录编译前需要的前提文件。通常是些包含汇编常量的头文件。
     例如:
     #arch/s390/Makefile
     prepare: include/asm-$(ARCH)/offsets.h
     在这个例子中include/asm-$(ARCH)/offsets.h将在进入子目录前编译。
      详见XXX-TODO文件描述了kbuild如何产生offset头文件。
--- 6.3 目录表
     体系makefile文件和顶层makefile文件共同定义了如何建立vmlinux文件的变量。注意没有体系相关的模块对象定义部分:所有的模块对象都是体系无关的。
  head-y, init-y, core-y, libs-y, drivers-y, net-y
     $(head-y) 列举首先链接到vmlinux的对象文件。
     $(libs-y) 列举了能够找到lib.a文件的目录。
     其余的变量列举了能够找到内嵌对象文件的目录。
     $(init-y) 列举的对象位于$(head-y)对象之后。
     然后是如下位置秩序:
     $(core-y), $(libs-y), $(drivers-y) 和 $(net-y)。
     顶层makefile定义了所有同用目录,arch/$(ARCH)/Makefile文件只需增加体系相关的目录。
     例如: #arch/sparc64/Makefile
           core-y += arch/sparc64/kernel/
           libs-y += arch/sparc64/prom/ arch/sparc64/lib/
           drivers-$(CONFIG_OPROFILE) += arch/sparc64/oprofile/
--- 6.4 引导映像
     体系makefile文件定义了编译vmlinux文件的目标对象,将它们压缩和封装成引导代码,并复制到合适的位置。这包括各种安装命令。如何定义实际的目标对象无法为所有的体系结构提供标准化的方法。
     附加处理过程常位于arch/$(ARCH)/下的boot/目录。
     内核编译系统无法在boot/目录下提供一种便捷的方法创建目标系统文件。因此arch/$(ARCH)/Makefile要调用make命令在boot/目录下建立目标系统文件。建议使用的方法是在arch/$(ARCH)/Makefile中设置调用,并且使用完整路径引用arch/$(ARCH)/boot/Makefile。
     例如: #arch/i386/Makefile
           boot := arch/i386/boot
           bzImage: vmlinux
              $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
     建议使用"$(Q)$(MAKE) $(build)="方式在子目录中调用make命令。
     没有定义体系目标系统文件的规则,但执行"make help"命令要列出所有目标系统文件,因此必须定义$(archhelp)变量。
     例如: #arch/i386/Makefile
     define
        archhelp echo '* bzImage     - Image (arch/$(ARCH)/boot/bzImage)'
      endef
     当执行不带参数的make命令时,将首先编译第一个目标对象。在顶层makefile中第一个目标对象是all:。
     一个体系结构需要定义一个默认的可引导映像。
     "make help"命令的默认目标是以*开头的对象。
     增加新的前提文件给all目标可以设置不同于vmlinux的默认目标对象。
     例如: #arch/i386/Makefile
           all: bzImage
     当执行不带参数的"make"命令时,bzImage文件将被编译。
--- 6.5 编译非内核目标
  extra-y
     extra-y定义了在当前目录下创建没有在obj-*定义的附加的目标文件。
     在extra-y中列举目标是处于两个目的:
      1) 是内核编译系统在命令行中检查变动情况
        - 当使用$(call if_changed,xxx)时
      2) 内核编译系统知道执行"make clean"命令时删除哪些文件
     例如: #arch/i386/kernel/Makefile
           extra-y := head.o init_task.o
     上面例子extra-y中的对象文件将被编译但不会练接到built-in.o中。
--- 6.6 编译引导映像命令
     Kbuild提供了一些编译引导映像有用的宏。
  if_changed
     if_changed是后面命令使用的基础。
     用法:
        target: source(s)
            FORCE $(call if_changed,ld/objcopy/gzip)
     当这条规则被使用时它将检查哪些文件需要更新,或命令行被改变。后面这种情况将迫使重新编译编译选项被改变的执行文件。使用if_changed的目标对象必须列举在$(targets)中,否则命令行检查将失败,目标一直会编译。
     赋值给$(targets)的对象没有$(obj)/前缀。
     if_changed也可以和定制命令配合使用,见6.7"kbuild定制命令"。
     注意: 一个常见错误是忘记了FORCE前导词。
  ld
      链接目标。常使用LDFLAGS_$@作为ld的选项。
  objcopy
      复制二进制文件。常用于arch/$(ARCH)/Makefile中和使用OBJCOPYFLAGS作为选项。
     也可以用OBJCOPYFLAGS_$@设置附加选项。
  gzip
      压缩目标文件。使用最大压缩算法压缩目标文件。
     例如: #arch/i386/boot/Makefile
     LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary
     LDFLAGS_setup   := -Ttext 0x0 -s --oformat binary -e begtext
     targets += setup setup.o bootsect bootsect.o
     $(obj)/setup $(obj)/bootsect: %: %.o FORCE
            $(call if_changed,ld)
      在上面例子中有两个可能的目标对象,分别需要不同的链接选项。使用LDFLAGS_$@语法为每个目标对象设置不同的链接选项。
     $(targets)包含所有的目标对象,因此内核编译系统知道所有的目标对象并且将:
      1) 检查命令行的改变情况
      2) 执行make clean命令时删除目标对象
     ": %: %.o"是简写方法,减写setup.o和bootsect.o文件。
     注意: 常犯错误是忘记"target :="语句,导致没有明显的原因目标文件被重新编译。
--- 6.7 定制编译命令
     当执行带KBUILD_VERBOSE=0参数的编译命令时命令的简短信息会被显示。要让定制命令具有这种功能需要设置两个变量:
     quiet_cmd_ - 将被显示的内容
      cmd_      - 被执行的命令
     例如: #
           quiet_cmd_image = BUILD   $@
            cmd_image = $(obj)/tools/build $(BUILDFLAGS) \
                    $(obj)/vmlinux.bin > $@
           targets += bzImage
           $(obj)/bzImage: $(obj)/vmlinux.bin $(obj)/tools/build FORCE
                $(call if_changed,image)
                @echo 'Kernel: $@ is ready'
     执行"make KBUILD_VERBOSE=0"命令编译$(obj)/bzImage目标时将显示:
     BUILD   arch/i386/boot/bzImage
--- 6.8 预处理连接脚本
     当编译vmlinux映像时将使用arch/$(ARCH)/kernel/vmlinux.lds链接脚本。
     相同目录下的vmlinux.lds.S文件是这个脚本的预处理的变体。内核编译系统知晓.lds文件并使用规则*lds.S -> *lds。
     例如: #arch/i386/kernel/Makefile
           always := vmlinux.lds
           #Makefile
           export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH)
     $(always)赋值语句告诉编译系统编译目标是vmlinux.lds。$(CPPFLAGS_vmlinux.lds)赋值语句告诉编译系统编译vmlinux.lds目标的编译选项。
     编译*.lds时将使用到下面这些变量:
     CPPFLAGS      : 定义在顶层Makefile
     EXTRA_CPPFLAGS      : 可以设置在编译的makefile文件中
     CPPFLAGS_$(@F) : 目标编译选项。注意要使用文件全名。
--- 6.9 $(CC)支持功能
     内核可能会用不同版本的$(CC)进行编译,每个版本有不同的性能和选项,内核编译系统提供基本的支持用于验证$(CC)选项。$(CC)通常是gcc编译器,但其它编译器也是可以。
  cc-option cc-option 用于检测$(CC)是否支持给定的选项,如果不支持就使用第二个可选项。
     例如: #arch/i386/Makefile
           cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586)
     在上面例子中如果$(CC)支持-march=pentium-mmx则cflags-y等于该值,否则等于-march-i586。如果没有第二个可选项且第一项不支持则cflags-y没有被赋值。
  cc-option-yn cc-option-yn用于检测gcc是否支持给定的选项,支持返回'y'否则'n'。
     例如: #arch/ppc/Makefile
           biarch := $(call cc-option-yn, -m32)
           aflags-$(biarch) += -a32
           cflags-$(biarch) += -m32
     在上面例子中如果$(CC)支持-m32选项则$(biarch)设置为y。当$(biarch)等于y时,变量$(aflags-y)和$(cflags-y)将分别等于-a32和-m32。
  cc-option-align gcc版本>= 3.0用于定义functions、loops等边界对齐选项。
     gcc = 3.00
        cc-option-align = -falign
     例如:
        CFLAGS += $(cc-option-align)-functions=4
     在上面例子中对于gcc >= 3.00来说-falign-functions=4,gcc ,均为两位数字。例如gcc 3.41将返回0341。
     当一个特定$(CC)版本在某个方面有缺陷时cc-version是很有用的。例如-mregparm=3在一些gcc版本会失败尽管gcc接受这个选项。
     例如: #arch/i386/Makefile
           GCC_VERSION := $(call cc-version)
           cflags-y += $(shell \
           if [ $(GCC_VERSION) -ge 0300 ] ; then echo "-mregparm=3"; fi
     在上面例子中-mregparm=3只使用在版本大于等于3.0的gcc中。
=== 7 Kbuild变量
  顶层Makefile文件导出下面这些变量:
  VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION
     这几个变量定义了当前内核版本号。很少体系体系Makefiles文件直接使用他们,常用$(KERNELRELEASE)代替。
     $(VERSION)、$(PATCHLEVEL)和$(SUBLEVEL)定义了三个基本部分版本号,例如"2", "4",和"0"。这三个变量一直使用数值表示。
     $(EXTRAVERSION)定义了更细的补钉号,通常是短横跟一些非数值字符串,例如"-pre4"。
  KERNELRELEASE
     $(KERNELRELEASE)是一个单一字符如"2.4.0-pre4",适合用于构造安装目录和显示版本字符串。一些体系文件使用它用于以上目的。
  ARCH
     这个变量定义了目标系统体系结构,例如"i386"、“arm"、"sparc". 一些内核编译文件测试$(ARCH)用于确定编译哪个文件。默认情况下顶层Makefile文件设置$(ARCH)为主机相同的系统体系。当交叉编译编译时,用户可以使用命令行改变$(ARCH)值:
        make ARCH=m68k ...
  INSTALL_PATH
     这个变量定义了体系Makefiles文件安装内核映项和System.map文件的路径。
  INSTALL_MOD_PATH, MODLIB
     $(INSTALL_MOD_PATH)定义了模块安装变量$(MODLIB)的前缀。这个变量通常不在Makefile文件中定义,如果需要可以由用户添加。
     $(MODLIB)定义了模块安装目录。
     顶层Makefile定义$(MODLIB)为$(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)。用户可以使用命令行修改这个值。
=== 8 Makefile语言
  内核Makefiles设计目标用于运行GNU Make程序。Makefiles仅使用GNU Make提到的特性,但使用了较多的GNU扩展部分。
  GNU Make程序支持基本的列表处理功能。内核Makefiles文件结合"if"语句使用了简单的列表建立和维护功能。
  GNU Make程序有两种赋值操作符:":="和"="。 ":="执行时立即计算右值并赋值给左值。"="类似公式定义,当每次使用左值要被使用时计算右值并赋给它。
  一些情况中使用"="合适,而一些情况中使用":="才是正确选择。
=== 9 Credits
  Original version made by Michael Elizabeth Chastain,  Updates
by Kai Germaschewski  Updates by Sam Ravnborg
=== 10 TODO
- Describe how kbuild support shipped files with _shipped.
- Generating offset header files.
- Add more variables to section 7?

论坛徽章:
3
天秤座
日期:2013-12-27 13:44:58射手座
日期:2014-05-22 16:52:43天蝎座
日期:2014-08-13 16:03:21
64 [报告]
发表于 2014-10-23 16:03 |只看该作者
本帖最后由 compare2000 于 2014-10-23 16:08 编辑

根据HR的有关安排,参加了一些社招和校招的面试工作,包括集体面试和业务(专业)面试。

         面试他人的过程,实际也是在面试自己。由己及人,由人及己。

     简单整理下之前到现在的几点零星体会。自勉或他勉,仅供参
【给应聘初试者的几点基本建议】

     今日做了一天的面试官,遇到一些有一定工作经验的求职者,但还是犯了一些低级错误,忍不住给几点建议供参考并与大家探讨。

1、简历要简,一页为好,呈现要点亮点即可;

2、目标岗位要明确,至少要事先研究其名称和职责要求;

3、换岗求职的原因、意愿要清晰,意愿的强烈程度常常是相互的(正/反相关);

4、英语要有所准备,至少要准备下自我介绍与项目类的内容。  



【社招招聘面试随感】

1、工作年限如果不伴随着职位的提升或相应的职业成熟,只能是负分; 简单重复的日历累积(而不是阅历增长)只是平庸的潜台词。年龄亦然。

2、正能量因素在比较中(集面中)效应明显。积极主动、开放进取、团队精神(融入度与合作性)、成就欲......谁都喜欢。等待、保守、沉默、不合群......尽管有时并非坏事,但大部分人更愿意打常规牌。

3、差异性是一把双刃剑,要慎用。可以脱颖而出,可以早夭出局。大家钟爱独特价值,但不敢乱用旁门左道和哗众取宠。

4、留学背景、大公司的历练、专业认证的把关......其影响潜移默化,在日常的表达呈现和解决问题上是可见一斑的。

5、微笑、礼貌……这些简单的待人接物在默默地发挥着作用,影响着受众的感知。  

【今日招聘面试小体悟】  

- 微笑是人际交往永远的利器;自然友好的眼神接触,是最好的见面礼。

- 主动、开放、分享、友善……所有面向他人和团队的优秀习惯,让人们在人群中发现你。这种人一入团队就能凸显。

- 自信、坚韧、沉稳、度量……所有向内修炼的良好特质,让自己散发个性魅力。这种人不需要多表现即可见。

- 面相和气场的差异,带来的不同直觉体验,这种第一感对人的认知影响很大。



【今日招聘面试小体悟】  

- 集体面试是“群殴”或“选秀”,业务面试则是“单挑”或“独角戏”。集面讲究脱颖而出,业面追求单点突破。呈现的侧重点不同。

- 不怕示弱,因为没有全才;

  关键是不忘展示强项所在。

- 不懂没关系,装懂才误事;

  不懂可以学,续航看能力。

- 深进去抓细节和重点(微观),跳出来理结构和逻辑(宏观),如此,才会融会贯通而理解,将知识结构化于脑中。深入浅出,则是理解的最高境界。接下来就是实践转化能力。

- 基础很重要,应该是深入骨髓的。没有人因为学了高数而忘记了123加减乘除,也不应该因为学了经济学而忘了会计要素。



【今日招聘面试小体悟】  

- 人生充满了偶然。 有些偶尔就是单纯的偶然,比如单独事件; 有些偶然中间有必然,比如统计意义下的重复。以平淡心看待偶然,以认真劲对待必然。

- 一个环节的单独面试的成败,在我看来,其中有很大的偶然因素。你的成败可能源于一个很小的原因:一个微笑、一个眼神、一句话、一个正式或随意的打扮、一次积极或消极的发言、一个突发奇想的观点、同伴或对手的一个失误或攻击、一位严苛或随和的考官、一道碰巧的容易或刁钻的考题……从这个意义上来说,大可不必在一个环节的得失上太纠结。尽力而为,成败在天。

- 然,就长远而言,多轮面试乃至后续工作的成功者,确实富有正的能量特质。所谓性格决定命运,这其中就已经包含了众多偶然中蕴藏的必然。从这个意义上来说,正向地修炼自身、打磨性格,是永远不变的必要。

- 招聘考核,确实应该客观评测和主观面试相结合,融科学和艺术于一体,才可能尽量减少偶然的偏差。


- 微笑是人际交往永远的利器;自然友好的眼神接触,是最好的见面礼。

- 主动、开放、分享、友善……所有面向他人和团队的优秀习惯,让人们在人群中发现你。这种人一入团队就能凸显。

- 自信、坚韧、沉稳、度量……所有向内修炼的良好特质,让自己散发个性魅力。这种人不需要多表现即可见。

- 面相和气场的差异,带来的不同直觉体验,这种第一感对人的认知影响很大。
——最后总结的是:人格魅力

论坛徽章:
3
天秤座
日期:2013-12-27 13:44:58射手座
日期:2014-05-22 16:52:43天蝎座
日期:2014-08-13 16:03:21
65 [报告]
发表于 2014-10-23 16:09 |只看该作者
从一个个人员的面试(微观)的表现,整理出来一套逻辑和整体结构(宏观), 以人为镜,在做面试官观察别人的同时,也总结与人交往过程中哪些有益,哪些有弊。文采出众精彩。
深进去抓细节和重点(微观),跳出来理结构和逻辑(宏观),如此,才会融会贯通而理解,将知识结构化于脑中。深入浅出,则是理解的最高境界。
大学毕业后大大小小面了几十场各类面试,也较为深入的研究过多个行业多累岗位的宣讲会和招聘模式,楼主所说的这些,稍稍研究下就可以被化解。面到最后就是返璞归真。对于面试官,最主要的就是关注在群面表现环节,再考虑经历、证书等,排除第一印象的影响;良好的题目设计,而不是千篇一律看题目就知道讨论结果与讨论套路是极其必要的,我司的题库差太多对于面试者,就是排除掉杂念,破解题目自身的漏洞,这样就可以减少和其他竞争者(合作者)的PK而增大自己的胜率,至于什么时候该用什么样的方法说什么样的话,普遍来说,在面试失败15-20次后可以完成第一阶段的面试经验积累,可以攻克绝大部分普通的面试套路,在面试总数超过25次后达到大成,不是碰到非能力不及的,基本没问题。
0     核心标准永远只有一个,你符不符合我们的职责要求

1     多问一些开放性的问题。面上的,很考验思维能力

2     再问几个细节。看他细致不细致。点上的,能否把问题搞清楚

3     思维能力,表达能力,是最重要的两方面。

3.1 分类。回答问题不要上来就特别具体化,先分类。这是逻辑思维的最基本方法。不然一下子就乱了,深一脚浅一脚的

          能高阶到结构化思维、系统性思维,甚至战略思维当然更好。

3.2 表达清晰。慢一点不要仅

4     说话自信,声音稳重,绝对加分

5     多让面试者自己说。看他的局面掌控能力。有的人经常就不知道绕到哪里了

6     问题不是要打翻他,重点要通过问题发现他的能力与潜力。

7     经验当然重要,但世界变化这么快,我更看重你后续的学习能力

8     "提一些新问题,看他的问题处理能力,复杂场景能力。压力下的从容能力。

如果遇到XXX问题,你怎么处理?"
演员的自我修养 对自己永远要有要求。

论坛徽章:
3
天秤座
日期:2013-12-27 13:44:58射手座
日期:2014-05-22 16:52:43天蝎座
日期:2014-08-13 16:03:21
66 [报告]
发表于 2014-10-23 16:18 |只看该作者
阿里分布式数据库服务原理与实践-shenxun.pdf ( 676.73 KB ,672 downs )   
实时计算服务化实践-qiangqi.pdf ( 8.01 MB ,447 downs )   
构建一个跨机房的Hadoop集群-wuwei.pptx ( 698.49 KB ,405 downs )   
无线互联网-产品质量保证-xuzheng.ppt ( 2.68 MB ,411 downs )   
探求计算性能极限-探求计算密集应用优化的天花板-wangzheng.pdf ( 881.78 KB ,346 downs )   
基于Hadoop_HBase的一淘搜索离线系统-wangfeng.pptx ( 1.05 MB ,401 downs )   
深度学习:机器学习的新浪潮-yukai.pdf ( 5.69 MB ,508 downs )   
百度媒体云技术及架构-chenbing.pdf ( 1.75 MB ,479 downs )   
后端-大型网站SEO优化实践-zhouwenjun.pdf ( 1.77 MB ,379 downs )   
去哪儿酒店实时搜索技术分享-liuyue.pdf ( 1.48 MB ,469 downs )   
淘宝消息中间件技术演变-zhanglewei.pdf ( 1.31 MB ,378 downs )   
AB测试和灰度发布平台架构设计和实践-oucheng.pdf ( 1.08 MB ,339 downs )   
淘宝网CRM平台架构for ADC-yunguang.pdf ( 4.32 MB ,340 downs )   
HouseMD介绍-jushi.pdf ( 360.25 KB ,274 downs )   
Inside TAE-liuhaoyu.pdf ( 3.3 MB ,308 downs )   
Nashorn与JDK8——动态语言在JVM上的高性能实现-mosu.pdf ( 1.09 MB ,307 downs )   
Scala中的函数式特征与并发-wanghongjiang.pdf ( 1.57 MB ,318 downs )   
TMS模块化页面搭建平台-fangjun.pdf ( 1.07 MB ,279 downs )   
Web页面分层交叉实验-chendong.pdf ( 792.51 KB ,279 downs )   
北冥神功- 新一代数据查询中间层-zhijiale.pdf ( 11.24 MB ,341 downs )   
互联网系统的稳定性保证:微博的实践-hongxiaojun.pdf ( 1.02 MB ,311 downs )   
基于OpenStack构建网易云主机服务-zhangxiaolong.pdf ( 1010.79 KB ,300 downs )   
架构模式与实践漫谈-wangfuqiang.pdf ( 12.51 MB ,406 downs )   
容量规划与授权限流降级-zhangjun.pdf ( 414.97 KB ,257 downs )   
淘宝文本中的语义分析以及技术展望-wangtianzhou.pdf ( 3.21 MB ,298 downs )   
天猫个性化推荐架构-zhangqi.pdf ( 2.34 MB ,339 downs )   
新一代前端代码开发与部属方案——独角兽系统功能简介-dengnanqiao.pptx ( 1.2 MB ,279 downs )   
让店铺飞起来-feichang.ppt ( 1.32 MB ,297 downs )   
商品详情页静态异步化-jicheng.pptx ( 876.04 KB ,256 downs )   
架起前端和开发的桥梁-chenzhongyin.ppt ( 4.14 MB ,306 downs )

论坛徽章:
3
天秤座
日期:2013-12-27 13:44:58射手座
日期:2014-05-22 16:52:43天蝎座
日期:2014-08-13 16:03:21
67 [报告]
发表于 2014-10-23 16:19 |只看该作者
淘宝网商品详情页静态异步化-liujunyuan.ppt ( 1.31 MB ,255 downs )   
不一样的装修-wangyufeng.pptx ( 116.91 KB ,248 downs )   
跨终端的文件加载及缓存-liushuang.pdf ( 9.82 MB ,271 downs )   
开放JS在淘宝的应用-shiba.pdf ( 324.43 KB ,237 downs )   
你所不知道的TAE SDK-taogu.pdf ( 629.35 KB ,238 downs )   
DBFree-阿里数据库自动化运维平台-yangxu.pptx ( 1009.57 KB ,249 downs )   
CAP 理论与实践-tongjiawang.pptx ( 2.42 MB ,297 downs )   
iDB-阿里集团数据库服务平台-yezhengsheng.pptx ( 1.08 MB ,243 downs )   
MySQL at NetEase-jianchengyao.pdf ( 937.27 KB ,243 downs )   
OceanBase0.4:从API到SQL-yangchuanhui.pptx ( 1.05 MB ,249 downs )   
阿里巴巴离线大数据处理平台概述-tangzinan.pptx ( 2.51 MB ,311 downs )   
阿里“去IOE”实践-chenzhaoshan.pptx ( 1.47 MB ,290 downs )   
阿里数据同步前世今生-chenshouyuan.pptx ( 1.57 MB ,274 downs )   
大数据时代的月光宝盒-zhangmaosen.pptx ( 1.59 MB ,300 downs )   
分布式数据分析算法-yangxu2.pptx ( 1.01 MB ,291 downs )   
大众点评网高可用数据架构-lujunyi.pdf ( 302.2 KB ,271 downs )   
如何打造360 MySQL服务-yangting.pdf ( 1.57 MB ,270 downs )   
实时计算平台及相关业务实践-chaihua.pptx ( 236.78 KB ,244 downs )   
探索阿里数据藏宝图——数据地图管理实践-liuyingyao.pdf ( 1.64 MB ,297 downs )   
腾讯广点通的数据挖掘-xiaolei.pptx ( 2.08 MB ,273 downs )   
小公司的服务管理和监控成长之路-laiwei.pptx ( 1.78 MB ,289 downs )   
页面资源位监测和价值分析-zhaowenbo.pptx ( 6.13 MB ,245 downs )   
Cascadb TokuDB性能与适用场景分享-yigong.pptx ( 770.29 KB ,212 downs )   
Mysql高并发热点更新性能优化-liuhui.ppt ( 268.5 KB ,244 downs )   
开源软件的商业价值-michael.pdf ( 193.24 KB ,272 downs )   
CM–集群管理与负载均衡系统-sunquan.pptx ( 1020.42 KB ,226 downs )   
垂直抓取系统——EtaoSpider介绍-xiezhenliang.pptx ( 1.1 MB ,231 downs )   
个性化搜索技术和应用-chenxi.pptx ( 4.45 MB ,265 downs )   
关系搜索和推荐-ouwenwu.pptx ( 783.2 KB ,233 downs )   
海量商品的聚合技术及其在搜索中的应用-minghu.pptx ( 1009.46 KB ,240 downs )   
机器学习在搜索排序中的应用-zenganxiang.pptx ( 3.18 MB ,289 downs )   
搜索引擎和淘宝搜索不得不说的故事-zhengnan.pptx ( 1.05 MB ,265 downs )   
实时个性化系统和应用-linjianguo.pptx ( 1.09 MB ,233 downs )   
文本挖掘在电子商务场景中的应用-sunjian.pptx ( 3.17 MB ,262 downs )   
一站式搜索服务平台-Tsearcher-liuming.pptx ( 3.53 MB ,239 downs )   
Android设备体验优化-fengsenlin.pptx ( 1.06 MB ,274 downs )   
百度云推送介绍和架构分享-guozheng.pptx ( 3.73 MB ,283 downs )   
无线客户端数据实战-ninghaiyuan.pdf ( 8.49 MB ,272 downs )   
一个移动互联网技术创业的故事-haopeiqiang.ppt ( 8.58 MB ,302 downs )   
移动设备客户端安全-luojingjian.ppt ( 2.83 MB ,272 downs )

论坛徽章:
3
天秤座
日期:2013-12-27 13:44:58射手座
日期:2014-05-22 16:52:43天蝎座
日期:2014-08-13 16:03:21
68 [报告]
发表于 2014-10-23 16:19 |只看该作者
移动系统中的Java虚拟机-xuweigang.pptx ( 339.14 KB ,213 downs )   
如何有效控制Andoid应用的耗电量-qianjiajing.pptx ( 936.48 KB ,220 downs )   
Lua wax在ios上的应用-huwenjiang.pptx ( 469.03 KB ,186 downs )   
Hybrid组建实践-WindVane项目简述-yujia.pptx ( 4.53 MB ,218 downs )   
Android自动化测试-jiale.pptx ( 885.66 KB ,255 downs )   
ios客户端稳定性-yudong.pptx ( 1.61 MB ,231 downs )   
android app性能优化之list篇-huangkun.ppt ( 1.42 MB ,247 downs )   
OS客户端应用测试实践-chenxu.pptx ( 2.38 MB ,227 downs )   
Fault injection实现原理与应用-liguodong.pptx ( 1.48 MB ,212 downs )  
iOS WEB自动化测试方案的探索与实践-banjun.pdf ( 24.27 MB ,347 downs )   
更好更快的Android自动化测试-luxiaoyu.pptx ( 1.02 MB ,304 downs )   
建设持续交付组织-jinming.pdf ( 2.78 MB ,321 downs )   
数据质量中心的设计与实现-xiemin.pptx ( 1.89 MB ,296 downs )   
无线质量全过程保障实践-xiapeifang.pptx ( 4.24 MB ,293 downs )   
不写代码实现UI自动化测试-xiadawei.pptx ( 7.48 MB ,330 downs )   
多浏览器兼容性测试平台xbrowser剖析-lihaijing.ppt ( 1.32 MB ,267 downs )   
前端无痛质量方案探索-pangeng.pdf ( 6.18 MB ,280 downs )   
淘宝电子商务云应用安全-liyonghui.pptx ( 2.43 MB ,294 downs )   
淘宝网应用性能管理的原理和实践-fangfei.pptx ( 863.6 KB ,282 downs )   
iOS WEB自动化测试方案的探索与实践-banjun.pdf ( 24.27 MB ,347 downs )   
更好更快的Android自动化测试-luxiaoyu.pptx ( 1.02 MB ,304 downs )   
建设持续交付组织-jinming.pdf ( 2.78 MB ,321 downs )   
数据质量中心的设计与实现-xiemin.pptx ( 1.89 MB ,296 downs )   
无线质量全过程保障实践-xiapeifang.pptx ( 4.24 MB ,293 downs )   
不写代码实现UI自动化测试-xiadawei.pptx ( 7.48 MB ,330 downs )   
多浏览器兼容性测试平台xbrowser剖析-lihaijing.ppt ( 1.32 MB ,267 downs )   
前端无痛质量方案探索-pangeng.pdf ( 6.18 MB ,280 downs )   
淘宝电子商务云应用安全-liyonghui.pptx ( 2.43 MB ,294 downs )   
淘宝网应用性能管理的原理和实践-fangfei.pptx ( 863.6 KB ,282 downs )   下
性能持续集成的探索和实践-xuxiao.pptx ( 765.44 KB ,171 downs )   
TCPFLOW业务网络服务质量分析-zhuyouzhi.pdf ( 1.98 MB ,185 downs )   
高性能网关产品的设计与实践-wangxinpu.pdf ( 844.18 KB ,176 downs )   
海量未知木马机器分析-huangzheng.pptx ( 119.37 KB ,162 downs )   
深入理解CPU的读写及优化-maling.pdf ( 944.57 KB ,200 downs )   
自动化运维和数据化运维-从硬盘开始-liuyi.pdf ( 1.41 MB ,202 downs )   
跨平台体验融合-shengbo.ppt ( 11.55 MB ,185 downs )   
设计之外 我们还追求什么样的设计-chenyizhang.pdf ( 2.8 MB ,198 downs )   
数据可视化设计-cuizhiwei.pdf ( 5.92 MB ,212 downs )   
Golden Age Of RTB-shengxuehua.pdf ( 1.58 MB ,169 downs )   下
Tanx业务发展及系统架构-suning.pdf ( 4.75 MB ,180 downs )

论坛徽章:
3
天秤座
日期:2013-12-27 13:44:58射手座
日期:2014-05-22 16:52:43天蝎座
日期:2014-08-13 16:03:21
69 [报告]
发表于 2014-10-23 16:20 |只看该作者
阿里广告中的机器学习平台-jianglong.pdf ( 1.17 MB ,191 downs )   
个性化推荐技术在广告中的应用-zhaobinqiang.pdf ( 1.06 MB ,172 downs )   
淘宝联盟前端引擎技术发展-kejie.pdf ( 2.51 MB ,178 downs )   
时间-兴趣耦合的IPTV用户收视模型-zhangya.pdf ( 989.82 KB ,161 downs )   
搜索广告触发的挑战和应用-huyunhua.pdf ( 1006 KB ,150 downs )   
淘宝DMP平台-xucheng.pdf ( 1019.18 KB ,152 downs )   
实时定向广告技术-DSP框架及算法-lijunliang.pdf ( 1.46 MB ,176 downs )   
广告中的Match新架构和CVR预估-liuhualei.pptx ( 202.11 KB ,141 downs )   
广告引擎的索引设计实现和性能优化-liuyichuan.ppt ( 777.5 KB ,151 downs )   
canal产品介绍-loujianghang.ppt ( 1.47 MB ,178 downs )   
Druid数据库连接池介绍-wenshaojing.pptx ( 363.72 KB ,153 downs )   
Dubbo开源-liangfei.pptx ( 3.2 MB ,180 downs )   
Fastjson介绍-wenshaojing2.pptx ( 154.58 KB ,156 downs )   
Introduction to KISSY-heyiming.pdf ( 726.9 KB ,151 downs )   
MySQL复制-zaiweixiang.pptx ( 408.59 KB ,161 downs )   
OceanBase介绍-yangchuanhui2.pptx ( 1.08 MB ,168 downs )   
tengine介绍-yaoweibing2.pptx ( 4.08 MB ,180 downs )   
Tsar介绍-like.pptx ( 2.36 MB ,169 downs )   
OpenStack Summit Intel Efforts-wangqing.pdf ( 1.88 MB ,186 downs )   
纠错码技术在hadoop分布式文件系统的应用-jinjun.pdf ( 1.32 MB ,197 downs )   
利用固态硬盘解决存储瓶颈-nijingfeng.pdf ( 2.19 MB ,217 downs )

论坛徽章:
3
天秤座
日期:2013-12-27 13:44:58射手座
日期:2014-05-22 16:52:43天蝎座
日期:2014-08-13 16:03:21
70 [报告]
发表于 2014-10-23 16:20 |只看该作者
本帖最后由 compare2000 于 2014-10-23 16:27 编辑

大家都很关心电软转型的机会和挑战,目前能看到有IoT、互联网金融、能力中心,而这些机会的核心还是基于数据资产的运营。感觉现在即使机会摆在我们面前,我们也未必能抓住,因为还没看清支撑这些机会的平台和架构。运营商还有哪些领域可以涉足,是不是该有个面向互联网、面向数据运营的OS,具体的技术和平台有哪些,


讨论输入:

1、IoT(健康医疗、智能家居、车联网、家电数字化)
1)关注对象:
google:android auto,android wear,android TV,Google Fit
apple:homekit、healthkit、car play
海尔、三星:数字家电
微信:社交融合智能家居
2)关键信息
行业动态、业务战略、商业模式、业务场景、方案&架构


2、中小企业数字化(公有云、能力中心)
1)关注对象:
IBM Bluemix、APIGee、阿里云
2)关键信息
战略布局、商业模式、生态系统、平台架构、相关技术


3、互联网金融
1)关注对象
阿里:支付宝、余额宝
联通:话费宝
电信:添益宝
银联:二维码支付技术
NTTDOCOMO:手机钱包(做的最好的移动支付、拓展到了信用卡、海外转移支付等业务)
2)关键信息
行业分析、商业模式、供应商、解决方案、功能架构、相关技术


4、电商(B2C、商场数字化使能)
1)关注对象
微信、微软/google/apple室内定位、NTTDOCOMO的dshop(全球运营商做的最好的电商)
2)关键信息
商业模式、生态系统、功能架构、相关技术


5、颠覆性商业模式、创新公司和技术——
C2B(尚品宅配,阿里很推崇的柔性制造)
Luvocracy,电商中间件
surf air,航空短途月票服务
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP