Messages in this thread | | | Date | Wed, 9 Aug 2000 13:36:39 -0700 | From | David Hinds <> | Subject | Re: [PATCH] aironet4500_cs.c kmalloc checking |
| |
On Wed, Aug 09, 2000 at 10:24:04PM +0000, Elmer Joandi wrote: > > yes, I looked them somewhat. The bottom line is that most of this code IS > not needed there - could be taken one level up.
As you wish. Are you volunteering to actually implement this?
> a year ago, when I looked, it wasnt complete.
In what sense was it not complete? I wrote it more than five years ago and have only made minor updates for new features. Every entry point and every data structure is documented.
> Major problem is that it is(was) not encapsulated in OO sense, > i.e. I have to operate with structures, > when I would like to operate only with functions.
I'm afraid I'm not sure how to answer this because I don't understand the issue.
> well, it would be nice to delete that, then people would stop copying that...
Yeah whatever.
> > There is a hot plug PCI interface in > > 2.4, that also works for CardBus cards, but so far only a few drivers > > use it. > > Yes, yes, that I was talking about.Looked yesterday, very nice. > So i82365 does not operate with that interface ?
The question makes no sense. CardBus drivers can use the hot plug PCI interface. 16-bit PCMCIA cards are not PCI devices and can't use this API. Both are stacked on the same bridge driver.
> But can be taken down to very simple one on average case.
It can be simplified in some cases. I don't know what the average case is. I know that most of the common PCMCIA clients (serial, IDE, the most common network chipsets) require special handling, because there are many different PCMCIA "glue" implementations, and many vendors supply incomplete or incorrect configuration information.
The Windows solution for this is that every PCMCIA device has a .INF file that describes in detail how it should be configured, and this information then doesn't need to be encapsulated in the driver. I am not convinced that this is a particularly good solution.
I think about half of the existing *_cs drivers could make use of a generic PCMCIA configuration layer with a simplified API. The other half need more control.
> Maybe a virtual+fake PCI bus for ISA(made up with probes before PNP > enable and duplicate bad PNP behaviour devices removed after ), > PNP,PCMCIA as there is now nice general pci_* interface.
This sort of thing has been proposed for the future.
The Linux PCMCIA API is a fairly direct implementation of the API described in the PC Card Standard. Knowing what I knew at the time, I thought this was a reasonable approach. Knowing what I know now, if I didn't care at all about following the standard, I might do things differently. I'm not that interested in completely reworking it now, however; if someone else wishes to do so, they are welcome to.
To give an example of a different approach, the FreeBSD people have a much simpler PCMCIA driver API. It is very limiting; FreeBSD supports far fewer cards, partly because the API doesn't offer the right abstractions or enough control over how cards can be configured.
-- Dave Hinds
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |