Messages in this thread | | | Date | Mon, 19 Jul 2004 10:02:37 +0200 | From | Dominik Brodowski <> | Subject | Re: [RFC][PATCH] driver model and sysfs support for PCMCIA (1/3) |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |