>>> I still have problems understanding your scenario, thus I'm careful >>> with >>> pointing at certain design paths. It basically depends on >>> >>> a) the real-time requirements of your components >> >> To sum up quickly, my Application and Mac Layers put in place >> communication with hardware distributed units and standardize access to >> these heterogeneous units. The main idea is to build a kind of generic >> middleware that can be "adapted" according to 1) the type of the >> communication media used (e.g. Ethernet in the frame of our discution), >> 2) >> the MAC Layers used to manage communications on these media (one for a >> given network) and 3) the Application layers used to manage >> communication >> with the distributed units (one for each type of units). On top of that >> middleware, there are several "hardware independant" real-time modules >> (managing control, and perception activities) that communicate in a >> transparent way with units. All modules need to be "real-time" because i >> need to manage precisely task preemption in my control architecture and >> because the overall dynamics of the system imposes to limit the "cost" >> of >> context change (far to high in user mode). >> >>> b) the programming model (single application/multiple apps, >>> user/kernel >>> space) >> >> - Multiple applications: i am programming a generic framework that can >> be >> specialized for different applications in the same business domain. >> - Kernel space only: all modules (MAC modules, Application layer module, >> control modules) have to be implemented with kernel space tasks. > > Hmm, kernel space applications - sounds like old dinosaurs... ;)
I think i made a terminological mistake by using the term "kernel space tasks". I should use "hard real time task", because all tasks of my architecture are LXRT hard real-time tasks. But the overall design remain the same -i.e. MAC real time task has to be able to preempt all other real-time tasks ... Maybe it makes a difference for the use of lipcap (with RTCap) ? >> So, what i need is the simplest API(s ?) to capture and send Ethernet >> packets, but also to handle IRQ comming from Ethernet boards, without >> leaving the kernel space. Does RTCap satisfy all my wishes ? Can I use >> it > > No, given your requirements, I don't think RTcap is the right interface > for you. Do you think it is still true, given my correction ? >> directly without using all other (unecessary for me) RTNet >> functionnalities ? > > First of all, RTnet is modular. You can pick its subsystems as you need > them, more or less. The basic setup, e.g., would be some driver + the > RTnet core + some application protocol (AF_PACKET or AF_INET). But you > could also exchange the application protocol against something you > implement on your own. > > Orthogonal to this setup, you can furthermore plug in software MAC > modules based on the RTmac framework. Check stack/rtmac/nomac for a > trivial (no-op) RTmac module). If some interface is lacking in this > service for what you want to realise, call back, maybe we can extend > this layer. OK. It seems to be interesting, i will have a look more deeply in RTNet. Best regards Robin ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
