Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S272289AbTHRTHt (ORCPT ); Mon, 18 Aug 2003 15:07:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S272404AbTHRTHt (ORCPT ); Mon, 18 Aug 2003 15:07:49 -0400 Received: from hera.cwi.nl ([192.16.191.8]:22736 "EHLO hera.cwi.nl") by vger.kernel.org with ESMTP id S272289AbTHRTHr (ORCPT ); Mon, 18 Aug 2003 15:07:47 -0400 From: Andries.Brouwer@cwi.nl Date: Mon, 18 Aug 2003 21:07:44 +0200 (MEST) Message-Id: To: Andries.Brouwer@cwi.nl, Dominik.Strasser@t-online.de, hch@infradead.org, jgarzik@pobox.com, linux-kernel@vger.kernel.org, torvalds@transmeta.com Subject: headers Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1119 Lines: 32 From garzik@gtf.org Mon Aug 18 20:14:47 2003 I support include/abi, or some other directory that segregates user<->kernel shared headers away from kernel-private headers. I don't see how that would be auto-generated, though. Only created through lots of hard work :) Yes, unfortunately. I started doing some of this a few times, but it is an order of magnitude more work than one thinks at first. Already the number of include files is very large. And the fact that it is not just include/abi but involves the architecture doesn't make life simpler. No doubt we must first discuss a little bit, but not too much, the desired directory structure and naming. Then we must do 5% of the work, and come back to these issues. In case people actually want to do this, I can coordinate. In case people want to try just one file, do signal.h. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/