Dale Whitfield (dale@elad.cix.co.uk)
Fri, 19 Mar 1999 13:52:19 +0000
>> It appears that validating storage as well as the __get_user()/__put_user type
>> routines are designed for calls from user-space only. It seems unnecessarily
>> restrictive for calls from drivers and somewhat pointless. Drivers calling
>> drivers are penalised by having to set things up before the call, rather than
>> applications. I'd have thought the reverse would be true.
>
>I am scratching my head here trying to figure out what you are talking about.
>For block devices you either have a statically allocated array or kalloc
>some space, copy the data from user land into kernel space and update a
>pointer or two. After it is in the kernel land array you are free to
>mangle the data at your hearts content.
That assumes the philosophy of copying buffers around. I'm dealing with images
which would require copying buffers of up to 256k in size. Its bad enough
trying to allocate enough working storage for this in the driver already, with
the kmalloc limits etc.
The issue is that most original parport routines only read or write one
character at a time. However, there are new routines which can read/write,
using dma or pio, large blocks of data. Its not correct to assume these blocks
of data originate in user-space. My camera driver, for example, needs to build
and write a 128k compression table to the camera. This is done in kernel-space,
it has nothing to do with an application. A lot of setting up goes on inside
the driver about which the user knows nothing and never needs to know about. In
fact, smaller blocks of data may even be on the driver's stack.
>Umm... I can not seem to locate a get_user() in my 2.2.0 source code here
>as part of the parport drivers. I think you will find that the code that
>dirrectly interfaces with user land is responsible for buffer management.
>(here I user the term buffer managemnet loosely in the context of
>shifting data between the application and kernel regions).
No, its in the IEEE1284 support which is fairly recent.
You raise the same question: "the code that directly interfaces with user
land". Who decides where or what this may be? Surely, you either assume that
parport always interfaces with "mid-level" (ie. kernel) drivers, or it always
interfaces with user-land?
>> This is particularly relevant in the vc-qcam driver I'm writing which makes a
>> huge number of calls to parport.
>
>The bulk of the parport calls should resolve down to single "asm" statements,
>at least for the port access level.
Not for IEEE1284 support, I'm afraid. If only!!! There's often a load of bit
twiddling and handshaking of control lines before a byte of data changes
hands...
>As I said before, try bulk copy between userland and kernel using
>(reach here for grep on the kernel headers) with the
User-land has nothing to do with most of the calls, unfortunately...
Dale.
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Sun 28 Mar 1999 - 17:02:30 EST