Linked by Thom Holwerda on Mon 30th Jan 2012 20:39 UTC
Permalink for comment 505538
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 06/18/13 22:33 UTC
Linked by Anonymous on 06/18/13 22:26 UTC
Linked by Thom Holwerda on 06/18/13 22:25 UTC
Linked by Thom Holwerda on 06/18/13 17:45 UTC
Linked by Thom Holwerda on 06/18/13 17:32 UTC, submitted by poundsmack
Linked by Thom Holwerda on 06/17/13 17:58 UTC
Linked by Thom Holwerda on 06/17/13 17:52 UTC
Linked by Thom Holwerda on 06/14/13 21:03 UTC
Linked by Thom Holwerda on 06/14/13 20:46 UTC
Linked by Thom Holwerda on 06/14/13 17:32 UTC
More News »
Sponsored Links



Member since:
2009-05-06
How's that any different than code decode a jpeg or other on disc files? Stick it in a userland lib. Less in kernel space the better. Plus often, you don't need much userland code (maybe for ALSA, but not OSS ;-) ). A framebuffer file is just that, you can even memmap it and use it raw!
It is simple. The way I see things, the Turing machine works on addresses, certain address ranges map to certain things. Unix abstracts that so the address system is file paths, and the certain address ranges are files. It then abstracts further by making those certain address ranges map to files via a standard layout (and pushing settings to ioctl), rather than device specific. As everything is done via a file interface, you don't need a million different syscalls, you only need file syscalls and a few others for what isn't files (sleep, fork, etc). It makes everything standard and means you can plug pretty much anything together.
Edited 2012-02-01 20:53 UTC