Date: Fri, 05 Jan 2001 22:05:38 +0000 From: Paul Richards <paul@originative.co.uk> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: freebsd-arch@freebsd.org Subject: Re: Inheritance in new-bus. Message-ID: <3A564532.ADE40E6E@originative.co.uk> References: <200101050528.f055SGU00338@caspian.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Justin T. Gibbs" wrote: > > I've finished a first pass at making cardbus a "sub-class" of pci. > Patches for this have been distributed to a few developers and will > appear hear as soon as I finish the "play by play" for the formal > post to -arch. In doing this work, I ran into several small issues > that I have not resolved to my satisfaction. My hope is that this > forum will have some ideas. > > 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. I looked at implementing kobj inheritance while I was working on my talk. My original thinking was that the upcalls could be done away with if a child device inherited its methods from its parent bus, filling in the child's kobj method table with the parent bus' methods. However, when I discussed it with Doug at the conference he didn't see things being related in that way and having spent some time pondering that I can see what he meant. For instance, an ethernet driver may be a child of a PCI device and at the moment it performs upcalls to the PCI card to carry out various functions, but method inheritance based on the device hierarchy wouldn't be correct since an ethernet kobj is in no way a child of a PCI kobj, they're only related because of their physical association. Cardbus on the other hand is related to PCI and so it would make sense to inherit from PCI. So I think that adding inheritance to kobj would be good thing, so that cardbus can inherit from PCI, but it wouldn't be right if inheritance was based on devclasses or on any other aspect of the device hierarchy, particularly since kobj is meant to be a generic OO mechanism rather than a part of newbus. I don't know which particular take on inheritance you've implemented, I wouldn't mind getting a look at the patches :-) Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A564532.ADE40E6E>