public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: s.schmidt@avm.de
Cc: kkeil@suse.de, libusb-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, linux-kernel-owner@vger.kernel.org,
	opensuse-factory@opensuse.org, torvalds@osdl.org
Subject: Re: 2.6.16 serious consequences / GPL_EXPORT_SYMBOL / USB drivers of major vendor excluded
Date: Mon, 6 Mar 2006 09:05:42 -0800	[thread overview]
Message-ID: <20060306170542.GB8142@kroah.com> (raw)
In-Reply-To: <OF2725219B.50D2AC48-ONC1257129.00416F63-C1257129.00464A42@avm.de>

On Mon, Mar 06, 2006 at 01:47:43PM +0100, s.schmidt@avm.de 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

  reply	other threads:[~2006-03-06 17:05 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200601200904.00389.dazzle.digital@gmail.com>
2006-02-03 16:24 ` 2.6.16 serious consequences / GPL_EXPORT_SYMBOL / USB drivers of major vendor excluded s.schmidt
2006-02-03 22:50   ` Pavel Machek
2006-02-04 16:27   ` Valdis.Kletnieks
2006-02-04 19:24     ` Jan Kiszka
2006-02-09 15:52       ` Jan Engelhardt
2006-02-05 20:53   ` Greg KH
2006-02-16 14:24     ` Re[2]: " s.schmidt
2006-02-16 14:35       ` Arjan van de Ven
2006-02-16 19:49       ` [opensuse-factory] " Robert Schiele
2006-02-16 22:09       ` Carl-Daniel Hailfinger
2006-02-16 22:51         ` Karsten Keil
2006-02-17 23:00       ` Greg KH
2006-02-19 14:34         ` Stephan von Krawczynski
2006-03-06 12:47         ` Re[2]: " s.schmidt
2006-03-06 17:05           ` Greg KH [this message]
2006-03-06 21:09             ` [Libusb-devel] " Michael Bender
2006-03-06 22:02               ` Greg KH
2006-03-07  7:42           ` [opensuse-factory] Re[2]: " Silviu Marin-Caea
2006-03-07 22:10             ` Lee Revell
2006-03-07 23:37               ` Matthias Andree
2006-03-08  0:55                 ` Lee Revell
2006-03-08  1:39                   ` Douglas McNaught
2006-02-18  2:42       ` Lee Revell
2006-02-19  4:57       ` Sasha Khapyorsky
2006-02-19 17:02         ` Steven Rostedt
2006-02-20  3:11           ` Sasha Khapyorsky
2006-02-20  6:58             ` Steven Rostedt
2006-02-19 16:25       ` Re[2]: " Christoph Hellwig
2006-02-19  3:09     ` Anton Blanchard
2006-02-19  3:20       ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060306170542.GB8142@kroah.com \
    --to=greg@kroah.com \
    --cc=kkeil@suse.de \
    --cc=libusb-devel@lists.sourceforge.net \
    --cc=linux-kernel-owner@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=opensuse-factory@opensuse.org \
    --cc=s.schmidt@avm.de \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox