CAN stands for Controller Area Network, a broadcast network used
in automation and automotive fields. For example, the NMEA2000 standard
developped for marine devices uses a CAN network as the link layer.
This is an implementation of the linux socketcan API:
https://www.kernel.org/doc/Documentation/networking/can.txt
you can also see can(4).
This adds a new socket family (AF_CAN) and protocol (PF_CAN),
as well as the canconfig(8) utility, used to set timing parameter of
CAN hardware. Also inclued is a driver for the CAN controller
found in the allwinner A20 SoC (I tested it with an Olimex lime2 board,
connected with PIC18-based CAN devices).
There is also the canloop(4) pseudo-device, which allows to use
the socketcan API without CAN hardware.
At this time the CANFD part of the linux socketcan API is not implemented.
Error frames are not implemented either. But I could get the cansend and
canreceive utilities from the canutils package to build and run with minimal
changes. tcpudmp(8) can also be used to record frames, which can be
decoded with etherreal.
Remove rtsol(8) from rc.d/network.
Add -w seconds command to ifconfig to wait for N seconds for until DAD
has finished on all addresses.
Use ifconfig -w in rc.d/network instead of a forced sleep.
As discussed on tech-net@
listens on drvctl for new devices and invokes MAKEDEV for them.
missing:
- manual page
- rc.d script
- more testing
but it works well enough to make new disk nodes appear in /dev when
netbsd sees them and they're missing. you will need to make sure
you have a new /dev/MAKEDEV for this to work properly (postinstall
should handle this normally, of course.)
thanks jared!
to access, manage and manipulate device-mapper driver. Which opens us bunch
of new possibilities like
dm-multipath device target
dm-crypt device target
dm-ccd compatibility layer
With this import I'm bringing in dmctl tool for working with dm driver ,too.
I plan to replace gpl2 licensed dmsetup command with our dmctl tool in near
feature. It can also by placed to /rescue where we was not able to put
dmsetup because of licensing problems.
With libdm in tree we can now write RUMP atf test suite for dm driver to
ensure LVM subsystem stability as time goes.
Reviewed by: blymn@ and rmind@
Oked: by no objections on tech-userlevel@
ramdisks and prefer disklabel elsewhere.
Based on discussion on affected port lists (port-sparc port-sparc64
port-sun3 port-sun2 port-atari port-mvme68k).
All listed ports plus amd64 test built after change
tested with a DEBUG+DIAGNOSTIC+LOCKDEBUG kernel. To summerise NiLFS, i'll
repeat my posting to tech-kern here:
NiLFS stands for New implementation of Logging File System; LFS done
right they claim :) It is at version 2 now and is being developed by NTT, the
Japanese telecom company and recently put into the linux source tree. See
http://www.nilfs.org. The on-disc format is not completely frozen and i expect
at least one minor revision to come in time.
The benefits of NiLFS are build-in fine-grained checkpointing, persistent
snapshots, multiple mounts and very large file and media support. Every
checkpoint can be transformed into a snapshot and v.v. It is said to perform
very well on flash media since it is not overwriting pieces apart from a
incidental update of the superblock, but that might change. It is accompanied
by a cleaner to clean up the segments and recover lost space.
My work is not a port of the linux code; its a new implementation. Porting the
code would be more work since its very linux oriented and never written to be
ported outside linux. The goal is to be fully interchangable. The code is non
intrusive to other parts of the kernel. It is also very light-weight.
The current state of the code is read-only access to both clean and dirty
NiLFS partitions. On mounting a dirty partition it rolls forward the log to
the last checkpoint. Full read-write support is however planned!
Just as the linux code, mount_nilfs allows for the `head' to be mounted
read/write and allows multiple read-only snapshots/checkpoint mounts next to
it.
By allowing the RW mount at a different snapshot for read-write it should be
possible eventually to revert back to a previous state; i.e. try to upgrade a
system and being able to revert to the exact state prior to the upgrade.
Compared to other FS's its pretty light-weight, suitable for embedded use and
on flash media. The read-only code is currently 17kb object code on
NetBSD/i386. I doubt the read-write code will surpass the 50 or 60. Compared
this to FFS being 156kb, UDF being 84 kb and NFS being 130kb. Run-time memory
usage is most likely not very different from other uses though maybe a bit
higher than FFS.
and DVD's behave like floppy discs. Writing is supported upto and including
version 2.01; version 2.50 and 2.60 will follow.
Also extending the UDF implementation to support symbolic links and
hardlinks.
Added are the mmcformat(8) tool to format rewritable CD/DVD discs and
newfs_udf(8).
Limitations:
all operations can be performed on the file system though the
sheduling is currently optimised for archiving workloads.
mv(1)/rename(2) is currently only implemented for non-directories.
device controllers, and more specifically raid controllers.
Add a new sensor type, ENVSYS_DRIVE, to report drive status. From OpenBSD.
Add bio and sysmon support to mfi(4). This allow userland to query
status for drives and logical volumes attached to a mfi(4) controller. While
there fix some debug printfs in mfi so they compile.
Add bio(4) to amd64 and i386 GENERIC.
archs) and add wedges for them. Similar to the kernel options
DKWEDGE_AUTODISCOVER and DKWEDGE_METHOD_BSDLABEL, and actually reusing
most of that code.
This means, for example, you can plug a sparc64 disk into an i386, run
this tool and mount the partitions (provided your kernel has the FFS_EI
option).
commands to the controller.
Add a amrctl(8) control tool, which for now only allows to get status
from the adapter (status of adapter, logical volumes and and individual
drives).
From FreeBSD, with some adjustements by Andrew Doran and me.
was developed as part of Google's Summer of Code 2005 program. This
change adds the kernel code, the mount_tmpfs utility, a regression test
suite and does all other related changes to integrate these.
The file-system is still *experimental*. Therefore, it is disabled by
default in all kernels. However, as typically done, a commented-out
entry is added in them to ease its setup.
Note that I haven't commited the required mountd(8) changes to be able
to export tmpfs file-systems because NFS support is still very unstable
and because, before enabling it, I'd like to do some other changes.
OK'ed by my project mentor, William Studenmund (wrstuden@).
christos