veyepar: Why kernel space sucks

Author(s):	Michael Kerrisk
Location	MCC1
Date	feb Fri 01	Days Raw Files
Start	13:20	First Raw Start	error-in-template
Duration	0:45:00	Offset	None
End	14:05	Last Raw End
Chapters
Total cuts_time	None min.

http://lca2013.linux.org.au/schedule/30013/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf Why_kernel_space_sucks.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

A few years ago, respected kernel hacker Dave Jones gave a highly amusing talk, "Why userspace sucks"[1], which looked at the extraordinary ways in which userspace programmers wreck the performance of Linux systems--systems based on the kernel whose performance kernel hackers go to such lengths to improve.

There's no denying Dave's analysis. But, sucking can go in both directions, and there are some myths about the perfection of kernel development to be deconstructed.

I'll take the specific example of programming interfaces--a place where kernel hackers inflict special pain on userspace, in the form of designs that are inconsistent, insufficiently general, unmaintainable, nonstandard, overcomplicated, nonextensible, poorly integrated with existing APIs, and simply out-and-out wrong. That leads to a parallel question: is code the only--or even the best--way to contribute to a project? That question in turn leads to some ideas about how we might improve the process of API design.

[1] http://lwn.net/Articles/192214/

Comment:

production notes