From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Robert Schwebel <r.schwebel@pengutronix.de>
Cc: Greg KH <greg@kroah.com>,
linux-kernel@vger.kernel.org,
daniel.krueger@systec-electronic.com,
Michael Olbrich <mol@pengutronix.de>,
Wolfram Sang <wsa@pengutronix.de>,
Marc Kleine-Budde <mkl@pengutronix.de>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: The Linux Staging tree, what it is and is not.
Date: Fri, 20 Mar 2009 10:01:46 +0000 [thread overview]
Message-ID: <20090320100146.6599f671@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <20090320005808.GM5367@pengutronix.de>
> However, I'm still not convinced that this is the right way to go. What
> you want to do for the main APIs is provide some nice userspace library
> API for your applications. Why not put the whole "stack" into userspace
> then and connect it to the kernel only via raw socket.
- Security
- Compartmentalisation
- Sharing the device/interconnect
- Real time prioritisation
and a few others.
> What do others think? Is it worth the effort to invent a proper objdict
> API for linux?
Objdict appears to be a legacy wart and can stay where it belongs I
suspect - you might need to have a objdict -> 21st century conversion
library for the afflicted. We don't put specialised COBOL support in the
kernel either we let user space figure out how to cope with the funnies.
Alan
next prev parent reply other threads:[~2009-03-20 10:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-18 18:32 Greg KH
2009-03-20 0:58 ` Robert Schwebel
2009-03-20 2:48 ` Greg KH
2009-03-20 8:34 ` Daniel Krüger
2009-03-20 8:46 ` Robert Schwebel
2009-03-20 17:25 ` Greg KH
2009-03-20 10:01 ` Alan Cox [this message]
2009-03-20 10:35 ` Robert Schwebel
2009-03-20 10:55 ` Alan Cox
2009-03-20 11:15 ` Robert Schwebel
2009-03-20 15:16 ` Daniel Krüger
2009-03-20 15:37 ` Alan Cox
2009-03-20 20:32 ` david
2009-03-23 9:03 ` Daniel Krüger
2009-03-23 9:16 ` Robert Schwebel
2009-03-20 4:26 ` Dave Airlie
2009-03-20 4:46 ` Greg KH
2009-03-20 16:05 ` Lubomir Rintel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090320100146.6599f671@lxorguk.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=daniel.krueger@systec-electronic.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=mol@pengutronix.de \
--cc=r.schwebel@pengutronix.de \
--cc=tglx@linutronix.de \
--cc=wsa@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®