From owner-freebsd-hackers  Sun Jan 19 20:14:22 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id UAA09573
          for hackers-outgoing; Sun, 19 Jan 1997 20:14:22 -0800 (PST)
Received: (from julian@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id UAA09566
          for hackers; Sun, 19 Jan 1997 20:14:20 -0800 (PST)
Date: Sun, 19 Jan 1997 20:14:20 -0800 (PST)
From: Julian Elischer <julian>
Message-Id: <199701200414.UAA09566@freefall.freebsd.org>
To: hackers
Subject: Would like to us a BIT in buf.h
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk



I would like to get a bit in the buf b_flags lword.

however it's full :(

If I could get it I would like to call this bit B_UIO.

the setting of this bit would indicate to some drivers
that the (initially b_driver2 field but eventually b_addr) field
points to a UIO struct that details the physical 
scatter/gather (page) segments of the io requested, rather than
a kv mapping of said space.

This is a continuation of work I did at TFS when I wrote the SCSI
drivers and the BT driver (and aha too I believe) already have support for
this. There are times when io is requested, or buffs are being moved around,
when there is NO REASON for having the pages mapped..

e.g. for scatter Gather DMA, whay do we map the pages into KVM?
(and then extract those same addresses to get the scatter-gather
list for the IO.)

example:
user does raw IO to tape..
Initially the buffer is mapped in user space (hard to avoid this)
physio extracts the physical pages.
physio maps them to KV space and points a buf at it.
driver re-extracts physical addresses again for DMA S/G list.

wouldn't it have been easier if the buf struct had just had a UIO/IOVEC
attached that remember ed the physical addresses when first extracted?

If I can't get a bit then I'd like to change the b_driver2 pointer
to be b_uio and suggest that this be used to flag the presence ot the UIO
by being non NULL.

I plan on making a function call that will map the UIO's 
physical addresses into KVM fo rthe use of the
IDE driver, and other things that require 
programmed IO. What I'd like ot know from John, David, Peter and the others
is whether it would make sence to ALWAYS keep that information
with a buf.?

would the VM system need to look at the contents of 
buffers?

the only time I see that being needed is when data needs to be
copied to user-space, and a "just in time" mapping scheme might 
work just as well for that... (and a LRU list of 
KV slots to map them into..)

any comments!??

julian (E)