> 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/