From owner-freebsd-arch Fri Jan 5 0: 3: 4 2001 From owner-freebsd-arch@FreeBSD.ORG Fri Jan 5 00:03:00 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (unknown [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9FBE437B402 for ; Fri, 5 Jan 2001 00:02:58 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.1/8.11.0) with ESMTP id f0582vl10504; Fri, 5 Jan 2001 01:02:57 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.8.3) with ESMTP id f0582v151429; Fri, 5 Jan 2001 01:02:57 -0700 (MST) Message-Id: <200101050802.f0582v151429@harmony.village.org> To: "Justin T. Gibbs" Subject: Re: Inheritance in new-bus. Cc: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 04 Jan 2001 22:28:16 MST." <200101050528.f055SGU00338@caspian.scsiguy.com> References: <200101050528.f055SGU00338@caspian.scsiguy.com> Date: Fri, 05 Jan 2001 01:02:57 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101050528.f055SGU00338@caspian.scsiguy.com> "Justin T. Gibbs" writes: : Method Inheritance : ================== : In my patches, cardbus.c is now 518 lines long. Most of this is : copyright and the method table. Like most "sub-classes", cardbus : need only specialize a few methods of pci. In a true object oriented : environment, you would overload the method and perhaps even call into : the parents implementation of that method as part of implementing : the new method. In new-bus, method tables are constructed by hand. : This means that the cardbus code must fill in the appropriate pci : method in its own table in the case of no-override. When the pci : method table is changed, chances are high that the cardbus method : table will require a similar update. One could imagine devclasses : with the concept of a parent and having kobj handle the magic for : you. This would be difficult to implemement in the case of multiple : parents. Cardbus, for example, will be a subclass of "card services" : at some point. If the method tables were broken down in terms of : distinct interfaces, single inheritance *per interface* would probably : be sufficient. One can get a fair amount of milage with good defaults. However, there does need to be something like this. Right now PCI implements at least three interfaces (bus, device and pci), so you don't have to go too far afield to find devices that implement many interfaces. For cardbus and card sevices, I'm not so sure that cardbus would be overriding too many things. The only differences that I can think of in the pcmcia standard card services between 16 bit and 32 bit stuff is a) the resource allocation (which we do the bus interface) and b) the CIS parsing in general is a little different, especially for multi-function cards. There's some differences in where to get the data from (from the card's ROM space vs common memory vs attribute memory, every byte vs every other) so maybe that is adding up to enough to make a full blown MI at least desirable. We could do something like perl does. IIRC, each class has a list of parent classes and they are searched, in list order, for the method to call when one isn't defined in that class. I would think that would be sufficient. This would make it not per interface, but rather be more full blown MI w/ about the same effort (or maybe a little less) than having a per interface table. Right now a kobj doesn't know what interface it comes from, if I'm reading the code right, so that might be hard. : Ivar namespace I've wanted this for a long time. It would make the pccard bus a more easily subclassible bus from isa than things are now (see above). Not that I'm sure that pccard should be a subclass of isa, since there are a lot of oddities and unique things in it that aren't in ISA and vice versa (there's no such thing as ISA PNP enumeration with pccard, for example, and ISA cards don't have CIS). It would make it a lot easier to have more generic IVARs than we have now. It would also parallel the interface mathod tables that we have which are fairly generic. Taken to an extreme, it might make sense to have them just be key/value pairs. This would make a lot of things more generic, as well as allowing properties to be set on device nodes that are generic on the whole system. An example I'm thinking of would be that pccard and cardbus could both set removable on the sio devices attached to these two busses, but not on any other bus. This would obviate the need for one of the proposed interfaces that I posted before. But like all cool, generic things, I worry a little over the overhead that something like this would bring. : In general, I've been very pleased with the new bus framework. : It still needs to be documented better (especially in regards : to resource allocation/activateion/deactivateion/release/delete), : and it still needs multi-pathing, but its pretty cool stuff. What is multi-pathing? Are you talking about a tree that is more of a directed graph like so: A0 / \ B1 B2 \ / C1 Where C1 has two parents. I can see how that would be useful in systems where one SCSI bus has mutliple controllers on it for redundnacy. Maybe some other specialized devices could use this too (I think phk had a case where he had a pci device that had two functions and he wanted to connect another device to them pair of them like above). We told him he was nuts for wanting that, but he did have good reasons for it, it seemed. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message