Umm... Let me try and further explain what I need. I'm writing a certain software network filter that handles -certain- Ethernet and ATM/POS traffic. Due to obvious performance consideration (Especially when under ATM) the filter runs in kernel space, start to finish. After the traffic is filtered and reassembled, it's being transferred to a certain 3'rd party. If the connection to the dies for any reason (or if the 3'rd party lags under load), I must encrypt the traffic and save it on disk. Once the connection resumes, I begin transmitting the stored traffic, in a FIFO manner. (Which translates to an annoying state while on one end, I'm yanking traffic out of the buffer, while the filter continuously encrypts and writes new traffic on the other hand)
Even worse, in a certain filter mode, all data is first committed to disk and then passed to the 3'rd party in-order to ensure >99% delivery. (Even if the machine/kernel/filter dies during processing, at worse, only the current [read: have yet to be processed] Ethernet frames/ATM cells will be lost) As far as I can see, realyfs uses memory buffer for storage, which is major no-no in my case: At 50-200MB/sec I'll deplete the system RAM within minutes (even on AMD64) and as far as I can see, there's no obvious way to commit the buffers into static storage. Current me if I'm wrong, but relayfs was designed for fast Kernel/User transactions and not Kernel/Kernel transactions, right? I'm looking for 50% match open solution that can be bent to suite my rather weird requirements. As the saying goes: Writing you own FS really cuts down on your Doom3 time! :-) Gilboa On Sun, 2005-07-31 at 14:56 +0300, Gilad Ben-Yossef wrote: > Gilboa Davara wrote: > > Muli, > > > > I well aware of the controversy surrounding FS access from kernel > > modules and I accept, that in general, kernel modules should be using > > the FS for storage. > > However, in essence, I'm using the *wrong* tool for the right job: I > > shouldn't be using Linux on a i386/x86-64 in the first place; I should > > be using a network OS with a network chip. > > However, Linux/x86 uses (relatively) cheap hardware and has massive > > driver support and a kernel modules is (again, relatively) easy to write > > and modify. Oh... and Linux is easy to bend :) > > > > After doing some contemplating I decided that I don't really need access > > to an FS; or actually, all I need a is huge cyclic buffer with fast > > sequential R/W and force-able sync. If anything the VFS layer will only > > slow me down. > > I wonder if the raw character code is code enough to be yanked out and > > used for this project? > > > Now you're re-inventing RelayFs :-) > > Gilad ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
