Am Mittwoch, 23. Mai 2007 10:48 schrieb David Brownell:
> On Wednesday 23 May 2007, Oliver Neukum wrote:
>
> > I thought a bit about this. Maybe there _is_ room for an allocator that
> > will provide memory the HCD can get at, but without the full overhead
> > of allocating a coherent buffer.
>
>
On Wednesday 23 May 2007, Oliver Neukum wrote:
> I thought a bit about this. Maybe there _is_ room for an allocator that
> will provide memory the HCD can get at, but without the full overhead
> of allocating a coherent buffer.
kmalloc() does exactly that...
-
Am Dienstag, 22. Mai 2007 17:23 schrieb Alan Stern:
> On Tue, 22 May 2007, Laurent Pinchart wrote:
>
> > The usb_buffer_alloc name is misleading. Many USB driver developers believe
> > it
> > is a generic purpose buffer allocator.
> >
> > I'd like to change usb_buffer_alloc to make it a general
Am Dienstag, 22. Mai 2007 18:10 schrieb Laurent Pinchart:
> My idea was to have a general purpose URB buffer allocation function that all
> (most?) drivers could use, with flags (or another function) for specific
> cases. usb_buffer_alloc is currently used by some drivers when they should
> use
On Tuesday 22 May 2007, Oliver Neukum wrote:
> Am Dienstag, 22. Mai 2007 15:28 schrieb Laurent Pinchart:
> > I'd like to change usb_buffer_alloc to make it a general purpose
> > allocator. A parameter would tell the function to just allocate memory
> > (default behaviour)
>
> Nope. What for? We avo
On Tue, 22 May 2007, Laurent Pinchart wrote:
> The usb_buffer_alloc name is misleading. Many USB driver developers believe
> it
> is a generic purpose buffer allocator.
>
> I'd like to change usb_buffer_alloc to make it a general purpose allocator. A
> parameter would tell the function to just
Am Dienstag, 22. Mai 2007 15:28 schrieb Laurent Pinchart:
> I'd like to change usb_buffer_alloc to make it a general purpose allocator. A
> parameter would tell the function to just allocate memory (default behaviour)
Nope. What for? We avoid such flags if we can. If you need two version,
create
On Friday 18 May 2007, David Brownell wrote:
> On Thursday 17 May 2007, Hans Petter Selasky wrote:
> > Isn't that the job of "usb_buffer_alloc()", to allocate memory in blocks
> > of PAGE_SIZE bytes?
>
> Not at all. The "size" parameter is in bytes, and the utility
> code it calls goes to some len
Am Montag, 21. Mai 2007 23:36 schrieb David Brownell:
> On Monday 21 May 2007, Oliver Neukum wrote:
> > Am Mittwoch, 16. Mai 2007 16:41 schrieb David Brownell:
> > > > in that when you have
> > > > pre-allocated all buffers and all USB host controller descriptors, you
> > > > will
> > > > never
On Monday 21 May 2007, Oliver Neukum wrote:
> Am Mittwoch, 16. Mai 2007 16:41 schrieb David Brownell:
> > > in that when you have
> > > pre-allocated all buffers and all USB host controller descriptors, you
> > > will
> > > never get in the situation of not being able to allocate transfer
> >
Am Mittwoch, 16. Mai 2007 19:33 schrieb Alan Stern:
> > All devices need to allocate some memory, even if they are not used. That
> > is
> > just the way it is. If you want to save memory, then USB has the advantage
> > that you can unplug the device and save resources.
>
> Of course all device
Am Mittwoch, 16. Mai 2007 16:41 schrieb David Brownell:
> > in that when you have
> > pre-allocated all buffers and all USB host controller descriptors, you will
> > never get in the situation of not being able to allocate transfer
> > descriptors
> > on the fly, like done on Linux.
>
> That'
Am Mittwoch, 16. Mai 2007 19:38 schrieb Alan Stern:
> > > It doesn't save code. You need to check for the memory when you
> > > allocate it, no matter when that is done.
> >
> > Yes, but it is a difference doing it once at attach or doing it every time
> > you
> > start a transfer.
>
> Above y
On Monday 21 May 2007 13:37, Oliver Neukum wrote:
> Am Mittwoch, 16. Mai 2007 20:43 schrieb Hans Petter Selasky:
> > The lock that you are holding during submission is the same lock that is
> > protecting the callback. Actually you can end up calling the
> > __usbd_callback() prematurely in my new
Am Mittwoch, 16. Mai 2007 20:43 schrieb Hans Petter Selasky:
> The lock that you are holding during submission is the same lock that is
> protecting the callback. Actually you can end up calling the
> __usbd_callback() prematurely in my new USB stack, but that is handled just
> fine, through som
Am Donnerstag, 17. Mai 2007 20:39 schrieb Pete Zaitcev:
> I think we should remove those local_irq_save's, and leave just the
> guarantee that it won't be re-entered (currently such a guarantee
> is inherited from the Linux's interrupt handling, and we'll only
> need to make it explicit if any HCDs
On Saturday 19 May 2007, Alan Stern wrote:
> On Sat, 19 May 2007, David Brownell wrote:
>
> > > Absolutely right, I'm being an idiot here. I think I looked at root
> > > hub code in the rush to the FreedomHEC preparations. We do not have
> > > local_irq_save in the giveback routine. So, when Alan
On Sat, 19 May 2007, David Brownell wrote:
> > Absolutely right, I'm being an idiot here. I think I looked at root
> > hub code in the rush to the FreedomHEC preparations. We do not have
> > local_irq_save in the giveback routine. So, when Alan wrote "USB
> > callbacks cannot be interrupted", he m
On Saturday 19 May 2007, Pete Zaitcev wrote:
> On Thu, 17 May 2007 17:37:22 -0700, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > > > > > As it happens, USB callbacks cannot be interrupted. That's a
> > > > > > somewhat
> > > > > > artificial restriction; in theory there's no reason we couldn'
On Thu, 17 May 2007 17:37:22 -0700, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > > As it happens, USB callbacks cannot be interrupted. That's a
> > > > > somewhat
> > > > > artificial restriction; in theory there's no reason we couldn't allow
> > > > > interrupts.
> > > >
> > > > Do you
On Fri, 18 May 2007, Hans Petter Selasky wrote:
> > It occurred to me last night that you could accomplish what you want
> > without any change to the Linux drivers at all. Just change the
> > FreeBSD stack so that it preallocates one or two transfers for every
> > endpoint at the time the endpoi
On Friday 18 May 2007 16:26, Alan Stern wrote:
> On Fri, 18 May 2007, Hans Petter Selasky wrote:
> > Hi,
> >
> > If you are interested, the files are:
> >
> > http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_co
> >mpat_linux.c
> > http://www.turbocat.net/~hselasky/isdn4bsd/sou
On Fri, 18 May 2007, Hans Petter Selasky wrote:
> Hi,
>
> If you are interested, the files are:
>
> http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.c
> http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.h
>
> It is almost fini
Hi,
If you are interested, the files are:
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.c
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.h
It is almost finished now.
And it is not very much code.
--HPS
On Thursday 17 May 2007, Hans Petter Selasky wrote:
> Isn't that the job of "usb_buffer_alloc()", to allocate memory in blocks of
> PAGE_SIZE bytes?
Not at all. The "size" parameter is in bytes, and the utility
code it calls goes to some lengths to *avoid* that kind of wastage.
As they say: UT
On Thursday 17 May 2007, Pete Zaitcev wrote:
> On Thu, 17 May 2007 12:08:15 -0700, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > > > As it happens, USB callbacks cannot be interrupted. That's a somewhat
> > > > artificial restriction; in theory there's no reason we couldn't allow
> > > > inte
On Thu, 17 May 2007 12:08:15 -0700, David Brownell <[EMAIL PROTECTED]> wrote:
> > > As it happens, USB callbacks cannot be interrupted. That's a somewhat
> > > artificial restriction; in theory there's no reason we couldn't allow
> > > interrupts.
> >
> > Do you remember why we're doing this?
On Thursday 17 May 2007 23:04, Alan Stern wrote:
> On Thu, 17 May 2007, Laurent Pinchart wrote:
> > A user of the Linux UVC driver unfortunately reported such a failure. The
> > driver allocates 5 bulk URBs, and the device asked for a 2.7MB buffer.
> > The system had been used for quite some time,
> > > The call will setup one or two pre-allocated USB transfers for the
> > > emulation layer between the Linux USB stack and the FreeBSD USB stack.
> >
> > So what's a "transfer" ... just a bunch of TDs? And what would be
> > the advantage to a Linux driver, since the TDs are allocated on
> > d
On Thursday 17 May 2007, David Brownell wrote:
> On Thursday 17 May 2007, Laurent Pinchart wrote:
> > On Wednesday 16 May 2007, David Brownell wrote:
> > > On Wednesday 16 May 2007, Hans Petter Selasky wrote:
> > > > in that when you have
> > > > pre-allocated all buffers and all USB host controlle
On Thu, 17 May 2007, Laurent Pinchart wrote:
> A user of the Linux UVC driver unfortunately reported such a failure. The
> driver allocates 5 bulk URBs, and the device asked for a 2.7MB buffer. The
> system had been used for quite some time, and the user reported that
> allocating such an amoun
On Thursday 17 May 2007, Laurent Pinchart wrote:
> On Wednesday 16 May 2007, David Brownell wrote:
> > On Wednesday 16 May 2007, Hans Petter Selasky wrote:
> > >
> > > in that when you have
> > > pre-allocated all buffers and all USB host controller descriptors, you
> > > will never get in the situ
On Wednesday 16 May 2007, David Brownell wrote:
> On Wednesday 16 May 2007, Hans Petter Selasky wrote:
> > Hi,
> >
> > I'm currently working on a Linux USB emulation layer for FreeBSD. In that
> > regard I have some issues that makes the stack peform non-optimal due to
> > its API design.
> >
> >..
Hi,
On Thursday 17 May 2007 21:26, David Brownell wrote:
> On Thursday 17 May 2007, Hans Petter Selasky wrote:
> > On Thursday 17 May 2007 19:44, David Brownell wrote:
> > > On Thursday 17 May 2007, Hans Petter Selasky wrote:
> > > > I would like introduce a new USB API call, so that my pre-alloca
On Thursday 17 May 2007, Hans Petter Selasky wrote:
> On Thursday 17 May 2007 19:44, David Brownell wrote:
> > On Thursday 17 May 2007, Hans Petter Selasky wrote:
> > > I would like introduce a new USB API call, so that my pre-allocate model
> > > will work better with your USB API. ...
> > >
> >
On Thursday 17 May 2007, Pete Zaitcev wrote:
> On Thu, 17 May 2007 10:44:13 -0700, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > So what's the model ... GPL'd Linux drivers will be modified to
> > incorporate that call, so they'd work better on FreeBSD?
>
> I thought that we ignored this on pur
On Thursday 17 May 2007, Pete Zaitcev wrote:
> On Thu, 17 May 2007 14:26:18 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]>
> wrote:
>
> > As it happens, USB callbacks cannot be interrupted. That's a somewhat
> > artificial restriction; in theory there's no reason we couldn't allow
> > interrupts.
On Thu, 17 May 2007, Pete Zaitcev wrote:
> On Thu, 17 May 2007 14:26:18 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]>
> wrote:
>
> > As it happens, USB callbacks cannot be interrupted. That's a somewhat
> > artificial restriction; in theory there's no reason we couldn't allow
> > interrupts.
>
On Thursday 17 May 2007 20:19, Pete Zaitcev wrote:
> On Thu, 17 May 2007 10:44:13 -0700, David Brownell <[EMAIL PROTECTED]>
wrote:
> > So what's the model ... GPL'd Linux drivers will be modified to
> > incorporate that call, so they'd work better on FreeBSD?
>
> I thought that we ignored this on
On Thu, 17 May 2007 14:26:18 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> As it happens, USB callbacks cannot be interrupted. That's a somewhat
> artificial restriction; in theory there's no reason we couldn't allow
> interrupts.
Do you remember why we're doing this? I did not touch th
On Thursday 17 May 2007 19:44, David Brownell wrote:
> On Thursday 17 May 2007, Hans Petter Selasky wrote:
> > I would like introduce a new USB API call, so that my pre-allocate model
> > will work better with your USB API. For example I want something like
> > this:
> >
> > void
> > usb_setup_endp
On Thu, 17 May 2007, Hans Petter Selasky wrote:
> Hi,
>
> On Thursday 17 May 2007 19:03, Alan Stern wrote:
> > On Thu, 17 May 2007, Hans Petter Selasky wrote:
> > > > In Linux, the USB callbacks are generally atomic. Does that answer
> > > > your question?
> > >
> > > Yes. So you protect the cal
On Thu, 17 May 2007 10:44:13 -0700, David Brownell <[EMAIL PROTECTED]> wrote:
> So what's the model ... GPL'd Linux drivers will be modified to
> incorporate that call, so they'd work better on FreeBSD?
I thought that we ignored this on purpose and talking about the
licensing so deeply in the thr
Hi,
On Thursday 17 May 2007 19:03, Alan Stern wrote:
> On Thu, 17 May 2007, Hans Petter Selasky wrote:
> > > In Linux, the USB callbacks are generally atomic. Does that answer
> > > your question?
> >
> > Yes. So you protect the callback with a lock to make it atomic?
>
> No, you don't understand
On Thursday 17 May 2007, Hans Petter Selasky wrote:
>
> I would like introduce a new USB API call, so that my pre-allocate model will
> work better with your USB API. For example I want something like this:
>
> void
> usb_setup_endpoint(struct usb_device *usb, struct usb_interface *ui, struct
>
On Thu, 17 May 2007, Hans Petter Selasky wrote:
> > In Linux, the USB callbacks are generally atomic. Does that answer
> > your question?
>
> Yes. So you protect the callback with a lock to make it atomic?
No, you don't understand. The callback is atomic because it is not
allowed to sleep. Th
On Thursday 17 May 2007 16:20, David Brownell wrote:
> > > > > > On FreeBSD it will never happen that you call the equivalent
> > > > > > of "usb_submit_urb()" after that the device has detached! It must
> > > > > > be something terribly wrong in the Linux USB stack if the
> > > > > > callbacks are
On Thursday 17 May 2007 16:35, Alan Stern wrote:
> On Thu, 17 May 2007, Hans Petter Selasky wrote:
> > If you need to do Async stuff, then you have to do it in a separate
> > thread or in a so-called task-queue. Else you are in for great trouble!
> > That was the big "sin" in the old USB stack on F
On Thu, 17 May 2007, Hans Petter Selasky wrote:
> If you need to do Async stuff, then you have to do it in a separate thread or
> in a so-called task-queue. Else you are in for great trouble! That was the
> big "sin" in the old USB stack on FreeBSD: Calling synchronous USB callbacks
> from ever
> > > > > On FreeBSD it will never happen that you call the equivalent
> > > > > of "usb_submit_urb()" after that the device has detached! It must be
> > > > > something terribly wrong in the Linux USB stack if the callbacks are
> > > > > alive after that you have detached a USB device.
> > > >
>
On Wed, May 16, 2007 at 02:49:37PM +0200, Hans Petter Selasky wrote:
> Hi,
>
> I'm currently working on a Linux USB emulation layer for FreeBSD. In that
> regard I have some issues that makes the stack peform non-optimal due to its
> API design.
I think the API design issues have been hashed ou
Hi,
On Thursday 17 May 2007 06:38, David Brownell wrote:
> On Wednesday 16 May 2007, Hans Petter Selasky wrote:
> > Hi,
> >
> > On Wednesday 16 May 2007 20:20, David Brownell wrote:
> > > > > > > URB submission has other failure possibilities than lack of
> > > > > > > memory. Those other things h
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
> Hi,
>
> On Wednesday 16 May 2007 20:20, David Brownell wrote:
> > > > > > URB submission has other failure possibilities than lack of memory.
> > > > > > Those other things have to be checked for regardless.
> > > > >
> > > > > Yes, but that i
On Wednesday 16 May 2007 20:20, Pete Zaitcev wrote:
> On Wed, 16 May 2007 18:11:35 +0200, Hans Petter Selasky <[EMAIL PROTECTED]>
wrote:
> > My "usbd_transfer_start()" returns "void". Your "usb_submit_urb()"
> > returns "int".
>
> We (ok, I) don't like this scheme. In Linux only SCSI uses it,
> pr
Hi,
On Wednesday 16 May 2007 20:20, David Brownell wrote:
> > > > > URB submission has other failure possibilities than lack of memory.
> > > > > Those other things have to be checked for regardless.
> > > >
> > > > Yes, but that is because you allow too many parameters in the URB to
> > > > be ch
On Wed, 16 May 2007 19:49:57 +0200, Hans Petter Selasky <[EMAIL PROTECTED]>
wrote:
> > No; it's because unforeseen events can occur. For example, the device
> > may have been unplugged or suspended.
>
> On FreeBSD it will never happen that you call the equivalent
> of "usb_submit_urb()" after
> > > > URB submission has other failure possibilities than lack of memory.
> > > > Those other things have to be checked for regardless.
> > >
> > > Yes, but that is because you allow too many parameters in the URB to be
> > > changed between USB transfers.
> >
> > No; it's because unforeseen eve
On Wed, 16 May 2007 18:11:35 +0200, Hans Petter Selasky <[EMAIL PROTECTED]>
wrote:
> My "usbd_transfer_start()" returns "void". Your "usb_submit_urb()"
> returns "int".
We (ok, I) don't like this scheme. In Linux only SCSI uses it,
primarily because that's how Eric Youngdale defined it in 1992.
Hi,
On Wednesday 16 May 2007 19:38, Alan Stern wrote:
> On Wed, 16 May 2007, Hans Petter Selasky wrote:
> > On Wednesday 16 May 2007 18:25, Alan Stern wrote:
> > > On Wed, 16 May 2007, Hans Petter Selasky wrote:
> > > > It is very clear to me that non-blocking memory allocation at the
> > > > poin
On Wed, 16 May 2007, Hans Petter Selasky wrote:
> On Wednesday 16 May 2007 18:25, Alan Stern wrote:
> > On Wed, 16 May 2007, Hans Petter Selasky wrote:
> > > It is very clear to me that non-blocking memory allocation at the point
> > > of starting an USB transfer will require extra error handling
On Wed, 16 May 2007, Hans Petter Selasky wrote:
> > It's also true for bulk-only; the same URB and buffer get used for the
> > IN and the OUT endpoints (CSW and CDB). Yes, we could dealias them if
> > necessary.
>
> I would says it is a specification design fault that read and write endpoints
>
On Wednesday 16 May 2007 18:25, Alan Stern wrote:
> On Wed, 16 May 2007, Hans Petter Selasky wrote:
> > It is very clear to me that non-blocking memory allocation at the point
> > of starting an USB transfer will require extra error handling in the USB
> > device driver code!
>
> It's not so clear
On Wednesday 16 May 2007 18:21, Alan Stern wrote:
> On Wed, 16 May 2007, Pete Zaitcev wrote:
> > On Wed, 16 May 2007 10:57:04 -0400 (EDT), Alan Stern
<[EMAIL PROTECTED]> wrote:
> > > It's worth pointing out that there already are drivers which
> > > preallocate URBs and memory buffers and then sha
On Wednesday 16 May 2007, Alan Stern wrote:
> On Wed, 16 May 2007, Pete Zaitcev wrote:
> > Right. Per-endpoint with a size limits also allows TDs to be
> > preallocated.
>
> With a large potential waste of memory!
Which is the general down-side of preallocation...
> UHCI is so inefficient that
On Wed, 16 May 2007, Hans Petter Selasky wrote:
> It is very clear to me that non-blocking memory allocation at the point of
> starting an USB transfer will require extra error handling in the USB device
> driver code!
It's not so clear to me.
> My "usbd_transfer_start()" returns "void". Your
On Wed, 16 May 2007, Pete Zaitcev wrote:
> On Wed, 16 May 2007 10:57:04 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]>
> wrote:
>
> > It's worth pointing out that there already are drivers which
> > preallocate URBs and memory buffers and then share them among multiple
> > endpoints. One example i
On Wednesday 16 May 2007 18:00, David Brownell wrote:
> On Wednesday 16 May 2007, Alan Stern wrote:
> > On Wed, 16 May 2007, David Brownell wrote:
> > > > I have never, ever, seen USB stack deplete the atomic pool completely
> > > > either, if this is what you are talking about. So, you're quite ri
On Wednesday 16 May 2007, Alan Stern wrote:
> On Wed, 16 May 2007, David Brownell wrote:
>
> > > I have never, ever, seen USB stack deplete the atomic pool completely
> > > either, if this is what you are talking about. So, you're quite right
> > > about that.
> >
> > I was referring to the dma_p
On Wed, 16 May 2007 10:57:04 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> It's worth pointing out that there already are drivers which
> preallocate URBs and memory buffers and then share them among multiple
> endpoints. One example is usb-storage.
This is for CBI transport, right? Hones
On Wed, 16 May 2007 11:38:47 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> > > I have never, ever, seen USB stack deplete the atomic pool completely
> > > either, if this is what you are talking about. So, you're quite right
> > > about that.
> >
> > I was referring to the dma_pool allocat
On Wed, 16 May 2007 16:52:53 +0200, Hans Petter Selasky <[EMAIL PROTECTED]>
wrote:
> [...] Then you need to send specific
> commands to the PCI-bridge, for example "pshyco". From what I see
> your model will not work in all cases.
USB through Psycho/Schizo is fully supported on Linux. Heck it w
On Wed, 16 May 2007, David Brownell wrote:
> > I have never, ever, seen USB stack deplete the atomic pool completely
> > either, if this is what you are talking about. So, you're quite right
> > about that.
>
> I was referring to the dma_pool allocations ... those don't need
> to be atomic. OHCI
On Wednesday 16 May 2007, Pete Zaitcev wrote:
> On Wed, 16 May 2007 07:41:26 -0700, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > > in that when you have
> > > pre-allocated all buffers and all USB host controller descriptors, you
> > > will
> > > never get in the situation of not being able
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
> On the BSD platform there is something called BUS-DMA. Memory is allocated
> according to PCI device capabilities. This is because sometimes the PCI
> device is not capable of addressing the complete memory. Also you need to
> sync memory,
On Wed, 16 May 2007 07:41:26 -0700, David Brownell <[EMAIL PROTECTED]> wrote:
> > in that when you have
> > pre-allocated all buffers and all USB host controller descriptors, you will
> > never get in the situation of not being able to allocate transfer
> > descriptors
> > on the fly, like do
On Wed, 16 May 2007, Pete Zaitcev wrote:
> > What I would suggest is that when you allocate an URB and DMA'able memory,
> > you
> > have to specify which pipe {CONTROL, BULK, INTERRUPT or ISOC} it belongs to.
> >
> > What do you think?
>
> Just a side note, we are trying to move away from the
On Wednesday 16 May 2007 16:41, David Brownell wrote:
> On Wednesday 16 May 2007, Hans Petter Selasky wrote:
> > Hi,
> >
> > I'm currently working on a Linux USB emulation layer for FreeBSD. In that
> > regard I have some issues that makes the stack peform non-optimal due to
> > its API design.
> >
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
> Hi,
>
> I'm currently working on a Linux USB emulation layer for FreeBSD. In that
> regard I have some issues that makes the stack peform non-optimal due to its
> API design.
>
>...
>
> What I would suggest is that when you allocate an URB
Hi,
Interesting reading.
On Wednesday 16 May 2007 16:08, Pete Zaitcev wrote:
> On Wed, 16 May 2007 14:49:37 +0200, Hans Petter Selasky <[EMAIL PROTECTED]>
wrote:
> > I'm currently working on a Linux USB emulation layer for FreeBSD. In that
> > regard I have some issues that makes the stack pefor
On Wed, 16 May 2007 14:49:37 +0200, Hans Petter Selasky <[EMAIL PROTECTED]>
wrote:
> I'm currently working on a Linux USB emulation layer for FreeBSD. In that
> regard I have some issues that makes the stack peform non-optimal due to its
> API design.
I think that what you described is largely
80 matches
Mail list logo
