Aqui esta uma pequena estatística de onde o código sofreu mais mudanças desde a versão .25:
4.9% arch/arm/
9.0% arch/powerpc/configs/
11.8% arch/powerpc/
28.7% arch/
5.0% drivers/media/video/
9.2% drivers/media/
5.5% drivers/net/sk98lin/
6.6% drivers/net/wireless/
17.8% drivers/net/
4.8% drivers/s390/net/
5.3% drivers/s390/
49.7% drivers/
6.4% include/
5.1% net/
Como podem ver, metade foi na parte de drivers mesmo, com destaque para a parte de wireless, a remoção do driver sk98lin (obsoleto) e bastante coisa na parte de vídeo (V4L).
A grande mudança no diretório Arch se deve a ports do KVM, suporte a PAT (Page Attribute Table) no x86, o KGDB e a implementação do semáforo genérico que veio para substituir os específicos de cada arquitetura e reduzir a repetição de código (e COMO reduziu).
Apenas lembrando que isso são as maiores porcentagens de milhares de linhas de códigos alteradas/modificas/removidas, então nem pensem que somente isso foi trabalhado =]
Agora vamos ao resumo das novidades (aka Cool Things) do KernelNewbies:
1 - Support for read-only bind mounts:
Since 2.4.0 Linux has supported bind mounts. Bind mounts are a sort of directory symlinks that allow to share the contents of a directory in two different paths. For example, "mount --bind /foo /bar" will "bind" the contents of /foo not only to /foo, but also /bar. IOW, /foo and /bar would have the same content - and any modification in one directory is visible in the other. This has been useful for things like chroots or ftp/webservers, but until now, if /foo was writable, there was no way to stop /bar from being also writable.
In Linux 2.6.26, you can make those bind mounts read-only. If we made the bind mount in the previous example read-only, the contents of /foo would show up in /bar - but an application trying to modify a file in /bar will not be able to do it (/foo could continue being writable, of course). This has a number of uses. It allows chroots to have parts of filesystems writable. It's useful for containers because users may have root inside a container, but should not be allowed to write to some filesystems. It allows security enhancement by making sure that parts of your filesystem read-only (such as when you don't trust your FTP server), when you don't want to have entire new filesystems mounted, or when you want atime selectively updated.
(The current implementation does not allow to make a bind mount directly read-only: you need to make the bind mount first - mount --bind /foo /bar - and then remount the bind as ro - mount -o remount,ro /bar)
Recomendado: http://lwn.net/Articles/281157/
2 - x86 PAT (Page Attribute Tables):
PAT (Page Attribute Table) is a feature found in x86 processors that allows for setting the memory attribute at the page level granularity. PAT is complementary to the MTRR settings which allows for setting of memory types over physical address ranges. However, PAT is more flexible than MTRR due to its capability to set attributes at page level and also due to the fact that there are no hardware limitations on number of such attribute settings allowed. It's not a very new feature: the Linux support for this has been in the works for a long time: the current patches are evolved from ones started in 2006, and there're traces of preliminary patches in 2001. Probably because it's not a critical feature and MTRRs did the job.
3 - PCI Express ASPM (Active State Power Management)
4 - Ports of KVM to IA64, S390 and PPC:
KVM, the virtualization solution included in Linux 2.6.20, has been rearchitected to give support to architectures other than x86: IA64 (Itanium), S390 and PPC
5 - Other KVM improvements including basic paravirtualization support
6 - Preliminar support of the future 802.11s wireless mesh standard
A year ago, in Linux 2.6.22, Linux included a new wireless stack. In 2.6.26 that stack is adding support for the draft of wireless mesh networking (802.11s), thanks to the open80211s project (http://www.open80211s.org/)
7 - Much improved webcam support thanks to a driver for UVC devices
2.6.26 inclues a driver that supports video input devices compliant with the USB Video Class specification (http://en.wikipedia.org/wiki/USB_video_device_class). This means lots of currently manufactured webcams (http://linux-uvc.berlios.de/#devices), and probably most of the future ones
8 - Built-in memory tester
Memtest is a commonly used tool for checking your memory. In 2.6.26 Linux is including his own in-kernel memory tester. The goal is not to replace memtest, in fact this tester is much simpler and less capable than memtest, but it's handy to have a built-in memory tester on every kernel. It's enabled easily with the "memtest" boot parameter.
9 - Kernel debugger (KGDB)
For many years Linux has not included a kernel debugger. Linus Torvalds vetoed them for years, for reasons that he explained quite well in a know email: "When things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger [...] I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_."
Despite of those objections, many people wanted a debugger and KGDB is finally going in. It's a remote debugger, it needs two machines. x86 and sparc machines are supported
10 - BDI statistics and parameters exposure in /sys/class/bdi
Linux 2.6.24 merged per-device dirty thresholds: The limits that the kernel put to the amount of memory that a process can "dirty" changed from being global to be per-device. 2.6.26 exposes a interface in /sys/class/bdi that allow to set several parameters. There's another set of read-only parameters that are exposet in debugfs (debug/bdi//stats)
11 - New /proc/PID/mountinfo file for more accurate information about mounts
The work being done these days in the VFS like per-process namespaces and such is obsoleting some things, like /proc/mounts (which is always a link to /proc/self/mounts). In its current form lacks important information and suffers some problems (see the code link). 2.6.26 introduces /proc/PID/mountinfo which addresses these deficiencies. Information about the information that can be found on these new files is explained in the commit links.
12 - Per-process securebits
Filesystem capability support makes it possible to do away with (set)uid-0 based privilege and use capabilities instead. That is, with filesystem support for capabilities but without this present feature, it is (conceptually) possible to manage a system with capabilities alone and never need to obtain privilege via (set)uid-0. Of course, conceptually isn't quite the same as currently possible since few user applications, certainly not enough to run a viable system, are currently prepared to leverage capabilities to exercise privilege. Further, many applications exist that may never get upgraded in this way, and the kernel will continue to want to support their setuid-0 base privilege needs. Where pure-capability applications evolve and replace setuid-0 binaries, it is desirable that there be a mechanisms by which they can contain their privilege. In addition to leveraging the per-process bounding and inheritable sets, this should include suppressing the privilege of the uid-0 superuser from the process' tree of children. The feature added in 2.6.26 can be leveraged to suppress the privilege associated with (set)uid-0. This suppression requires CAP_SETPCAP to initiate, and only immediately affects the 'current' process (it is inherited through fork()/exec()). This reimplementation differs significantly from the historical support for securebits which was system-wide, unwieldy and which has ultimately withered to a dead relic in the source of the modern kernel.
Recomendado: http://lwn.net/Articles/280279/
13 - Device white-list for containers users
This feature implements a functionality wanted by some virtualization users: The ability to control the access to devices in a per-container basis. A cgroup is used to track and enforce open and mknod restrictions on device files. More details can be found in the commit link.
Recomendado: http://lwn.net/Articles/273822/
14 - Support for the OLPC
15 - Some new drivers and many small improvements
Para ver um resumo mais completo das mudanças, recomendo ver:
http://kernelnewbies.org/Linux_2_6_26
(Pois o change-log inteiro é looooooongo)
Nenhum comentário:
Postar um comentário