lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 03 Feb 2008 01:58:16 GMT From: Hubert Tonneau <hubert.tonneau@...lpliant.org> To: linux-kernel@...r.kernel.org Subject: Desparately wanted: intelfb modesetting in mainline As a probable result of Intel opening specifications, it is now fairly easy to buy a business computer that will run Linux without loosing weeks hacking to get it up and running: just go with an intel graphic board since Intel X11 driver now works just fine. Well, this apply only if you run mainstream Linux, that is X11 for the graphics, because if your application relies on the framebuffer, we are still at far west time. Now that Linux is getting more professional with plenty of hackers paid to do so, it would be nice to include active minimal completeness of the system goal, as opposed to just passive filtering of preposed patches, because without it, small more inovative projects (that sit on top of the kernel instead of beeing kernel rated projects) have a hard time, so that Linux behaviour is not that different from closed one: favor the mainstream and ignore small players at the expense of inovation. Same applies for user land part of some drivers. The current situation is complete lack of consistency so that getting a working kernel (which nowdays means kernel + many user land helpers) get's more and more complicated year after year, as opposed to early days where user land was just achieving a fiew simple IOCTLs to configure. It is very understandable to reject many part of drivers to user land to avoid too much code (with nasty well known side effects) in the kernel, but just saying that since it is user land it does not have to follow any rule (such as beeing part of the kernel source and linking only to kernel source provided libraries) just means lot of work to distributions (so death of small ones that are not just a recent fork of a big one) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists