Hi
Any objections remaining against this being committed?
On Sat, Jan 25, 2014 at 05:18:16PM +0100, Emmanuel Dreyfus wrote:
Index: sys/kern/kern_exec.c
===
RCS file: /cvsroot/src/sys/kern/kern_exec.c,v
retrieving revision 1.369
On Sun, Jan 26, 2014 at 05:01:42PM +1100, matthew green wrote:
i think this could be fixed by introducing new disk major numbers for
both i386 and amd64 that are associated with the same definition of
major() and minor(), but i've never gotten around to or found someone
else willing to code
On Fri, 24 Jan 2014, Alan Barrett wrote:
I have successfully used magic symlinks (see symlink(7)) to allow
i386 and amd64 to use different instances of /dev. The basic scheme is:
Build a kernel with options MAGICLINKS, or arrange to run
sysctl -w vfs.generic.magiclinks=1 very early in
On Sat, 25 Jan 2014, Emmanuel Dreyfus wrote:
Oh, I forgot to address the issue of booting without options
MAGICLINKS in the kernel. No matter how early in /etc/rc you try
to put the sysctl -w vfs.generic.magiclinks=1 command, init(8)
will want to open /dev/console earlier than that. So you
Alan Barrett a...@cequrux.com wrote:
I see the following differences from this mtree comparison:
As I said, if your only filesystem is root on raid0a and your swap is on
sd0b/wd0b, you boot to multiuser without touching /dev
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
In article 1lfyrch.n0en6eho0ft6m%m...@netbsd.org,
Emmanuel Dreyfus m...@netbsd.org wrote:
Since nobody opposes, I am going to commit that. Perhaps the option name
could be better: NATIVE_EMULROOT or EMULROOT_NATIVE?
--- sys/kern/kern_exec.c.orig 2014-01-21 16:55:00.0 +0100
+++
Christos Zoulas chris...@astron.com wrote:
I think EMUL_NATIVEROOT is better, since everything starts with EMUL?
We'd get this, with the option documentation:
Index: sys/kern/kern_exec.c
===
RCS file:
On Sat 25 Jan 2014 at 17:18:16 +0100, Emmanuel Dreyfus wrote:
+an emulation root (e.g.:
+.Pa /emul/linux )
That colon doesn't go there.
(I see that often, in various languages, and since a colon is (often)
pronounced as a change in pitch before it, and a brief pause, it causes
a weird sentence.
Rhialto rhia...@falu.nl wrote:
+an emulation root (e.g.:
+.Pa /emul/linux )
That colon doesn't go there.
RIght, fixed that at mine (easy change!)
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
On Sat, 25 Jan 2014, Emmanuel Dreyfus wrote:
Alan Barrett a...@cequrux.com wrote:
I see the following differences from this mtree comparison:
As I said, if your only filesystem is root on raid0a and your
swap is on sd0b/wd0b, you boot to multiuser without touching
/dev
Perhaps you are
On Sat, 25 Jan 2014, Thor Lancelot Simon wrote:
Perhaps you are thinking of some other scenario, but I am
talking about the scenario that exists if you follow the
steps in my first message, and do not follow the steps in my
second message, and use a kernel that does not have options
Alan Barrett a...@cequrux.com wrote:
init detects the absence of /dev/console, and tries to mount a
tmpfs /dev, but the first step in that process is chdir(/dev),
which fails when /dev is a dangling symlink.
The easier way would therefore just be to remove the content of /dev and
let init
On Fri, Jan 24, 2014 at 06:27:32PM +1100, matthew green wrote:
joerg opposed it, and i'm not particular happy about this change.
Why? It does not affect you if you do not enable it, and the
change is not intrusive.
--
Emmanuel Dreyfus
m...@netbsd.org
On Fri, 24 Jan 2014, matthew green wrote:
i386 and amd64 do NOT have compatible /dev. if you boot an amd64
kernel, make sure you run an amd64 MAKEDEV in /dev.
I have successfully used magic symlinks (see symlink(7)) to allow
i386 and amd64 to use different instances of /dev. The basic scheme
On Fri, Jan 24, 2014 at 08:22:30AM +, Emmanuel Dreyfus wrote:
On Fri, Jan 24, 2014 at 06:27:32PM +1100, matthew green wrote:
joerg opposed it, and i'm not particular happy about this change.
Why? It does not affect you if you do not enable it, and the
change is not intrusive.
It's ugly
On Fri, Jan 24, 2014 at 08:03:03AM -0500, Thor Lancelot Simon wrote:
It's ugly and it will paper over more and more compat32 bugs as
time passes. For example, with the exception of the /dev issues,
as far as I can tell everything you've had trouble with is a failure
to properly translate
On Fri, Jan 24, 2014 at 01:19:52PM +, Emmanuel Dreyfus wrote:
The alternative is to switch the whole userland to amd64 at the same time
the kernel is changed. It means the new kernel cannot be tested without
undergoing changes to the system that are difficult to revert. This is
not good
On Fri, Jan 24, 2014 at 03:16:22PM +0100, Joerg Sonnenberger wrote:
Why can't you just build the few problematic binaries as static?
Because I just want to test a kernel before doing a migration, and
not rebuild various corners of the system as I discover problems with
them.
--
Emmanuel
Hello,
On Wed, 22 Jan 2014 00:24:52 +0200
Alan Barrett a...@cequrux.com wrote:
On Tue, 21 Jan 2014, Emmanuel Dreyfus wrote:
In order to have more RAM without reinstalling everything,
using an amd64 kernel on to of a i386 userland seems
appealing. netbsd32 emulation works fine, and the
times and the only snags I've run into are that very old i386 NetBSD-0.x
binaries won't run and there is a compatibility bug in the socket code
whereby 32-bit programs can't use local sockets to talk to other programs
via AF_LOCAL sockets.
are there PRs for these problems?
Other than
oh, one thing i forgot to mention.
i386 and amd64 do NOT have compatible /dev. if you boot an amd64
kernel, make sure you run an amd64 MAKEDEV in /dev.
yes, this sucks big time.
.mrg.
matthew green m...@eterna.com.au wrote:
i386 and amd64 do NOT have compatible /dev. if you boot an amd64
kernel, make sure you run an amd64 MAKEDEV in /dev.
Yes, I noticed that. Fortunately, raidframe causes most of /etc/fstab to
be shielded from that.
--
Emmanuel Dreyfus
Since nobody opposes, I am going to commit that. Perhaps the option name
could be better: NATIVE_EMULROOT or EMULROOT_NATIVE?
--- sys/kern/kern_exec.c.orig 2014-01-21 16:55:00.0 +0100
+++ sys/kern/kern_exec.c2014-01-21 16:55:13.0 +0100
@@ -184,9 +184,13 @@
/*
i386 and amd64 do NOT have compatible /dev. if you boot an amd64
kernel, make sure you run an amd64 MAKEDEV in /dev.
Yes, I noticed that. Fortunately, raidframe causes most of /etc/fstab to
be shielded from that.
it does?
the biggest problem is that eg, i386 wd1a is amd64 wd0i and
i386
Since nobody opposes, I am going to commit that. Perhaps the option name
could be better: NATIVE_EMULROOT or EMULROOT_NATIVE?
--- sys/kern/kern_exec.c.orig 2014-01-21 16:55:00.0 +0100
+++ sys/kern/kern_exec.c2014-01-21 16:55:13.0 +0100
@@ -184,9 +184,13 @@
On Wed, Jan 22, 2014 at 05:02:48AM +, David Holland wrote:
Or, just forget about i386 :-)
Before forgetting about it, it is a good idea to have a decent migration path.
--
Emmanuel Dreyfus
m...@netbsd.org
Hi
In order to have more RAM without reinstalling everything, using
an amd64 kernel on to of a i386 userland seems appealing. netbsd32
emulation works fine, and the machine boots to multiuser without
a hassle.
But there are minor problems, with binaries that use ioctl to talk
with a kernel
On Tue, Jan 21, 2014 at 05:33:41PM +, Emmanuel Dreyfus wrote:
A quick and dirty way to work the problem around is to use the amd64
binaries for ipf and raidctl. But that cannot work with the rest of
the system not yet migrated to amd64: amd64 binaries will get the i386
dyanmic loader
Joerg Sonnenberger jo...@britannica.bec.de wrote:
At least raidctl can be found in /rescue, which is statically linked.
That's likely easier to play with than any compat hacks.
Yes, but that does not solves the problem for ipf, for instance.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
On Tue, Jan 21, 2014 at 09:14:36PM +0100, Emmanuel Dreyfus wrote:
Joerg Sonnenberger jo...@britannica.bec.de wrote:
At least raidctl can be found in /rescue, which is statically linked.
That's likely easier to play with than any compat hacks.
Yes, but that does not solves the problem for
On Tue, 21 Jan 2014, Emmanuel Dreyfus wrote:
In order to have more RAM without reinstalling everything,
using an amd64 kernel on to of a i386 userland seems
appealing. netbsd32 emulation works fine, and the machine boots
to multiuser without a hassle.
But there are minor problems, with
David Laight da...@l8s.co.uk wrote:
You could build the 64bit ipf with a different 'elf interpreter'
namein it (or patch the string in the binary, it is unlikely to be shared).
Then you just need to sset an appropriate LD_LIBRARY_PATH.
The kernel patch solves the problem for all dynamic amd64
Brian Buhrow buh...@nfbcal.org wrote:
hello. The solution I use for this problem is to install native amd64
userland binaries from the base distribution over the machine I want to use
with more than 4GB of RAM. I leav everything in usr/pkg and /usr/local as
32-bit and install the
On Tue, Jan 21, 2014 at 05:33:41PM +, Emmanuel Dreyfus wrote:
Things would be much easier if the kernel searched /emul/netbsd64
before / for native binaries. Of course such a behavior cannot be made
default because of the performance penalty. But a compile time option
would be nice
34 matches
Mail list logo
