Thread: fcp handling
Brought to you by:
aeb,
bencollins
From: Manfred W. <e95...@st...> - 2000-03-26 18:05:59
|
I still have not tested the new fcp-functions, but I had a look at the code and I think I discovered a flaw, which might cause errors in some situations, which are very difficult to locate. If I understood the code correctly, then by issuing raw1394_start_fcp_listen we tell the kernel to store the packets arriving in a buffer array which is located in raw1394_handle. BTW: That ist the same buffer which is used for iso packets, so it would probably be advisable for people, who are listening for iso_packets _and_ fcp_frames, to allocate two seperate handles for those two purposes (I think, that should be mentioned in a comment in raw1394.h). If a new packet arrives before the first one was read completly by the application, it would overwritten and the application either loses the first one completly or it reads a mixture (which can in worst case be a mixture fcp-commands, fcp-responses and iso-packets). I am also not quit sure, if it was a good idea to mix up the reception of fcp commands and responses into one handler, since an application might be interested in only listening to either commands or responses (of cource, if somebody wants to implement a fully AV/C-compliant unit, he will have to handle both). In that context I have another qestion: If two application (or one application using two raw-handles) register for listening at the FCP addresses, which buffer will be used? Or will the kernel create two copies of that packet in both raw-handle-buffers? I think that the kernel will do this, but I just wanted to ask, because I was not sure, and studying the source-code is not easy... greetings Manfred Weihs |
From: Andreas B. <and...@mu...> - 2000-03-27 00:54:08
|
On Sun, Mar 26, 2000 at 07:30:51PM +0200, Manfred Weihs wrote: > If I understood the code correctly, then by issuing > raw1394_start_fcp_listen we tell the kernel to store the packets > arriving in a buffer array which is located in raw1394_handle. BTW: That > ist the same buffer which is used for iso packets, so it would probably > be advisable for people, who are listening for iso_packets _and_ > fcp_frames, to allocate two seperate handles for those two purposes (I > think, that should be mentioned in a comment in raw1394.h). The buffer is only overwritten on a raw1394_loop_iterate() call which then calls the handlers. After a handler ends, the corresponding data is invalid (the handler must process the data immediately or save it somewhere else if it really has to store plain data). Therefore there won't be problems with correct usage. In the future the address given to an iso or FCP handler might not even exist anymore since I intend to implement kernel-to-user memory mapping at some point in the future and the page containing the data could be unmapped immediately after use. > I am also not quit sure, if it was a good idea to mix up the reception > of fcp commands and responses into one handler, since an application > might be interested in only listening to either commands or responses > (of cource, if somebody wants to implement a fully AV/C-compliant unit, > he will have to handle both). Future optimization. For now this just amounts in unneccessary handler calls (and data copies) but doesn't create any realy problems. Just ignore handler calls with the wrong direction argument. > In that context I have another qestion: > If two application (or one application using two raw-handles) register > for listening at the FCP addresses, which buffer will be used? Or will > the kernel create two copies of that packet in both raw-handle-buffers? > I think that the kernel will do this, but I just wanted to ask, because > I was not sure, and studying the source-code is not easy... The FCP data (like iso data) is stored once in the kernel and then copied to each listening app. The data in kernel is deleted after the reference count reaches zero (all apps got a copy). -- Andreas E. Bombe <and...@mu...> http://home.pages.de/~andreas.bombe/ DSA key 0x04880A44 |
From: Manfred W. <e95...@st...> - 2000-04-05 16:48:20
|
Andreas Bombe wrote: > [concerning the buffers which are handed over to the iso- or fcp-handlers] > The buffer is only overwritten on a raw1394_loop_iterate() call which > then calls the handlers. After a handler ends, the corresponding data > is invalid (the handler must process the data immediately or save it > somewhere else if it really has to store plain data). Therefore there > won't be problems with correct usage. Is the data really invalid, when the handler ends, or does it stay valid until the next call of raw1394_loop_iterate()? Imagine an application which processes data that arrives on an isochannel; and everytime, when its buffer is empty, it does (one or more) raw1394_loop_iterate() until the iso_handler is executed. Does the handler really have to copy the data to a separate buffer, or would it be sufficient to store the address of the (internal) buffer in a (global) variable? The premise is - of course - that raw1394_loop_iterates (on that particular raw-handle) is only done, when we need a new iso-packet. > In the future the address given to an iso or FCP handler might not > even exist anymore since I intend to implement kernel-to-user memory > mapping at some point in the future and the page containing the data > could be unmapped immediately after use. I think, that has no effet to my question above, isn't it? Manfred Weihs |
From: Andreas B. <and...@mu...> - 2000-04-11 00:10:10
|
On Wed, Apr 05, 2000 at 06:40:59PM +0200, Manfred Weihs wrote: > Andreas Bombe wrote: > > [concerning the buffers which are handed over to the iso- or fcp-handlers] > > The buffer is only overwritten on a raw1394_loop_iterate() call which > > then calls the handlers. After a handler ends, the corresponding data > > is invalid (the handler must process the data immediately or save it > > somewhere else if it really has to store plain data). Therefore there > > won't be problems with correct usage. > > Is the data really invalid, when the handler ends, or does it stay valid > until the next call of raw1394_loop_iterate()? Currently it stays valid for that time. > Imagine an application > which processes data that arrives on an isochannel; and everytime, when > its buffer is empty, it does (one or more) raw1394_loop_iterate() until > the iso_handler is executed. Does the handler really have to copy the > data to a separate buffer, or would it be sufficient to store the > address of the (internal) buffer in a (global) variable? The premise is > - of course - that raw1394_loop_iterates (on that particular raw-handle) > is only done, when we need a new iso-packet. Hm, probably. But my original idea was that the handler directly processes the data (and therefore creates processed data at another place anyway). > > In the future the address given to an iso or FCP handler might not > > even exist anymore since I intend to implement kernel-to-user memory > > mapping at some point in the future and the page containing the data > > could be unmapped immediately after use. > > I think, that has no effet to my question above, isn't it? Instead of overwriting the buffer the buffer pointed to will be either replaced with another page or unmapped entirely (giving a segfault if it is accessed). This unmapping or replacing wouldn't happen until the next iterate call, probably, saving a syscall after the handler finished. OTOH the page containing the data could be physically locked down for a long time then if the app doesn't do iterate calls often enough. I'm not yet decided, but I think it could make some sense to have data valid until the next iterate call. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |