i don't understand why you think framebuffers are mapped uncacheable.
your proposal appears to provide no benefit for anything currently
supported, and i'm not sure why bus_space_physload() needs to be
in the bus_space domain, rather than plain UVM. your XIP use-case
may be valid -- i haven't
int prot is the device's characteristic. Audio mic devices would use
VM_PROT_READ. Framebuffers would use VM_PROT_WRITE. We need to introduce
BUS_SPACE_PROT_* symbols too.
i don't see why you think that reads from fb devices never occur.
i'm also unsure how audio devices matter
On Tue, Mar 23, 2010 at 07:03:11PM -0700, Michael Graff wrote:
It appears that this patch works. I believe the submitter was working
on Ruby 1.9 on NetBSD, and ran into this (which I also did.)
The supplied patch works on my netbsd-5 branch test box, and should also
apply for current.
On Wed, Mar 24, 2010 at 09:15:53PM +0900, Izumi Tsutsui wrote:
I'd like to propose a new function in bus_space(9) API,
bus_space_physload(9).
void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
bus_size_t size);
This function is provided for device drivers
On Fri, Mar 12, 2010 at 4:31 AM, David Holland dholland-t...@netbsd.org wrote:
On Mon, Mar 08, 2010 at 06:33:04PM +0900, Masao Uebayashi wrote:
Well, first of all nothing says you can't read the whole file before
resolving dependencies; there's nothing inherently wrong with
define
2010/3/16 Wojciech A. Koszek wkos...@freebsd.org:
On Tue, Mar 16, 2010 at 06:55:36AM +0900, Masao Uebayashi wrote:
On Tue, Mar 16, 2010 at 1:57 AM, Eduardo Horvath e...@netbsd.org wrote:
On Sun, 14 Mar 2010, Wojciech A. Koszek wrote:
I was wondering how does Linux/Solaris kernel build
2010/3/16 Wojciech A. Koszek wkos...@freebsd.org:
On Mon, Mar 15, 2010 at 11:50:09PM +0900, Masao Uebayashi wrote:
2010/3/15 Wojciech A. Koszek wkos...@freebsd.org:
device X
builds device X staticly into the kernel (and maybe does something
device-specific), while:
On Thu, Mar 25, 2010 at 01:16:02AM +0900, Masao Uebayashi wrote:
On Mon, Mar 22, 2010 at 6:14 AM, Sverre Froyen sve...@viewmark.com wrote:
Could this be resolved by adding a get label ioctl that could be used on
any
device? ?It might return a descriptive string from the device driver /
On Wed, Mar 24, 2010 at 05:09:23PM +0900, Masao Uebayashi wrote:
On Wed, Mar 24, 2010 at 03:06:08PM +0900, Masao Uebayashi wrote:
void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
bus_size_t size);
This function should take the same arguments as
Could this be resolved by adding a get label ioctl that could be
used on any device?
That's part of the plan of my devfs.
yuck.
Agreed. For one thing, you can't ioctl anything until you open it,
which is a nontrivial operation for many devices - and closing it when
you're done is a
On 3/24/10 3:09 AM, Andrew Doran wrote:
The comment that pthread_* functions cannot safely be used in the forked
child is not QUITE what I understand to be what POSIX has in mind. They
say only one thread is running (that is, the child's MAIN thread).
Creating another thread afterwards should be
On Wed, Mar 24, 2010 at 03:09:19PM -0700, Michael Graff wrote:
The comment that pthread_* functions cannot safely be used in the forked
child is not QUITE what I understand to be what POSIX has in mind.
To quote the SUSv3:
***cut**
A process shall be created with a single thread. If a
On 3/24/10 3:32 PM, Joerg Sonnenberger wrote:
Consider the method to become a daemon, you fork() then let the child
continue. Surely we're not saying you cannot use pthread_create() there...
You are confusing something here. The constraints apply to
multi-threaded programs. Most daemons do
On Wed, Mar 24, 2010 at 01:07:15PM -0500, David Young wrote:
Can it be implemented like this?
void *
bus_space_physload(bus_space_tag_t bst, bus_addr_t addr, bus_size_t size,
vm_prot_t prot, int flags)
{
bus_space_handle_t bsh;
void *p;
int rc;
rc =
On Thu, Mar 25, 2010 at 11:43:52AM +0900, Masao Uebayashi wrote:
void *
bus_space_physload(bus_space_tag_t t, bus_addr_t addr, bus_size_t size,
int prot, int flags)
{
const bus_addr_t busp = addr;
const bus_addr_t busq = addr + size;
On Thu, Mar 25, 2010 at 01:14:51AM +0900, Masao Uebayashi wrote:
? (Besides, it's not necessarily as flat as all that, either.)
?
? It's necessary to be flat to be modular.
Mm... not strictly. That's only true when there are diamonds in the
dependency graph; otherwise, declaring
On Fri, Mar 19, 2010 at 02:49:37PM +, Andrew Doran wrote:
I *do* think it's a useful datapoint to note that sun2, pmax, algor, etc.
are never, ever downloaded any more.
Right, and these dead ports must be euthanized. The mountain of
unused device drivers and core kernel code is a
On Thu, Mar 25, 2010 at 12:18 PM, David Holland
dholland-t...@netbsd.org wrote:
On Thu, Mar 25, 2010 at 01:14:51AM +0900, Masao Uebayashi wrote:
? (Besides, it's not necessarily as flat as all that, either.)
?
? It's necessary to be flat to be modular.
Mm... not strictly.
Another question is, do we want to register device memory as part of usual
memory? For example OpenBSD seems to be trying to use framebuffer's memory
for mbufs.
It's possible if we prepare the relevant interface and call uvm_page_physload(9)
instead of uvm_page_physload_device(9). Maybe worth
19 matches
Mail list logo
