lkml.org 
[lkml]   [1999]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:52    [W:2.440 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site