linux-kernel - Re: [GIT PATCH] more Driver core patches for 2.6.19

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Dec 2006 20:16:29 +0100
From:	Olivier Galibert <galibert@...ox.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19

On Thu, Dec 14, 2006 at 01:45:16PM +0100, Hans-Jürgen Koch wrote:
> What you suggest is not a "small kernel module". It's what we have now,
> writing a complete driver.

Who says a complete driver has to be big?

> That's what UIO does, plus some standard sysfs files, that tell you e.g.
> the size of the cards memory you can map. There are standard file names
> that allow you e.g. to automatically search for all registered uio 
> drivers and their properties.

Which makes the userspace code much more complex than needed.

> If the card already has that data in its dual port RAM, you do an
> unneccessary copy.

Unnecessary only if
  [card data rate]*[maximum userspace latency] < [dual port ram size].

Doing the buffering in the kernel where it belongs changes the right
part of the equation to [buffer size], which can be orders of
magnitude way bigger.  And you can have the card DMA into the buffer
directly if you feel like it.

> > - implements a read interface to read data from the buffer
> 
> Here you do the next unneccessary copy.

You can mmap, you can splice(), none is really hard.

> > - implement ioctls for whatever controls you need
> 
> Implementing ioctls for everything is bad coding style and a has bad
> performance.

I thought the ALSA guys always said their stuff was high performance?

In any case, if ioctl is too slow for your controls, it means that
your ioctls are too low level, as in register access instead of
"reboot card at address x".  And uio, with its lack of protection
against wandering interrupts, can't cut it.

> I said "high-end AD card", that means you have a 
> signal processor on that board, want to download firmware to it 
> and so on. You end up copying lots of data between user space
> and kernel space.

You're allowed to implement write() too.

> Yes, that's a complete kernel driver that you'd never get into
> a mainline kernel. Furthermore, the card manufacturer would have to
> employ at least two experienced Linux _kernel_ programmers. That's
> too much for a small company who's business is something different.

So they have a choice between learning a minimum of linux kernel
internals, or a minimum of uio.  I suspect the hidden kinks of uio and
relative lack of documentation make the kernel route *way* easier.

> You can achieve 100 lines with uio, including sysfs and poll. What you
> describe would never fit in 200 lines for a non-trivial card.

Ok, 200 is an exaggeration.  Here is a 600-lines 2.4 driver that does
what I say, with direct dma to the internal buffer from the card and
userland-driven firmware upload.  I know that a 2.6 version would
actually be smaller.

  OG.

View attachment "iiadc64.c" of type "text/x-csrc" (14658 bytes)

View attachment "iiadc64.h" of type "text/x-chdr" (1478 bytes)