On Mon, Feb 28, 2011 at 10:08:07PM +, Jonathan A. Kollasch wrote:
>
> autogen requires ed(1), which is not provided by our toolchain.
> (In other words, this causes a odd build failure on some Linux build
> hosts.)
I've not looked, but it is probably not too hard to change the script
to use a
On Wed, May 19, 2010 at 05:55:36PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Wed May 19 21:55:36 UTC 2010
>
> Modified Files:
> src/regress/sys/net: Makefile
> Added Files:
> src/regress/sys/net/ether_aton_r: Makefile autogen main.c
>
>
Matt Thomas wrote:
> As the overall powerpc port maintainer, I'd rather see all new
> majors be allocated from major.powerpc. This is that eventually
> all powerpc ports can use the same major number and that will
> eliminate one reason why we can't have a shared userland.
Ok, agreed. We make it
On Feb 28, 2011, at 6:55 AM, Toru Nishimura wrote:
> Frank Wille said;
>
>>> either way, 144 is wrong.
>> Ok. So you would suggest to allocate 100 for all powerpc ports?
>
> arch/powerpc/conf/major.powerpc contains "gtmpsc" for Marvell
> Discovery PPC system controller which is particular for a
Jukka Ruohonen wrote:
> > Why interrupts are disabled here? Calling xc_wait() with interrupts
> > disabled is, at minimum, very expensive, and I would say it is wrong.
> > Note that xc_wait(9) does not necessary spin - it can block.
>
> Because interrupts must be disabled when APERF and MPERF ar
On Mon, Feb 28, 2011 at 04:48:43PM +, Mindaugas Rasiukevicius wrote:
> Why interrupts are disabled here? Calling xc_wait() with interrupts
> disabled is, at minimum, very expensive, and I would say it is wrong.
> Note that xc_wait(9) does not necessary spin - it can block.
Because interrupts
Hello,
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> >> Log Message:
> >> an implementation of radix tree. the idea from linux.
> >
> > How is that different from ptree?
>
> while i'm not familiar with ptree...
>
Patricia/Radix tree added by Matt (see src/common/lib/libc/gen/ptree.c
and
Jukka Ruohonen wrote:
>
> Are there any plans for kernel equivalent to cpuset(3)?
>
Yes, there is kcpuset(9), see kcpuset_create() and friends. I plan to
modify it so it could be used early in MD code (when memory allocation
is not yet available) and thus unify random MD cpuset implementations
"Jukka Ruohonen" wrote:
> Module Name: src
> Committed By: jruoho
> Date: Fri Feb 25 09:16:00 UTC 2011
>
> Modified Files:
> src/sys/arch/x86/acpi: acpi_cpu_md.c
> src/sys/dev/acpi: acpi_cpu.h acpi_cpu_pstate.c
>
> Log Message:
> Add preliminary support for the IA32_APERF an
Frank Wille said;
either way, 144 is wrong.
Ok. So you would suggest to allocate 100 for all powerpc ports?
arch/powerpc/conf/major.powerpc contains "gtmpsc" for Marvell
Discovery PPC system controller which is particular for a very
specific platform. Then, it'd be forgiving to cope with ha
matthew green wrote:
> since satmgr(4) is sandpoint specific, it very much does not
> belong in the 144-159 range.
>
> why does it need to be changed?
Because I fear that the next developer who adds a new device to
majors.powerpc will use 100, without realizing it is in use by sandpoint.
> thi
11 matches
Mail list logo
