l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: drivers for l4-hurd


From: Daniel Wagner
Subject: Re: drivers for l4-hurd
Date: Fri, 29 Nov 2002 10:00:14 +0100
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu)

> I don't actually think you should start with filesystem integration here. 
> Adding filesystem interfaces to a device driver is opening a large can of
> worms, and you don't really want to worry about that.  Look at the proc
> server, it doesn't provide any filesystem interface, although it arguably
> could (/proc anyone?).

I think creating a hierarical driver framework is very good thing,
because then we can use the OO approach which was suggested few mails
ago. I had a quick look into newbus. It seems very promising to steal
some ideas. For example the interface for a bus looks like this 
(kern/bus_if.m):

#
# This is called from system code which prints out a description of a
# device.  It should describe the attachment that the child has with
# the parent.  For instance the TurboLaser bus prints which node the
# device is attached to.  See bus_generic_print_child.9 for more 
# information.
# This method returns the number of characters output.
#
METHOD int print_child {
        device_t dev;
        device_t child;
};

# 
# Called for each child device that 
# did not succeed in probing for a
# driver.
#    
METHOD void probe_nomatch {
        device_t dev;
        device_t child;
};

#
# These two methods manage a bus specific set of instance variables of
# a child device.  The intention is that each different type of bus
# defines a set of appropriate instance variables (such as ports and
# irqs for ISA bus etc.)
#
# This information could be given to the child device as a struct but
# that makes it hard for a bus to add or remove variables without
# forcing an edit and recompile for all drivers which may not be
# possible for vendor supplied binary drivers.

#
# Read an instance variable.  Return 0 on success.
#
METHOD int read_ivar {
        device_t _dev;
        device_t _child;
        int _indx;
        uintptr_t *_result;
};

#
# Write an instance variable.  Return 0 on success.
#
METHOD int write_ivar {
        device_t _dev;
        device_t _child;
        int _indx;
        uintptr_t _value;
};

#
# Called after the child's DEVICE_DETACH method to allow the parent
# to reclaim any resources allocated on behalf of the child.
#
METHOD void child_detached {
        device_t _dev;
        device_t _child;
};

#
# Called when a new driver is added to the devclass which owns this
# bus. The generic implementation of this method attempts to probe and
# attach any un-matched children of the bus.
#
METHOD void driver_added {
        device_t _dev;
        driver_t *_driver;
} DEFAULT bus_generic_driver_added;

#
# For busses which use use drivers supporting DEVICE_IDENTIFY to
# enumerate their devices, these methods are used to create new
# device instances. If place is non-NULL, the new device will be
# added after the last existing child with the same order.
#
METHOD device_t add_child {
        device_t _dev;
        int _order;
        const char *_name;
        int _unit;
};

#
# Allocate a system resource attached to `dev' on behalf of `child'.
# The types are defined in <machine/resource.h>; the meaning of the
# resource-ID field varies from bus to bus (but *rid == 0 is always
# valid if the resource type is).  start and end reflect the allowable
# range, and should be passed as `0UL' and `~0UL', respectively, if
# the client has no range restriction.  count is the number of consecutive
# indices in the resource required.  flags is a set of sharing flags
# as defined in <sys/rman.h>.
#
# Returns a resource or a null pointer on failure.  The caller is
# responsible for calling rman_activate_resource() when it actually
# uses the resource.
#
METHOD struct resource * alloc_resource {
        device_t        _dev;
        device_t        _child;
        int             _type;
        int            *_rid;
        u_long          _start;
        u_long          _end;
        u_long          _count;
        u_int           _flags;
} DEFAULT null_alloc_resource;

METHOD int activate_resource {
        device_t        _dev;
        device_t        _child;
        int             _type;
        int             _rid;
        struct resource *_r;
};

METHOD int deactivate_resource {
        device_t        _dev;
        device_t        _child;
        int             _type;
        int             _rid;
        struct resource *_r;
};

#
# Free a resource allocated by the preceding method.  The `rid' value
# must be the same as the one returned by BUS_ALLOC_RESOURCE (which
# is not necessarily the same as the one the client passed).
#
METHOD int release_resource {
        device_t        _dev;
        device_t        _child;
        int             _type;
        int             _rid;
        struct resource *_res;
};

METHOD int setup_intr {
        device_t        _dev;
        device_t        _child;
        struct resource *_irq;
        int             _flags;
        driver_intr_t   *_intr;
        void            *_arg;
        void            **_cookiep;
};

METHOD int teardown_intr {
        device_t        _dev;
        device_t        _child;
        struct resource *_irq;
        void            *_cookie;
};

#
# Set the range used for a particular resource. Return EINVAL if
# the type or rid are out of range.
#
METHOD int set_resource {
        device_t        _dev;
        device_t        _child;
        int             _type;
        int             _rid;
        u_long          _start;
        u_long          _count;
};

#
# Get the range for a resource. Return ENOENT if the type or rid are
# out of range or have not been set.
#
METHOD int get_resource {
        device_t        _dev;
        device_t        _child;
        int             _type;
        int             _rid;
        u_long          *_startp;
        u_long          *_countp;
};

#
# Delete a resource.
#
METHOD void delete_resource {
        device_t        _dev;
        device_t        _child;
        int             _type;
        int             _rid;
};

#
# Return a struct resource_list.
#
METHOD struct resource_list * get_resource_list {
        device_t        _dev;
        device_t        _child;
} DEFAULT bus_generic_get_resource_list;

#
# Is the hardware described by _child still attached to the system?
#
# This method should return 0 if the device is not present.  It should
# return -1 if it is present.  Any errors in determining should be
# returned as a normal errno value.  Client drivers are to assume that
# the device is present, even if there is an error determining if it is
# there.  Busses are to try to avoid returning errors, but newcard will return
# an error if the device fails to implement this method.
#
METHOD int child_present {
        device_t        _dev;
        device_t        _child;
} DEFAULT bus_generic_child_present;

#
# Returns the pnp info for this device.  Return it as a string.  If the
# string is insufficient for the storage, then return EOVERFLOW.
#
METHOD int child_pnpinfo_str {
        device_t        _dev;
        device_t        _child;
        char            *_buf;
        size_t          _buflen;
};

#
# Returns the location for this device.  Return it as a string.  If the
# string is insufficient for the storage, then return EOVERFLOW.
#
METHOD int child_location_str {
        device_t        _dev;
        device_t        _child;
        char            *_buf;
        size_t          _buflen;
};


And the pci bus extends this general bus with (dev/pci/pci_if.m):


METHOD u_int32_t read_config {
        device_t        dev;
        device_t        child;
        int             reg;
        int             width;
};

METHOD void write_config {
        device_t        dev;
        device_t        child;
        int             reg;
        u_int32_t       val;
        int             width;
};

METHOD int get_powerstate {
        device_t        dev;
        device_t        child;
};

METHOD int set_powerstate {
        device_t        dev;
        device_t        child;
        int             state;
};

METHOD void enable_busmaster {
        device_t        dev;
        device_t        child;
};

METHOD void disable_busmaster {
        device_t        dev;
        device_t        child;
};

METHOD void enable_io {
        device_t        dev;
        device_t        child;
        int             space;
};

METHOD void disable_io {
        device_t        dev;
        device_t        child;
        int             space;
};


I very like to use some code of the newbus, so we don't have to
invent everything new and we get a working interface also. So if we
use the newbus approach (which also in somehow the basic idea by the our
draft) then we have a hierarchical system. So far nothing is
really hurd specific. It is a logic order of the drivers. So any other 
project could use this. It just depends how we represent in hurd. 

> Just a word of warning so that you don't fall for the old "if you only have
> a hammer, everything looks like a nail" trap.  Certainly you can make it
> look like a filesystem, but that doesn't mean it is useful or
> feasible.

Yes, that's a good point. But we need a roundevouz place where a translator
like the pfinet attaches to the network driver. This could be still
/dev/eth?. I could live with that. But I think then we have
some problems with the hotplug devices. E.g if I don't need the
pcmcia network card the driver should go away. But what happends to
/dev/eth?, should it also go away? 

Unfortunatly I don't know how the linux does it and I guess the have/had
the same problems. I will have to look at this to. 

wagi






reply via email to

[Prev in Thread] Current Thread [Next in Thread]