On Wed, Aug 17, 2005 at 02:54:04 +0300, Stauros Passas wrote: > >>an interrupt handler has no address space. > >>Also.. what if the memory in userspace is actually swapped out? > Sure,I must care about this ,it will be the next big problem. No. copy_to/from_user should take care of it. And it is the very thing that confines it to process context, as it must be able to sleep. > >>you just can't do this in linux; you need to do this from user context; > >>and wake that user context up from the irq. > > > >Saying "process context" would be a bit clearer here, as it really runs in > >kernel, either inside a syscall or in a kernel thread. > If it necessary to write the data from the user space, > it will be a good tactic to create a thread > only for waiting when the data will be arrive? It is not possible to wrtie the data fro *USERSPACE* in the first place. Data in kernelspace can only be accessed from kernelspace, unless they are mmaped to userspace by mmap on some device. Creating a kernel thread is probably useless here as the user program has to call read or some other syscall for fetching the data anyway. > >Actually there are two ways to read a device file and these determine the > >solution: > > > >1) The device is read via read syscall. > > > > In this case, the irq must place the data in a buffer in kernel memory > > and, if registered, wake up the process if waiting in poll or in read. > > > > When the process is awoken it will issue/continue a read, which will do > > the actual copy_to_user from it's file_operations->read. > > > The problem is that the user program mustn't make any call to receive > the data. May be it must be notified somehow when the reception is > completed,but not before of that. *WHY*?!?! What is the program doing so important while the data is being received? Also you can use threads, one of them receiving data and another processing the previous round. You should be able to implement it via aio too, but I don't know the details there. If nothing else I expect the subsystem to provide the context for doing the copying to user for you. > >2) The device is read via mmap. > > > > In this case, the irq places the data in a buffer in kernel memory > > exactly as before. It also should wake up the process if it is waiting > > (it probably should have some means of waiting for the data). > > > > Now there is _no_ copy_to_user, since the buffer is visible in the > > process. The mmap method you would implement here would attach the > > buffer > > where the data is placed into address space of the calling process. > > The data is stored on a buffer from a source, which can be for example > a network device, and I want to make as less as possible copies > to the destination address. This is the least copies possible -- 1. From the device to the buffer. The buffer is made visible to the process meaning the pages have two virtual addresses -- one from kernelspace and one from the process. You could probably get to the same level with asynchronous IO, but I don't know the details there. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
