Johannes Erdfelt wrote:
>
> On Mon, Mar 06, 2000, Dunlap, Randy <[EMAIL PROTECTED]> wrote:
>
> > And finally, where do you/I/we draw the line on
> > what goes into the kernel (for USB driver support) and
> > what does not? How do we differentiate and spell
> > out to driver developers what is acceptable and
> > what is not?
I missed something -- the "why we must draw this particular line".
I'd be more interested in the "when would we remove something
from the kernel" question. Clearly, if we'd remove it as soon
as it went in, that might answer Randy's question ... but it'd
also answer a few related important questions too.
> I've been trying to convince David Brownell that the dc2xx driver does
> not need to be in the kernel. In fact I even went as far as hacking in
> all of the USB support into the next version of gphoto and I'm about to
> submit my digita driver.
Of course, that's only part of the story. You could look at
the very last paragraph in my info page about that:
http://home.pacbell.net/david-b/digicam
My issues with the approach Johannes has presented to me are twofold:
* First, that whole infrastructure won't be complete/usable
for some time. Steps are being taken, but they're not all
ready yet, and meanwhile ... people have been using USB and
DC-2xx cameras since last August.
They can switch to new tools when/if they're available. I'm
not sure that smaller systems will want to bulk up on code
steroids anyway, even if it does become a common way for bigger
systems to use USB.
* Second, as someone who doesn't program exclusively in C/C++,
APIs that rely on features like ioctl() [ which was needed,
last I knew, to write a user mode devfs-based driver ], even
if it had been complete and perfect this morning, I still
couldn't have used it.
I've got to work with java.io.File, which doesn't have ioctls.
and writing native code to talk to the kernel via a libusb is
a non-option.
Re the missing pieces in the first point above, I think I'm wondering
about the "usbd" work -- stuff to interact with devfs, intelligently
load kernel modules, manage permissions for device specific files,
and so on.
> Things like digital still cameras, scanners and the like which usually
> have no kernel interface (gphoto uses serial, sane uses SCSI genric,
> etc) are very good candidates for being userspace.
That's scenario 1 to a tee. Though from what I know, user mode isn't
a complete replacement (yet?) for a kernel mode driver.
But it's irrelevant for scenario 2.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
