Red Hat's "obfuscated" kernel source [LWN.net]

Red Hat's "obfuscated" kernel source

Posted Feb 28, 2011 19:44 UTC (Mon) by riel (subscriber, #3142)
In reply to: Red Hat's "obfuscated" kernel source by jonabbey
Parent article: Red Hat's "obfuscated" kernel source

You cannot really see that anymore, anyway. Since upstream has adapted git, more and more developers have gotten into the habit of breaking up their changes into small changesets.

As a result, the number of kernel patches from one RHEL update to the next has grown from a few hundred large patches, to a few thousand tiny patches.
I suspect this trend will continue.

That is just not a practical amount to comb through, and it was getting to the point where applying the patches took almost as much time as compiling the kernel on some systems.

to post comments

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 2:02 UTC (Tue) by brouhaha (guest, #1698) [Link] (7 responses)

and it was getting to the point where applying the patches took almost as much time as compiling the kernel on some systems.

So? Computers are also twice as fast as they were ten years ago.

I have a hard time believing that Red Hat's kernel developers can effectively manage kernel development WITHOUT keeping a set of patches against the stock kernel. It seems likely to me that they are just flattening it somewhere in the process downstream from where the actual maintenance occurs.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 4:47 UTC (Tue) by jzbiciak (guest, #5246) [Link] (1 responses)

So? Computers are also twice as fast as they were ten years ago.

I'm glad I don't buy computers where you buy computers.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 9:49 UTC (Tue) by dgm (subscriber, #49227) [Link]

Well, maybe he forgot to mention that they become ten times smaller, too.

Red Hat's "obfuscated" kernel source

Posted Mar 1, 2011 17:02 UTC (Tue) by jengelh (subscriber, #33263) [Link] (4 responses)

>So? Computers are also twice as fast as they were ten years ago.

And yet you win nothing. Your double computing power is again eaten by double-optimizing compilers and a larger set of files to deal with.
(Remember the day when an operating system was just the 100-or-so files in C:\DOS.)

Red Hat's "obfuscated" kernel source

Posted Aug 8, 2012 19:22 UTC (Wed) by hummassa (guest, #307) [Link] (3 responses)

> Remember the day when an operating system was just the 100-or-so files in C:\DOS

Twenty. There were roughly twenty files. DIR C:\DOS did not scroll, nor paused, nor "more"'d or "less"'ed. It just showed less then twenty files, and a little bit less than 120K bytes free space (in a 160k disk).

*sigh* the follies of youth...

Red Hat's "obfuscated" kernel source

Posted Aug 11, 2012 11:03 UTC (Sat) by Jonno (subscriber, #49613) [Link] (2 responses)

FOUR (4) files (io.sys, msdos.sys, config.sys, command.com), the rest was not the OS, just utilities distributed together with the OS.

Red Hat's "obfuscated" kernel source

Posted Aug 11, 2012 17:24 UTC (Sat) by hummassa (guest, #307) [Link] (1 responses)

not all computers had config.sys or autoexec.bat... :-D Technically, MS-DOS was msdos.sys. io.sys was the "device driver pack" and command.com was a (changeable) shell.

Red Hat's "obfuscated" kernel source

Posted Aug 11, 2012 21:50 UTC (Sat) by Jonno (subscriber, #49613) [Link]

io.sys was not a driver pack loaded by msdos.sys, it was in fact the "core" kernel image that also included some io drivers needed to load msdos.sys (e.g. for disk drives and filesystem). In Linux terms it would be equivalent to /boot/vmlinuz.

msdos.sys, on the other hand, was auxiliary kernel functionality loaded by io.sys. The closest things in the Linux world would be loadable kernel modules in /lib/modules. In MS-DOS 7 (only sold bundled with the Windows 9x Desktop Environment) all code from msdos.sys has been merged into io.sys, and in FreeDOS the combination has been renamed kernel.sys.

config.sys was a text file parsed by msdos.sys (or io.sys in MS-DOS 7). Essentially it was the DOS equivalent of the Linux cmdline (on modern x86 systems usually specified in the Grub configuration file). It also allowed loading additional kernel modules and specifying parameters to them (eg replacing the modprobe utility). While not strictly required, still definitely part of the OS.

command.com was the entry point for userspace code. Not part of the kernel, but still part of the OS. In GNU/Linux terms it would be a merge of /sbin/init and /bin/sh as well as most of coreutils. While replaceable, replacing it would pretty much make a different OS with the same kernel (think Android vs GNU/Linux).

I didn't mention autoexec.bat, it was not part of the OS, but a way to autostart non-os stuff on your computer, essentially the DOS equivalent of /etc/rc.local.