Linux Gained Some Weight The Past Two Weeks: Around 200,000 Lines

[Ericg]

I know people who find they write better code when they have a cat in the room glaring at them... doesn't seem to work with dogs though.

That's because it just degenerates into "Who's a good boy? Who's a good boy!? You are! Yes you are!"

[bridgman]

That's because it just degenerates into "Who's a good boy? Who's a good boy!? You are! Yes you are!"

Yep. Been there, done that

[mmstick]

You might be interested in using Tokei.

[mmstick]

Here are the stats generated by Tokei, a CLOC program written purely in Rust, which seems far more realistic:

-------------------------------------------------------------------------------
 Language            Files        Total       Blanks     Comments         Code
-------------------------------------------------------------------------------
 BASH                  156        13196         1661         2909         8626
 C                   23070     15577493      2221493      2051749     11305852
 C++                     1         1870          231           58         1581
 Device Tree          2013       480995        55427        44432       381142
 LISP                    1          281           63            0          218
 C Header            17766      3957458       427444       738477      2796167
 HTML                    4         4793          509            0         4284
 LD Script              19          571           57           58          456
 Makefile             2274        54611         8967         8645        36999
 Markdown                1            0            0            0         1297
 Objective C++           1          244           55            0          189
 Perl                   43        31967         4488        27344         7585
 Python                 40        10366         1363         1269         7735
 Assembly             1421       402355        47706         4164       350485
 TeX                     1         1022          108            3          911
 Plain Text           3475            0            0            0       425239
 Vim script              1           42            3           12           27
 XML                   181        54049         3436          252        50369
-------------------------------------------------------------------------------
 Total               50469     20591313      2773011      2879372     15379162
-------------------------------------------------------------------------------

[Guest]

Naturally I wonder, did anybody actually test those 200k lines of code? Or is it cowboy programming all the way as is the usual style?

You should ask this question at microsoft.com or bsd.org.

[bridgman]

AFAIK most of the automated tests are being uploaded -- for graphics drivers the low level tests tend to go into mesa/drm/tests while high level tests go into piglet.

You shouldn't expect to see a lot of test changes when new HW support is added though - tests at libdrm level tend to be the same for a new HW generation as they were for the previous generation, and tests at standard API level like piglet tend to be common across vendors as well as across HW generations.

https://cgit.freedesktop.org/mesa/drm/tree/tests

https://cgit.freedesktop.org/piglit

There are also ongoing updates to the testing folder in the kernel tree, although most of those tests tend to be very low level. Maintaining test cases that call directly into IOCTLs is a poor use of time since the maintenance activity there duplicates what needs to be done in the userspace libs, so most functional testing tends to happen on top of the userspace lib (eg libdrm for graphics, libhsakmt for HSA/ROC, syscall library for others).

Now that we have the new ROC code out in public I'm trying to get the associated low level tests for that out in public as well.

[F1esDgSdUTYpm0iy]

but nobody actually can prove that their code works

Well, kernel releases do go through a good number of rc's. And for each of those rc's, obviously a lot of people end up testing those rc's, bisecting bugs and so forth and so on. I'd also expect a good number of developers actually testing code locally before even committing it to the kernel's git.

Not to mention frameworks/initiatives like Phoronix and the Phornoix Test Suite which do also generate a lot of data for developers to analyze. Ultimately, kernel development has been doing fine so far and I don't think the primary concern for the kernel's integrity, stability and performance is in the method by which it is developed.

[F1esDgSdUTYpm0iy]

Seems that's not to be the case. Maybe I will try Linux again sometimes this year, but unfortunately Windows has so much ahead of Linux when it comes to drivers that it's hard to break away. Especially in the graphics drivers department.

Actually, solely in the graphics drivers department. I switched from Windows to Linux in 2014 and could not be happier. For various reasons, I was almost forced to temporarily reinstall Windows 7 on this PC I am typing this from -- I quickly changed my mind when I was confronted by the fact Windows 7's install DVD does not recognize half the components in this machine. Amongst which -- the motherboard's NIC.

Only sure solution Windows-wise? Buying a new Windows. Because, downloading the correct drivers is out, since there is no Internet connection without the NIC's drivers.

See, part of Windows' problem is that it's a commercial product. So, to keep up with your hardware, some or all of which gets replaced over time, you have to spend even more money just to have a working OS. Particularly if you start replacing the motherboard or build yourself an entirely new system. With Linux, all I have to do is to ensure I have a recent Live USB of my favourite distribution.

[starshipeleven]

With Linux, all I have to do is to ensure I have a recent Live USB of my favourite distribution.

Incorrect.
Once a device is supported in Linux it will stay supported and functional for an appropriate time (till it actually gets obsolete), while there is still PLENTY of stuff that has crappy-to-none linux support. (like say many audio cards, TV tuners, wifi dongles, cadres of assorted specialistic peripherals)
Although that's also cheap and/or crap hardware that comes with ONE driver that will NEVER EVER see updates even on Windows, so even on Windows they aren't terribly good.

So the caveat to what you said is *as long as my hardware is in the compatibility lists.

The fun happens when such cheap crap hardware gets supported by linux, while on Windows it stops working beyond the all-encompassing XP.

For example, I was very relieved when someone pointed out to Flashrom devs that someone had reverse-engineered the control protocol of the chip used in the cheapest SPI flashers around (10$ apiece, can flash both 25 and 24 SPI chips). A few months later that family of devices was supported by Flashrom (although only to flash 25 SPI chips, since Flashrom deals only with them).

[PyroDevil]

There is also https://kernelci.org/ . But thats more concerned with Linux on embedded platforms.