[lkml]   [1999]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC: Devices, buses and hotplug

    > User space utilities (read as new modutils) should be able to do things like
    > initialize device class XY identification ZW (bus dependent) instance number N
    > or uninstall it.

    Can be done via ioctl() on the device tree exported in /proc :-)

    > And it should take care of checking whether it will be
    > served by an in-kernel driver (in which case it will have to take care about
    > its init sections (maybe provide just those initsections as separate
    > modules)) or by a module (whether to load the module or if it is
    > already loaded, it will need to insmod just its init sections and link it to
    > the module sections already in the kernel)

    The question is whether such separate loading of module init sections
    is worth the extra complexity. The only case where it can gain a lot of memory
    is when the driver contains huge firmware image.

    > and call drivers' init/cleanup
    > routines for a particular instance of a particular device. So what we should
    > keep in mind is that we'll need to export this device identification to
    > userland as well.

    See my remarks about /proc in the original post.

    > I'd prefer separate probe functions and init functions (probe will just tell
    > whether the driver supports the particular device and for most sane buses it
    > would be just NULL or default handler meaning the IDs are sufficient to
    > identify this driver).

    With few strange exceptions like ISA, I don't like the concept of probe
    functions at all since it doesn't suit our "cards can appear anytime" axiom.
    When a driver just needs to apply some strange conditions to select devices
    it wants, it can just use a wildcard tag matching all IDs and filter the
    devices itself. In case of a ISA driver, we could design a separate probing
    entry point, but I still don't see any advantage in it.

    On the other hand, it would be nice to define our own ID space for ISA
    devices as well, so that it will be possible to say things like "there's
    a NE2000 at 0x320, so handle it" from user space without needing to reboot
    the kernel or using modules.

    > Maybe also drivers could have a per-driver init
    > function and per-instance init function, so the per-driver init would be
    > called only the first time the driver is loaded/used and the latter would be
    > called with device_t of the particular instance.

    I think we can do per-instance init directly in the probe routine when
    we decide to accept the device.

    > I'd propose using physaddr_t or something like that port dependent instead
    > of void */long, as e.g. sparc32 has 36bit physical addresses and if you look
    > into the sbus drivers, they have to cope with this mess.

    It's probably a good way to do things if we will guarantee that physaddr_t
    will be always an integer type, so that we will be able to use it directly
    in the resource manager. For sane machines, it can be just unsigned long,
    for sparc32 36-bit addresses we can use unsigned long long instead.

    Have a nice fortnight
    Martin `MJ' Mares <>
    Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
    "DEC = Delay in Error Correction"

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.033 / U:4.572 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site