Vote Up
6
Votes
Vote Down

This man is unquestionably a moron. What the hell is an “in-kernel api?” Yes, I know what it is, but does GregKH?

Sorry to get slightly technical about this, but here are a few points where I feel GregKH might need a clue-bat:

The kernel to userspace interface is the one that application programs use, the syscall interface… users and application programmers can count on [it] being stable.

I presume this refers to the Bash shell. The interface I use when programming on Unix is libc.so.n, plus associated libraries. On Linux, they’re stable like Mount Etna, but without the pretty fireworks, or warning noises.

You think you want a stable kernel interface, but you really do not, and you don’t even know it.

Jesus. I’ve programmed through eight major releases of VOS, with a stable kernel interface. I really do want one. What I don’t want is an insufferable little ponce telling me what’s good for me.

What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. Says who?

You also get lots of other good benefits if your driver is in the main kernel tree Like what?

all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place. Not because it’s the only fscking thing in front of me at work, obviously.

...Binary kernel interface… Please consider the following facts about the Linux kernel:

It’s built on C. C has a preprocessor. There are many C compilers. Each compiler has options.

I think that’s about it. (Actually, there’s one more thing. I’ll get to that next.)

Windows is built on C. OSX is built on C (this is an early 200x article. But even the original Mac OS was built on C). FreeBSD is built on C.

Most, if not all, other operating systems have taste and discrimination. It’s not difficult to define a binary kernel interface in C, if that’s what you want to do. Hint: offer up documentation and a makefile. Oh, that’s right. You guys don’t really do documentation, do you?

Linux runs on a wide range of different processor architectures. There is no way that binary drivers from one architecture will run on another architecture properly.

Let me try to get this straight.

We refuse to provide you with a decent interface, because we can’t guarantee that our wondertabulous software will work on your fridge. And we wouldn’t port it to your fridge anyway. Because, y’know, we’re still trying to get the kernel to work on a Z80. Except we’re not. But we might be, if those bastards at Google would cave.

In what small, tiny, pointless little way does any of this make sense?

But multiply that single build by the number of different Linux distributions and the number of different supported releases of the Linux distribution and you quickly have a nightmare of different build options on different releases.

An uncanny prediction of the current Linux Distro mess, I would say. But not, so much, an argument against stable ABIs and stable APIs.

Trust me, you will go insane over time if you try to support this kind of release, I learned this the hard way a long time ago… I trust you, Greg. The evidence is in front of me.

As Linux supports a larger number of different devices “out of the box” than any other operating system It doesn’t

and it supports these devices on more different processor architectures than any other operating system It doesn’t

this proven type of development model It’s not proven

must be doing something right :) Do tell. What?

Thanks to Randy Dunlap, Andrew Morton, David Brownell, Hanna Linder, Robert Love, and Nishanth Aravamudan for their review and comments on early drafts of this paper.

Wow. There are six other dimwits out there who think this sort of guff is a valuable contribution to the future of Computer Science.

“Paper?”

Did any of these six idiots actually “review” the thing? Or did they just print it out on a giant Rizla, roll a little skunk, and shrivel what remains of their brains?

#1 Posted by KOMMENTER on Feb 9, 2010 4:47 PM

“The kernel to userspace interface is the one that application programs use, the syscall interface… users and application programmers can count on [it] being stable.”

He means posix.

#2 Posted by Declination on Feb 9, 2010 11:04 PM

No, he really means the syscall interface. It is possible to wrap posix semantics around a different syscall interface. For an example, see cygwin/interix.

#3 Posted by Declination on Feb 9, 2010 11:12 PM

The reason he means the syscall interface is because if this weren’t the case it would require changes to the libc (which presents the posix interface) with every new kernel version. If I remember correctly, there is like 1 glibc maintainer and he’s a jackass. I’m sure there would be a bunch of great quotes from him if the syscall interface did change.

#4 Posted by Declination on Feb 9, 2010 11:22 PM

It ultimately a cop-out though. Their software is insufficiently designed. I’m not sure why he thinks that it matters that binary drivers for one architecture won’t run on another. Big whoop. Define a stable in-kernel interface and companies only have to compile their drivers once for each platform they want to support. Sure, this will likely mean that a bunch of drivers only ever get compiled for Intel, but from my readings the market is definitely there for Linux on Power servers from IBM. In fact there an article just the other day that IBM is now selling Power7’s with AIX or Linux. Gee? I wonder if IBM could rustle up some Linux Kernel Gurus (I call them Guru’s since they clearly aren’t real engineers) to build the requisite drivers on Power.

#5 Posted by KOMMENTER on Feb 10, 2010 8:25 AM

http://linux.die.net/man/2/syscalls

I thought this was posix, guess my teachers aren’t as good as I though :(. Learn something new everyday.

#6 Posted by DrLoser on Feb 10, 2010 12:23 PM

Guys, I don’t care what he means. I doubt even he knows.

Posix is not stable, if that’s what he means by “syscalls.” It hasn’t been stable since 1997, which is when they started to cobble it together.

Whaddya want, Posix 1.b, 1.c, 2, 2004, 2008? To Pthread or not to Pthread? Mostly compliant or “fully” compliant?

I’ve had to deal with this brown stuff excreted from the back end of mammals which, in common terms, is referred to using an anagram of “this,” although generally speaking it’s a straightforward drop-in for “rubbish” and couldn’t possibly offend anyone other than a little old lady who is very close to death or else a televangelist, and who the fsck gives a this about televangelists? for ten or more years. I don’t need Greg KH shoving more of it down my throat.

Kommenter, you might well be right, as of five o’clock this afternoon. Be warned that it won’t last beyond the next blue moon. And blue moons occur more often than you’d think.

#7 Posted by Declination on Feb 10, 2010 12:39 PM

Generally, system calls of POSIX implementing systems tend to have system calls that align fairly closely with the user space implementation, I’m not really sure why this is, it just is. I think the link you posted is somewhat deceiving since it presents the syscalls as though they were functions, which they are not. Unless I completely misunderstood the purpose of that website and it is actually showing the libc wrapper around each of the syscalls.

#8 Posted by KOMMENTER on Feb 10, 2010 1:08 PM

@Declination
It’s a site with man pages. I used it a lot when we had to make a multithreaded openssl key generation project.
They even threw in IOCTL of all things.
Not something I expected to be doing on the first semester of the 2nd year…
We had to use the functions provided “directly” by the operating system in some parts, so no printf and stuff.
Since we were told that the linux api was a POSIX implementation, I assumed that was posix.

#9 Posted by DrLoser on Feb 10, 2010 1:18 PM

Kommenter: This isn’t an anti Loon/Sun/Posix anything comment.

Quite the reverse. The TMR is a (beloved) backwater.

If you’re really serious, and your university fiddles around with “multithreaded openssl key generation projects,” not to say “Posix! Zwar, das ist 2004! Alles Natuerlich!”

Walk away. Do not touch cookie jar. Find a better universitaet.

#10 Posted by KOMMENTER on Feb 10, 2010 1:54 PM

“If you’re really serious, and your university fiddles around with “multithreaded openssl key generation projects,”

I probably made it sound worse than it really was.

genkeysRSA [–d dimkeys] [–n nkeys] [–p nprocesses]

This little program in 2 versions (fork and fork/exec, using semaphores and shared memory)
We also had to take care of signals.
And later we had to add logging in both binary and text formats, and some console input (with IOCTL).

The cookies at the end were pretty good though.

#11 Posted by Declination on Feb 10, 2010 2:25 PM

Meh. If the goal is to teach using system calls and synchronization who cares. The actual task was probably to make it interesting. Some of that is pretty heavy for 3rd semester stuff though. Still, I would think actually generating an RSA key would be a non-trivial implementation detail. How complex is that algorithm (I have 0 cryptography background).

#12 Posted by KOMMENTER on Feb 10, 2010 2:33 PM

Still, I would think actually generating an RSA key would be a non-trivial implementation detail. How complex is that algorithm”

Very complex, that’s why we used openssl to do it for us.

#13 Posted by Declination on Feb 10, 2010 2:35 PM

Oh. Haha. I apparently spaced out for that sentence when reading.

#14 Posted by Declination on Feb 11, 2010 8:43 PM

Figure I’m going to take one last little collection of thoughts I’ve had over the last few days. It seems to me that I keep seeing articles talking about how Linux has grown up. I think this policy shows exactly the opposite. Not only is it actively hostile towards third parties, but it shows that Linux developers plan on actively squandering manpower. Consider that the way to be immune from the shifting API to to put your drivers in the kernel. Well, every time the API changes, that means that someone has to go through every driver that makes use of it fix it. So, that’s wasted manpower that could go towards the actual fixing of bugs and is just as likely to introduce regressions. Maybe thats why things break from release to release.

#15 Posted by KOMMENTER on Feb 11, 2010 10:17 PM

“So, that’s wasted manpower that could go towards the actual fixing of bugs and is just as likely to introduce regressions.”

About 1000 distros, 11 different sound servers, 60+ window managers, 4 desktop environments, 4+ standard gui toolkits, multiple (incompatible) package managers, various forks/clones for ideological reasons, almost 1 repository per distro…

The ever changing kernel api is just salt in the wound.
Not to mention the time/energy we spend countering those lunatic freetards (and the time/energy they spend on this crap).

Linux is such a massive waste of resources it’s not even funny (ok maybe it is).

You must be signed in to leave comments.