From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 11 19:01:03 2011 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B8221065694 for ; Tue, 11 Jan 2011 19:01:03 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id E31998FC2D for ; Tue, 11 Jan 2011 19:01:02 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 6172D1E00CCE; Tue, 11 Jan 2011 19:41:23 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p0BIdb4u039413; Tue, 11 Jan 2011 19:39:37 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p0BIdbix039412; Tue, 11 Jan 2011 19:39:37 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Tue, 11 Jan 2011 19:39:37 +0100 To: "\"J.R. Oldroyd\"" Message-ID: <20110111183937.GA36761@triton8.kn-bremen.de> References: <20091204223126.00005392@unknown> <201001081650.14189.hselasky@c2i.net> <20100108114130.1cfe88c5@shibato.opal.com> <201101110947.46399.hselasky@c2i.net> <20110111092609.7bf82016@shibato.opal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110111092609.7bf82016@shibato.opal.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-multimedia@freebsd.org, emulation@freebsd.org, freebsd-emulation@freebsd.org, Matthias Apitz , Alexander Leidinger Subject: Re: FYI: v4l-linuxulator support in FreeBSD-current now X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 19:01:03 -0000 On Tue, Jan 11, 2011 at 09:26:09AM -0500, "J.R. Oldroyd" wrote: > On Tue, 11 Jan 2011 09:47:46 +0100, Hans Petter Selasky wrote: > > > > Hi, > > > > I've received the following patch for my cuse4bsd module. Could this be > > included in the kernel's linux.ko ? This patch allows for linux DVB > > applications running under FreeBSD linux emulation. > > > > --HPS > > > > Index: cuse4bsd_kmod.c > > =================================================================== > > --- cuse4bsd_kmod.c (revision 1700) > > +++ cuse4bsd_kmod.c (working copy) > > @@ -1689,3 +1689,49 @@ > > > > return (0); > > } > > + > > + > > +#include > > +#if defined (__amd64__) > > +#include > > +#include > > +#else > > +#include > > +#include > > +#endif > > + > > +#include > > +MODULE_DEPEND(cuse4bsd, linux, 1, 1, 1); > > + > > +#define DVB_LINUX_IOCTL_MIN 0x6f00 > > +#define DVB_LINUX_IOCTL_MAX 0x6fff > > + > > + > > +static linux_ioctl_function_t cuse4bsd_linux_ioctl; > > +static struct linux_ioctl_handler cuse4bsd_linux_handler = > > + {cuse4bsd_linux_ioctl, DVB_LINUX_IOCTL_MIN, DVB_LINUX_IOCTL_MAX}; > > + > > +SYSINIT (cuse4bsd_linux_register, SI_SUB_KLD, SI_ORDER_MIDDLE, > > + linux_ioctl_register_handler, &cuse4bsd_linux_handler); > > +SYSUNINIT(cuse4bsd_linux_unregister, SI_SUB_KLD, SI_ORDER_MIDDLE, > > + linux_ioctl_unregister_handler, &cuse4bsd_linux_handler); > > + > > +static int > > +cuse4bsd_linux_ioctl(struct thread *td, struct linux_ioctl_args *args) > > +{ > > + unsigned long cmd; > > + > > + /* swap the read/write bits, due to differences in bsd & linux ioctls*/ > > + cmd = (unsigned long)args->cmd; > > + if (cmd & (0x40 << 24)) { > > + cmd &= 0xffffff; > > + cmd |= (0x80 << 24); > > + } else if (cmd & (0x80 << 24)) { > > + cmd &= 0xffffff; > > + cmd |= (0x40 << 24); > > + } > > + args->cmd = (l_uint)cmd; > > + > > + /* Pass the ioctl off to our standard handler, now that its valid */ > > + return(ioctl(td, (struct ioctl_args *)args)); > > +} > > This patch merely flips the cmd bits. > > I'm not familiar with the Linux DVB ioctls... is it really the case > that none of the data structures have 32/64-bit architecture dependent > field sizes? Great if that's the case, but if not, we need to do > data structure conversions here too, as we did for V4L. Yes we do, but after looking at the headers a bit it looks like it'll only be needed for FE_SET_PROPERTY, FE_GET_PROPERTY (unless I was being blind again; the latter also needs to be fixed from _IOR to _IOW before passing it on as we also had to do in our version of /usr/local/include/linux/dvb/frontend.h - see this thread for details: http://lists.freebsd.org/pipermail/freebsd-multimedia/2010-April/010958.html ), and conversions would be needed for some other structs that I _think_ are only used with full-feature tuner cards with internal mpeg2 decoders which I'm pretty sure don't exist as usb versions anyway so in that case we probably can get away by just ignoring them for now. (Tho I'd say we should treat them as errors insted of passing them thru wrong, I'm talking about ones in osd.h and video.h.) And FE_[GS]ET_PROPERTY I think are part of the `new' dvb api that was introduced when adding support for dvb-s2, which would also explain why the naive patch appeared to work: whatever app(s) were used to test it probably were just still using the `old' dvb api. (Well, or the tests were only done on i386. :) HTH, Juergen