have a cu command installed, even when the rest of uucp was removed
via MKUUCP=no. The old uucp-derived cu is no more, and is not
installed in either case.
make it so, by correcting some confusion that had made the non-uucp
tip-as-cu cu conditional on MKUUCP
Use __builtin_va_* instead of hand written code in va-sh.h that uses
LHS casts. Slightly worse code is generated by gcc 3.3.3, but LHS
casts are outlawed in gcc 3.3.6 and gcc 4.
Build-tested on hpcsh (le) and mmeye (be), run-tested on hpcsh.
initiator (used on Solaris 10 Update 1) - the initiator demands that a
UUID is returned, so give it one.
Add autoconf glue for that, and a compat uuid_create(3) and
uuid_to_string(3).
This still spews a lot of output via the target's syslog, but persevere,
since it does actually make the target work with the Solaris initiator:
solaris10# format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c1d0 <DEFAULT cyl 29728 alt 2 hd 64 sec 63>
/pci@0,0/pci-ide@1f,1/ide@0/cmdk@0,0
1. c2t5d0 <DEFAULT cyl 96 alt 2 hd 64 sec 32>
/iscsi/disk@0000iqn.1994-04.org.netbsd.iscsi-target%3Atarget00001,0
Specify disk (enter its number): ^D
solaris10# df -k /mnt
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c2t5d0s0 91407 1041 81226 2% /mnt
solaris10# uname -a
SunOS solaris10 5.10 Generic_118844-26 i86pc i386 i86pc
solaris10#
/sys/net/if_spppvar.h says:
"Lower layer drivers that are always ready to communicate
(like hardware HDLC) can shortcut pp_up from pp_tls,
and pp_down from pp_tlf."
When I follow those instructions, I get a kernel stack
overflow as soon as I open the HDLC device.
Here is the loop:
sppp_ioctl calls sppp_lcp_open
sppp_lcp_open calls sppp_open_event
sppp_open_event calls sppp_lcp_tls
sppp_lcp_tls calls pp_tls
pp_tls is the SHORTCUT to sppp_lcp_up
sppp_lcp_up calls spp_lcp_open
...and around we go until the stack overflows.
The fix is to reverse the order of the action (tls)
and the state change (from INITIAL to STARTING) in
sppp_open_event.
There is a similar loop during closing:
sppp_ioctl calls sppp_lcp_close
sppp_lcp_close calls sppp_close_event
spp_close_event calls sppp_lcp_tlf
sppp_lcp_tlf calls pp_tlf
pp_tlf is the SHORTCUT to sppp_lcp_down
sppp_lcp_down calls sppp_lcp_close
...and around we go until the stack overflows.
The fix is to reverse the order of the action (tlf)
and the state change (from STARTING to INITIAL) in
sppp_close_event.
Separately, while I was discovering this, I noticed
that pp_tlf was being called unconditionally rather
than first checking to see if it is NULL. pp_tlf
is a callout from sppp to the hdlc device driver.
Elsewhere in sppp, this is always checked for NULL
before calling it, and the comments in if_spppvar.h
imply that filling it in is optional.
From spppvar.h:
"These functions need to be filled in by the lower layer
(hardware) drivers if they request notification from the
PPP layer whether the link is actually required."
This clearly says that pp_tlf and pp_tls are optional
and so sppp must check before calling them.
ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX before defining them. (XXX should we
use the versions in pa-linux.h? or what?)
also, convert ASM_FILE_START into TARGET_ASM_FILE_START, using the
pa_linux_file_start version.
