Date: Fri, 05 Jan 2001 01:02:57 -0700 From: Warner Losh <imp@bsdimp.com> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Inheritance in new-bus. Message-ID: <200101050802.f0582v151429@harmony.village.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101050802.f0582v151429>