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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090320024816.GA20213@kroah.com>
Date:	Thu, 19 Mar 2009 19:48:16 -0700
From:	Greg KH <greg@...ah.com>
To:	Robert Schwebel <r.schwebel@...gutronix.de>
Cc:	linux-kernel@...r.kernel.org, daniel.krueger@...tec-electronic.com,
	Michael Olbrich <mol@...gutronix.de>,
	Wolfram Sang <wsa@...gutronix.de>,
	Marc Kleine-Budde <mkl@...gutronix.de>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: The Linux Staging tree, what it is and is not.

On Fri, Mar 20, 2009 at 01:58:08AM +0100, Robert Schwebel wrote:
> Greg,
> 
> On Wed, Mar 18, 2009 at 11:32:32AM -0700, Greg KH wrote:
> > If anyone has any questions that this summary doesn't answer, please let me
> > know.
> 
> Let me take this as an opportunity to discuss the epl (Ethernet
> Powerlink) driver in staging. Taken aside the eye-cancer thing while
> looking at the code (this could be fixed in the staging model), I
> suppose the whole design is questionable.

Sure it's questionable, and it's horrid code, but it is being used by
people and is the only public implementation of EPL on Linux that I can
find.

> We have ported similar commercial EPL stacks to linux-rt in the past,
> and what we simply did is to implement the code completely in userspace,
> ontop of a raw socket. It worked out pretty well and with reasonable
> realtime performance. For the high level API, we used the process data
> model provided by libpv [1], which gives you an abstraction that follows
> both, automation-people's "process variable" concept and a modern object
> oriented desing (in C, modeled after the POSIX object model for example
> like pthread_create() & friends).
> 
> Doing this kind of network protocols in kernel space may be possible in
> general, but IMHO the first thing that has to be done for a sane design
> is:
> 
> 	"Invent proper APIs and abstractions"

Agreed.

> Unfortunately, industry people have somehow missed the last 10 years of
> software engineering, so even recent ethernet fieldbus designs like
> PowerLink or EtherCAT use the CANopen Object Dictionary [1] as their
> "abstraction" between the stack and the application. So writing
> applications in the EPL/CANopen/EtherCAT world works by PEEK and POKE on
> a variable-length global variable array. Welcome to software design of
> the 80es. Nevertheless, "Object Dictionary" is a standard API for
> industry people which cannot be discussed away, because automation
> people are used to this terminology.
> 
> So if we want to do any kind of EPL/CANopen/EtherCAT work in the kernel,
> let's start with the question what it buys us in comparism with a pure
> userspace solution like outlined above.

Are userspace solutions for this opensource today?

<snip>

> What do others think? Is it worth the effort to invent a proper objdict
> API for linux?

I suggest discussing this on netdev, that's the proper place for network
protocol discussions like this, right?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/