On Mon, Mar 20, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> > > 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???
Umm, no. We'd remove it from the kernel if it doesn't have any need to
be in the kernel.
> > > > 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.
I'm not arguing what has been done elsewhere for other
devices/systems/OS's. I'm arguing what should be done in this instance,
for this device/driver and system.
The fact of the matter is, dc2xx.c does not need to be in the kernel.
> > 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.
Regardless if you're insulted by what I'm saying, it's still wrong.
Just because you're insulted by something I said doesn't mean it's
incorrect.
I tried in the first half dozen emails to be as diplomatic (and possibly
vague) as possible, but I'm being blunt for the sake of clarifty now.
> > > > 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.
devfsd/usbd. Actually in userspace, you can track devices and have the
permissions follow them, whereas in kernel space, you track which device
was plugged in first.
> > > 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.
Actually you did:
* 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.
You argued that since your laguage doesn't have support, moving it to
user space is not an option for you. Thusly, you'd rather have the
kernel provide the support.
This is the *wrong* way of thinking. Moving support from the kernel to
user space is good since user space is more flexible (preemptive
multitasking, paged memory, process protection, etc). The other way is
bad.
> And still no solution. Not helpful, if you were really trying to
> convince me of anything. Try again.
Does the API you created for dc2xx.c work under Windows? Macintosh?
Picojava?
One of Java's greatest strengths, cross platform API, is your greatest
weakness right now.
> > 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.
Everything is a tradeoff, but I see no overwhelming reason to keep the
driver in the kernel, whereas there are tons of good, tangible reasons
to move it to userspace.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
