Re: drivers for l4-hurd

[Maurizio Boriani]

>>>>> "Daniel" == Daniel Wagner <address@hidden> writes:

    Daniel> Hello Peter De Schrijver and I started to write a proposal
    Daniel> for a driver framework for l4-hurd. We would like to here
    Daniel> some feedback. As I said it's just a draft and nothing
    Daniel> definitive.

IMHO a generic device driver system based upon l4 (X.1 on X.2) could be
a better solution instand of a hurd-only solution. In this way other
OS project l4 based (l4linux, fresco and so on) could use this 
"device driver api" and also contribute.

        [...snip...]

    Daniel> Bus Drivers ===========

        [...snip...]

    Daniel> Configure client device drivers The bus driver should
    Daniel> start the appropriate client device driver translator when
    Daniel> an insertion event is detected. It should also provide the
    Daniel> client device driver with all necessary configuration
    Daniel> info, so it can access the device it needs. This
    Daniel> configuration data typically consists of the bus addresses
    Daniel> of the device and possibly IRQ numbers or DMA channel
    Daniel> ID's.

As said upper a generic "device driver" system could be used and it could live
as a separated user-level entity from translators. Translators could 
(using a specific api) attach them in a hurdish manner. 

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

I agree with a previus e-mail which suggests the use of a OO interface.

        [...snip...]

    Daniel> Device Drivers ==============

    Daniel>    Generic operations:

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

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

    Daniel> suspend Put the hardware in low power mode and save all
    Daniel> the necessary state for resume

    Daniel> resume Reenable the device and restore the state saved at
    Daniel> suspend time.

        Module dependences how could be managed?

        [...snip...]

    Daniel>    Classes: character devices This the standard tty as
    Daniel> known in the Unix environment.

        I agree with use of OO interfaces and others, a good point where 
start could be device driver sistem implemented in "MAC OSX". I this system
device drivers and bus are builded using some "template classes". 

        [...snip...]

    Daniel>    For each of the buses we have one bus driver:
    Daniel> /servers/hardware/ This is the 'rootbus' driver. It
    Daniel> abstracts the interface between the CPU and the I/O
    Daniel> system. It knows which I/O buses are connected to the CPU
    Daniel> and knows where in the CPU physical address space they are
    Daniel> located.

        This is a very good idea, like devfs in Linux kernel

        [...snip...]

    Daniel> Omega0 ======

        [...snip...]

    Daniel> IO ==

    Daniel> Memory ======

    Daniel> Drivers *******

    Daniel> Hardware Bus ============

    Daniel> Hardware Bus ============

    Daniel> PCI services ------------

    Daniel>    pci_find_device: search for PCI device by vendor/device
    Daniel> id pci_read_config_byte: read configuration BYTE register
    Daniel> of PCI device pci_write_config_byte: write configuration
    Daniel> BYTE register of PCI device

    Daniel> Bootstraping ************

    Daniel>    XXX How do we boot the system?

The system boot could be done by grub, loading module which are useful
before core kernel start up and the other after core kernel bootstrap

bye,


-- 
Maurizio Boriani -- Debian Developer
E-mail address: address@hidden
GPG key: 0xCC0FBF8F
fingerprint => E429 A37C 5259 763C 9DEE  FC8B 5D61 C796 CC0F BF8F <= fingerprint