Indian Developers Redesigning Linux Kernel With OOP, C++ Support

[david_lynch]

The Linux kernel is C and assembly. All of the drivers are included within the source code, or as a portion of a shim module that is compiled against the source code.
Linux meanwhile must be recompiled. This allows for constantly changing APIs, with no common or frozen ABI whatsoever. AMD tries to make their driver shims and closed-source stuff fit within this model, which is why it is always broken. NVidia doesn't bother, and essentially replaces most of what X is doing, with minimal involvement of kernel code or APIs, which is why their stuff almost always works.

That's actually not the case. Linux drivers have been available as loadable modules since - oh, about 1996 or so, IIRC.

So no, you don't have to recompile the kernel to add a driver. You simply build the module against the running kernel, load the module and you're good to go. Same thing goes for updating an existing driver.

[Min1123]

That's actually not the case. Linux drivers have been available as loadable modules since - oh, about 1996 or so, IIRC.

So no, you don't have to recompile the kernel to add a driver. You simply build the module against the running kernel, load the module and you're good to go. Same thing goes for updating an existing driver.

Yes, compile into kernel or into modules. You change the kernel, you compile against the new target for new modules (or DKMS can do it for you as also mentioned). Point is, the kernel and the drivers are one giant ball of stuff, one giant GIT repo, and the drivers are constantly changing because of API changes that are constantly happening in the kernel. insmod/rmmod/modprobe after bulding a module so that it is out of the main kernel blob isn't a valid substitute for code and package modularization and separation at the source level, or for providing something consistent so you don't have to #ifndef a bunch of stuff around kernel revisions to target different APIs.

[mwpow3ll]

They didn't take 1 thing in consideration: Low-level people, hardware people(embedded guys for example) hate with passion C++ and the other higher level programming languages.

I was talking to some embedded developers, for them C++ seemed something from a fantasy world(One guy was claiming that if it's C++ it's consuming automatically more memory - which is absolute non-sense). Because they were educated to program in C, they strongly believe that you can't write for embedded in C++... I was explaining that you can and there are companies that write in C++(like Boeing) and their next argument was "Then why do all the people at [that automotive company] write in C?" - simple, old people teach old techniques and technologies and it's passed on. Same problem that happens with C++ - people don't get taught modern C++ and then you hear people complaining about memory management for example...

I agree with you and Linus.

Converting the linux kernel to C++ is do-able and if done methodically would likely yield results beyond everyone's negative expectation; however, Linus has made it clear that a large reason he doesn't like these C++ porting efforts of the linux kernel is because it's mostly done or talked about by younger programmers that have the attitude, "C++ is cool. Why isn't this in C++?" without the low-level knowledge of the language or skills required to do it right. While I don't necessarily agree with his tact to vehemently attack the projects on sight, I do think he is largely being a protective voice of reason for the linux kernel and its main requirement of performance.

[staalmannen]

Another useless tons of work. Would be better if some one tried to make Linux a micro-kernel.

As a logical extension of DDEKit, the GenodeOS guys are thinking about microkernelization of Linux (arguably, something similar has already happened with NetBSD and Rump)

http://genode.org/documentation/api/dde_kit_index

http://genode.org/about/challenges

[mdias]

People seem to be throwing arguments randomly...

The problem of out-of-tree drivers is the exact same if you use C or C++.
The problem of vtables being slow also exit in C.
The code sharing you can do in C++ can also be done in C.
C and C++ code can be GPLv2 or any other license.

Maybe I missed something about this project, but it seemed to me to be about C++ (code maintainability, syntatic sugar, other C++ pluses), not about stable ABIs?

C++ also supports functions, not just methods. C++ also supports static methods. I see no reason at all why performance could be lower if the coder knows what he's doing...
Plus, we live in an age where people run phone software on top a virtual machine and don't seem to care about the performance hit (yeah, wtf!), so I don't think 1% or 2% slowdown is bad if code maintainability would go up considerably.

[curaga]

...And each and every one of the above is bad for determinism and jitter, making it unsuitable for many embedded uses, at the very least. And if you lose the embedded developers you lose the single largest source of funding and developers for the linux kernel, not to mention the group with the greatest interest in keeping the kernel small and fast.

Perhaps you have a different definition for embedded? The kernel community has for years complained nobody from the embedded world contributes to the mainline kernel, and the embedded folks complain about it getting bloated without doing anything. [insert several LWN and elinux links here]

Android and server companies are the overwhelming majority: http://lwn.net/Articles/613006/

Most active employers, 3.15–3.17
By changesets
(None)	4492	11.6%
Intel	4088	10.6%
Red Hat	3577	9.2%
(Unknown)	3409	8.8%
Linaro	1702	4.4%
Samsung	1646	4.3%
SUSE	1243	3.2%
IBM	1050	2.7%
(Consultant)	1016	2.6%
Texas Instruments	942	2.4%
Vision Engraving Systems	919	2.4%
Google	763	2.0%
Renesas Electronics	753	1.9%
Free Electrons	753	1.9%
Freescale	620	1.6%
C-DAC	400	1.0%
Oracle	390	1.0%
Imagination Technologies	361	0.9%
NVidia	355	0.9%
FOSS Outreach Program for Women	336	0.9%

[chrisb]

Moving to an object-oriented language is a great idea, but C++ is too old and complicated and programmers would still have to deal with memory allocation. Would be better to use a microkernel with XML API and loadable modern OO language (Java or C#) servlets for all ?kernel modules and drivers. We could call it Fluck, to signify all the objects working together.

[DataPath]

[QUOTE=curaga;444000]Perhaps you have a different definition for embedded? The kernel community has for years complained nobody from the embedded world contributes to the mainline kernel, and the embedded folks complain about it getting bloated without doing anything. [insert several LWN and elinux links here]

Arguing from incredulity will not advance your point. Admittedly, in my argument I was conflating the embedded and the real-time consumers of the kernel and while there is a great deal of overlap between the two, they are not the same.

The range of embedded systems is huge, spanning systems that are necessarily way too small for linux to ever be suitable, up to systems built with hardware that could easily suit a desktop computer or even greater (e.g. bitcoin miners). The "embedded folks" you refer to are, I will suggest, primarily those whose applications lie in the ever-shifting band of hardware that is barely sufficient for running linux (or barely insufficient) and applications with timing requirements that linux can just barely meet (or barely doesn't). Above that band is a massive list of contributors, whose contributions consist of more than merely code, but code review, financial resources. After all, the Linux Foundation, who signs Linus's paycheck, is funded almost entirely by voluntary contributions from (mostly) large corporate entities who build their business on Linux.

Android and server companies are the overwhelming majority: http://lwn.net/Articles/613006/

You say "Android" as if that doesn't mean "embedded" (not that it unequivocally does - it's probably best just to say that it occupies a gray area). At the same time, most of those vendors of "Android" hardware aren't only selling it into Android, and do care about more deeply embedded systems. TI and Freescale are mostly definitely among those.

[asavah]

Moving to an object-oriented language is a great idea, but C++ is too old and complicated and programmers would still have to deal with memory allocation. Would be better to use a microkernel with XML API and loadable modern OO language (Java or C#) servlets for all ?kernel modules and drivers. We could call it Fluck, to signify all the objects working together.

One of stupidest things I ever read.
Run kernel on Java or C#? WTF you were smoking?
What about VMs those 2 languages need to run?
One by Oracle and another one by MS.
Should we embed jre + mono into kernel to run modules?
Or should we run kernel modules with userspace runtimes?

[sarcasm] Excellent idea for the linux kernel. [/sarcasm]

[LinuxID10T]

One of stupidest things I ever read.
Run kernel on Java or C#? WTF you were smoking?
What about VMs those 2 languages need to run?
One by Oracle and another one by MS.
Should we embed jre + mono into kernel to run modules?
Or should we run kernel modules with userspace runtimes?

[sarcasm] Excellent idea for the linux kernel. [/sarcasm]

I'm pretty sure HE was being sarcastic...