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

s/driver/documentation/

s/driver/documentation/

Posted Jul 5, 2010 14:48 UTC (Mon) by avik (guest, #704)
Parent article: A line in the sand for graphics drivers

I don't think it's right to demand an open driver. Instead, demand full documentation of the interface. Every bit of the buffers passed into the kernel should be documented, and if anyone is interested, they can write the user code for that.


(Log in to post comments)

s/driver/documentation/

Posted Jul 5, 2010 15:04 UTC (Mon) by hummassa (subscriber, #307) [Link]

> I don't think it's right to demand an open driver.

I think it's right, for someone who volunteers to maintain that part of the kernel tree, to demand anything she seems fit to demand that will make possible to do said maintenance, before she merges some patch from someone.

A closed driver has the potential make that maintenance difficult (or even impossible), so...

s/driver/documentation/

Posted Jul 5, 2010 15:38 UTC (Mon) by kirkengaard (guest, #15022) [Link]

And it isn't simply arbitrary.

The trouble, as was mentioned, is that this isn't just an interface. We have a boatload of interfaces. I think one of the good comparisons is sound drivers. There are quite a few high-end cards that have chip drivers in ALSA, but you use JACK and some other userspace programs to get full function out of them. But the drivers are complete and perform properly (modulo some tinkering) for the chips they drive, and the userspace components sit over the driver or work through it. We're talking instead about half of a driver.

If the submitter wishes the driver to be in the kernel, it is perfectly appropriate for the developer to advise them that the whole driver needs to be open. One way to comply might be to document and re-engineer the kernel component in order to develop a compliant userspace component; another might be to write an all-kernelspace driver; another might be to rip out what "must" be binary blob for now and open everything else -- but only as a first step. I doubt that throwing documentation over the wall will make it acceptable as-is.

s/driver/documentation/

Posted Jul 5, 2010 16:10 UTC (Mon) by ebiederm (subscriber, #35028) [Link]

Please notice that Dave is a man and use the gender appropriate pronoun, or if you are speaking in general please use the plural, as in English that is always gender neutral.

A maintainer can ask for too much, and that is why in Linux there is always the possibility to route around a maintainer. Not that this happens often.

In this case one of the primary complaints is poor userspace ABI design, and that is always a valid issue to push back on. Even the most temporary, transient and little used ABIs requires years to phase out.

Overall it appears to be a good thing this conversation is happening, and I hope this can get settled before too much more time passes.

s/driver/documentation/

Posted Jul 5, 2010 16:41 UTC (Mon) by njs (guest, #40338) [Link]

> Please notice that Dave is a man and use the gender appropriate pronoun, or if you are speaking in general please use the plural, as in English that is always gender neutral.

...Huh, I thought it was pretty obvious that they were speaking in general, and the use of, say, alternating gender pronouns for generics is very common.

Do you make this comment every time someone uses a generic "he"?

s/driver/documentation/

Posted Jul 5, 2010 23:53 UTC (Mon) by hummassa (subscriber, #307) [Link]

And, furthermore, I was under the impression that "she" was a correct way to say "one person, any person, of any gender".

s/driver/documentation/

Posted Jul 6, 2010 1:53 UTC (Tue) by csamuel (✭ supporter ✭, #2624) [Link]

I would suggest "they" instead, as it's gender neutral (he and she aren't).

s/driver/documentation/

Posted Jul 6, 2010 3:38 UTC (Tue) by njs (guest, #40338) [Link]

Certainly "they" is an option, and often recommended for this; but "he or she", and picking one at random and alternating, are also both accepted and commonly used: http://www.unc.edu/depts/wcweb/handouts/gender.html

They all have their advantages and disadvantages, but I was more struck at the suggestion that using "she" was illegitimate, when in actual usage it plainly isn't.

s/driver/documentation/

Posted Jul 6, 2010 9:25 UTC (Tue) by rsidd (subscriber, #2582) [Link]

"They" is often ungrammatical when used for this purpose. At best, it leads to grammatical but horribly contorted sentence constructions. "She" is fine by me: no matter how much and how often "she" is used, it will take a while to overcome existing bias, leave alone historical bias. It's ok to refer to Dave, or other males, now and then as "she": it's certainly no worse than referring to a woman as "he", which happens to women all the time, and it does force readers to think about sexist language.

s/driver/documentation/

Posted Jul 6, 2010 10:44 UTC (Tue) by nix (subscriber, #2304) [Link]

What? People of unknown gender are singular they; people of known male/female gender are he/she. The unfortunate convention of referring to single people of unknown gender as 'he' is bad enough (and can nearly always be substituted with singular they or in extremis the clumsy 'he or she'), but referring to specific single people of known gender with the opposite-gendered singular personal pronoun is like spikes in the eyes. It's *always* wrong.

s/driver/documentation/

Posted Jul 6, 2010 10:54 UTC (Tue) by rsidd (subscriber, #2582) [Link]

What's "singular they"? Would you write "they sees fit" or "they merges some patch"? Doesn't sound like English to me.

Of course, you can use plural they if you make all references plural. This is usually awkward and sometimes impossible.

s/driver/documentation/

Posted Jul 6, 2010 11:36 UTC (Tue) by nye (guest, #51576) [Link]

>What's "singular they"?

Possibly you should have looked it up before proceeding.

When you talk about using the 'plural they', you are of course obliquely referring to the fact that 'they' remains morphologically plural in all (correct) uses, however its usage to refer to a singular subject is well established.

It has been the preferred style for decades, an accepted style for centuries, and an existing style in English since so long ago that the language is barely recognisable.

If you can present an example sentence where using 'he' or 'she' is grammatically correct, but 'they' is not, then I would be interested to hear it.

s/driver/documentation/

Posted Jul 6, 2010 11:56 UTC (Tue) by farnz (subscriber, #17727) [Link]

"Singular they", as used by authors from Shakespeare onwards, is things like "they see fit" and "they merge a patch". It's simply the same pattern as "singular you"; or art thou one of the people who insisteth that "you" must be reserved for the plural form, and who joketh about "you sees fit" and "you merges a patch"?

s/driver/documentation/

Posted Jul 20, 2010 17:10 UTC (Tue) by pdundas (guest, #15203) [Link]

Thou speakest wisely. But prithee tell, surely thou wantedst to say "thou insistest" or "thou jokest"?

I joke / thou jokest / he joketh, et ceterea...

s/driver/documentation/

Posted Jul 20, 2010 17:17 UTC (Tue) by pdundas (guest, #15203) [Link]

Doh! Thou art right. I shall don mine coat, and quit this thread.

s/driver/documentation/

Posted Jul 6, 2010 23:49 UTC (Tue) by csamuel (✭ supporter ✭, #2624) [Link]

It's "they see fit" (or "they saw fit" for past tense), "they are merging some patches" ("they merged some patches" for past tense).

s/driver/documentation/

Posted Jul 16, 2010 7:48 UTC (Fri) by dododge (subscriber, #2870) [Link]

Just as more background material: the OED lists the singular use of "they" as "often used" and gives numerous examples back to 1526 "Yf..a psalme scape ony persone, or a lesson, or else yt they omyt one verse or twayne."

For further reading they reference Jespersen's "Progress in Language", which discusses it in more detail and gives many more examples. You can find scans of the 1909 2nd edition at books.google.com, with the relevant text in section 24 on pages 27-30.

s/driver/documentation/

Posted Jul 6, 2010 11:06 UTC (Tue) by farnz (subscriber, #17727) [Link]

Traditionally, in English, you use the plural form as a highly respectful singular. So, for 1st person, you have the "royal we" - or use of 1st person plural for a singular entity. For second person, we've completely lost the 2nd person singular (thou), in favour of always using the 2nd person plural in its role as the respectful 2nd person singular. We also use 3rd person plural as a respectful 3rd person singular in English.

Arguably, the fix to the existing habit of subconsciously sexist language is not to just flip the sexism round some of the time, but to make the same move for 3rd person as we've made for 2nd person - drop he/she/it when referring to a singular entity (except when gender is important), and use the 3rd person plural form ("they are" instead of "he/she/it is") in its traditional role as a respectful singular.

So much grammar correction, so little correct!

Posted Jul 7, 2010 21:22 UTC (Wed) by baldridgeec (guest, #55283) [Link]

Or better still one could utilize a form which is less oft seen in informal English, but easily remembered by a student of linguistics or esp. Romance languages - the third person indefinite personal pronoun. It exists for precisely this sort of case.

So much grammar correction, so little correct!

Posted Jul 7, 2010 21:26 UTC (Wed) by farnz (subscriber, #17727) [Link]

Except that the modern English usage of "one" places it as a variation on the first person, not the third - one tends to use it not to mean "an unidentified individual", but to mean "an individual from the set that I would cover if I were to use we".

So much grammar correction, so little correct!

Posted Jul 7, 2010 21:51 UTC (Wed) by baldridgeec (guest, #55283) [Link]

Is that really accurate? My observation has been that one tends to use it on behalf of the group for which one is advocating in an argument, but I wouldn't want to rephrase the first half of this sentence using the phrase "I tend," because I'm not referring to myself, but to every instance I have ever heard or read in which the case was used.

(Rereading this before submission, I realize that you could just quote the above paragraph and respond with "QED." :) More meat follows below.)

I assume that that sort of observation (that it coincides with an individual from the first person plural set) stems from the fact that one does not often pose arguments which prescribe the behavior of groups which exclude oneself - that doesn't mean it can't happen though.

One may believe that one's computer is powered by hamsters on exercise wheels, but one would be incorrect. :)

So much grammar correction, so little correct!

Posted Jul 8, 2010 10:20 UTC (Thu) by farnz (subscriber, #17727) [Link]

It's a difficult one (the joys of a language defined by usage, not prescribed by an academy); in my experience the use of "one" is either a "posh way of saying I", or "this is what should happen in an ideal world, not necessarily what anyone in particular does". Singular they feels slightly weird, but doesn't come with that baggage.

Of course, this is all based on past experience - and continued use of "one" as a gender-neutral singular would change the implications. If only programming languages had a similar habit of changing to adapt to what is meant, not what it used to mean :)

s/driver/documentation/

Posted Jul 6, 2010 10:13 UTC (Tue) by nye (guest, #51576) [Link]

>I was under the impression that "she" was a correct way to say "one person, any person, of any gender".

As a purely factual point, this is incorrect in English.

s/driver/documentation/

Posted Jul 6, 2010 11:09 UTC (Tue) by sorpigal (subscriber, #36106) [Link]

In English the correct gender-neutral term is "he." Some people don't like this for various reasons and choose to substitute "she" as gender neutral, often in an attempt to combat a perception of male dominance or out of a sense of fairness. "They" is also often used as a neutral form but it is incorrect (ungrammatical) when used to refer to a singular entity.

Regardless of the reasons for the origin of the use, "he" and "him" are correct when the gender is unknown or ambiguous. Other forms, no matter how common, are not good English.

English

Posted Jul 6, 2010 11:43 UTC (Tue) by samth (guest, #1290) [Link]

Regardless of the reasons for the origin of the use, "he" and "him" are correct when the gender is unknown or ambiguous. Other forms, no matter how common, are not good English.
This is totally false. First, the use of singular "they" is long-standing and good English, used by "Addison, Austen, Chesterfield, Fielding, Ruskin, Scott, and Shakespeare", to quote the Chicago Manual of Style. Second, prescriptivism is wrong about language, as a general principle, and thus your second sentence is false regardless of the particular topic.

s/driver/documentation/

Posted Jul 6, 2010 11:49 UTC (Tue) by nye (guest, #51576) [Link]

>"They" is also often used as a neutral form but it is incorrect (ungrammatical) when used to refer to a singular entity.

Simply wrong. There is no reason to support this assertion; it's a modern invention with no reasoning behind it - simply an arbitrary decision by a handful of grammatical prescriptivists who choose to ignore the large corpus of historical English text, not to mention the overwhelming current usage.

Since we mostly hear it coming from Americans, I conjecture that it may originate in Strunk and White (a highly questionable but ubiquitous American grammar guide).

s/driver/documentation/

Posted Jul 6, 2010 13:24 UTC (Tue) by anselm (subscriber, #2796) [Link]

Regardless of the reasons for the origin of the use, "he" and "him" are correct when the gender is unknown or ambiguous. Other forms, no matter how common, are not good English.

Please take this over to the Language Log blog at http://languagelog.ldc.upenn.edu/nll, where linguists, i.e., professionals who know a great deal about things like English grammar and usage, will quickly disabuse you of this notion.

s/driver/documentation/

Posted Jul 5, 2010 17:08 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

Once you're at the point of something as complex as a graphics driver, interface documentation is unlikely to be both precise and accurate. Say we end up with an open kernel driver, a closed userspace implementation and an open userspace implementation. Part of the interface documentation can be interpreted in two different ways, and interpreting it one way gives a significant performance boost to the open component and breaks the closed component. Do we accept the patch or refuse the patch? What if one interpretation allows DMAing to arbitrary addresses?

And this ignores the fact that any interface documentation for a graphics driver's kernel component is likely to be of the form "This ioctl submits a buffer of GPU commands to the device". These commands will typically not be interpreted by the kernel code beyond certain sanity checking, so documenting the interface does little to tell us how to implement a userspace version of the same code. Interface documentation is better than no interface documentation, and hardware documentation is better still. But if we have a kernel component with a well-defined ABI then that impairs our ability to implement a userspace driver unless we also develop a parallel kernel component. And that way lies madness.

s/driver/documentation/

Posted Jul 5, 2010 17:35 UTC (Mon) by avik (guest, #704) [Link]

Once you're at the point of something as complex as a graphics driver, interface documentation is unlikely to be both precise and accurate.
Then the driver+documentation is unlikely to be accepted. We need to insist on quality docs, just as we insist on quality code.

Say we end up with an open kernel driver, a closed userspace implementation and an open userspace implementation. Part of the interface documentation can be interpreted in two different ways, and interpreting it one way gives a significant performance boost to the open component and breaks the closed component. Do we accept the patch or refuse the patch?
We request a clarification to the specification.

What if one interpretation allows DMAing to arbitrary addresses?
Then it's clearly a bug. Both driver and documentation need to be fixed.

None of the above change when you get an open source driver instead of documentation. In fact, a driver is less likely to be complete (since it won't implement all capabilities), though more likely to be accurate (since it can be tested). Documentation contains a superset of the information in a driver, since you can write a driver based on the documentation, but you can't write the entire documentation from reading the driver source.

And this ignores the fact that any interface documentation for a graphics driver's kernel component is likely to be of the form "This ioctl submits a buffer of GPU commands to the device".
Such documentation should be rejected. Documentation should describe exactly what happens with the bits, either directly or by referring to hardware documentation.

These commands will typically not be interpreted by the kernel code beyond certain sanity checking, so documenting the interface does little to tell us how to implement a userspace version of the same code. Interface documentation is better than no interface documentation, and hardware documentation is better still.
what you describe is not an interface documentation, but a tunnel documentation. That should be rejected.

But if we have a kernel component with a well-defined ABI then that impairs our ability to implement a userspace driver unless we also develop a parallel kernel component. And that way lies madness.
Certainly, I got confused just reading that last paragraph.

s/driver/documentation/

Posted Jul 5, 2010 17:40 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

If we have full hardware documentation and we're expected to write our own userspace, then we also want to write our own kernel code. There's no incentive whatsoever for us to merge the upstream provided kernel code. If we do then we provide an interface that we're expected to support forever (see the argument over nouveau breaking ABI), and the only consumer of that interface is a closed userspace driver.

s/driver/documentation/

Posted Jul 5, 2010 17:50 UTC (Mon) by avik (guest, #704) [Link]

If we have full hardware documentation and we're expected to write our own userspace, then we also want to write our own kernel code.
Why? If the driver is good, accept it.

There's no incentive whatsoever for us to merge the upstream provided kernel code.
You get not to write that much code.

If we do then we provide an interface that we're expected to support forever (see the argument over nouveau breaking ABI), and the only consumer of that interface is a closed userspace driver.
Of course we should encourage an open source userspace driver, and with full documentation, there is really no reason not to open source the driver. But as a rule, adding a syscall should not require adding a consumer for that syscall.

s/driver/documentation/

Posted Jul 5, 2010 17:56 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

Because merging the upstream kernel component requires either slavishly adopting the same interface (and thus limiting our ability to write a driver), keeping one kernel driver that supports two different interfaces (maintenance nightmare) or providing two different kernel drivers (one of which will probably end up bitrotting). If the only consumer of the kernel code is a closed driver, we don't want it. If accepting it constrains our ability to write an open driver, we don't want it. In summary - we don't want it. It's great as an example of driving the hardware, and if it comes with documentation it's an excellent basis for the driver that does actually get merged. But it's not going into the kernel.

s/driver/documentation/

Posted Jul 5, 2010 18:02 UTC (Mon) by avik (guest, #704) [Link]

If the interface isn't good enough for an open driver, you reject the patch. IOW existing code (open or closed) can not be used as an argument for forcing a bad API on the kernel.

You end up with one driver that can support both the (modified) closed user driver and a newly written open driver.

s/driver/documentation/

Posted Jul 5, 2010 20:23 UTC (Mon) by airlied (subscriber, #9104) [Link]

avik, I don't think you understand how complex these interfaces are.

Its not something you can assess in abstract form, i.e. until you've written a complete graphics driver, both kernel and userspace components you rarely know if the API you chose is going to be correct and performant. However you generally pick the 80% interface, go with that, and hope you can easily make the 100% interface on top of it later.

However unless a single group is developing the kernel and userspace drivers, generally that API is going to be useless and really constrain any one else. So we end up with a driver in the kernel providing an API that only a closed source userspace can exercise and an API that only a open source userspace can exercise, why should we introduce the first API at all.

I don't mind introducing reduced functionality kernel drivers that don't expose major userspace APIs to just serve as an example of how these GPUs work, I don't want a driver with an API commitment and no way for anyone to make sure the API continue working.

s/driver/documentation/

Posted Jul 5, 2010 20:30 UTC (Mon) by airlied (subscriber, #9104) [Link]

I actually said an open driver, or open docs + writing an open driver.

But merging a driver whose only use is exposing an API for a closed source userspace to use is neither of those things.

The API is the problem, adding a restrictive API that we have to maintain indefinitely with no userspace code to test it is the core of the problem from a maintainer point of view.

s/driver/documentation/

Posted Jul 8, 2010 10:07 UTC (Thu) by willnewton (subscriber, #68395) [Link]

It is my understanding that Intel (and their subcontractors) had full documentation of the GMA500 hardware under NDA, but were unable to produce a working driver.


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