User: Password:
|
|
Subscribe / Log in / New account

Airlie: raspberry pi drivers are NOT useful

Airlie: raspberry pi drivers are NOT useful

Posted Oct 25, 2012 22:26 UTC (Thu) by asbradbury (guest, #47625)
Parent article: Airlie: raspberry pi drivers are NOT useful

It's also worth reading Alan Cox's view (second page of the comments): http://www.raspberrypi.org/archives/2221#comment-35253


(Log in to post comments)

Airlie: raspberry pi drivers are NOT useful

Posted Oct 25, 2012 22:40 UTC (Thu) by Zizzle (guest, #67739) [Link]

> I can only assume Dave Airlie is also upset that he can’t step the disk head by himself on his hard disk.

Hmmm... aren't the kernel devs frequently clamoring for direct access to flash devices instead of working around firmware and FTL bugs?

Aren't the kernel devs all about common infrastructure for drivers? Clearly this driver won't be using DRM2 KMS DMA-BUF etc.

Like David points out, there will be no optimization opportunities with this firmware blob abstraction layer type driver.

Also what is the state of X acceleration on the Pi?
Does this firmware blob provide 2D primitives?
The 2D on OpenGL glamor benchmarks I have seen have been less than impressive.

I think it far from wise for senior kernel guys to endorse this model of abstract everything away in a closed firmware blob and provide us some open source RPC stubs.

Airlie: raspberry pi drivers are NOT useful

Posted Oct 26, 2012 9:41 UTC (Fri) by renox (subscriber, #23785) [Link]

>> I can only assume Dave Airlie is also upset that he can’t step the disk head by himself on his hard disk.
>Hmmm... aren't the kernel devs frequently clamoring for direct access to flash devices instead of working around firmware and FTL bugs?

Yes they do(*), but this doesn't prevent them to include drivers in the kernel for these devices..

*: disks which lie about the state of the data are hugely annoying as well.

Airlie: raspberry pi drivers are NOT useful

Posted Oct 25, 2012 23:21 UTC (Thu) by luto (subscriber, #39314) [Link]

I tend to agree with that. ISTM that maybe the design of the device is suboptimal, but I don't see what's wrong with the driver given how the hardware is set up.

Airlie: raspberry pi drivers are NOT useful

Posted Oct 26, 2012 3:50 UTC (Fri) by airlied (subscriber, #9104) [Link]

I'm going to get to a follow up post as some point once I've digested and not thrown up more of the code.

But essentially providing any sort of DRI infrastructure on this where you want user processes to directly access the RPC interface, could be a security problem.

The GPU can access anything in RAM it wants afaik, and we've no idea what the complete command space the RPC interface covers. If there is any possibility that you can get the GPU do to something bad via the RPC interface, then you would need to audit all commands sent from userspace against a known list of safe ones in the kernel driver.

Their code afaik doesn't do any of that.

Airlie: raspberry pi drivers are NOT useful

Posted Oct 26, 2012 3:53 UTC (Fri) by bjacob (subscriber, #58566) [Link]

I'm not a free-as-in-freedom die-hard, but I know a bit about GL stuff, and Alan's comment doesn't make sense to me. The premise in Alan's comment seems to be that GLES2 is a low-level enough, universal enough interface to graphics hardware that you wouldn't in your right mind want any lower-level interface to it. Whence his "move the HDD heads" analogy.

That premise is really false, and the HDD analogy, just wrong. GLES2 is plenty high-level enough that you could reasonably want a lower-level interface to graphics hardware. Cases in point:
1) all GL implementations/drivers that I know have serious bugs that affect stability, security, performance, correct rendering, and memory usage of applications using them, and force serious applications to actively work around them. (I work on the Mozilla Gfx team and we have work-arounds in place for about every GL implementation we've encountered).
2) there exist competing APIs on the same level, especially Direct3D. They have the same issues as in 1).
3) there exists innovation in the area of establishing new interfaces to graphics hardware, either at the same level as GLES2 (e.g. GLES3) or on a lower level than GL's (e.g. Gallium3D).

I hope it's clear that these 3 points are valid reasons why anyone interested in graphics programming, let alone a driver developer, would be disappointed that any given flavor of GL is presented by a hardware vendor as the unique possible interface to their hardware.

Airlie: raspberry pi drivers are NOT useful

Posted Oct 26, 2012 8:09 UTC (Fri) by khim (subscriber, #9252) [Link]

I can understand disappointment, but I can not see what the fuss is all about.

Bugs? CD drives and, especially, chipsets (especially easrly IDE chipsets) have tons of them - and kernel contains quite a set of workarounds. Some are not usable because of bugs.

Different APIs? Well, there were Creative/MKE/Panasonic, Mitsumi, and Sony interfaces - which needed different code in a supporting program. That was before ATAPI won, of course.

Support for different APIs? There were tons of them. Besides three CD-specific ones there were ATAPI, SCSI - and these evolved over time.

IOW: I see absolutely nothing unique in this driver. Well, except for the fact that graphic driver developers feel that they deserve to have lower-level interface then what Broadcom is offering.

Basically everything "bad" people are now saying about these drivers you could have said about CD interfaces when when they were "hot".

Airlie: raspberry pi drivers are NOT useful

Posted Oct 26, 2012 12:34 UTC (Fri) by bjacob (subscriber, #58566) [Link]

I disagree again with the disk analogy here: why you were able to list some comparable issues with disks, the issues with graphics APIs are of a far greater magnitude.

Disk drivers don't typically cause your applications to crash. Disk driver bugs may have been problematic in the past but today, either due to being fixed or due to work-arounds, they're not an issue anymore for the user. Graphics driver bugs are a major user-visible issue everyday. We have detailed crash statistics for Firefox and driver issues are a significant cause of crashes. We had to add blacklists for graphics driver to bring crashiness down to acceptable levels. I don't think that any application has disk driver blacklists.

The correct disk analogy would be if a disk could only be used via the stdio and POSIX file API --- fopen, fwrite, fclose, chmod, unlink, etc. You wouldn't be able to access the disk as a block device at all, you couldn't even know or change what filesystem it's formatted as, and for reformatting/partitioning you could only use an opaque vendor-provided tool.

Airlie: raspberry pi drivers are NOT useful

Posted Oct 26, 2012 15:28 UTC (Fri) by renox (subscriber, #23785) [Link]

> I disagree again with the disk analogy here: why you were able to list some comparable issues with disks, the issues with graphics APIs are of a far greater magnitude.

Very funny, quite a few disk firmware lie(lied?) about the state of the data causing data loss in case of a crash because the firmware said that the data was on the disk even though it wasn't.
So closed source disk firmware is a very big issue, but at least you can try to select providers with good firmware..

Airlie: raspberry pi drivers are NOT useful

Posted Oct 26, 2012 17:00 UTC (Fri) by magila (subscriber, #49627) [Link]

Speaking of lies...

Disks only "lie" about write data having been written if they are configured with write cache enabled. In this case they aren't lying at all, they are doing exactly what they were told to do. Turning off write caching will ensure no write completes without having been written to non-volatile storage. There may be isolated incidents where there are legitimate bugs in this functionality, but the overwhelming majority of drives have no issues here.

Airlie: raspberry pi drivers are NOT useful

Posted Oct 27, 2012 7:48 UTC (Sat) by farnz (subscriber, #17727) [Link]

The historical problem to which people are referring is drives lying. There is a command in the ATA specification, FLUSH CACHE, documented as not completing until all data stored in drive caches is written to the disk. Back before ATX power supplies, many desktop drives completed the FLUSH CACHE command as soon as it came in, and then wrote the data from the cache to the platters as if no FLUSH CACHE command had been received, to improve benchmark results; it was sufficiently common a problem that Microsoft issued a hotfix for Windows 98SE and Windows ME that simply put in a two second delay before powering off the computer.

Airlie: raspberry pi drivers are NOT useful

Posted Oct 26, 2012 17:05 UTC (Fri) by khim (subscriber, #9252) [Link]

Disk driver bugs may have been problematic in the past but today, either due to being fixed or due to work-arounds, they're not an issue anymore for the user.

It's quite an argument: because disks have good firmware in 2012 it's Ok to include CD Linux drivers in 1993. So you are saying that GPU firmware is still problematic in 2031 and thats the problem with Broadcom's driver? I wish to have such a precise crystal ball.

We had to add blacklists for graphics driver to bring crashiness down to acceptable levels. I don't think that any application has disk driver blacklists.

I was talking about CD drivers, not about HDD drivers. CD burning software usually has extensive list of workarounds for different devices.

The correct disk analogy would be if a disk could only be used via the stdio and POSIX file API --- fopen, fwrite, fclose, chmod, unlink, etc. You wouldn't be able to access the disk as a block device at all, you couldn't even know or change what filesystem it's formatted as, and for reformatting/partitioning you could only use an opaque vendor-provided tool.

Ah, you mean MTP? Yeah, it's supported by Linux, too. Both as host and as target.

Airlie: raspberry pi drivers are NOT useful

Posted Oct 26, 2012 15:03 UTC (Fri) by Zizzle (guest, #67739) [Link]

> I can understand disappointment, but I can not see what the fuss is all about.

Following the disk analogy, this more like your disk only exposing a filesystem interface.

And then the manufacture claiming it's the most open device ever.

Want to improve performance? Fix bugs? Use a FS more suited to your needs?

Better start begging Broadcom.

But it gets better, the Alan Cox is endorsing this model. Maybe all linux drivers should just be RPC shims in front of closed firmware blobs. Yay freedom.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds