From: Josh Triplett <josh@joshtriplett.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [CORE TOPIC] More useful types in the linux kernel
Date: Sat, 30 Jul 2016 11:49:50 -0700 [thread overview]
Message-ID: <20160730184950.2elfi4edvkuthwaw@x> (raw)
In-Reply-To: <87vazn57gt.fsf@x220.int.ebiederm.org>
On Sat, Jul 30, 2016 at 01:03:30PM -0500, Eric W. Biederman wrote:
>
> Josh Triplett <josh@joshtriplett.org> writes:
>
> > On Tue, Jul 19, 2016 at 10:32:51AM -0500, Eric W. Biederman wrote:
> >> Would a gcc plugin that checks the most interesting things that sparse
> >> checks on every build be interesting? (endianness of integer types for example)
> >
> > I'd like to see those checks more widely available, ideally not just as
> > plugins. Some exploration of that occurred upstream:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59852 (bitwise/endian types)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 (contexts/locking)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59851 (nocast: no implicit conversions)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 (address spaces)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59855 (designated_init; done)
> >
> > I'd love to see someone pick those up and get them into upstream GCC.
> >
> >> Would a type system for pointers derived from separation logic that
> >> has the concept that a piece of data is owned by a piece of running
> >> code rather than another piece of data be interesting?
> >
> > Interesting, yes, but trying to track "ownership" gets complicated
> > *fast* to handle real-world cases. Rust went through quite a lot of
> > work, and multiple iterations, to get to the system it has now. I don't
> > think you'd be able to handle many of the cases in the kernel without
> > about that much complexity.
>
> Politely Rust did it the stupid way. "ownership" or perhaps better said
> who is allowed to modify the data is an active piece of code thing
> rather than a data thing, and Rust did it as a data thing.
I'd be interested to hear more details on what you mean by this, because
the way you've described it doesn't make sense to me. The way lifetimes
are implemented in Rust seems very much like "an active piece of code
thing". Can you give an example of the distinction you're making?
next prev parent reply other threads:[~2016-07-30 18:49 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-19 15:32 Eric W. Biederman
2016-07-19 17:31 ` Mark Brown
2016-07-19 18:52 ` Jiri Kosina
2016-07-19 20:39 ` Eric W. Biederman
2016-07-20 15:53 ` Mark Brown
2016-07-20 17:04 ` [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] Support (or move towards to) LLVM Jiri Kosina
2016-07-20 18:35 ` Alexey Dobriyan
2016-07-20 18:52 ` Mark Brown
2016-07-21 9:54 ` David Woodhouse
2016-07-21 13:41 ` Shuah Khan
2016-07-21 14:02 ` David Woodhouse
2016-07-21 16:21 ` Mark Brown
2016-07-23 3:28 ` Behan Webster
2016-07-21 18:38 ` Jiri Kosina
2016-07-21 20:47 ` Paul Turner
2016-07-26 11:22 ` David Woodhouse
2016-07-19 21:08 ` [Ksummit-discuss] [CORE TOPIC] More useful types in the linux kernel James Bottomley
2016-07-20 0:08 ` Eric W. Biederman
2016-07-20 7:32 ` Julia Lawall
2016-07-20 12:11 ` Jan Kara
2016-07-28 3:33 ` Steven Rostedt
2016-07-19 21:26 ` Josh Triplett
2016-07-20 2:36 ` Eric W. Biederman
2016-07-30 18:03 ` Eric W. Biederman
2016-07-30 18:49 ` Josh Triplett [this message]
2016-07-30 19:34 ` Eric W. Biederman
2016-07-30 20:56 ` Josh Triplett
2016-07-30 22:21 ` Eric W. Biederman
2016-07-21 15:05 ` David Howells
2016-07-21 23:33 ` Dmitry Torokhov
2016-07-22 6:00 ` Hannes Reinecke
2016-07-22 6:14 ` Julia Lawall
2016-07-22 13:57 ` Hannes Reinecke
2016-07-22 14:40 ` Julia Lawall
2016-07-22 19:12 ` Arnd Bergmann
2016-07-26 11:48 ` David Woodhouse
2016-07-26 12:53 ` Hannes Reinecke
2016-07-26 13:59 ` Alexey Dobriyan
2016-07-26 13:53 ` Alexey Dobriyan
2016-07-27 12:40 ` Julia Lawall
2016-07-27 13:25 ` James Bottomley
2016-07-27 13:33 ` David Woodhouse
2016-07-27 17:21 ` Bird, Timothy
2016-08-01 22:17 ` Rob Herring
2016-08-12 1:29 ` Stephen Boyd
2016-08-11 15:44 ` Dan Carpenter
2016-08-12 0:38 ` NeilBrown
2016-08-12 20:56 ` Dan Carpenter
2016-08-12 3:51 ` Matthew Wilcox
2016-08-12 4:01 ` Josh Triplett
2016-08-12 4:07 ` Matthew Wilcox
2016-08-12 5:29 ` Alexey Dobriyan
2016-08-12 5:38 ` Michael S. Tsirkin
2016-08-12 6:04 ` Julia Lawall
2016-08-12 6:09 ` Michael S. Tsirkin
2016-08-12 6:23 ` Matthew Wilcox
2016-08-12 6:37 ` Julia Lawall
2016-08-12 5:50 ` Matthew Wilcox
2016-08-04 7:15 ` NeilBrown
2016-08-04 11:19 ` Julia Lawall
2016-07-22 7:03 ` David Howells
2016-07-22 10:10 ` Alexey Dobriyan
2016-07-22 10:13 ` David Howells
2016-07-22 10:22 ` Alexey Dobriyan
2016-07-22 10:53 ` Vlastimil Babka
2016-07-22 11:05 ` David Howells
2016-07-22 17:18 ` Julia Lawall
2016-07-22 18:19 ` Dmitry Torokhov
2016-07-22 19:43 ` Guenter Roeck
2016-07-28 3:40 ` Steven Rostedt
2016-07-28 7:12 ` David Howells
2016-08-02 10:48 ` Jani Nikula
2016-08-04 11:31 ` David Woodhouse
2016-08-04 12:07 ` Jani Nikula
2016-07-22 11:19 ` David Howells
2016-07-22 12:44 ` Linus Walleij
2016-07-22 13:26 ` David Howells
2016-08-12 4:42 ` Michael S. Tsirkin
[not found] ` <871t1ulfvz.fsf@notabene.neil.brown.name>
2016-08-12 5:34 ` Michael S. Tsirkin
2016-08-12 6:23 ` NeilBrown
[not found] ` <87y442jytb.fsf@notabene.neil.brown.name>
2016-08-15 23:26 ` Michael S. Tsirkin
2016-08-12 6:23 ` NeilBrown
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=20160730184950.2elfi4edvkuthwaw@x \
--to=josh@joshtriplett.org \
--cc=ebiederm@xmission.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/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