On Mon, Mar 20, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> 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.
For all of the reasons that have existed since Linux (and many other
Unixes) have been created.
Does it need kernel support (ie access to hardware resources, kernel
resources, kernel API, etc)?
> > 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.
Putting something into the kernel is not done because the user level
support doesn't exist yet. You put dc2xx.c into the kernel for all the
wrong reasons. I can respect getting something working now, but that is
not a good reason for keeping it in the kernel.
> > 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.
It can do everything in userspace that a kernel driver can do, except
for provide a driver for an existing kernel API. Digital still cameras
don't have a kernel API, so there's no reason for putting it into the
kernel.
> But it's irrelevant for scenario 2.
Unfortunately, language support is not a good reason for putting
something into the kernel.
I could say that I can't do ioctl's from PHP, but that's why I don't use
PHP for this particular task.
Thank of it this way, you put something into the kernel because you have
to. You don't put something into the kernel because you can.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
