David Cambell (email@example.com)
Fri, 19 Mar 1999 08:11:01 -0500 (EST)
> Wondered what the opinions were on the fact that parport, and other drivers no
> doubt, always assume they are returning data to user-space. Hence they verify
> whether the data buffer is readable or writable.
Not always, SCSI style drivers leave the buffer management to the mid-level
> 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.
> In addition, its also not always possible to know whether the parport routine
> that is being called is verifying a buffer. It may not if its dealing with
> single bytes of data, as opposed to a larger buffer.
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).
> 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.
> Any comments or efficient workarounds? Having to wrap set_fs() around every
> call to a parport api seems ridiculous.
As I said before, try bulk copy between userland and kernel using
(reach here for grep on the kernel headers) with the
I hope this gives you some ideas....
-- To unsubscribe, send mail to: firstname.lastname@example.org --
-- 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:24 EST