Re: [rfc] a few kern.mk and bsd.sys.mk related changes
Alexander Best arun...@freebsd.org writes: On Fri May 27 11, Alexander Best wrote: On Fri May 27 11, Warner Losh wrote: These look generally good. Just one thing I had a question on: # +# Enable FreeBSD kernel-specific printf format specifiers. Also instruct gcc to +# enable some diagnostics, which make it easier to pinpoint tinderbox failures. +CFLAGS+= -fformat-extensions -fdiagnostics-show-option + Does this put sand in the gears of clang support? i've improved the above comment so as to note that clang won't be affected by -fdiagnostics-show-option. the new patch is available here: http://people.freebsd.org/~arundel/patches/kern.mk-bsy.sys.mk.patch another issue i've come across is the fact that on amd64, -O2 is always being set, no matter, if debugging is enabled or disabled. i think amd64 should also (just like all the other archs) be using -O, when debugging was enabled. Any reason a kernel with symbols (DEBUG) *must* be pessimized to -O1 level? Looking at r140606 it's not clear how symbols are related to a bump from -O1 to -O2 for non-amd64 archs. And -RELEASE kernels since at least 6.0R have `makeoptions DEBUG=-g' uncommented in GENERIC. changing this is quite easy. so if people think this is something worth changing i can integrate it into my existing patch. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Is BOOTWAIT still used? (Was: kernel memory checks on boot vs. boot time)
Oliver Fromme o...@lurza.secnetix.de writes: [...] To be honest, I don't think that loader takes so much time. When you set autoboot_delay=-1 and beastie_disable=YES, the time spent in loader is negligible. (I'm assuming that you also set BOOTWAIT=0 in make.conf, so boot2 doesn't wait for a keypress either. I think the default is to wait 3 seconds.) Is BOOTWAIT still used? A quick grep in sys/boot shows nothing. Digging history, BOOTWAIT never made its way from sys/i386/boot to sys/boot/i386 and was removed in r58284 around 11y ago. And more recently it disappeared from pc98, see r201342. %% Index: share/examples/etc/make.conf === --- share/examples/etc/make.conf(revision 219947) +++ share/examples/etc/make.conf(working copy) @@ -138,14 +138,6 @@ #PRINTERDEVICE=ps # # -# How long to wait for a console keypress before booting the default kernel. -# This value is approximately in milliseconds. Keypresses are accepted by the -# BIOS before booting from disk, making it possible to give custom boot -# parameters even when this is set to 0. -# -#BOOTWAIT=0 -#BOOTWAIT=3 -# # By default, the system will always use the keyboard/video card as system # console. However, the boot blocks may be dynamically configured to use a # serial port in addition to or instead of the keyboard/video console. Index: share/man/man5/make.conf.5 === --- share/man/man5/make.conf.5 (revision 219947) +++ share/man/man5/make.conf.5 (working copy) @@ -330,14 +330,6 @@ This defaults to The following list provides a name and short description for variables that are only used doing a kernel build: .Bl -tag -width Ar -.It Va BOOTWAIT -.Pq Vt int -Controls the amount of time the kernel waits for a console keypress -before booting the default kernel. -The value is approximately milliseconds. -Keypresses are accepted by the BIOS before booting from disk, -making it possible to give custom boot parameters even when this is -set to 0. .It Va COPTFLAGS .Pq Vt str Controls the compiler settings when building the %% ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [GSoC] About the idea: Unicode support in vi
Zhihao Yuan lich...@gmail.com writes:
Hi,
I'm a Computer Science student at Northern Illinois University, and I
used FreeBSD for a long time. I'm interested in the idea that to
improve the nvi in the base system. My proposal is slightly different:
I want to fork nvi and make it iconv-awared (or mbyte-mode tunable,
like tcsh), so that it can deal with more encodings. Can that be a
GSoC project proposal?
Why not just use traditional vi?
http://ex-vi.sourceforge.net/ (lives under editors/2bsd-vi)
don't forget to extract sources into contrib/ex-vi
diff --git a/rescue/rescue/Makefile b/rescue/rescue/Makefile
index d62b6f4..e6d8686 100644
--- a/rescue/rescue/Makefile
+++ b/rescue/rescue/Makefile
@@ -218,7 +218,8 @@ CRUNCH_LIBS+= -larchive -lmd
CRUNCH_LIBS+= -lcrypto
.endif
-CRUNCH_PROGS_usr.bin+= vi
+CRUNCH_SRCDIRS+= usr.bin/ex-vi
+CRUNCH_PROGS_usr.bin/ex-vi+= vi
CRUNCH_ALIAS_vi= ex
CRUNCH_PROGS_usr.bin+= id
diff --git a/usr.bin/Makefile b/usr.bin/Makefile
index f7965f1..ffde23d 100644
--- a/usr.bin/Makefile
+++ b/usr.bin/Makefile
@@ -169,7 +174,7 @@ SUBDIR= alias \
users \
uudecode \
uuencode \
- vi \
+ ex-vi \
vis \
vmstat \
w \
diff --git a/usr.bin/ex-vi/Makefile b/usr.bin/ex-vi/Makefile
new file mode 100644
index 000..d4db4a5
--- /dev/null
+++ b/usr.bin/ex-vi/Makefile
@@ -0,0 +1,5 @@
+# $FreeBSD$
+
+SUBDIR= expreserve exrecover vi
+
+.include bsd.subdir.mk
diff --git a/usr.bin/ex-vi/Makefile.inc b/usr.bin/ex-vi/Makefile.inc
new file mode 100644
index 000..4b1eb39
--- /dev/null
+++ b/usr.bin/ex-vi/Makefile.inc
@@ -0,0 +1,11 @@
+# $FreeBSD$
+
+SRCDIR= ${.CURDIR}/../../../contrib/ex-vi
+.PATH: ${SRCDIR}
+
+LIBEXECDIR?=/usr/libexec
+CFLAGS+=-DVMUNIX
+
+WARNS?= 1
+
+.include ${.CURDIR}/../../Makefile.inc
diff --git a/usr.bin/ex-vi/expreserve/Makefile b/usr.bin/ex-vi/expreserve/Makefile
new file mode 100644
index 000..ad1d953
--- /dev/null
+++ b/usr.bin/ex-vi/expreserve/Makefile
@@ -0,0 +1,7 @@
+# $FreeBSD$
+
+PROG= expreserve
+BINDIR= ${LIBEXECDIR}
+NO_MAN=
+
+.include bsd.prog.mk
diff --git a/usr.bin/ex-vi/exrecover/Makefile b/usr.bin/ex-vi/exrecover/Makefile
new file mode 100644
index 000..e808926
--- /dev/null
+++ b/usr.bin/ex-vi/exrecover/Makefile
@@ -0,0 +1,9 @@
+# $FreeBSD$
+
+PROG= exrecover
+BINDIR= ${LIBEXECDIR}
+NO_MAN=
+
+SRCS= exrecover.c mapmalloc.c
+
+.include bsd.prog.mk
diff --git a/usr.bin/ex-vi/vi/Makefile b/usr.bin/ex-vi/vi/Makefile
new file mode 100644
index 000..d974280
--- /dev/null
+++ b/usr.bin/ex-vi/vi/Makefile
@@ -0,0 +1,26 @@
+# $FreeBSD$
+
+PROG= vi
+MAN= ex.1 vi.1
+SRCS= ex.c ex_addr.c ex_cmds.c ex_cmds2.c ex_cmdsub.c \
+ ex_data.c ex_extern.c ex_get.c ex_io.c ex_put.c ex_re.c \
+ ex_set.c ex_subr.c ex_tagio.c ex_temp.c ex_tty.c ex_unix.c \
+ ex_v.c ex_vadj.c ex_vget.c ex_vmain.c ex_voper.c \
+ ex_vops.c ex_vops2.c ex_vops3.c ex_vput.c ex_vwind.c \
+ printf.c ex_version.c mapmalloc.c
+
+.for l in ex edit vedit view
+LINKS+= ${BINDIR}/vi ${BINDIR}/${l}
+.endfor
+MLINKS+=ex.1 edit.1 vi.1 vedit.1 vi.1 view.1
+
+CFLAGS+=-DUXRE -DREG_ANGLES=0 -DNO_BE_BACKSLASH
+CFLAGS+=-DEXPRESERVE=\${LIBEXECDIR}/expreserve\ \
+ -DEXRECOVER=\${LIBEXECDIR}/exrecover\
+CFLAGS+=-DLISPCODE -DCHDIR -DFASTTAG -DUCVISUAL -DMB -DBIT8
+#CFLAGS+=-DLARGEF
+
+LDADD+= -lncurses
+DPADD+= ${LIBNCURSES}
+
+.include bsd.prog.mk
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [GSoC] About the idea: Unicode support in vi
Zhihao Yuan lich...@gmail.com writes: Why not just use traditional vi? http://ex-vi.sourceforge.net/ (lives under editors/2bsd-vi) This one lacks of many feature, compared with nvi. nvi also lacks some features, e.g. lisp, modelines, sourceany. ex-vi is more lightweight # both built with DEBUG_FLAGS=-ggdb + mg(1) for reference $ du -Ah * 1.9Mnvi 556Kex-vi 505Kmg $ size * textdata bss dec hex filename 32908019524528 335560 51ec8 nvi 1756755048 233024 413747 65033 ex-vi 1285709760 10184 148514 24422 mg I'm not sure whether the FreeBSD system administrators (who opens 100 ssh sessions) agree with that to replace the nvi in base system with this one. Do they expect more features beyond POSIX vi? However, it's source code can be a great reference for a mbyte-capable nvi. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [GSoC] About the idea: Unicode support in vi
Zhihao Yuan lich...@gmail.com writes: If you really want to use vi in a 32MB mem environment, the ex-vi may make sense. It consumes 1600KB memory while nvi consumes 2000KB. Note that the ee editor uses same amount memory as ex-vi. ex-vi memory usage can be reduced a bit, e.g. by ~20% if you drop -DLISPCODE -DCHDIR -DFASTTAG -DUCVISUAL -DMB -DBIT8 in particular multibyte support. So basically, if no one disagree that we can drop the infinite undo, multiple buffer, multiple window and some other potential missing features, we can replace the nvi in the base system with ex-vi. If the intent is to make all interactive editors in base unicode aware then I wonder if you can use similar excuse when window(1) was kicked out but for missing features, i.e. use ports. As for other editors, ed(1) seems to support editing UTF-8. I've used it to read/edit cyrillic and CJK texts in single user mode before found out about ex-vi. And ee(1)... why not add unicode support there as a GSoC? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
