Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 May 2008 11:49:11 +0200
From:      Ed Schouten <ed@80386.nl>
To:        Alexander Leidinger <Alexander@Leidinger.net>
Cc:        emulation@freebsd.org
Subject:   Re: [RFC]: switch to 2.6 linux emulation on default
Message-ID:  <20080530094911.GY64397@hoeg.nl>
In-Reply-To: <20080530114038.92102g7uj7m3haqs@webmail.leidinger.net>
References:  <20080529214829.GA79810@freebsd.org> <20080530050453.GX64397@hoeg.nl> <20080530114038.92102g7uj7m3haqs@webmail.leidinger.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--dZHW955j1vPFHE0Q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Alexander Leidinger <Alexander@Leidinger.net> wrote:
> Quoting Ed Schouten <ed@80386.nl> (from Fri, 30 May 2008 07:04:53 +0200):
>
>> Hello Roman,
>>
>> * Roman Divacky <rdivacky@freebsd.org> wrote:
>>> FreeBSD 7.0 contains support for running emulation of Linux 2.6
>>> (=3D NPTL, futexes, TLS basically) and I'd like to switch this
>>> on default in HEAD to see if we can ship 8.0 with this emulation
>>> running on default.
>>
>> Speaking about Linux emulation: a couple of days ago I added Linux
>> support to my TTY code in the mpsafetty branch. This means that it can
>> handle the things done in posix_openpt() and ptsname().
>>
>> Because Linux wants the minor number to be within a certain region, the
>> PTY driver creates a linux_device_handler for each device. ptsname()
>
> There's already something like a device handler or wrapper or whatever =
=20
> (I hadn't a close look at this) for some devices. Does your work use =20
> this existing infrastructure or is this something else?

It just calls linux_device_register_handler() to create the mapping. I'm
not entirely happy with this yet, because this means our pts(4) driver
needs to be recompiled to work with Linux binary compatibility.

In CVS, there is already some code in place to make the mapping work for
/dev/pts/XXX (see linux_stats.c), but it always returns the same device
number for all pts devices. I should probably just change that code to
parse the device number and base the major/minor number on that.

>> seems to do an fstat() on the controller descriptor, followed by looping
>> on the files in /dev and /dev/pts, to find the matching device number.
>>
>> Unfortunately sendmsg() seems broken on amd64 with COMPAT_LINUX32. This
>
> The LTP test (http://wiki.freebsd.org/linux-kernel/ltp) for sendmsg =20
> tells it is broken on all architectures. Did you test on a i386 system =
=20
> too?

On i386, it works good enough to at least make sshd work. On amd64 it
returns EINVAL, using the same Linux binaries.

>> means that SSH'ing to a Linux jail only works on i386, or on amd64 when
>> logging in as root (in that case sshd seems to be taking a shortcut, not
>> causing sendmsg() to be called).
>
> That's not nice, this should work even for normal users. I think we =20
> should raise the priority for the sendmsg part.

Yes, we should. Unfortunately I don't I have the time to look into that.

--=20
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/

--dZHW955j1vPFHE0Q
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAkg/zZcACgkQ52SDGA2eCwWgTACfZa0yHbIDjqUxkOYjOJtfgYuR
zioAnipLHlezQOQ5biT3KrP8rs5F41Is
=n8Uy
-----END PGP SIGNATURE-----

--dZHW955j1vPFHE0Q--



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