Re: [rfc] a few kern.mk and bsd.sys.mk related changes

[Pan Tsu]

Alexander Best  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)

[Pan Tsu]

Oliver Fromme  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

[Pan Tsu]

Zhihao Yuan  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"

Re: [GSoC] About the idea: Unicode support in vi

[Pan Tsu]

Zhihao Yuan  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

[Pan Tsu]

Zhihao Yuan  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 
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 
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 
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 
___
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"