Re: 2.6.16 serious consequences / GPL_EXPORT_SYMBOL / USB drivers of major vendor excluded

[Greg KH]

On Mon, Mar 06, 2006 at 01:47:43PM +0100, s.schmidt@xxxxxx wrote:
> Your focus on the technical aspects shows us that there is a common
> understanding, so we certainly appreciate your input.
> 
> The described userland/kernel mix scenarios may work in uninterrupted
> environments, but non-stop quality of service "at all times and situations"
> is only truly feasible in kernel space. "with the only bottleneck being the
> CPU to RAM bus." is exactly the main argument against a mixed kernel/user
> space driver architecture. We know from our everyday business, Linux is
> often used in slow CPU environments like PIII or similar. Thus latency
> times are even more critical within these environments.

I agree.  But have you measured such latency on the 2.6 kernel recently?
On old hardware?  Is it still unacceptable for you?  If so, what is
required?

> Even though people might do realtime DSP things in user space with Linux
> and soft modems might work pretty well in userspace, in the case of Fax G3
> an extremely short latency is required. The user space lacks the required
> reliability and interoperability. Latency times of 4/10/20 or 40
> milliseconds are one aspect, but QoS is the overall essence. Within the
> kernel space there is no need for unnecessary mode switches or data copy
> procedures.

I understand, that is why I suggested a mix of a kernel driver to handle
the stuff that has latency issues, and userspace to handle the rest.

> Compared to other operating systems, such as Mac OS, BeOS,
> Windows etc., Linux is walking a solitary path with the "user mode only"
> shift. One gets the impression, that legal concerns are leading Linux to a
> technically suboptimal/isolated solution.

No, right now, Linux has the best latency numbers _by far_ than any
other operating system, so we can move stuff to userspace.

And again, it's your legal issues that are forcing you that way, if you
change that, putting everything in the kernel would be fine :)

So, in conclusion, is there anything that we can help you out with in
regards to you feeling that userspace can not handle your needs?  Do you
have numbers showing that putting a small portion of the USB urb handler
logic in the kernel and the rest in userspace will not work for you?
Example code showing long delay periods that we can help fix?

Anything else we can do?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/