[EMAIL PROTECTED] wrote: > First of all, thank you for your quick answer ! > >>> I am a newbie in RTNET and i have questions. I have to program a >>> specific >>> MAC protocol for interacting, over an ethernet bus, with hardware >>> specific >>> distributed units that implement this protocol. Since these units just >>> have a MAC and an Application Layers, i have to reproduce this network >>> stack on the PC side, that's why i don't want to use any IP layer on top >>> of my MAC layer. The MAC Layer will be included in a real-time task >>> running in kernel space (mandatory in the control architecture i am >>> developing). >> And the application layer? Will it be real-time as well, or standard >> Linux? > > Yes, the application layer will also be real-time. > >>> - If no, can i use, by any way, libpcap in hard real-time RTAI tasks in >>> combination with RTNET ? If yes, How should i proceed ? >>> - If no, does RTnet provide functions like the ones provided by libpcap >>> ? >>> If yes, where could I find documentation/examples on these functions ? >> RTnet's RTcap layer provides the low-end interface for libpcap to sniff >> also on with real-time interfaces. But in this case the capturing >> front-end remains non-RT. Would this be OK for you? > > I am not sure, but i think "no". A module implementing a MAC layer has to > be implemented as a "complete" real-time task. Indeed, a MAC module will > have the highest priority in my multi-tasks architecture because it needs > to preempt all other real-time tasks. So if "the capturing front-end > remains non-RT" means that the corredponding MAC module (that calls this > front-end) will be executed in user space (and so, if i don't make a > mistake, can be preempted by my other real-time tasks), it's not good for > me. > >> 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... ;) > > 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. > 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. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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://sourceforge.net/services/buy/index.php
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
