Re: The Linux Staging tree, what it is and is not.

[Robert Schwebel]

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/