From owner-freebsd-new-bus Sat Feb 26 15: 6:12 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from smtp02.wxs.nl (smtp02.wxs.nl [195.121.6.60]) by hub.freebsd.org (Postfix) with ESMTP id BCB4637B55F for ; Sat, 26 Feb 2000 15:06:04 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.199.49]) by smtp02.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA2512; Sun, 27 Feb 2000 00:06:02 +0100 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id AAA25818; Sun, 27 Feb 2000 00:04:59 +0100 (CET) (envelope-from asmodai) Date: Sun, 27 Feb 2000 00:04:58 +0100 From: Jeroen Ruigrok/Asmodai To: "Matthew N. Dodd" Cc: new-bus@FreeBSD.ORG Subject: Re: New version of the newbus draft Message-ID: <20000227000458.T79013@daemon.ninth-circle.org> References: <20000226113136.S79013@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from winter@jurai.net on Sat, Feb 26, 2000 at 06:01:26AM -0500 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000226 16:00], Matthew N. Dodd (winter@jurai.net) wrote: >Actually it came in with the Alpha port IIRC. Check 3.4. But it became widespread in 4.0, which is what I meant. =) >"Newbus is the new bus..." sounds clunky, as does "abstraction layer >architecture". If a sentence costs you more than $1.50 then you're using >too many 50c words. :) Ok, I reworded and restructured it a bit. Please look it over. >- Suggest using a bullet list for enumeration of multiple items. (p1s3) Done. >- The Alpha doesn't have 'nexus' (p3s1) Does this mean that: 1) the IA-32 is the only platform to have a nexus, or 2) the Alpha is the only platform to not have a nexus? >- A device is really the sum of its methods. A device is a device; a bus > is a device with bus methods. I'm not sure what you'd call a 'bridge' > in newbus terms. (p4s1) I added some blurb about this, but I think I might need to reword/restructure that paragraph in entirety. >- 'map its resources' and the implications of the text following aren't > quite clear. Resources are reserved and allocated (which isn't very > good either since we really want to reserve them, then activate them, > but that distinction is yet implemented in a coherent manner.) In > addition it is implied that the behavior of resource methods is > -always- to call the parent when that isn't always the case. Oh it doesn't? I was under a different assumption based on my notes. > Explaining default methods and the goal of resource > allocation/reservation/foo would be a better focus for this paragraph > since you could demonstrate the action that each layer takes on > resource allocation/reservation/foo. The existing example is a > pretty good start though. Ok, but I fail to show/describe the default methods. Hmm, need to dig through some files to scoop up some examples. >- Newbus doesn't really have anything to do with bus_space at this > point. We wish they were more intimate but they are really > separate. Same thing with bus_dma. True, but it would merit to document them all in one pull. >- Newbus doesn't 'allows for definitions of interface methods...'; thats > the entire ball of wax. bus_if.m and device_if.m provide the basic > structure to implement a hierarchy of devices. This functionality is > implicit. A more top down approach that brings the method definitions > and rules of hierarchy and inheritance into focus early in the document > would be good. Aha, I got it reversed then. The definitions of those interfaces and their methods allows for newbus. Is this correct or am I way off again? Well, the method definitions is what I was describing in the text, but where would I dig up the rules of the hierarchy and the inheritance? Also, an example of what you would consider a more top down approach would be welcome as well. >Anyhow, you've got a good start. Thanks. Only by your comments/patience/help/explanation/etc can I do this. =) So there is a new version up. Be sure to check it. -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project The only thing we have to fear is Fear itself... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message