Re: drivers for l4-hurd

[Peter 'p2' De Schrijver]

Hi,

> > 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.

You mean, first check if all devices support powermanagement before
doing something ? Probably wise to do so.

> 
> > 
> > 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.
> 

True. The interfaces should be as similar as possible. The aim should
indeed be to make drivers as portable as possible. That's also the idea
of the library. To hide platform specific details of bus accesses. Ie on
some platforms ISA I/O space is memory mapped and some address bits
indicate the transfer width. You don't want that kind of board specifics
in a graphics card driver for example.

> > 
> > 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).
> 

I would postpone initialization and resources claims until device is
opened. For IRQ's it does not make sense to hook handler to the IRQ if
you don't use it. Certainly in a shared IRQ environment.

> > 
> > 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.
> 

This probably makes more sense. There are probably situation in which
you want to reset all devices connected to a bus without stopping them.

> > 
> > 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.
> 

Does this map to the PC world view of PM or so ?

> > 
> >    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.
> 

Yes, the idea was to have interface classes devices can implement. 1
device can obviously implement multiple interface classes if approriate.

Cheers,

Peter.