linux-kernel - Re: Can we move device drivers into user-space?

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: <20120224201027.GA4859@polaris.bitmath.org>
Date:	Fri, 24 Feb 2012 21:10:27 +0100
From:	"Henrik Rydberg" <rydberg@...omail.se>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Guenter Roeck <guenter.roeck@...csson.com>,
	Jidong Xiao <jidong.xiao@...il.com>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Can we move device drivers into user-space?

> > > So yes, people will always do stupid, foolish things.  And they were
> > > doing them before UIO came along, now they just have the chance to at
> > > least do those foolish things in a way that interfaces with the kernel
> > > in a semi-sane manner, not messing anything else in the kernel up.
> > 
> > So the question is; can the uio example be repeated in other areas, to
> > bring more kernel power to userspace?
> 
> What exactly do you mean by "more kernel power"?  You can write
> userspace char drivers, filesystems, usb drivers, usb gadget drivers,
> and lots of other things today with the interfaces we provide from the
> kernel.

This is all good, but the thread was started for some generic reason
not covered by those examples. The uio interface was pointed out
because it brings pci(e) to userland, which was not (readily)
accessible before. However, every driver that cannot be implemented in
userspace is another example.

I am not complaining about the kernel and its driver structure - on
the contrary. I do, however, see a reason why constructing lower-level
interfaces to userspace may be of benefit. The kernel is growing
tremendously fast. Sooner or later, parts of the present driver
responsibility will have to be split into smaller chunks. Why not
place those chunks outside the kernel itself?

> And even better yet, please show what you mean with patches.

Sure. This particular thread seems to transcend patches, though. It
does not hurt to vent public opinion every now and then.

Henrik
--
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/