Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Jan 2011 19:39:37 +0100
From:      Juergen Lock <nox@jelal.kn-bremen.de>
To:        "\"J.R. Oldroyd\"" <fbsd@opal.com>
Cc:        freebsd-multimedia@freebsd.org, emulation@freebsd.org, freebsd-emulation@freebsd.org, Matthias Apitz <guru@unixarea.de>, Alexander Leidinger <Alexander@leidinger.net>
Subject:   Re: FYI: v4l-linuxulator support in FreeBSD-current now
Message-ID:  <20110111183937.GA36761@triton8.kn-bremen.de>
In-Reply-To: <20110111092609.7bf82016@shibato.opal.com>
References:  <20091204223126.00005392@unknown> <201001081650.14189.hselasky@c2i.net> <20100108114130.1cfe88c5@shibato.opal.com> <201101110947.46399.hselasky@c2i.net> <20110111092609.7bf82016@shibato.opal.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <hselasky@c2i.net> 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 <sys/sysproto.h>
> > +#if defined (__amd64__)
> > +#include <machine/../linux32/linux.h>
> > +#include <machine/../linux32/linux32_proto.h>
> > +#else
> > +#include <machine/../linux/linux.h>
> > +#include <machine/../linux/linux_proto.h>
> > +#endif
> > +
> > +#include <compat/linux/linux_ioctl.h>
> > +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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110111183937.GA36761>