linux-kernel - Re: [PATCH 01/13] kdbus: add documentation

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20150123131946.GA26302@kroah.com>
Date:	Fri, 23 Jan 2015 21:19:46 +0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	"Ahmed S. Darwish" <darwish.07@...il.com>
Cc:	arnd@...db.de, ebiederm@...ssion.com, gnomes@...rguk.ukuu.org.uk,
	teg@...m.no, jkosina@...e.cz, luto@...capital.net,
	linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
	daniel@...que.or, dh.herrmann@...il.com, tixxdz@...ndz.org,
	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Daniel Mack <daniel@...que.org>
Subject: Re: [PATCH 01/13] kdbus: add documentation

On Fri, Jan 23, 2015 at 08:28:20AM +0200, Ahmed S. Darwish wrote:
> On Fri, Jan 16, 2015 at 11:16:05AM -0800, Greg Kroah-Hartman wrote:
> > From: Daniel Mack <daniel@...que.org>
> > 
> > kdbus is a system for low-latency, low-overhead, easy to use
> > interprocess communication (IPC).
> > 
> > The interface to all functions in this driver is implemented via ioctls
> > on files exposed through a filesystem called 'kdbusfs'. The default
> > mount point of kdbusfs is /sys/fs/kdbus.
> 
> Pardon my ignorance, but we've always been told that adding
> new ioctl()s to the kernel is a very big no-no.  But given
> the seniority of the folks stewarding this kdbus effort,
> there must be a good rationale ;-)
> 
> So, can the rationale behind introducing new ioctl()s be
> further explained? It would be even better if it's included
> in the documentation patch itself.

The main reason to use an ioctl is that you want to atomically set
and/or get something "complex" through the user/kernel boundary.  For
simple device attributes, sysfs works great, for configuring devices,
configfs works great, but for data streams / structures / etc. an ioctl
is the correct thing to use.

Examples of new ioctls being added to the kernel are all over the
place, look at all of the special-purpose ioctls the filesystems keep
creating (they aren't adding new syscalls), look at the monstrosity that
is the DRM layer, look at other complex things like openvswitch, or
"simpler" device-specific interfaces like the MEI one, or even more
complex ones like the MMC interface.  These are all valid uses of ioctls
as they are device/filesystem specific ways to interact with the kernel.

The thing is, almost no one pays attention to these new ioctls as they
are domain-specific interfaces, with open userspace programs talking to
them, and they work well.  ioctl is a powerful and useful interface, and
if we were to suddenly require no new ioctls, and require everything to
be a syscall, we would do nothing except make apis more complex (hint,
you now have to do extra validation on your file descriptor passed to
you to determine if it really is what you can properly operate your
ioctl on), and cause no real benefit at all.

Yes, people abuse ioctls at times, but really, they are needed.

And remember, I was one of the people who long ago thought we should not
be adding more ioctls, but I have seen the folly of my ways, and chalk
it up to youthful ignorance :)

Hope this helps explain things better,

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/