From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 22:01:47 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 4DE28106567E; Fri, 22 Aug 2008 22:01:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id EFDD68FC15; Fri, 22 Aug 2008 22:01:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7MM0auW079721; Fri, 22 Aug 2008 16:00:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 22 Aug 2008 16:01:07 -0600 (MDT) Message-Id: <20080822.160107.511563083.imp@bsdimp.com> To: rizzo@iet.unipi.it From: "M. Warner Losh" In-Reply-To: <20080822214118.GA64725@onelab2.iet.unipi.it> References: <20080822193657.GB63527@onelab2.iet.unipi.it> <20080822.141312.732640662.imp@bsdimp.com> <20080822214118.GA64725@onelab2.iet.unipi.it> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: brooks@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: Fri, 22 Aug 2008 22:01:47 -0000 In message: <20080822214118.GA64725@onelab2.iet.unipi.it> Luigi Rizzo writes: : > Also, this problem isn't just replacing a table in the kernel. The : > problem is "map this ID to that ID" because many drivers do special : > things for different IDs, and you have to specify the ID that it is : > compatible with. : : : what's wrong with something like this : : driverparms.if_re.devid.0x11864300 = "0x04000000 D-Link DGE-528(T) Gigabit Ethernet Adapter" : driverparms.if_re.devid.0x11868139 = "0x74800000 RealTek 8139c..." : ... : : The subtree under if_re only needs to be known to the device, though : some standardization would help of course -- e.g. we could have generic : code to parse device ids of variable size using wildcards, and for : the value field we could use xml encoding (if something more trivial : does not fit -- but a barebone xml parser such as the one we need here : fits in 5-10k of object code, i did that a few months ago , see : : http://info.iet.unipi.it/~luigi/FreeBSD/minixmlrpc/ : : Hooking a write callback on a node, e.g. to driverparms. : if_re.devid would allow the driver to update its own internal : table of descriptors upon a change, and retain the current match : code (and speed) essentially unchanged in all drivers. You're going to have to give me a much more detailed description than this, because the driver getting a callback to update its information is very handwavy. And drivers wishing to do this would need to do a lot of work to make sure that their tables are dynamic. Today, they are static, or in code (eg, switch statements). this sounds like a very complex solution to the problem, without really a clear vision for how it would draw together different devices. : > : linux has a way (forget what the command name is) to add entries : > : to the table at runtime, whereas on freebsd : > : we need to patch&rebuild the module. : > : : > : if make this 'object store' thing (varsym) able to store arrays we : > : could have device drivers scan the arrays (e.g. uscanner_id or : > : if_rl_pciids etc.) to find out if it has a suitable string. : > : > That's the wrong way to solve the problem. In FreeBSD there's no : > universal table on any bus except for PC Card. Until we have that, : > this solution can't happen. Each driver has its own ad-hoc way of : > doing this. Even in PC Card land, the size of the table isn't : > exported. : > : > The way that drivers are written today in FreeBSD, the bus has to : > provide this translation layer. There's really no other viable : > solution. If someone goes through and fixes all the important busses, : > then maybe this would be a needed service. : : perhaps you are pointing to an ideal solution, which however would : still require significant work on each driver to adapt the current, : ad-hoc tables to the solution supplied by the bus. : : The approach i suggest above allows incremental deployment and i believe : it still scales well. Actually, the solution that I propose requires *NO* changes to any leaf drivers. None. It only requires changes in the bus level code to do the lookup and substitution. They are totally ignorant of the changes that are going on behind the scenes and can treat a new card just like a card they already support without even knowing that they are doing this. Since I don't understand your suggestion at all, I can't comment about how well it scales. From what I see, it is a disaster in that area as every driver that wants to participate in this would need to change. Warner