> > 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)?
We'd remove something from the kernel if it needs kernel support???
> > > I've been trying to convince David Brownell that the dc2xx driver does
> > > not need to be in the kernel. ...
> >
> > 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:
>
> ...
>
> Putting something into the kernel is not done because the user level
> support doesn't exist yet.
Did I say that? No.
However, I've seen support start in the kernel and move to userland later.
I've also seen it go the other way. Systems evolve over time. Where to
put a particular chunk of functionality is always a tradeoff, and the
factors being traded off will vary in different applications, and over
time as the system itself changes.
> You put dc2xx.c into the kernel for all the
> wrong reasons.
I guess you never took that class on "How to have Better Discussions
by NOT INSULTING ANYONE", did you? You've got a strange notion of
how to convince someone of your point of view.
> > > 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.
How do I make it so only one user ID can access particular devices?
Last time I looked, those solutions were not only uncoded, but couldn't even
be patched into any platform that's as widely adopted as 2.3 is. Even if it
were that widely adopted, "libusb" couldn't manage such stuff; there's no
TCB
(or analagous) boundary between that and the applications.
> > But it's irrelevant for scenario 2.
>
> Unfortunately, language support is not a good reason for putting
> something into the kernel.
A dogmatic reaction to an argument I didn't make.
And still no solution. Not helpful, if you were really trying to
convince me of anything. Try again.
> Thank of it this way, you put something into the kernel
> because you have to.
Keeping in mind that "have to" is a tradeoff (different assumptions
will make it evaluate differently), that agrees with what I said.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
