Re: The Linux Staging tree, what it is and is not.
From: Daniel Krüger
Date: Fri Mar 20 2009 - 11:16:59 EST
Robert Schwebel schrieb:
On Fri, Mar 20, 2009 at 10:55:56AM +0000, Alan Cox wrote:
It depends where you split the stack between kernel and user space. There
needs to be enough in the kernel to allow reasonably efficient
multi-process models but that can be a small part of the stack. The
Appletalk stack is a good example. Appletalk has a single address/port
system for all higher level protocols and the higher level protocols
don't interact much with each other. It's actually very elegant in that
way. One result of this is that the AF_APPLETALK kernel stack deals only
with low level packet routing and delivery. It doesn't have to care about
higher stuff to provide the needed separation and sharing. IP by
comparison has all sorts of interactions, multiple port addressing
schemes and ICMP interactions which mean the kernel has to hold the
entire TCP and UDP layers.
So what "layers" do we have for CANopen, EtherCAT and PowerLink?
- the lower api is getting ethernet frames
- the stack itself is a state machine that pushes things to objdict
- objdict needs to notify applications on certain changes
- userspace needs to trigger state machine on certain objcict changes by
the application
We can either put the state machine into the kernel or into userspace;
if userspace, the kernel API is already there (socket), if kernel we
would need an objdict API.
My understanding of an object dictionary is that it is only a structured
view to a set of configuration variables, process variables and
diagnostic information. It could also be an XML file or a simple C
struct. In our implementation the object dictionary is not necessarily
the backing store of the data. The process variables for example are
just linked into the objdict. The application or the process image
provides the backing store. In the end we can find any appropriate
structure to pass the configuration from userspace to the data link
layer and the PDO module in the kernel.
The PDO module is in fact a programmable scatter-gather copy machine
(like DMA) between process image and Ethernet frames and vice-versa. The
information of what to copy to where comes from the object dictionary.
But it is possible to extract this information from the objdict and pass
it via generic structures (e.g. something like IO vectors) to the PDO
module in kernel. The information flow of the configuration data is
one-way only, from userspace to kernel. This is what I plan to implement
in openPOWERLINK, because the copy information can also be passed to a
special hardware like a DMA controller.
So you can implement the objdict in userspace and access the process
image via mmap (e.g. libpv).
cu,
Daniel
--
SYS TEC electronic GmbH
August-Bebel-Str. 29
D-07973 Greiz
Telefon : +49 (0) 3661 6279 0
Fax : +49 (0) 3661 6279 99
Email : daniel.krueger@xxxxxxxxxxxxxxxxxxxxx
Internet : http://www.systec-electronic.com
Managing Director : Dipl.-Phys. Siegmar Schmidt
Commercial registry : Amtsgericht Jena, HRB 205563
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/