Re: drivers for l4-hurd

[Jörg Sonnenberger]

On Tue, 26 Nov 2002 22:24:10 +0100
Daniel Wagner <address@hidden> wrote:
> Hello
> 
> Peter De Schrijver and I started to write a proposal for a driver
> framework for l4-hurd. We would like to here some feedback. As I said
> it's just a draft and nothing definitive.
[snip]
> Configure client device drivers
>      The bus driver should start the appropriate   client device driver
>      translator when an insertion event is detected. It   should also
>      provide the client device driver with all necessary
>      configuration info, so it can access the device it needs. This
>      configuration   data typically consists of the bus addresses of
>      the device and possibly IRQ   numbers or DMA channel ID's.

I don't like the idea of a bus driver starting the client drivers automatically.
This would include too much policy in the bus driver. E.g. I don't want
the network adapter running when my notebook is on battery. Perhaps the bus 
driver
sends this insertion events to device management server, which handles the load 
of
devices. Removal events are sent to both, the device itself and the management
server. The bus driver doesn't need to send configuration data to the device
client, since it can and should be queried for the specific configuration.

> 
> Handle powermanagement
>      A bus driver should be able to power up or down the   bus it is
>      responsible for. Obviously it should notify the device drivers
>      of the devices connected to the bus of the new powerstate.

It should not only notify the device drivers, it should query them. There are
enough devices out there, which doesn't support PM the right way.

> 
> Provide access to devices
>      This means the bus driver should be able to   perform a bus
>      transaction on behalf of a client device driver. In some   cases
>      this involves sending a message and waiting for reply (eg. SCSI,
>      USB, IEEE 1394, Fibre Channel,...). The driver should provide
>      send/receive   message primitives in this case. In other cases
>      devices on the bus can be   accessed by doing a memory accesses or
>      by using special I/O instructions.    In this case the driver
>      should provide mapping and unmapping primitives so   a client
>      device driver can get access to the memory range or is allowed to
>      access the I/O addresses. The client device driver should use a
>      library,   which is bus dependant, to access the device on the
>      bus. This library hides   the platform specific details of
>      accessing the bus.

I agree that different buses have different features and so different
interfaces. But there should be some kind of basic API, f.e. getting
an IO-Mapping for ISA and PCI should be the same. This could save "porting"
time for identical devices on different bus systems. E.g. some graphic
adapters have both AGP and PCI versions.

> 
> Device Drivers
> ==============
> 
>    Generic operations:
> 
> start
>      Initialize hardware and internal states of the driver and prepare
>      the device for normal operation. Part of this work can be done
>      when   the driver is started, part of it when the device is opened
>      by an   application.

It could be useful to differentiate between initialization and configuration
of a device. The initialization should claim the resources of of the device
and set a well-known state, the configuration offers the transition from
this well-known state to the specific configuration. An ethernet card is
first initialized (settup IRQ,IO,...) and then configured.
This is also very useful for PM (see later).

> 
> stop
>      Stop the hardware and cleanup all state in the driver. (This
>      operation   also has to work if the hardware is removed from the
>      system). This is   necessary because a device can be unplugged and
>      the device driver has   to be notified.

The same as start: offer a reset facility and an stop facility.

> 
> suspend
>      Put the hardware in low power mode and save all the necessary state
>       for resume
> 
> resume
>      Reenable the device and restore the state saved at suspend time.

The PM interfaces should support at least four levels of power saving:
- normal operation
- power-saving mode (slower, but functional)
- "low-power" mode (not functinoal, but easy to wake up)
- "no-power" mode
A driver needn't support every of this modes, but should provide some kind of
mapping (power-saving -> normal, low-power->power-saving). The no-power mode
could be mapped to save configuration+reset+load configuration.

> 
>    We want interfaces to devices to be as uniform as possible, while
> still being able to use the capabilities of specific device. I devised
> a number standard interface classes devices can provide. Obviously not
> all interface classes are applicable to all devices.

To extend this idea and to merge it with the former interface: Why should
we not use some kind of OO interface? Let's ask the driver: Do you support
interface "TTY"? Yes. -> Let's speak TTY! Another example: CD burner provides
the read-only block device interface + some special kind of block writing
interface.
Compatibility issues could be solved by a small mapping library linked to
the driver.

[snip]
> 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 
> 03)
> 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 
> 03)
> 00:02.0 CardBus bridge: Texas Instruments PCI1450 (rev 03)
> 00:02.1 CardBus bridge: Texas Instruments PCI1450 (rev 03)
> 00:03.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 09)
> 00:03.1 Serial controller: Xircom Mini-PCI V.90 56k Modem
> 00:05.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear 
> SoundFusion Audio Accelerator] (rev 01)
> 00:07.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
> 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
> 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
> 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 
> 2x (rev 64)
> 
>    This would result in the following device tree:
> 
> /servers/hardware/pci0-+
>                        |-bridge00-AGP-+
>                                       |-1002:4c4d
>                        |-bridge01-Cardbus
>                        |-bridge02-Cardbus
>                        |-bridge03-ISA
>                        |-bridge04-IDE
>                        |-bridge05-USB
>                        |-bridge06-ACPI
>                        |-8086:1229
>                        |-115D:000c
>                        |-1013:6003

Agreed, like devfs on Linux extended to drivers.

The idea of ISR in the context of the Omega0 is perhaps the most critical part 
for
system security (from the therotical point of view). Perhaps a herd of processes
sharing the same AS with limited rw-access and the use of some fast intra-AS IPC
could provide a really stable situation.

I hope some of the ideas are useful. Nevertheless this is a really good first 
(?)
draft.

Regards,
Joerg Sonnenberger