linux-kernel - Re: [RFC v1 02/14] bus1: provide stub cdev /dev/bus1

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]

Date:   Sun, 30 Oct 2016 00:13:14 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Tom Gundersen <teg@...m.no>
Cc:     Andy Lutomirski <luto@...capital.net>,
        David Herrmann <dh.herrmann@...il.com>,
        Hannes Reinecke <hare@...e.com>,
        Jiri Kosina <jikos@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Josh Triplett <josh@...htriplett.org>,
        Greg KH <greg@...ah.com>, Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC v1 02/14] bus1: provide stub cdev /dev/bus1

On Thursday 27 October 2016, Tom Gundersen wrote:
> On Thu, Oct 27, 2016 at 11:11 AM, Arnd Bergmann <arnd@...db.de> wrote:
> > On Thursday, October 27, 2016 1:54:05 AM CEST Tom Gundersen wrote:
> >> On Thu, Oct 27, 2016 at 1:19 AM, Andy Lutomirski <luto@...capital.net> wrote:
> >> > This may have been covered elsewhere, but could this use syscalls instead?
> >>
> >> Yes, syscalls would work essentially the same. For now, we are using a
> >> cdev as it makes it a lot more convenient to develop and test as an
> >> out-of-tree module, but that could be changed easily before the final
> >> submission, if that's what we want.
> >
> >
> > Generally speaking, I think syscalls would be appropriate here, and put
> > bus1 into a similar category as the other ipc interfaces (shm, msg, sem,
> > mqueue, ...).
> 
> Could you elaborate on why you think syscalls would be more
> appropriate than ioctls?

Linus already answered this, but I'd also add that core kernel
features just make sense to be syscalls, rather than stuffing
them in a random device driver.

> > - Have a mountable file system, and use open() on that to create
> >   connections. Advantages are that it's fairly easy to have one
> >   instance per fs-namespace, and you can have user-defined naming
> >   of objects in the file system.
> 
> Note that currently we only have one object (/dev/bus1) and each fd is
> disconnected from anything else on creation, so not sure what benefits
> a filesystem (or several instances of it) would give?

I have not tried to understand some of the main concepts of bus1,
so I simply assumed that there was some way of looking up handles
of other instances. Using a file system gives you a natural way
to look up resources by name the way we do e.g. for mq_open(),
and it lets you easy decide whether containers should share
a view of the same namespace by mounting the same instance of
the file system into them or having separate instances.

If you don't ever need to look up a handle by name in bus1, using
a mountable file system would not help you.

	Arnd