pages tagged linuxThadeu Lima de Souza Cascardohttps://cascardo.eti.br/tags/linux/Thadeu Lima de Souza Cascardoikiwiki2019-10-31T22:08:11ZOverriding ACPI tables on Debianhttps://cascardo.eti.br/blog/Overriding_ACPI_tables_on_Debian/2019-10-31T22:08:11Z2019-10-31T22:08:11Z
<p>Linux supports overriding your computer ACPI tables by adding updated tables to
the initrd. Checkout your local documentation at the linux tree at
Documentation/admin-guide/acpi/initrd_table_override.rst.</p>
<p>I just uploaded to Debian a small initramfs-tools hook to add tables found at
/var/lib/acpi-override/ to the initrd. For now, it's all that it does. The
users have to modify the tables themselves and drop them at the referred
directory.</p>
<p>It should be on the NEW queue and out to unstable after some time, and it's
maintained at <a href="https://salsa.debian.org/cascardo/acpi-override">salsa</a>.</p>
<p>My usecase for this is a small change to the DMAR table of my Libreboot-enabled
X200, so I can experiment with IOMMU on it.</p>
<p>As future work, I may consider a tool to help at least update the OEM revision
of the tables, to make it less error-prone to users to update them.</p>
<p>I hope this is useful to other people.</p>
Stable TSC on X200https://cascardo.eti.br/blog/Stable_TSC_on_X200/2019-03-03T12:32:48Z2019-03-03T12:32:48Z
<p>I got a Thinkpad X200 running Libreboot. It uses an Intel CPU that has a
TSC (Time Stamp Counter), which allows software to count the passage of
time by the number of cycles. It's a 64-bit counter that used to count
the number of CPU cycles. With CPUs changing clocks to save power, new
CPUs (more than a decade old as shown by my X200) support a constant TSC
that runs under a different clock whose tick duration is constant. This
is supported by the X200 processor I have, and Linux will show it as
constant_tsc on /proc/cpuinfo.</p>
<p>However, Linux won't use the TSC as its clock source if it's marked
unstable, and it is by idle drivers in certain circumstances. The idle
driver changes CPU power states and that may stop the TSC from ticking,
unless the processor has an Invariant TSC, what Linux calls nonstop_tsc
(at /proc/cpuinfo). That is not the case of my processor, so the idle
drivers will mark the TSC as unstable unless they are not loaded or
won't change states.</p>
<p>In order to do the latter, the ACPI driver (the one that ends up being
used because the intel_idle does not support my processor), one needs to
add processor.max_cstate=0 to the command line. That will likely save
less power, which will cause the X200 to consume battery power faster.
But for some of the experiments I have been running with KVM and the
TSC, that is a trade-off I need to pay.</p>
GNU libc and Linuxhttps://cascardo.eti.br/blog/GNU_libc_and_Linux/2016-09-01T11:34:13Z2016-09-01T11:34:13Z
<p>Some time ago, I built a static program that I wanted to run on an
Android tablet. What was my surprise when I saw a message saying
"FATAL: kernel too old".</p>
<p>After some investigation, it turns out that GNU libc may assume some
Linux features are present during build time. This means that given a
minimum Linux version, that built libc might only work on that version
or newer.</p>
<p>Since 2014, GNU libc itself requires 2.6.32 as the minimum. Previously,
it was 2.6.16, changed in 2012.</p>
<p>Debian, as of 2015, builds it with a required minimum Linux version of
3.2.</p>
<p>To give an idea about the history of these kernel releases, we have:</p>
<ul>
<li>December 2009, Linus releases Linux 2.6.32.</li>
<li>November 2010, Red Hat releases RHEL 6.0, Linux 2.6.32.</li>
<li>February 2011, Debian 6.0 Squeeze, Linux 2.6.32.</li>
<li>January 2012, Linus releases Linux 3.2.</li>
<li>April 2014, GNU Libc requires Linux 2.6.32.</li>
<li>December 2015, Debian GNU Libc uploaded to unstable requires Linux 3.2.</li>
</ul>
<p>So, at least for GNU libc upstream, it would appear that not many
devices would stop being supported, though the situation would not be as
good for binary versions of Debian. However, I have a small list of
devices that might show otherwise.</p>
<ul>
<li>Nokia N900 shipped with Linux 2.6.28.</li>
<li>Android emulator, a platform called Goldfish, uses Linux 2.6.29.</li>
<li>The Wii port most widely tested is based on Linux 2.6.32.</li>
</ul>
<p>Many Android devices have been shipped with Linux 3.4, but I encountered
at least one using Linux 3.0.</p>
<p>So, even though many new devices ship with newer versions of Linux, it's
still possible to find some new and older devices using versions older
than 3.2, and even versions older than 2.6.32 may be found.</p>
<p>Another interesting note is that, without a few patches, it's not
possible to build Linux 2.6.32 with GCC 5 and newer. For that and many
other reasons, it's important that we update. For bug fixes, and so we
can make progress and use better software are some of the other reasons.</p>
<p>So, it's imperative that we have devices support upstream. Otherwise,
the task of doing updates with forward porting becomes daunting. And
that's the current state for many devices, which is why I have been
trying to use new software with older versions of Linux. But as time
passes, I realize how hard a task this is, as most new software these
days, even a building block like GNU libc, requires ever new versions of
Linux.</p>
<p>For now, most gadgets I have support Linux 3.4 or newer. But not long
ahead, that support will be dropped as well. And that means there will
be no more updates for those devices. It's a consequence of both
targeting time-to-market and programmed obsolescence as business
practices. Upstream support is no priority, and maintenance is only that
required until the next model is available on the stores.</p>
<p>This is one more reason why we need to have more operating systems
available for those devices. Systems that are designed to last more than
a couple of years. As I said, upstream support is imperative, but as a
step forward, I still believe we can provide the GNU experience to lots
of devices out there.</p>
Debian on old Linux versionshttps://cascardo.eti.br/blog/Debian_on_old_Linux/2016-07-03T02:18:00Z2016-07-03T02:18:00Z
<p>On recent posts, I mentioned that I have a Chromebook, and that I would
like to run Debian on devices that ship with old Linux versions. The
Samsung ARM Chromebook is such a device, it has Linux 3.4, and that's
still what I am running on it most of the time.</p>
<p>After an upgrade of Debian, systemd stopped working, and it took me some
time before I could look into it. In order to boot, I had to temporarily
use System V init. The bug involves the use of new interfaces, bugs in
such interfaces, and how versioning would not be a solution to such
cases. Cases like this are not common, so it's no excuse to doing the
right thing when developing software, like considering portability, API
and ABI maintenance and not bundle. But they expose some of the
challenges when trying to support different OSes on top of old versions
of Linux, or maybe even new versions.</p>
<p>The new version of systemd included in Debian Jessie uses a feature of
Linux of checking the mount ID of a file by inspecting the mnt_id line
in the fdinfo files. fdinfo files are not that new, they have been
present since 2007, Linux 2.6.22. The mnt_id line, however, is from
Linux 3.15, from 2014. So, a fairly new feature. But systemd falls back
to other methods if the feature is not present.</p>
<p>However, during the last few weeks of development of Linux 3.4, a bug
was introduced to fdinfo handling, which will cause its access to fail
in a way that will cause systemd to halt. It simply will refuse to mount
the most basic filesystems and not proceed. The bug was fixed not much
longer than two weeks after that, but that window of time was enough to
have it on a shipped product, one that was not using systemd, let alone
one that required a feature not yet present on Linux.</p>
<p>But now I wanted to run this new systemd on this old Linux version.
Being too early in the boot process, systemd even ignored some of the
debug options and I had to resort to other methods of debugging. As I am
running a kernel I built by myself, it wasn't hard for me to have a
fixed kernel up and running after I found out the problem.
Unfortunately, not everyone will be able to do it by themselves. And the
point of getting different OSes working on these many varied devices is
scaling. If every device needs to be tested, we lose this scalability.</p>
<p>The other problem I found was that this old Linux version didn't load
firmware files by itself, and requested help from userspace, which used
to be the job of udev. Well, udev now does not support loading firmware,
and the kernel must do it by itself. I managed to backport that feature
too. But now, it sounds like I should get upstream support for this
device.</p>
<p>Unfortunately, this means not working on the scalability problem, but
going back to get upstream support for a lot of devices out there, which
is very hard to scale without the necessary people to do the work. I am
certainly going to do that, because it's the right thing to do. But not
as many people will benefit from that.</p>
<p>But I think it has been interesting to look into the possible problems
we might find when trying to make Debian and other OSes working on old
Linux versions. I know even older Debian versions won't boot fine on
Linux 2.6.32, one of the LTS versions of Linux. I have one other device
which runs on it, and I am also working on getting better upstream
support for it. Let's see if I can get some news on that soon.</p>
Chromebook Trackpadhttps://cascardo.eti.br/blog/Chromebook_Trackpad/2016-05-14T15:26:51Z2016-05-14T15:26:51Z
<p>Three years ago, I wanted to get a new laptop. I wanted something that
could run free software, preferably without blobs, with some good amount
of RAM, good battery and very light, something I could carry along with
a work laptop. And I didn't want to spend too much. I don't want to make
this too long, so in the end, I asked in the store anything that didn't
come with Windows installed, and before I was dragged into the Macbook
section, I shouted "and no Apple!". That's how I got into the Chromebook
section with two options before me.</p>
<p>There was the Chromebook Pixel, too expensive for me, and the Samsung
Chromebook, using ARM. Getting a laptop with an ARM processor was
interesting for me, because I like playing with different stuff. I
looked up if it would be possible to run something other than ChromeOS
on it, got the sense that is, it would, and make a call. It does not
have too much RAM, but it was cheap. I got an external HD to compensate
for the lack of storage (only 16GB eMMC), and that was it.</p>
<p>Wifi does require non-free firmware to be loaded, but booting was a nice
surprise. It is not perfect, but I will see if I can get to that another
day.</p>
<p>I managed to get Fedora installed, downloading chunks of an image that I
could write into the storage. After a while, I backed up home, and
installed Debian using debootstrap.</p>
<p>Recently, after an upgrade from wheezy to jessie, things stopped
working. systemd would not mount the most basic partitions and would
simply stop very early in the boot process. That's a story on my backlog
as well, that I plan to tell soon, since I believe this connects with
supporting Debian on mobile devices.</p>
<p>After fixing some things, I decided to try libinput instead of synaptics
for the Trackpad. The Chromebook uses a Cypress APA Trackpad. The driver
was upstreamed in Linux 3.9. The Chrome OS ships with Linux 3.4, but had
the driver in its branch.</p>
<p>After changing to libinput, I realized clicking did not work. Neither
did tapping. I moved back to synaptics, and was reminded things didn't
work too well with that either. I always had to enable tapping.</p>
<p>I have some experience with input devices. I wrote drivers, small
applications reacting to some events, and some uinput userspace drivers
as well. I like playing with that subsystem a lot. But I don't have too
much experience with multitouch and libinput is kind of new for me too.</p>
<p>I got my hands on the code and found out there is libinput-debug-events.
It will show you how libinput translates evdev events. I clicked on the
Trackpad and got nothing but some pointer movements. I tried evtest and
there were some multitouch events I didn't understand too well, but it
looked like there were important events there that I thought libinput
should have recognized.</p>
<p>I tried reading some of libinput code, but didn't get too far before I
tried something else. But then, I had to let this exercise for another
day. Today, I decided to do it again. Now, with some fresh eyes, I
looked at the driver code. It showed support for left, right and middle
buttons. But maybe my device doesn't support it, because I don't
remember seeing it on evtest when clicking the Trackpad. I also
understood better the other multitouch events, they were just saying how
many fingers there were and what was the position of which one of them.
In the case of a single finger, you still get an identifier. For better
understanding of all this, reading Documentation/input/event-codes.txt
and Documentation/input/multi-touch-protocol.txt is recommended.</p>
<p>So, in trying to answer if libinput needs to handle my devices events
properly, or handle my device specially, or if the driver requires
changes, or what else I can do to have a better experience with this
Trackpad, things were tending to the driver and device. Then, after
running evtest, I noticed a BTN_LEFT event. OK, so the device and driver
support it, what is libinput doing with that? Running evtest and
libinput-debug-events at the same time, I found out the problem.
libinput was handling BTN_LEFT correctly, but the driver was not
reporting it all the time.</p>
<p>By going through the driver, it looks like this is either a firmware or
a hardware problem. When you get the click response, sound and
everything, the drivers will not always report it. It could be pressure,
eletrical contact, I can't tell for sure. But the driver does not check
for anything but what the firmware has reported, so it's not the driver.</p>
<p>A very interesting I found out is that you can read and write the
firmware. I dumped it to a file, but still could not analyze what it is.
There are some commands to put the driver into some bootloader state, so
maybe it's possible to play with the firmware without bricking the
device, though I am not sure yet. Even then, the problem might not be
fixable by just changing the firmware.</p>
<p>So, I left with the possibility of using tapping, which was not working
with libinput. Grepping at the code, I found out by libinput
documentation that tapping needs to be enabled. The libinput xorg driver
supports that. Just set the Tapping option to true and that's it.</p>
<p>So, now I am a happy libinput user, with some of the same issues I had
before with synaptics, but something you get used to. And I have a new
firmware in front of me that maybe we could tackle by some reverse
engineering.</p>
Processos, compartilhamento e isolamentohttps://cascardo.eti.br/blog/Processos_Compartilhamento_Isolamento/2014-09-22T23:08:17Z2014-09-22T23:08:17Z
<p>Pra poder falar um pouco mais sobre <a href="https://cascardo.eti.br/tags/linux/../../blog/Virtualizacao_em_SO/">Virtualizacao em SO</a>, penso ser
importante ressaltar como processos são projetados para compartilhar
informações e, no entanto, serem isolados uns dos outros. Ou vice-versa.</p>
<p>Geralmente, diferentes processos executam diferentes programas. O modo
<a href="http://secure.wikimedia.org/wikipedia/pt/wiki/POSIX">POSIX</a> de fazer as coisas, muito criticado por alguns, é fazer
uma cópia do processo original e, então, substituir este novo processo
pelo programa a ser executado. Basicamente, corresponde a sequência de
chamadas de sistema <a href="http://man7.org/linux/man-pages/man2/fork.2.html">fork</a>/<a href="http://man7.org/linux/man-pages/man2/execve.2.html">execve</a>. Uma das críticas é
ter de efetuar uma cópia de um processo para, logo em seguida,
substituí-la, gastando recursos de processamento e memória
desnecessariamente.</p>
<p>Esse processo de cópia faz com que muitas coisas sejam compartilhadas
entre dois processos ou mesmo entre vários processos no sistema. Entre
elas, podemos destacar o diretório raiz do sistema, a partir do qual os
mesmos arquivos podem ser acessados. Se não fosse por esse
compartilhamento, não seria possível abrir um arquivo que acabou de ser
criado por um processo em um novo processo. Imagine nunca poder abrir um
arquivo porque um processo foi isolado de qualquer outro processo
futuro.</p>
<p>E é justamente esse o propósito da chamada <a href="http://man7.org/linux/man-pages/man2/chroot.2.html">chroot</a>. Esta
chamada permite alterar o diretório raiz do processo que realiza a
chamada, permitindo que código executado a partir de então não possa
acessar arquivos sob a raiz original do sistema. Com exceção, é claro,
daqueles sob a nova raiz. A partir desse processo cujo diretório raiz
foi alterado, novos processos iniciados por ele ou por aqueles iniciados
por ele (formando assim uma hierarquia de processos) estarão limitados
aos arquivos sob aquela raiz. Essa nova hierarquia de processos
enxergará, portanto, um novo ambiente, em que a hierarquia de arquivos
visíveis, o espaço de nomes limitado por barras ("/") é diferente
daquela que outras hierarquias de processos enxergam.</p>
<p>Criamos, então, uma separação, um isolamento, entre diferentes grupos de
processos. Outros recursos ainda são compartilhados, mas outros
isolamentos são possíveis, como veremos futuramente, criando, assim,
conteineres de processos, incapazes de afetar uns aos outros (ou assim
devem ser).</p>
<p>Por outro lado, processos podem compartilhar mais do que é normalmente
compartilhado em uma chamada padrão à chamada de sistema <em>fork</em>. A
chamada de sistema <a href="http://man7.org/linux/man-pages/man2/clone2.2.html">clone2</a>, que aceita diferentes opções de
compartilhamento, permite a criação de novos isolamentos ou
compartilhamentos. Entre essas opções, temos <em>CLONE_THREAD</em> e
<em>CLONE_VM</em>, capazes de criar uma nova thread, com acesso ao mesmo espaço
de endereçamento, ou seja, compartilhando a memória e com o mesmo número
de processo (<em>PID</em>).</p>
<p>E é essa chamada e uma chamada irmã, <a href="http://man7.org/linux/man-pages/man2/unshare.2.html">unshare</a>, um dos dois
pilares de Linux Containers a que daremos atenção nesta série de posts.
Veremos mais sobre várias das opções de <em>clone2</em> e <em>unshare</em> em posts
que seguirão.</p>
Iniciando com desenvolvimento do Linuxhttps://cascardo.eti.br/blog/Iniciando_com_desenvolvimento_do_Linux/2014-09-11T11:41:00Z2014-09-11T11:34:03Z
<p>Recentemente, dei uma palestra sobre como iniciar no desenvolvimento do
Linux, um projeto bem conhecido, hospedado em <a href="http://kernel.org/">http://kernel.org/</a>.</p>
<p>Um de seus mais importantes contribuidores, Greg Kroah-Hartman, oferece
muitos documentos que recomendo, em seu <a href="http://kroah.com/linux/">site</a>.</p>
<p>Entre eles, recomendo para os iniciantes, o <a href="http://kroah.com/lkn/">Linux Kernel in a
Nutshell</a>.</p>
<p>Boa leitura!</p>
Virtualização em SOhttps://cascardo.eti.br/blog/Virtualizacao_em_SO/2014-09-22T23:40:34Z2012-03-30T00:40:18Z
<p>Há bastante tempo, me interesso por sistemas de virtualização. Foi em
2005 quando comprei uma das primeiras edições da <a href="http://www.freesoftwaremagazine.com/">Free Software
Magazine</a>, que tinha como capa uma
matéria sobre diferentes tipos de virtualização, que me interessei em
particular por virtualização no nível do sistema operacional.</p>
<p>Esse tipo de virtualização implica em isolar as camadas acima do kernel
de outras instâncias. Você poderia, por exemplo, utilizar Debian como
uma instância, Fedora como outra instância, etc. Uma implementação para
Linux daquela época era o Linux-Vserver, sendo constituído por patches
que você poderia aplicar ao Linux.</p>
<p>Uma forma de descrever esse conceito de virtualização é um "chroot"
bombado. Enquanto um "chroot" isola o diretório raiz de uma árvore de
processos dos demais diretórios do sistema, uma virtualização por SO
isola também processos, CPU, memória, dispositivos, entre outras coisas.</p>
<p>Implementações em outros sistemas operacionais incluem o Jails do
FreeBSD, que além de isolar diretórios, isola processos, usuários,
limita acessos, incluindo configuração de rede, e montagem de sistemas
de arquivos. Outra implementação é Solaris Zones.</p>
<p>O trabalho do Linux-VServer não se encontrava no mainline (ou upstream,
ou vanilla), mas a funcionalidade era desejável. Outra implementação que
foi criada foi o OpenVZ. Boa parte desse segundo trabalho foi
contribuído de alguma forma e o OpenVZ foi se aproximando cada vez mais
do upstream.</p>
<p>Hoje em dia, a tecnologia existente no mainline costuma ser chamada de
Linux Containers. Trata-se de um conjunto de funcionalidades que podem
ser utilizadas de forma independente entre si e pretendo falar dessas
funcionalidades em posts que seguirão a esse.</p>