[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Article on state of graphics drivers on BSDs
James K. Lowden <jklowden%schemamania.org@localhost> wrote ..
> On Wed, 13 Feb 2013 15:33:25 +1100
> Martin <martin.kelly4000%gmail.com@localhost> wrote:
> > The first problem is an obvious given, that the kernel API's of each
> > system are going to be different unless direct they are forked and
> > have direct compatibility with each other.
> Or maybe it's not obvious, because that's not how I would characterize
> the problem.
> The problem is not that kernels differ. The problem is that X is no
> longer portable. It no longer provides a machine-independent
> layer for the driver. There is no reason, theoretically, that a
> graphics driver should be tied to the kernel, but that's what's
> > So any suggestion of making head-way to unify kernel api's across all
> > systems is out of the question.
> Linux and Apple are surely the biggest X users these days, and probably
> contribute the Lion's share (no pun intended) of the code. Given that
> Apple is doing its own thing with Xquartz, there's essentially no
> motivation among the current developers to maintain a MI API.
> If you wade into these waters, you will find them swift and murky.
> >From the point of view of the Linux-only, Linux-always folks, OS
> independence is pure overhead -- both for the developer and for the
> machine -- whose only purpose is to facilitate portability to an alien
> system. The problem, you see, is not technical.
> The history of bridging the Linux-BSD divide is not encouraging. I can
> think of a few APIs the BSDs adopted from Linux (e.g. iconv and PAM,
> IIRC) but none in the last 10 years, say, that Linux adopted from
> BSD. (Perhaps others have better memories?)
> If you want to try anyway, your mission becomes one of persuasion: to
> convince those involved that a simpler API would facilitate driver
> development *and* kernel development by decoupling them. Surely some
> would accept that argument on its face; others might if you demonstrate
> (in English, not C) that drivers written to your API would be easier to
> implement with no appreciable speed degradation.
> Perhaps the only chance of success is radical departure. Plan 9 can be
> a source of inspiration. It supports graphics through "8½" which serves
> a device, /dev/bitblt. (Beware of the trap that these preclude using
> shared memory. The device is an abstraction, not an implementation.)
> Cf. http://plan9.bell-labs.com/sys/doc/8½/8½.html.
> Defining the interface in terms of I/O would naturally restrict it to
> purely graphical requirements, leaving to the kernel developers the
> choice of how those requirements are met by the kernel.
Linux has moved farther and farther away from being a "free" operating system,
it is laden with proprietary closed-source binary blobs, which are the
"Drivers" you are talking about. There's not much to preach about, and there's
not much use of comparison - it's a matter of a decision whether you choose to
use free or non-free software.
San Jose California USA
Main Index |
Thread Index |