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

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