From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 22:48:45 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 81B351065674; Fri, 22 Aug 2008 22:48:45 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 081718FC0C; Fri, 22 Aug 2008 22:48:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 7139273098; Sat, 23 Aug 2008 00:51:19 +0200 (CEST) Date: Sat, 23 Aug 2008 00:51:19 +0200 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20080822225119.GA65119@onelab2.iet.unipi.it> References: <20080822193657.GB63527@onelab2.iet.unipi.it> <20080822.141312.732640662.imp@bsdimp.com> <20080822214118.GA64725@onelab2.iet.unipi.it> <20080822.160107.511563083.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080822.160107.511563083.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i 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:48:45 -0000 On Fri, Aug 22, 2008 at 04:01:07PM -0600, M. Warner Losh wrote: > In message: <20080822214118.GA64725@onelab2.iet.unipi.it> > Luigi Rizzo writes: ... > : 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. take if_re as an example. When if_re loads, it would call object_store_register("driverparms.if_re.devids", if_re_update_devid_table, if_re_devid_table_root); which in turn puts the string-function-arg tuple in a hash table using the string as a search key. Optionally, it could also call a routine to pre-fill the object store subtree with static content supplied by if_re.c or so. When (from the upper part of the kernel, so it can sleep etc.) the subtree is written to, the object store calls if_re_update_devid_table(if_re_devid_table_root) which in turn would scan the subtree using the api supplied by the object store itself, and rebuilds the table, quirks, whatever used by if_re for its own purposes. Clearly, this is specific for if_re. umass will likely have a more complex structure with quirks etc, uscanner is just a table of device ids, etc. > 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. ... > : 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. sorry but now i am the one who doesn't understand how you can move, with *NO* changes to the leaf drivers, from a bunch of drivers using ad-hoc solutions (static tables with variable number of fields, or lookups hardwired in the code, which don't use just the vendor/device fields but also other info e.g. subdevice as in if_re) to one that relies on the bus code for the matching. At the very least you need to replace the part of the *_probe routines with something that uses the bus routines -- and implement something that lets you manipulate the mapping/quirks table at runtime so that if a compatible device with different IDs comes out you don't have to recompile and reload a module. That's the same kind of changes that I expect to be necessary with the way I have in mind. i am sorry i cannot expand this more as i am about to leave for holidays, but will try to come up with some proof-of-concept code when i am back. cheers luigi