Re: The Linux Staging tree, what it is and is not.
- From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
- Date: Fri, 20 Mar 2009 12:15:53 +0100
On Fri, Mar 20, 2009 at 10:55:56AM +0000, Alan Cox wrote:
- Security
For industrial I/O? We are talking about transportation of analog and
digital I/O, relais, ADC input etc. The only part that I'd consider
security related is tunnel traffic; EPL and EtherCAT have the
Maybe in your case but if that analogue I/O controls parts of a power
plant or weapons system you really really don't want a worm or trojan
getting involved with it.
right :) But is there any difference between the stack and the
application here? Applications must be able to set process variables, so
if you compromize them and write the wrong ones to the stack, your power
plant goes baaaang as well.
- Sharing the device/interconnect
Sharing the device works also with userspace, because the device is a
network card and the interface is raw ethernet frames. What do you mean
with interconnect?
Load two user space fieldbus stacks on the same network card (remembering
this could be done by accident)
ok
- Real time prioritisation
Would be done by giving the kernel task (with threaded interrupts) or
userspace task the right POSIX relatime priorities, so I don't see a
difference here.
There may be multiple user space tasks with differing priorities beyond
the message priority. That in turn means you want them to have different
priorities to the scheduler which means you want them to be different
processes really.
right, but that's the same, no matter if it runs in kernel or user
space.
Don't tell that to the industrial networking people - they are very
proud of the fact that they use a "standardized application API", so
even the fanciest and newest industrial ethernet technologies are based
on that legacy wart objdict, and it is officially considered to be a
*feature*.
It's a standard yes, but so once was the horse and cart.
/me puts this into his cites file :)
then you can put the whole stack into userspace. If kernel, we would
need an objdict API to userspace...?
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.
One model would be
kernel demux by objdict id -> forwards packet to the right user
How would a user attach to the "right" thing? Sounds like some
publish/subscribe pattern.
a completely and gloriously insane one might be to have the objdict in
mmap space as you suggest but with a futex on each objdict entry.
uuuuh :)
The problem with mmap is that the objdict is not "rectangular", so you
would need an mmapped blob + description of the variable length content,
plus access serialization. Sounds indeed gloriously insane :)
Note that what they are doing is to use the objdict as a binary
config space (think registers) to configure the whole network
workflow; so if
I tend to think of it as a rather peculiar shared event space - much
like the device end of SNMP. I guess we should be thankful for small
mercies that it wasn't invented today and using XML ;)
None of which is to say that an entirely userspace stack might not be
the right model, but there are distinct appeals to the kernel doing
some of the demux work and separation of stuff.
seconded, we'll put some brain into that idea ...
I shall be interested to see what turns out best as there are other
busses where the design really expects to set up states and the stack
to do regular repeating.
That's not different here.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
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/
- Follow-Ups:
- Re: The Linux Staging tree, what it is and is not.
- From: Daniel Krüger
- Re: The Linux Staging tree, what it is and is not.
- References:
- The Linux Staging tree, what it is and is not.
- From: Greg KH
- Re: The Linux Staging tree, what it is and is not.
- From: Robert Schwebel
- Re: The Linux Staging tree, what it is and is not.
- From: Alan Cox
- Re: The Linux Staging tree, what it is and is not.
- From: Robert Schwebel
- Re: The Linux Staging tree, what it is and is not.
- From: Alan Cox
- The Linux Staging tree, what it is and is not.
- Prev by Date: Re: [PATCH 0/7] blktrace: various cleanups and fixes
- Next by Date: Re: [PATCH v3 0/6] ATS capability support for Intel IOMMU
- Previous by thread: Re: The Linux Staging tree, what it is and is not.
- Next by thread: Re: The Linux Staging tree, what it is and is not.
- Index(es):
Relevant Pages
|