Re: CVS commit: src/sys/arch/atari/stand/installboot

[Dennis Ferguson]

On 14 Nov, 2014, at 14:18 , Martin Husemann mar...@duskware.de wrote:
 I still don't see the segmentation violation - what am I missing?
 Gdb is a bit confused about the stack:

This

0x8c2b4: movel %d1,%a1@+

looks a little suspicious.  %a1 seems to be 0x4.

Dennis Ferguson

Re: CVS commit: src/sys/arch/x68k/stand/boot_ustar

[Dennis Ferguson]

On 15 Apr, 2014, at 05:14 , Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:
 - NetBSD/x68k supports only X680x0 machines with MC68030 and higher
  processors.
 
 - Normal X68000 machines (i.e. all X680x0 except X68030) have MC68000,
  so 030 accelerators are required for the X68000 models, i.e.
  XVI, SUPER, EXPERT, PRO, and ACE.
 
  (BTW the normal X68030 has MC68EC030 so users also have to replace
   its CPU to with MC68030 to use NetBSD/x68k)
 
 - On the other hand, probably early x68k developers considered
  that some stupid users could try to boot NetBSD/x68k on X68000
  without 030 and bootloaders should have some sanity checks.

I'm pretty sure NetBSD could never run on a 68000 since the 68000
had no memory management unit.  The 68010 and 68020 didn't have memory
management units either, but Sun did proprietary MMUs for both (that's
sun2 and sun3, respectively) and I think other companies may have done
MMUs for the 68020.  The 68030 was the first CPU in the series to come
with an MMU built in.

That generic x68x requires a 68030 makes sense since that's the first
CPU where the code can count on knowing how the MMU works.  A 68020
would have a manufacturer-specific MMU, while for the 68010 there is
only sun2.  There is no reason to restrict the instruction set to
that of the 68000 in any case since NetBSD won't run on that.

I once had a 68000 board that ran a 4.3 BSD kernel, but it was a
4.3 BSD kernel with all the process scheduling hacked out so that
it ran exactly 1 compiled-in user space process, without memory
protection.  I used it as an ntp server.

Dennis Ferguson

Re: CVS commit: src/sys

[Dennis Ferguson]

On 26 Nov, 2013, at 01:55 , Alan Barrett a...@cequrux.com wrote:
 -for (mp = mountlist.cqh_first; mp != (void*)mountlist; mp = nmp) {
 -nmp = mp-mnt_list.cqe_next;
 +for (mp = mountlist.tqh_first; mp != (void*)mountlist; mp = nmp) {
 +nmp = mp-mnt_list.tqe_next;
 
 ... could be rewritten to use TAILQ_FOREACH.

Actually not TAILQ_FOREACH, but TAILQ_FOREACH_SAFE, though the operation
of the latter is obscure enough that one could be forgiven for writing
code that makes what is needed explicit.

For a minimal improvement just TAILQ_FIRST and TAILQ_NEXT would be good.

Dennis Ferguson

Re: CVS commit: src/sys/sys

[Dennis Ferguson]

On 21 Nov, 2013, at 11:04 , Christos Zoulas chris...@netbsd.org wrote:

 Module Name:  src
 Committed By: christos
 Date: Thu Nov 21 19:04:19 UTC 2013
 
 Modified Files:
   src/sys/sys: queue.h
 
 Log Message:
 provide a const and a non const flavor for CIRCLEQ_END because the kernel
 needs a const one. The const one is supposed to be used for comparisons
 and the non-const one for assignments.

It is a tiny thing, but I think one of the CIRCLEQ_END macros is
useful in applications to replace what is now written as (void *)head with
CIRCLEQ_END(head), and the version best suited for this should be the
one named CIRCLEQ_END() with no extra characters.

Given that all application use of (void *)head in the base system is
for end-of-list comparisons, while only the macros do assignments to
list variables, it might be a bit better to call the comparison version
CIRCLEQ_END() and the assignment version something else.  If you really
do decide to fix the alias problem with the ugly inline then CIRCLEQ_END()
can be defined as that to fix both macros and applications while leaving
CIRCLEQ_END_DONT_USE_THIS() as-is for assignments.

Dennis Ferguson