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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:19 EST