Messages in this thread | | | Date | Sun, 6 Jun 1999 20:38:22 +0200 | From | Jakub Jelinek <> | Subject | Re: RFC: Devices, buses and hotplug |
| |
> Whenever possible, the probing for devices should be done by the > generic code and the drivers should just list the ID's of devices > they want to handle. Also, adding of devices to already running > drivers should be possible, so that we won't need to load the same > module three times when we want to use it for three devices.
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. 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) 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.
> o Initialization function. (Will be used mostly for ISA > drivers, filesystems et cetera.) Called when the driver > is loaded or initialized during bootup.
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). 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.
> Device access > ~~~~~~~~~~~~~ > All addresses in device nodes should be expressed as physical addresses, > i.e. those accepted by ioremap(), /dev/mem and similar interfaces.
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.
> readb() and similar functions should no longer accept and automatically convert > ISA addresses. Most drivers should be converted to use ioremap() > properly and if it's too hard, isa_readb() introduced and used instead > of readb() in non-converted drivers. > readl() et al. should also exist in variants directly specifying endianity > of target data.
I'd like to see readx/writex functions which would a) work in machine's native endianity b) work in a specific endianity c) work in bus native endianity (those would need to be called from bus_ops)
Cheers, Jakub ___________________________________________________________________ Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz Administrator of SunSITE Czech Republic, MFF, Charles University ___________________________________________________________________ UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/ Linux version 2.3.4 on a sparc64 machine (1343.49 BogoMips) ___________________________________________________________________
- 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/
| |