Date: Sun, 19 Jan 1997 20:14:20 -0800 (PST) From: Julian Elischer <julian> To: hackers Subject: Would like to us a BIT in buf.h Message-ID: <199701200414.UAA09566@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701200414.UAA09566>