Linux-kernel mailing list archive 1999-23,: Re: RFC: Devices, buses and hotplug

# Re: RFC: Devices, buses and hotplug

Martin Mares (mj@ucw.cz)
Sun, 6 Jun 1999 20:57:58 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Riley Williams: "Re: serial callout devices"
- Previous message: Riley Williams: "Re: Now who does cause this ???"

Hello!

> 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   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
    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 majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

- Next message: Riley Williams: "Re: serial callout devices"
- Previous message: Riley Williams: "Re: Now who does cause this ???"