Messages in this thread | | | Date | Sat, 5 Jun 1999 19:52:15 +0300 (IDT) | From | Alon Ziv <> | Subject | Re: 2.3 wish: integrate pcmcia into mainstream kernel |
| |
On Thu, 3 Jun 1999, Pavel Machek wrote:
> Hi! > > > I'll ignore the third option: if someone wants to rewrite PCMCIA, they > > can go for it. > > We want to rewrite more things than only pcmcia. Current modules > system has problem: if driver is in kernel, one driver handles two > devices. HOWEVER if driver is module, two drivers are required for two > devices. > > This seems ugly. > It not only _seems_ ugly; it simply _is_ ugly.
> Many laptops with pcmcia are out there, and hot pluggable pci has > became reality. Current kernel does not support hot-plugging. > > This has to change. > Hear, hear!
> Parameter passing is very different in modular / nonmodular versions. > > This should be unified. > Aye!
> So maybe it is time for major changes around devices. Than changes > should bring hotplugging into normal kernel. And it seems to me like > rather good time for bringing PCMCIA support in. I would really like > to boot up monolitic kernel on my laptop and _still_ use pcmcia ne2k. > The best solution I see is to split device initialization from the actual driver loading; so, an already-loaded driver will be able to get `reconfiguration' requests.
So, to get a driver for a device, the device driver module will be loaded (unless it's resident) and then called upon to configure itself for the device. This means it will have a second entry point, say we call it <configure_device>, which will be supplied with the device we want to configure and will cause the driver to register that device (and, of course, there will also be an <unconfigure_device>).
So, devices will actually exist (= be registered) only when they have some user.
Also, resource configuration can this way be implemented quite easily. One way is by making a configuration manager write the resource configuration into the driver's tables (i.e., before configuring device 2 on a driver, fill in it's irq[1] / ioport[1] / memstart[1] &c), possibly by making the driver export all of those in a standardized way; but I believe a better way will be just providing the configuration as a parameter to <configure_device>.
So, my proposed implementation looks like the following:
* We have a <device_resources> struct, with access functions for getting irq, mem, and whatever else out of it (and with support for defaults). * There's always _at_least_ a rudimentary configuration manager in the kernel, whose job it is to activate devices when needed; the most primitive one will just configure devices will default values whenever they are needed (so in the end it will be just as it is today). * All kernel command-line options that now go to configure individual compiled-in drivers' resources will be redirected at the basic configuration manager, which will keep them to serve as defaults when the devices are actually configured. * Any bus that supports dynamic configuration will have a bus driver which will supplant the configuration manager for devices on this bus. It will create the <device_resources> for a device before configuring it (possibly already configuring the device, or the bus, or both). * If a bus supports dynamic reconfiguration of active devices, the bus driver may call <configure_device> on an already active device with a different resource set than it currently has (e.g., when a new card was inserted into some hotplug bus and it requires `stealing' some resources from another device). Also, a device may be unconfigured by the driver if a card was ejected or alike.
Note that it's still possible (indeed advisable) to use userspace tools for dynamically configurable busses. The userspace tools will communicate with the bus driver (probably using a device entry), and consult configuration files / card databases / whatever to create new configuration records.
Opinions, anyone?
-az
------------------------+---------------------------------------------------- . __ | Phone: +972 3 5340753 (home), +972 3 9685882 (work) _| / | email: alonz@usa.net / | /_ Alon Ziv | smail: 33 Ha-Rama St., Ganey Tiqwah 55900, Israel ------------------------+---------------------------------------------------- <<<(((this place reserved for that ultra-wise oneliner I haven't found.)))>>>
- 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/
| |