Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Jan 2000 01:01:50 -0500 (EST)
From:      Luoqi Chen <luoqi@watermarkgroup.com>
To:        kato@ganko.eps.nagoya-u.ac.jp
Cc:        FreeBSD-current@FreeBSD.ORG, FreeBSD-hackers@FreeBSD.ORG, FreeBSD98-hackers@jp.freebsd.org, nyan@jp.freebsd.org
Subject:   Re: indirection in bus space
Message-ID:  <200001250601.BAA17157@lor.watermarkgroup.com>

next in thread | raw e-mail | index | archive | help
> I think it is difficult to implement such conversion because:
> 
>   - Not only bus space stuff also resource manager stuff need to
>     perform such conversion.

Why? Both bus_space_handle_t and bus_space_tag_t are supposed to be
opaque types. Resource manager needs not know the implementation details.

>   - The type of the bus_space_handle_t can by determined only by the
>     bus tag.  The isa_alloc_resourcev (new function) cannot modify bus
>     tag because what it does is only to allocate resources and it
>     cannot register the address to the bus_space_handle_pc98.  But
>     allocated resources must be stored into bus_space_handle_pc98.
> 
We could create a new resource type SYS_RES_IOPORT_ARRAY, and intercept
it in all isa_*_resoruce() methods. In isa_alloc_resource(), we malloc and
return a fake resource record, in which we store I386_BUS_PIO_IND as
bus tag and address of bus_space_handle_pc98 as bus handle. And in
isa_release_resource(), we first release the underlying resources stored
in the bus_space_handle_pc98 record and then free the fake resource record
itself. It should be safe as long as we don't manipulate this resource by
direct resource manager calls, which we shouldn't do anyway.
(or we should implement it at the root bus level, if pci devices in
pc98 systems also use discrete port addresses).

-lq


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001250601.BAA17157>