linux 3.14？debian centos

大家好,今天小编来为大家解答以下的问题，关于linux 3.14，debian centos这个很多人还不知道，现在让我们一起来看看吧！

怎样查看linux单板操作系统类型

使用的Linux内核源代码版本是3.14.12（最新是3.14.16了），是比较新的版本，而且3.14也是一个会长期维护的版本。由内核源代码到生成内核，需要首先进行配置，自己喜欢并常用的方法是：make menuconfig。因为试图生成一个最小的内核，所以就选择尽量少的配置。没有料到的是在这里费了很长的时间。

首先，加载启动生成的内核时，没有任何显示！就是说，在u-boot打印出信息：Starting kernel...后，屏幕上再无任何输出。

这里需要简单介绍一下Beaglebone Black单板的输出。它有一个micro HDMI，这个经过转换后，连接到所用的SOC AM3358上的图形显示卡（可直接驱动LCD）上。很显然，这个输出不适合开发过程中使用，因为它依赖比较复杂的驱动程序。单板机通常有JTAG接口，可以用来显示输出，也可以用来调试单板机的运行。这个比较偏向硬件，可能是硬件工程师喜欢的方式。对于我来讲，使用串口进行输入输出是比较合适的方式。串口的电路和驱动都比较简单，适合做最初的开发使用。AM3358有6个串口(UART0~ UART5)，Beaglebone black将UART 0的管脚直接接了出来，总共六根。因为SOC工作在TTL电压（3.3V），接口没有在电气物理层面上做转换使之符合RS232的要求，所以不能直接连接任何设备的串口，比如PC机的串口。好在市场上存在这种USB转串口的，接口为TTL 3.3V的连接线，通过它，可以将这个串口直接连接至PC机的USB端口。

在LINUX PC上，用minicom终端软件，通过USB转RS232的设备，可以对Beaglebone black的启动过程进行监测，并可以做交互。

内核启动后，没有观测到任何输出，这是一个比较棘手的问题，因为没有任何信息可供参考判断。内核启动的第一步，首先是将内核解压到一个固定的物理地址开始的区域，在TI的SOC上，一般这个地址是0x8000 8000，因为TI的ARM架构的SOC，内存开始地址通常为0x8000 0000。在过去版本的正常启动里，解压开始和结束，会输出“Uncompressing Linux... done, booting the kernel.”。如何知道究竟运行到了哪里？为什么出错？

好在单板机上，一般都有几个led显示管，通过写入一个内存区域的二进制位，来点亮它。那么可以找到驱动某个led的物理地址，在内核设置并启用虚拟内存机制之前，直接在对应的地址位写1来点亮某个led。启用虚拟地址机制后，就无法如此操作，因为不知道这个物理地址对应的虚拟地址是什么，甚至都不知道这个地址的对应关系是否已经建立。不过，至少在虚拟地址机制开启前，可以通过这个方式来查找内核启动过程是否走过了某一段。很不幸的是，使用这种方式，验证了内核已经正确执行到了开始启用虚拟内存的地方。如果虚拟内存机制设置完毕，就会跳转到内核"start_kernel"这个函数，它是一个C程序。由此开始，内核就基本上是在执行C语言的代码了！

为什么解压缩完成却没有输出“Uncompressing Linux... done, booting the kernel.”？原来是使用了设备描述树来创建设备的内核，在开始阶段（读取并分析设备描述树之前），并没有创建任何串口设备。如果是在开始就创建并使用这些设备，那么就是又回到用静态变量来存储设备和驱动的老做法了！所以使用Device Tree Blob来指定设备的内核，在启动开始的解压缩阶段，再也无法输出类似的信息了！

既然是通过设备描述树来指定设备，那么也许要查看一下设备描述树的源文件，看看那里对uart0是如何描述的。通过查看"am335x-boneblack.dts"文件和它所包含的文件，发现uart0启用时，需要用"pinctl-single"这个管脚复用的驱动来设置管脚。在内核配置文件里，有选择这个驱动的选项，但是因为我追求最小内核，所以没有选用它！重新配置内核选项，选中这个驱动，内核启动的输出就正常了！

这里顺带解释一下管脚复用。SOC芯片，一般都集成了CPU和其它很多外设，例如串口控制器，USB控制器，等等。芯片输出的管脚，不能完全将所有的外设连接都输出，这样就存在多个外设信号连接到一个管脚的现象。例如串口0的RX信号，和I2C 2的SDA信号，还有其它6种信号，共用一个管脚！如果需要将这个管脚设置为做串口0的RX信号，就需要在一个内存地址（寄存器）里写入0，如果需要它做为I2C 2的SDA，需要写入3。管理这种复用的驱动程序，最简单的那种（每个管脚配置占用四个字节），叫pinctl-single。之前内核不能输出信息，就是因为没有配置选中这个驱动。

内核启动完成，最后加载一个内存根文件系统，并尝试执行根目录下的init程序。这个初始根文件系统的内容是最简单和常用的命令。用klibc和busybox的生成结果，充当这个文件系统的内容，是最常用的做法。内存文件系统（非内存块设备）和内核初始根文件系统，是LINUX里的发明，降低了内核复杂度的同时，增加了灵活性！

内核启动完成，执行klibc的SHELL（sh.shared）后，却发现内核没有识别到MMC卡（或是4GB的eMMC）！根据内核启动过程的输出提示，发现是加载对应MMC的电源驱动失败。还是查找设备描述树源文件，发现Beaglebone black的mmc使用一个最简单的电源驱动：regulator-fixed。而内核配置里，漏掉了这个驱动。又是最求最小内核配置惹的祸！重新配置并选中这个驱动，现在看起来一切正常。

到此为止，一个小的系统就诞生了。它运行在Beaglebone black的板子上，MMC卡，USB和网卡都可以使用用。当然这还是一个比较小的配置，以后根据需要，可能还需要追加必要的驱动。下一步就是开始编译生成系统的各种程序了。首当其冲的就应该是"systemd"，它是最新的，也是最流行的，替代过去UNIX/Linux INIT的程序。

用软件lmsensors监测Linux系统和CPU温度

lm_sensors的软件可以帮助我们来监控主板，CPU的工作电压，风扇转速、温度等数据。这些数据我们通常在主板的 BIOS也可以看到。当我们可以在机器运行的时候通过lm_sensors随时来监测着CPU的温度变化，可以预防呵保护因为CPU过热而会烧掉。

1.安装lm_sensors

现在基本上每个Linux都已经有lm_sensors包了，我们主要安装了就可以了。或者我们也可以通过源文件来自己编译。

1)在FC，RH， CENTOS下，用rpm：

[root@securitycn~]# rpm-ivh lm_sensors-2.10.0-3.1.i386.rpm

3)编译源文件安装

我们可以通过:这里下载源文件

这里我们要注意的问题是要先安装libsysfs库，是Sysfsutils，Sysfsutils-devel软件

tar xzvf lm-sensors-xxx.tar.gz

make user

make user_install testing

下面我们就用一些简单的命令来利用lm_sensors来得到CPU的数据。我们要用root的身份来：

sensors-detect，然后它会自动搜索主板上的chipset和相应的driver，我们全部答YES就可以了

[root@securitycn~]# sensors-detect

# sensors-detect revision 1.413(2006/01/19 20:28:00)

This program will help you determine which I2C/SMBus modules you need to

load to use lm_sensors most effectively. You need to have i2c and

lm_sensors installed before running this program.

Also， you need to be `root'， or at least have access to the/dev/i2c-*

files， for most things.

If you have patched your kernel and have some drivers built in， you can

safely answer NO if asked to load some modules. In this case， things may

seem a bit confusing， but they will still work.

It is generally safe and recommended to accept the default answers to all

questions， unless you know what you're doing.

We can start with probing for(PCI) I2C or SMBus adapters.

You do not need any special privileges for this.

Do you want to probe now?(YES/no):

全部默认YES即可。

然后我们启动lm_sensors：

/etc/init.d/lm_sensors start

Starting lm_sensors: [ OK ]

我们可以通过lsmod来确定我们需要的driver已经加载了没有

lsmod| grep i2c

i2c_isa 9153 2 w83627hf，w83781d

i2c_i801 11341 0

i2c_dev 12613 0

i2c_ec 9025 1 sbs

i2c_core 23745 6 w83627hf，w83781d，i2c_isa，i2c_i801，i2c_dev，i2c_ec

然后我们用sensors的命令就可以了：

[root@securitycn~]# sensors

w83627hf-isa-0290

Adapter: ISA adapter共2页。

VCore 1:+3.33 V(min=+0.00 V， max=+0.00 V) ALARM

VCore 2:+3.36 V(min=+0.00 V， max=+0.00 V) ALARM

+3.3V:+0.93 V(min=+3.14 V， max=+3.46 V) ALARM

+5V:+5.11 V(min=+4.73 V， max=+5.24 V)

+12V:+4.56 V(min=+10.82 V， max=+13.19 V) ALARM

-12V:-7.10 V(min=-13.18 V， max=-10.88 V) ALARM

-5V:-1.93 V(min=-5.25 V， max=-4.75 V) ALARM

V5SB:+5.51 V(min=+4.73 V， max=+5.24 V) ALARM

VBat:+0.02 V(min=+2.40 V， max=+3.60 V) ALARM

fan1: 0 RPM(min= 2732 RPM， div= 2) ALARM

fan2: 0 RPM(min= 0 RPM， div= 2)

fan3: 0 RPM(min= 0 RPM， div= 2)

temp1:+38癈(high=+50癈， hyst=+45癈) sensor= thermistor

temp2:+33.5癈(high=+80癈， hyst=+75癈) sensor= thermistor

temp3:+33.5癈(high=+80癈， hyst=+75癈) sensor= thermistor

vid:+0.000 V(VRM Version 10.0)

alarms:

beep_enable:

Sound alarm enabled

这里我们可以看到温度还没有相对应CPU，我们主要稍微修改一下/etc/sensors.conf就可以了，不过其实都不用我们自己去动手，一般我们都可以从主板生产商那里下载到配置文件。通过lmsensors我们就可以得到主板温度，CPU电压，风扇转速这些信息。我们可以根据这些数据来监察系统的运行情况来预防系统的问题。

接下来让它和MRTG整合在一起吧

[root@securitycn~]# cd/usr/local/mrtg/bin

[root@securitycn~]# vi temp.sh

#内容如下

#!/bin/bash

cputemp=`/usr/bin/sensors| grep temp1|awk'{print$2}'|cut-c 2-4`#这句是说找出有temp1那一行，印出第二个列的2-4个字

systemp=`/usr/bin/sensors| grep temp2|awk'{print$2}'|cut-c 2-5`不用解释了吧

echo$cputemp

echo$systemp

# the uptime

uptime| sed's:^.* up\(.*\)， [0-9][0-9]* users.*$:\1:'

# my name

uname-n

[root@securitycn~]# chmod+x temp.sh改成可执行

[root@securitycn~]#./temp.sh试试看有没有问题

39

33.5

15:36:19 up 22:28， 1 user， load average: 0.04， 0.09， 0.04

securitycn

再来写下面的文件

[root@securitycn~]# cd../etc/

[root@securitycn~]# vi temp.cfg

WorkDir:/data1/usr/apache/htdocs/mrtg/temp/

Target[index]: `/usr/local/mrtg/bin/temp.sh`

MaxBytes[index]:80

Options[index]: gauge， nopercent， growright

YLegend[index]: Temp(度)

ShortLegend[index]:度

LegendO[index]:系统温度;

LegendI[index]: CPU温度;

Title[index]:系统温度表

PageTop[index]:

主机温度表

[root@securitycn~]#/usr/local/mrtg/bin/mrtg/usr/local/mrtg/etc/temp.cfg

执行3次就不报错了

然后加入到crontab里面

*/5****/usr/local/mrtg/bin/mrtg/usr/local/mrtg/etc/temp.cfg共2页。

一文读懂Linux系统的write调用

本文旨在澄清Linux系统中的write调用特性。许多人对write调用的原子性存在疑问，本文将通过实例和分析给出答案。

首先，明确一点，write调用并不能保证整个写操作是原子的。以写入512字节的缓冲区到文件为例，Linux内核并不能确保这个操作在单次调用中顺利完成，因为存在一些不可忽视的因素。尽管如此，write设计的初衷是考虑到系统的复杂性和安全性，它保证的是在共享文件描述符的上下文中，每个write调用在写入数据时是原子且不可中断的，即线程或进程之间的写入顺序不会交错。

当两个独立进程分别对文件进行写入，如进程A写'a'，进程B写'b'，结果可能为'aaabbb'或'bbbaaa'，而非交错。若希望避免交错，需要在打开文件时使用O_APPEND模式。

write调用的原子性保障主要局限于共享文件结构的范围，而非独立文件。在多线程或多进程共享文件时，用户程序需要自行处理短写问题，例如使用锁保护，以确保写入完整。

一些关键应用，如Apache和Nginx的日志记录，通过使用APPEND模式来保证独立的原子写入。然而，即便有这些保证，我自己的一个分析TCP数据包程序实例中，尽管理论上应保证原子性，但有时仍会发现数据包信息被覆盖，这提示了潜在的问题。

在深入调查后，我发现了write调用在3.10社区版内核中存在race条件。通过分析代码，我发现了一个在1和2或者2和3之间可能发生并发问题的场景。通过加载特定模块和调整操作，我成功重现了问题，验证了write调用的原子性在此版本中并未得到充分保证。

幸运的是，这个问题在3.14以后的内核版本中已被修复。通过查阅文档和源码，我发现该问题早在那时就已经被注意到并修复。从这个经历中，我们学习到在遇到问题时，查阅文档比直接分析代码可能更有效率。

最后，虽然2.6.32内核在理论上也存在相同问题，但在Centos这样的稳定版内核中，这些问题通常会被修复，从而避免了实际问题的出现。