EPROTONOSUPPORT instead of EAFNOSUPPORT.
from pavel@ with a little bit of clean up from myself.
XXX: netbsd32 (and perhaps other emulations) should be able
XXX: to call the standard socket calls for this i think, but
XXX: revisit this at another time.
Big5-2003, Big5-ETen, Big5-IBM, Big-5E, Big-5+.
``Big5 is now the alias of Big5-ETen,
if you want Unicode.org's obsolete mappings, use Big5-IBM instead.
NetBSD Foundation Membership still pending.) This stack was written by
Iain under sponsorship from Itronix Inc.
The stack includes support for rfcomm networking (networking via your
bluetooth enabled cell phone), hid devices (keyboards/mice), and headsets.
Drivers for both PCMCIA and USB bluetooth controllers are included.
The former two are no longer necessary as slstats is no more
and pppstats now uses an ioctl instead of rummaging through kmem.
The latter has nothign interesting for the userland, but uses
struct bintime that I'm about to hide under #ifdef _KERNEL.
A bunch of remaining <net/if_*.h> headers is pretty useless to the
userland too, but ... someone else's yag to shave...
default the partition to FFSv2 (instead of FFSv1).
This makes update installs add the correct bootstrap code.
Fixes PR/33682 and PR/32636 (and 33228 which has alrady been closed
as a duplicate of 32636).
of obsolete directories and handle them via the "sendmail" item in
postinstall(8), too. These directories are of course necessary on
systems using the "sendmail" package.
Problem pointed out by Hisashi T Fujinaka on "current-users" mailing list.
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
prop_dictionary_keysym_equals(), and prop_object_equals() functions.
- Use realloc() where it makes sense. There will be more changes in this
area.
- Add a _prop_object_type structure that is used internally to keep
information about the object types. Decreases the footprint of the
objects slightly by replacing several pointers with just one.
a "distribution" build with MKGCCCMDS=no and any of MKCATPAGES, MKMAN, and
MKINFO set to yes can still succeed.
Tested with two distribution builds of i386; one with MKGCCCMDS=no and
one without.
floppies. (The build is broken again without this.) "boot-big1.fs", from
the same ramdisk as "bootN.fs", still just fits in 2880KB by virtue of the
fact that the 9KB of padding is only added once per floppy image.
I think the code it correct - but since it is only relevant when setting
the default boot partition (for mbr_bootsel) to an extended partition
it probably doesn't matter too often!
* RFC 3542 isn't binary compatible with RFC 2292.
* RFC 2292 support is on by default but can be disabled.
* update ping6, telnet and traceroute6 to the new API.
From the KAME project (www.kame.net).
Reviewed by core.
While there are some open issues, particulary wrt support of old
NetBSD-specific interfaces, it is better to get the code some public
testing before NetBSD-4 is branched.
${RELEASEDIR}/${MACHINE}. The former is the blessed way as it's
defined as a "subdirectory used below ${RELEASEDIR} when building a
release" and defaults to MACHINE in bsd.own.mk.
Make sure that ${RELEASEDIR}/${RELEASEMACHINEDIR} exists before
installing notes in to it. It only ever worked because ~all ports
build at least one kernel as part of make release, and so the release
directory was created when kernel sets are installed.
XXX: Why don't we create ${RELEASEDIR}/${RELEASEMACHINEDIR} from the
top-level makefile before running make release?
bad output for HTML, and warning for other formats. Fix last line to
have enough empty cells.
XXX: The list of portmasters should be sorted by last name.
gpioow(4), attaching a bit-banging driver via a GPIO pin. Also,
owtemp(4) which supports some of the 1-Wire temperature sensors, including
the DS18b20 and DS1920 - temperatures are returned via the envsys(4)
framework.
Original drivers by Alexander Yurchenko (grange@openbsd), with envsys(4)
support and a fix to the 1-wire search algorithm (for discovering
devices on the bus) by me.
As discussed on tech-kern earlier this week.
1) Add an md_post_extract() function. This function is called after
extracting the sets, and allows the arch to do something at that time.
In the case of prep, it is much easier to install the bootcode after all
the sets are extracted, so we do it in md_post_extract(). Added empty
md_post_extract() functions to all other arches so they compile.
2) Add md_mbr_use_wholedisk() and md_check_mbr(). In edit_mbr() I have
split off the code that uses the whole disk for NetBSD, into the
mbr_use_wholedisk() function. On most ports that use mbr.c, I made
md_mbr_use_wholedisk() just call that and return. On prep we create the
magical prep boot partition here. The md_check_mbr() function allows the
arch to add additional checks after the user had manually edited the MBR
to make sure the choices he made allow NetBSD to function. Added a dummy
routine to all mbr.c using arches.
3) Added code to bsdlabel.c to create a partition of type boot if
PART_BOOT is defined, but BOOT_SIZE is not defined. Also added two more
globals "bootsize" and "bootstart" which must be seeded in order to do
so. This is done on prep in md_check_mbr().
4) Added MBR_PTYPE_PREP to the list of MBR partitions.
5) Made the prep port actually install sanely. It now creates a prep
boot partition, labels it correctly, installs all the sets, and then runs
mkbootimage and dd's the bootimage into the prep partition. The result
is a prep installer that creates a bootable NetBSD installation
automatically.
6) Edited the prep menus and messages files to add new labels. In the
case of the translated files, I just added the words in english for
someone to translate later.
I tried to xcompile a few arches to make sure I didn't break anything,
but I could have missed something. Please let me know if I have broken
your arch in any way. I'll watch the autobuilds for the next few days
too. For all ports other than prep there should be no functional changes
at all.
of digital video recorders popular in Europe and Australia.
These devices have a USB client port which can be used to upload and
download recordings (and other files, such as MIPS binaries for execution
on the DVR's CPU) to/from their internal hard disk, in addition to some
other operations on files and directories.
mrg