Re: getsockopt(2)

[Christos Zoulas]

In article ,
Robert Swindells   wrote:
>
>chris...@astron.com (Christos Zoulas) wrote:
>>In article ,
>>Robert Swindells   wrote:
>>>
>>>chris...@astron.com (Christos Zoulas) wrote:
In article ,

So depending on the contents of the sockval we do something different?
>>>
>>>FreeBSD does. The calls to copy in or out the data are scattered
>>>throughout the network stack.
>>
>>Is sockval always an int? 
>
>Do you mean optname or optval ?

optval.

>The operation required for setsockopt() is to mostly set things but in
>certain cases to return an int value that results from setting stuff.

I've lost track of what we are trying to achieve :-( Can you please
post an example?


Also lets compile a table of choices that has:

- description of what's done
- which os implemented it (if any)
- pros
- cons

Or something along those lines so we can make a decision?

Thanks,

christos

Re: Merging ugen into the usb stack

[Wolfgang Solfrank]

Hi Martin,


I have a Guruplug JTAG device (and right now need to use it to unbrick
one of my Guruplugs after some ... stupid u-boot experiment).


I've got some similar device which also uses a 2 port uftdi, where one
port is wired as a serial interface and the other is used for jtag.

In order to support that, I changed the uftdi driver to match against
an interface instead of the whole device. Thus you could specify

uftdi1 at uhub? port ? configuration ? interface 1
ucom* at uftdi1

and leave interface 0 of uftdi alone, which then resulted in ugen
to attach there.

Unfortunately, this modification has bit rotted since then and
doesn't work in its current state.


I could hack uftdi to allow attaching a ugen child, but that sounds like a
very special hack. Jared suggested to instead make ugen not a separate device,
but globaly fold it into the usb stack. That would also solve similar issues
we have seen with usb scanner devices and ulpts.

So, how should we proceed here?


However, I support the idea of allowing ugen to attach to some
usb device independent of some other driver matching it. Of
course, there needs to be some mutual exclusion between ugen
and the other driver.

Ciao,
Wolfgang
--
wolfg...@solfrank.net   Wolfgang Solfrank

Re: Merging ugen into the usb stack

[Stephen Borrill]

On Mon, 11 Dec 2017, Martin Husemann wrote:
[snip]

However, it can not work with the way NetBSD uses ugen devices:

uftdi0 at uhub3 port 2
uftdi0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, 
addr 3
ucom0 at uftdi0 portno 1
ucom1 at uftdi0 portno 2

I can disable the ucom at uftdi0 portno 1, but there is no way to get a ugen
device to attach there.

The uftdi chip itself offers a separate interface for each of the ports,
at that layer there should not be a problem.

I could hack uftdi to allow attaching a ugen child, but that sounds like a
very special hack. Jared suggested to instead make ugen not a separate device,
but globaly fold it into the usb stack. That would also solve similar issues
we have seen with usb scanner devices and ulpts.


This sounds to be related to the requirements of USB remoting 
such as USB-over-IP and Citrix Receiver. With the latter, I may 
choose to access a device using a known virtual channel such as video, in 
which case I would be using the kernel driver. Within my remote session, I 
may choose to use the USB virtual channel which would detach the 
kernel driver and use the native Windows driver within the session.


libusb has libusb_detach_kernel_driver() which NetBSD does not have the 
functionality to support. The ability to detach a kernel driver, then 
attach a ugen in its place would be useful (good for rump device driver 
development too!). However, as Taylor says, with care it may be possible 
to maintain both interfaces.


--
Stephen