Thank you very much for your reply, this is extremely high signal.
On Mon, Apr 03, 2023 at 10:15:00AM -0000, Stuart Henderson wrote:
> On 2023-04-01, Paul Tagliamonte <paul...@gmail.com> wrote:
> > I've been trying to take a library[1] I use on my Linux boxen, and coax
> > it into working on OpenBSD[2], and have been able to get a compiled .so
> > that looks good, with the exception of the USB transport. Given the
>
> This is probably the most informative reply from the previous times the
> subject came up:
>
> https://marc.info/?l=openbsd-tech&m=159420462501384&w=2
>
> (I don't think anything changed in this area since then).
Exactly the same, in fact! Disapointing reply, but after having spent a
bit over a week tracing this down, it's a relief to my ego that it's not
something obvious. It's doubly frustrating since what I do see in
kernelspace looks to be initialized sensibly, it just sits in progress
and never completes until EINTR.
I'll have to track down that GSOC work, but I'm not super inclined to
put a -current kernel into use outside the lab bench. I fear I may be
the next breadcrumb when someone tries this again within the next 4
years.
> OpenBSD's USB stack, especially regarding direct device access from
> userland, definitely has some issues that don't exist on other systems.
> FWIW I'm tending to run such devices on single-purpose Linux boxes now.
Totally. I was trying to get to 100% feature parity between OpenBSD and
Linux for some code I spend my free time on. Given the better idea I now
have of the landscape, I'm now trying to balance how much I want 100%
feature parity against the three practical options in front of me;
namely:
1) writing enough of a shim in libusb or libuhd to make this work as-is
today (the only reason I think this is possible is because
unmodified upstream rtl-sdr and hackrf are making libusb async calls
and getting data on my OpenBSD system)
2) make the most minimal kernel change to get the userland code working
3) giving up entirely on libuhd on OpenBSD
I'll likely give #2 an ernest try this week, and then fall back on #3. I
don't think I'm going to be the one to crack this multi-decade TODO in
spare cycles between work on a spare cycles project.
> I don't have a kernel core handy to test but you can load a kernel into
> gdb (watch out for reorder_kernel; you will need to save the actual
> kernel that produced the core) and may be able to load the core (saved
> in /var/crash after booting following "boot crash") into gdb with
> 'target kvm $file'. Not sure if you will get better results from base
> or ports gdb ("egdb" binary) in this case; try the other if one doesn't
> work. Though I don't think it's very widely used so may have rotted.
> Generally I think either ddb or adding debug code seem more common,
> also dt(4) helps figure out some things.
This is very pointer rich, thank you very much. I'll give this a try to
see if I can refine the workflow a bit. It sounds like I'm not far off
from best practice, which is -- again -- a bit of a relief.
> Here or maybe tech@. Though this (libusb/direct device access from
> userland) is not an area in which anyone is particularly active.
full ack
Thanks sth@ for your reply, I very much appreciate it.
paultag
--
:wq
