Re: [RFC][PATCH] driver model and sysfs support for PCMCIA (1/3)

[Dominik Brodowski]

Hi Adam,

On Mon, Jul 05, 2004 at 10:47:04PM +0000, Adam Belay wrote:
> > - I like many ideas in your patches -- large parts of them, though, are
> >   "double work" as similar things have already been submitted (by me)
> >   to Russell on the linux-pcmcia mailing list. What's missing in my current
> >   patches [proof-of-concepts do exist and had been announced both on lkml
> >   and on said linux-pcmcia list, though] is the exporting of product and
> >   manufactor ID and "vers_1" strings, because that needs better resource
> >   handling.
> > - the resource_ready handling is "racy", at least. Resources can disappear
> >   again.
> 
> Could you provide an example of how resources will disappear again?

/etc/pcmcia/config.opts may include

include memory 0xc0000-0xfffff
exclude memory 0xc0000-0xfffff

even though it wouldn't make sense.

>  My patch
> was designed so that even if they weren't available, nothing bad would happen.
> Furthermore, it rescans for devices when userspace attempts to bind a driver.
> Resources would almost certainly be available during that time,

Indeed, they _are_ available during that time, else userspace wouldn't know
what driver to bind. That's why my approach registers the pcmcia "sysfs"
device struct at that place.

> In other
> words, it seems that resource handling is a problem for all of pcmcia.

It is, but partly because used ioports and iomem are not 100% accounted in
/proc/ioports and /proc/iomem. I'm eagerly awaiting the creation of a PNP-
and/or ACPI-based resource core "backend", like you proposed at Kernel
Summit last year, IIRC, which possibly allows the PCMCIA core on x86{,_64} 
to "trust" the resources not in the resource database to be available for
PCMCIA's use.

> It was to add minimal support for a much needed feature while introducing
> as few potential bugs as possible to a stable kernel series.  I see 2.7 as 
> the time for rewrites.  With that in mind, I consider your patches to be a
> great solution, but I'm worried about changing internal ds functionality
> during 2.6.

However, adding pcmcia devices at the place you suggest causes resource
headaches and makes merging my patches in 2.7. much more difficult. So,
could we work to a compromise patch where PCMCIA sysfs device structs are
only registered at "bind" time [as long as Russell agrees, that is...]?

Also, what do we need the "hotplug" export for? I'd like to avoid backwards
compatibility trouble in future, and as users _need_ to run cardmgr hotplug
seems to be without usage now.

	Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/