2.  Implications for future struct buf improvements

      Concerns have been raised about the implications this separation will have for future work on struct buf, I will try to address these concerns here.

      As the existence and popularity of vinum and ccd proves, there is a legitimate and valid requirement to be able to do I/O operations which are not initiated by a vnode or filesystem operation. In other words, an I/O request is a fully valid entity in its own right and should be treated like that.

      Without doubt, the I/O request has to be tuned to fit the needs of struct buf users in the best possible way, and consequently any future changes in struct buf are likely to affect the I/O request semantics.

      One particular change which has been proposed is to drop the present requirement that a struct buf be mapped contiguously into kernel address space. The argument goes that since many modern drivers use physical address DMA to transfer the data maintaining such a mapping is needless overhead.

      Of course some drivers will still need to be able to access the buffer in kernel address space and some kind of compatibility must be provided there.

      The question is, if such a change is made impossible by the separation of the I/O aspect into its own data structure?

      The answer to this is ``no''. Anything that could be added to or done with the I/O aspect of struct buf can also be added to or done with the I/O aspect if it lives in a new "struct bio".