From owner-freebsd-arch@FreeBSD.ORG Mon Aug 25 04:28:54 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27D3E106566B; Mon, 25 Aug 2008 04:28:54 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp13.yandex.ru (smtp13.yandex.ru [77.88.32.83]) by mx1.freebsd.org (Postfix) with ESMTP id 769D78FC0C; Mon, 25 Aug 2008 04:28:52 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([77.72.136.145]:24567 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S1820148AbYHYE2l (ORCPT + 5 others); Mon, 25 Aug 2008 08:28:41 +0400 X-Yandex-Spam: 1 X-Yandex-Front: smtp13 X-Yandex-TimeMark: 1219638521 X-MsgDayCount: 9 X-Comment: RFC 2476 MSA function at smtp13.yandex.ru logged sender identity as: bu7cher Message-ID: <48B234F7.8070407@yandex.ru> Date: Mon, 25 Aug 2008 08:28:39 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: "M. Warner Losh" References: <20080823013912.GA19588@epsilon.local> <20080822.200511.1137957320.imp@bsdimp.com> <200808222241.52325.jhb@freebsd.org> <20080822.224404.691670281.imp@bsdimp.com> In-Reply-To: <20080822.224404.691670281.imp@bsdimp.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: brooks@FreeBSD.org, rpaulo@FreeBSD.org, jhb@FreeBSD.org, ivoras@FreeBSD.org, brueffer@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Magic symlinks redux X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2008 04:28:54 -0000 M. Warner Losh wrote: > : The lookup table you have still requires patching source somewhere which > : probably defeats the purpose. > > That's the whole "less lame of getting data into the kernel" I was > talking about. The above was to show the concept, not an actual > implementation of the data. I don't like the hint idea so much, but > was looking for some other way to get the data into the kernel. What is about extending pciconf(8) (or making a pcictl(8) alias) for this purposes? -- WBR, Andrey V. Elsukov