From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id BA442198005 for ; Thu, 21 Feb 2013 22:05:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D41AB21C030; Thu, 21 Feb 2013 22:05:53 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BCBFEE045E for ; Thu, 21 Feb 2013 22:05:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 0AEB033E0CF for ; Thu, 21 Feb 2013 22:05:52 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5.5 tests=[AWL=-1.016, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.593, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGZn3O_FcMbZ for ; Thu, 21 Feb 2013 22:05:46 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id E553033E0B3 for ; Thu, 21 Feb 2013 22:05:43 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1U8eHA-0006Mq-Df for gentoo-dev@gentoo.org; Thu, 21 Feb 2013 23:06:00 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Feb 2013 23:06:00 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Feb 2013 23:06:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Building against /usr/src/linux and linux-info.eclass Date: Thu, 21 Feb 2013 22:05:28 +0000 (UTC) Message-ID: References: <51266AA2.40505@opensource.dyc.edu> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT db8adcf /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: 816cf7fd-3a45-440b-b552-622f8cdd355f X-Archives-Hash: 63eecb8144b135af354b92831635060f Markos Chandras posted on Thu, 21 Feb 2013 21:25:30 +0000 as excerpted: >>> Eg. bug #458014. >>> >>> Any ideas about how to deal cleanly with situations like that? >>> >>> >> I'm no expert, but I always thought that modules are supposed to >> consume headers from the kernel source directory, not from >> /usr/include/linux. I believe I've read that somewhere quite authoritative (like LWN) as well. Kernel modules, kernel sources. Userspace, the cleaned up Linux- headers. In fact, there has been quite some kernel work recently (3.7 I believe, the commit log was heavy with related commits) done in ordered to make the separation cleaner. >> As well, the modules should be installed for whatever kernel version is >> present in /usr/src/linux (or KERNEL_DIR. This may be distinct from the >> currently running kernel. This problem is much worse with gentoo than with a typical binary distro that much more strictly controls both the kernel and headers shipped. AFAIK, that's one of the major reasons the eclass is there, to semi- standardize both the handling and the relative priority of the various possibilities, but no solution's going to hit every corner-case, and if something's breaking on specific user's systems, in the end it's them that may have to either standardize their system (and build practices) to some degree, or handle their own breakage if they choose not to. But userspace definitely should be using the installed linux-headers. And in-treeing kernel modules is STRONGLY encouraged upstream exactly due to this and other issues, to the point that while out-of-tree modules are tolerated as a fact of life, they're very much on a "the responsible dev (and users who choose to use his code) gets to keep his pieces" policy. That being the upstream policy, there's definitely limits on what gentoo can do to unbreak what upstream has already declared broken, too. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman