Date: Fri, 19 Feb 2016 21:52:28 -0700 (MST) From: Warren Block <wblock@wonkity.com> To: =?ISO-8859-15?Q?Jean-S=E9bastien_P=E9dron?= <jean-sebastien.pedron@dumbbell.fr> Cc: freebsd-x11@freebsd.org Subject: Re: Guide to contribute to kernel video drivers Message-ID: <alpine.BSF.2.20.1602192152110.20127@wonkity.com> In-Reply-To: <56C7A8B8.7090406@dumbbell.fr> References: <56C708E9.8050203@FreeBSD.org> <alpine.BSF.2.20.1602191625370.9171@wonkity.com> <56C7A8B8.7090406@dumbbell.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 20 Feb 2016, Jean-Sébastien Pédron wrote: > On 20/02/2016 00:26, Warren Block wrote: >>> As promised a (too) long time ago, here are some instructions to get you >>> started with kernel video drivers. >> >> This is very nice! What is the URL for it on the wiki? Can I edit it? :) > > Not yet published on the wiki :) I was busy with another long email: > https://lists.freebsd.org/pipermail/freebsd-arch/2016-February/017699.html > > But let's publish it on the wiki now, while Mesa is rebuilding. Ah. The URL is https://wiki.freebsd.org/Graphics/Getting%20started%20with%20kernel%20projects From owner-freebsd-x11@freebsd.org Sat Feb 20 07:46:28 2016 Return-Path: <owner-freebsd-x11@freebsd.org> Delivered-To: freebsd-x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC74BAAE558 for <freebsd-x11@mailman.ysv.freebsd.org>; Sat, 20 Feb 2016 07:46:28 +0000 (UTC) (envelope-from afiskon@devzen.ru) Received: from relay16.nicmail.ru (relay16.nicmail.ru [195.208.5.134]) by mx1.freebsd.org (Postfix) with ESMTP id 3F1561BA6; Sat, 20 Feb 2016 07:46:27 +0000 (UTC) (envelope-from afiskon@devzen.ru) Received: from [31.177.73.23] (port=51737 helo=nicmail.ru) by f17.mail.nic.ru with esmtp (Exim 5.55) (envelope-from <afiskon@devzen.ru>) id 1aX2F7-0003bb-5Q; Sat, 20 Feb 2016 10:46:17 +0300 Received: from [10.0.6.228] (account afiskon@devzen.ru HELO fujitsu) by fcgp12.nicmail.ru (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 102551171; Sat, 20 Feb 2016 10:46:17 +0300 Received: from [93.174.131.138] (account afiskon@devzen.ru HELO fujitsu) by proxy08.mail.nic.ru (Exim 5.55) with id 1aX2F7-0000lI-HG; Sat, 20 Feb 2016 10:46:17 +0300 Date: Sat, 20 Feb 2016 10:43:49 +0300 From: Eax Melanhovich <afiskon@devzen.ru> To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= <dumbbell@FreeBSD.org> Cc: "freebsd-x11@freebsd.org" <freebsd-x11@FreeBSD.org> Subject: Re: Guide to contribute to kernel video drivers Message-ID: <20160220104349.2bc8b22a@fujitsu> In-Reply-To: <56C708E9.8050203@FreeBSD.org> References: <56C708E9.8050203@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support <freebsd-x11.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-x11>, <mailto:freebsd-x11-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-x11/>; List-Post: <mailto:freebsd-x11@freebsd.org> List-Help: <mailto:freebsd-x11-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-x11>, <mailto:freebsd-x11-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sat, 20 Feb 2016 07:46:28 -0000 Hello Thanks a lot for a guide! I have a few questions. Do I right understand that the only way to debug a kernel is to crash it and then analyze a dump using gdb? Is it possible to attach to a running kernel remotely? Are there any books or tutorials regarding kernel development you would recommend? For instance are these books relevant and still actual: * FreeBSD Architecture Handbook (2013, 178 pages) * FreeBSD Developers' Handbook (2014, 178 pages) ? I believe some experience with Linux kernel is required too? Same question - which books and/or tutorials would you recommend and is a book "Linux Kernel Development, 3rd Edition" (2010, 441 pages) still actual? On Fri, 19 Feb 2016 13:22:01 +0100 Jean-S=C3=A9bastien P=C3=A9dron <dumbbell@FreeBSD.org> wrote: > Hi! >=20 > As promised a (too) long time ago, here are some instructions to get > you started with kernel video drivers. >=20 > First, don't be afraid by the kernel. In the kernel, you have to live > with some constraints and debugging is more challenging, but it's not > an order of magnitude harder than userland. Moreover, we are porting > existing working code. >=20 > =3D=3D Requirements =3D=3D >=20 > o You need to run CURRENT on the test computer. I recommend you work > from another computer. You only need to copy the built kernel to > the test computer. >=20 > o You need to setup kernel core dumps on the test computer. This is > step #1 here: >=20 > https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Lin= ux%203.8#Testing_Instructions_.2F_How_To >=20 > To test core dumps work: > sysctl debug.kdb.panic=3D1 >=20 > o You need a clone of Linux. I use the following Git remotes: > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git >=20 > The second one is useful to get the patch releases, such as > "v3.8.13". The former only provides "v3.8". >=20 > o You need a clone of FreeBSD. You can fork this repository: > https://github.com/freebsd/freebsd-base-graphics >=20 > I recommend you add this one as a second remote (in addition to > your fork), as well as the FreeBSD official Git mirror: > https://github.com/freebsd/freebsd.git >=20 > =3D=3D Source code locations =3D=3D >=20 > In Linux, DRM is located in three places: > drivers/gpu/drm > include/drm > include/uapi/drm >=20 > In FreeBSD, DRM is located in sys/dev/drm2, with the Makefiles in > sys/modules/drm2. >=20 > =3D=3D Targets =3D=3D >=20 > During the discussion, some wanted to work on Linux 3.9, some on Linux > 4.3/4.4. >=20 > That said, I believe we should start by moving to linuxkpi before > anything. It would consist of modifying DRM to use sys/compat/linuxkpi > instead of its own drm_os_freebsd.[ch] files. This would help a *lot* > next updates. >=20 > =3D=3D Workflow =3D=3D >=20 > The workflow was discussed in previous threads: > https://lists.freebsd.org/pipermail/freebsd-x11/2015-December/017056.html >=20 > The conslusion is here: > https://lists.freebsd.org/pipermail/freebsd-x11/2016-January/017109.html >=20 > The file-by-file workflow, which was more popular in the discussion, > was explained in the link above. >=20 > As for the branches, we are going to use drm-next-$target (eg. > drm-next-3.9). Please send pull requests to these branches. At least > in freebsd-base-graphics, "master" will remain the same code as > Subversion's HEAD so we have a point of comparison. >=20 > Let's take drm-next-3.9 as an example. We want to update the entire > DRM to Linux 3.9: DRM core (the device-independent code), the i915 > driver and the Radeon driver. >=20 > As we are testing the file-by-file approach, we need to coordinate who > does what. And before the task is finished, the kernel won't compile > (that's the risk with the file-by-file approach). >=20 > I would like to record all the contributors on the wiki or on GitHub, > I'm not sure yet. Maybe it should take the form of issues on GitHub > (ie. one issue per file to update and an assignee). The issue even > let us discuss specific details about the file. >=20 > DRM core should be updated first, then the drivers. >=20 > =3D=3D How to build =3D=3D >=20 > I usually build a full kernel with "make buildkernel". Then, I can > rebuild the DRM part with: > make buildkernel -DKERNFAST DEBUG_FLAGS=3D"-g -O0" >=20 > Add -j$N to accelerate the build. >=20 > You can't use "-O0" for the entire kernel otherwise the kernel will > overflow the stack. However, use it for subsequent rebuilds (ie. when > using -DKERNFAST), otherwise, you'll get a lot of "<optimized out>" > variables in gdb. >=20 > When working on the update of a single file, you should move that file > to the top of $(SRCS) in the Makefile (eg. > sys/modules/drm2/drm2/Makefile) so other files don't prevent you from > build-testing your work. >=20 > I (re)install the new kernel in /tmp, because I use tmpfs there (I > don't care about the installed kernel on my working computer): > make (re)installkernel DESTDIR=3D/tmp >=20 > From the test computer, I rsync the new kernel. >=20 > =3D=3D How to test =3D=3D >=20 > Do not load the driver from /boot/loader.conf or /etc/rc.conf. Load it > manually after boot. >=20 > You can set drm.debug=3D7 in /boot/loader.conf to have more debug > informations during kldload. To lower the log level afterward (in case > it's too verbose), the corresponding sysctl is hw.dri.debug. >=20 > Play with several applications and use cases. I use: > o glxinfo/glxgears > o clinfo > o Some of the games listed in the following page: > https://dri.freedesktop.org/wiki/Benchmarking/ > (OpenArena and Xonotic in my case) > o WebGL, I use this demo: http://www.david.li/waves/ > o Desktop environments (GNOME 3, KDE 4) and compositors such as > compton. I use compton to have a tearfree environment: > compton -CG --backend glx -b > o Some video players with the GL and XVideo backends. > o HTML5 videos. I watched this video which is exposes tearing a > lot: > https://www.youtube.com/watch?v=3DhpHknKaq_M0 > o Stellarium > o xrandr(1) to manage output connectors > o Suspend/resume > o Piglit (from our development Ports tree; we should definitely > commit it) >=20 > If you find a problem, try to reduce it to the minimum, then: > 1. From a remote computer, use tmux or screen for your session > (not mandatory, but quite handy) > 2. From one tab, start a plain X server: > Xorg > 3. From another tab, start the bad, bad program: > DISPLAY=3D:0 bad_application > 4. Use other tabs to look at log files, run dtrace scripts, etc. >=20 > By doing so, you limit the number of calls to the video drivers to the > minmum. Running a full desktop environment will spam a lot of > unrelated messages. >=20 > If the computer doesn't crash and you want to load a newer driver, > you can: 1. Close all applications and the X server > 2. kldunload the driver (note that it doesn't work for i915kms in > HEAD, the update will fix that) > 3. kldload the new one. >=20 > It saves you a reboot. Again, do this from a remote computer because > after kldunloading, you may not get a console back (it works with the > Radeon driver, but so far, not with the updated i915 driver). >=20 > If you get a core dump, it will be available in /var/crash after the > reboot. Usually, core.txt.$N has enough informations. If not, you can > start gdb (either the one in base or the one from Ports): > gdb /boot/kernel/kernel /var/crash/vmcore.last > (change /boot/kernel/kernel to match the kernel you used) >=20 > Thanks for reading! :) If something is missing, please ask! I will put > this information on the wiki. >=20 --=20 Best regards, Eax Melanhovich http://eax.me/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1602192152110.20127>