On Wed, 2 Jun 1999, Stephen C. Tweedie wrote:
> Hi,
>
> On Wed, 2 Jun 1999 20:18:27 +0200 (MET DST), Gerard Roudier
> <groudier@club-internet.fr> said:
>
> > Thanks, Stephen, for your raw-io patch.
>
> > It does work, but refuses to work for me with non sector-size aligned
> > buffer address.
>
> That's correct: this is expected behaviour for Unix raw character
> devices. You are doing dma from memory to disk, so the application
> needs to do the alignment normally done by the OS.
A requirement that is not needed is called a limitation.
> > If the IO is broken into several ones, perhaps this condition would
> > be required, but it seems to me that only the total IO length has to
> > be a multiple of the sector-size.
>
> You might be talking to a device which cannot scatter-gather, or which
> can scatter-gather only on block boundaries.
I might but I don't, and so I am not happy to be imposed limitations
I donnot deserve to suffer of.
> Remember that the
> virtual memory is not going to be physically contiguous.
I donnot have to remember for that point.
Btw, there is some parts in the kernel that seem not to care enough about
the virtual/physical issue, in my opinion.
> > I have implemented recently the support of unaligned Wide Transfers in the
> > sym53c8xx driver and I need something that provides some oddly aligned
> > buffers to test the driver code. If it is possible to remove the checking
> > of buffer alignment in your code without serious breakage,
>
> It will break the code, since there is absolutely no support anywhere
> in the kernel for submitting an IO to a single disk block from a
> scatter-gather buffer.
Indeed, that is the issue. The ll_rw_blk thing and the current kernel
interfaces with IO sub-systems are the problems.
Your raw-io implementation is fine with regards to exiting kernel
interfaces. Thanks again for this very interesting feature.
Regards,
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/