Re: CVS commit: src
mrg@ wrote:
> > > to the PowerPC Virtex that lives in arch/evbppc/virtex.
> >
> > BTW evbppc has 405 vs oea issue in module.
>
> i have a solution for this i haven't implemented. it basically
> involves two things:
>
> - allow a different subdir in the module dir
>
> - re-use the src/compat framework to build multiple
> versions of modules and make sure we use the first
> part to choose the right one
To build module binaries it might work, but how can kernels
(and bootloaders) choose subdir in /stand to load modules per machine?
Introduce a new variable ${MACHINE_KERNEL_ARCH} etc?
I considered the similar idea for sun3/sun3x, but I realized
that module binaries could be shared among sun3/sun3x kernels
even though their TEXTADDR values were different.
(kobj_reloc() handles it)
BTW, is anyone working on arch/mips/mips/kobj_machdep.c?
Currently no MD kobj(9) functions for module(7) on mips.
(and there is no kobj(9) man pages ;-p)
---
Izumi Tsutsui
Re: CVS commit: src
On Jan 28, 2011, at 3:25 PM, matthew green wrote: > >>> to the PowerPC Virtex that lives in arch/evbppc/virtex. >> >> BTW evbppc has 405 vs oea issue in module. >> >> evb* method is used for boards/appliances that have >> less man power and few variants, I think. > > one problem i have with the current way we do this is that we > end up compiling userland multiple times for no good reason. > > i don't know exactly what a better method would be, but maybe > using something similar to sparc port including the SUN4U > kernel (which is built from sources in arch/sparc64) so we can > keep kernel stuff separate, regardless of where the sources > are kept, but leave userland shared. I firmly believe that /usr/include/machine should point to (e.g. mips) instead of (e.g. pmax). If you are building specific programs to a port, then you should use something . This would go a long way to have a common userland per arch. Things like disklabel.h need to special cased (I'd probably use an array with port/labelsector/labeloffset) that disklabel could search for the right value.
Re: CVS commit: src
On Jan 28, 2011, at 3:38 PM, matthew green wrote: > >> disklabel.h should export nothing to userland and values userland >> needs should be obtained via sysctl. >> >> I've been asking this question of various developers for a while. > > how do i create a disklabel on a file system image as a normal > user a non-netbsd host with this method? But that would be a hosted tool and that's a different case than a native tool.
re: CVS commit: src
> disklabel.h should export nothing to userland and values userland > needs should be obtained via sysctl. > > I've been asking this question of various developers for a while. how do i create a disklabel on a file system image as a normal user a non-netbsd host with this method? .mrg.
re: CVS commit: src
> > to the PowerPC Virtex that lives in arch/evbppc/virtex. > > BTW evbppc has 405 vs oea issue in module. i have a solution for this i haven't implemented. it basically involves two things: - allow a different subdir in the module dir - re-use the src/compat framework to build multiple versions of modules and make sure we use the first part to choose the right one anyone else could do this, too :-) .mrg.
re: CVS commit: src
> > to the PowerPC Virtex that lives in arch/evbppc/virtex. > > BTW evbppc has 405 vs oea issue in module. > > evb* method is used for boards/appliances that have > less man power and few variants, I think. one problem i have with the current way we do this is that we end up compiling userland multiple times for no good reason. i don't know exactly what a better method would be, but maybe using something similar to sparc port including the SUN4U kernel (which is built from sources in arch/sparc64) so we can keep kernel stuff separate, regardless of where the sources are kept, but leave userland shared. .mrg.
Re: CVS commit: src
Antti Kantee wrote: > On Fri Jan 28 2011 at 18:05:50 +0900, Izumi Tsutsui wrote: > > > Out of curiosity, was there any thought is adding this to evbmips > > > instead of getting its own top-level arch subdir? > > > > emips already has native bootloader and src/distrib files, > > so it's enough reason to have own port dir. Fair enough here, this isn't something that evb* handles well. One day I'd like to move sbmips under evbmips but sbmips/stand is the biggest part of work there. > additionally, userland is built with MKSOFTFLOAT=yes Was softfloat vs kernel emulation ever benchmarked? It's been many years since I looked at this but my (very vague) recollection was that there was no real difference and there are then the benefits of sharing binaries with other MIPS ports. > plus, what was said about a research platform, > with implications for teaching too. This is the only point you raise that I don't understand. How does its location in the source tree effect its use as a research platform? Cheers, Simon.
Re: CVS commit: src/sys
Hi, I just got a compile error after the movement of the sysctls. When having netbsd32 compat on a 64bit machine. A conditional include for compat/netbsd32/netbsd32.h fixed this, one like in init_sysctl.c Kind Regards, Lars Am 28.01.2011 19:44 schrieb "Antti Kantee" : > Module Name: src > Committed By: pooka > Date: Fri Jan 28 18:44:45 UTC 2011 > > Modified Files: > src/sys/kern: init_main.c init_sysctl.c kern_descrip.c kern_proc.c > kern_sysctl.c > src/sys/sys: proc.h sysctl.h > > Log Message: > Move sysctl routines from init_sysctl.c to kern_descrip.c (for > descriptors) and kern_proc.c (for processes). This makes them > usable in a rump kernel, in case somebody was wondering. > > > To generate a diff of this commit: > cvs rdiff -u -r1.426 -r1.427 src/sys/kern/init_main.c > cvs rdiff -u -r1.176 -r1.177 src/sys/kern/init_sysctl.c > cvs rdiff -u -r1.209 -r1.210 src/sys/kern/kern_descrip.c > cvs rdiff -u -r1.169 -r1.170 src/sys/kern/kern_proc.c > cvs rdiff -u -r1.229 -r1.230 src/sys/kern/kern_sysctl.c > cvs rdiff -u -r1.299 -r1.300 src/sys/sys/proc.h > cvs rdiff -u -r1.190 -r1.191 src/sys/sys/sysctl.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src
On Jan 28, 2011, at 6:40 AM, Izumi Tsutsui wrote:
> pooka@ wrote:
>
additionally, userland is built with MKSOFTFLOAT=yes,
> :
>>> In that case, shouldn't we have different ${MACHINE_ARCH}
>>> for different binaries?
>>
>> i think you're right. hmm, looking at the build cluster output there
>> seem to be very few sets shared between mips archs (i don't know the
>> details of how they are selected).
>
> base and comp can't be shared due to etc.
> On the other, packages binaries are seriously affected.
disklabel.h should export nothing to userland and values userland
needs should be obtained via sysctl.
I've been asking this question of various developers for a while.
>> Do you have a naming suggestion? mipsebsf?
>
> hpcmips chose and implemented painful fpemul to avoid such discussion,
> IIRC :-)
>
> It looks eb/el should be suffix, but probably we should check
> other OSes and misc configure scripts etc.
One thing I've played with implementing a softfloat lib that
used the hardfloat instructions in the softfloat calls. So it's
a bit slower than direct FP but compatible with softfloat.
My idea was to preload this with ld.so.conf mechanism based on
machdep.fpu_present value. With martin's work on SIGFPE from
userland this becomes more practical.
>> should the mips64 archs be
>> renamed to follow the same convention?
>
> Only if we will also have non-softfloat mips64?
> (as sh3 has only softfloat currently)
sbmips has hardfloat as do many other mips64 processors.
Re: CVS commit: src
> > evb* method is used for boards/appliances that have > > less man power and few variants, I think. > > While it avoids clutter, it also tends to "bury the lead" as it were. > It is harder to know what NetBSD supports and eaiser to pass it by... It depends. (as I wrote "less man power") It might be worth to have explicit names of emips, cobalt, shark (and future netwalker) etc. in the port list for advocacy, but not algor, cesfic, mmeye, mvmeppc... --- Izumi Tsutsui
Re: CVS commit: src
On 01/28/2011 02:05, Izumi Tsutsui wrote: Out of curiosity, was there any thought is adding this to evbmips instead of getting its own top-level arch subdir? emips already has native bootloader and src/distrib files, so it's enough reason to have own port dir. to the PowerPC Virtex that lives in arch/evbppc/virtex. BTW evbppc has 405 vs oea issue in module. evb* method is used for boards/appliances that have less man power and few variants, I think. While it avoids clutter, it also tends to "bury the lead" as it were. It is harder to know what NetBSD supports and eaiser to pass it by... Warner
Re: CVS commit: src
On 28 January 2011 14:40, Izumi Tsutsui wrote: > > hpcmips chose and implemented painful fpemul to avoid such discussion, > IIRC :-) > If emips is going to be using softfloat it looks like it could be an opportunity for hpcmips machines of the same endian to gain some better suited pkgsrc binaries :) As a complete aside whatever is done to address this might be extended to mac68k which has a selection of machines with broken FPU emulation and as such require softfloat userlands. Currently someone just builds & provides softfloat userlands outside of the project...
Re: CVS commit: src
uwe@ wrote: > Heh, adding FPU support to sh4 kernels is not that much work, Just FYI, ftp://ftp.NetBSD.org/pub/NetBSD/misc/nonaka/sh4-fpu/ ftp://ftp.NetBSD.org/pub/NetBSD/misc/nonaka/sh4a/ > but i > never had energy to sit down and figure out how to handle hard vs > softfloat userlands :) --- Izumi Tsutsui
Re: CVS commit: src
On Fri, Jan 28, 2011 at 23:40:34 +0900, Izumi Tsutsui wrote: > Only if we will also have non-softfloat mips64? > (as sh3 has only softfloat currently) Heh, adding FPU support to sh4 kernels is not that much work, but i never had energy to sit down and figure out how to handle hard vs softfloat userlands :) As an aside, I've just learned recently that regardless of fp support sh3 and sh4 are not abi compatible: 64-bit args are "aligned" to register pairs on sh4, but not on sh3. E.g. you cannot call snprintb(3) across abis, "uint64_t val" argument is passed differently. -uwe
Re: CVS commit: src
> > > Do you have a naming suggestion? mipsebsf? > > > > hpcmips chose and implemented painful fpemul to avoid such discussion, > > IIRC :-) > > heh. well, in this case I guess we could implement fpu support in the > CPU to avoid discussions ;) Heh, indeed, though I'm afraid it will require more FPGA chips :-) --- Izumi Tsutsui
Re: CVS commit: src
On Fri Jan 28 2011 at 23:40:34 +0900, Izumi Tsutsui wrote: > > Do you have a naming suggestion? mipsebsf? > > hpcmips chose and implemented painful fpemul to avoid such discussion, > IIRC :-) heh. well, in this case I guess we could implement fpu support in the CPU to avoid discussions ;) -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
pooka@ wrote:
> > > additionally, userland is built with MKSOFTFLOAT=yes,
:
> > In that case, shouldn't we have different ${MACHINE_ARCH}
> > for different binaries?
>
> i think you're right. hmm, looking at the build cluster output there
> seem to be very few sets shared between mips archs (i don't know the
> details of how they are selected).
base and comp can't be shared due to etc.
On the other, packages binaries are seriously affected.
> Do you have a naming suggestion? mipsebsf?
hpcmips chose and implemented painful fpemul to avoid such discussion,
IIRC :-)
It looks eb/el should be suffix, but probably we should check
other OSes and misc configure scripts etc.
> should the mips64 archs be
> renamed to follow the same convention?
Only if we will also have non-softfloat mips64?
(as sh3 has only softfloat currently)
---
Izumi Tsutsui
Re: CVS commit: src
On Fri Jan 28 2011 at 16:26:50 +0200, Antti Kantee wrote:
> On Fri Jan 28 2011 at 23:07:37 +0900, Izumi Tsutsui wrote:
> > > additionally, userland is built with MKSOFTFLOAT=yes,
> >
> > Hmm.
> >
> > In that case, shouldn't we have different ${MACHINE_ARCH}
> > for different binaries?
>
> i think you're right. hmm, looking at the build cluster output there
> seem to be very few sets shared between mips archs (i don't know the
> details of how they are selected).
>
> Do you have a naming suggestion? mipsebsf? should the mips64 archs be
> renamed to follow the same convention?
Actually, shouldn't things work even with hardfloat binaries on a nofpu
arch with fpu emul, and softfloat binaries should work on a hardfloat
machine. The performance will not be the same, but isn't that technically
the same thing as compiler optimization for a certain cpu type?
(i never tried building/running non-softfloat binaries on emips)
--
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
On Fri Jan 28 2011 at 23:07:37 +0900, Izumi Tsutsui wrote:
> > additionally, userland is built with MKSOFTFLOAT=yes,
>
> Hmm.
>
> In that case, shouldn't we have different ${MACHINE_ARCH}
> for different binaries?
i think you're right. hmm, looking at the build cluster output there
seem to be very few sets shared between mips archs (i don't know the
details of how they are selected).
Do you have a naming suggestion? mipsebsf? should the mips64 archs be
renamed to follow the same convention?
--
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
> additionally, userland is built with MKSOFTFLOAT=yes,
Hmm.
In that case, shouldn't we have different ${MACHINE_ARCH}
for different binaries?
---
Izumi Tsutsui
Re: CVS commit: src
On Fri Jan 28 2011 at 18:05:50 +0900, Izumi Tsutsui wrote: > > Out of curiosity, was there any thought is adding this to evbmips > > instead of getting its own top-level arch subdir? > > emips already has native bootloader and src/distrib files, > so it's enough reason to have own port dir. additionally, userland is built with MKSOFTFLOAT=yes, and there are several hardware devices the port runs on. also, sysinst has some port-specific tweaks. plus, what was said about a research platform, with implications for teaching too. so, no consideration to evbmips. i think the port is right where it belongs. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src
> Out of curiosity, was there any thought is adding this to evbmips > instead of getting its own top-level arch subdir? emips already has native bootloader and src/distrib files, so it's enough reason to have own port dir. > to the PowerPC Virtex that lives in arch/evbppc/virtex. BTW evbppc has 405 vs oea issue in module. evb* method is used for boards/appliances that have less man power and few variants, I think. --- Izumi Tsutsui
