cvs commit: src Makefile.inc1 ObsoleteFiles.inc src/etc/defaults rc.conf src/etc/mtree BSD.usr.dist src/etc/rc.d Makefile isdnd pcvt syscons src/release/picobsd/build picobsd src/share/man/man4 Makefile atkbd.4 kbdmux.4 pcvt.4 splash.4 vkbd.4 ...

[Poul-Henning Kamp]

In message <200605181516.15541.hm at kts.org>, Hellmuth Michaelis writes:

>With all respect for you and your work on FreeBSD, Poul-Henning,
>i'd like to get some things said:
>
>pcvt is broken since your cleanup of the tty kernel code.

Correct.

I attempted to migrate pcvt, but had to give up, it would simply
take too much time for me to figure out how to make it work.

As far as I recall, the problem is that struct tty is no longer
controlled by the driver and that made the changes very massive.

If somebody finds time to update PCVT to our current APIs, then I
have absolutely no problems with it coming back.

On the other hand, if neither you, I nor anybody else has time to
fix PCVT, the it clearly is not important enough to hold up work
on the infrastructure or generic pieces of the kernel.


This all comes back to what I have harped about many times over
before, we can either:

A)	Avoid breaking anything by leaving our infrastructure
	unchanged.  This is the fastest way to become a
	"historical operating system" because things like
	removable devices, power management, SMP locking etc
	will simply not happen to us.

B)      Update our infrastructure to the demands of the times,
	update as many of the drivers as reasonably possile, and
	if nobody picks up the missing bits, remove them and get
	on with our lives.

If you prefer A), pick any version of FreeBSD apart from -current
and stick to it.  Otherwise B) is a given.

Part of the problem is that there will never be a "definitive kernel
API manual" for FreeBSD, it will always be in flux and therefore
drivers will need to be updated to keep abreast.

Fortunately, improving our APIs reduce the amount of work repeated
through all drivers, and consequently increases the chance that
infrastructure changes does not affect drivers (as much).

We've seen this with disk- and ethernet-drivers already.

The tty work I did last year was first half of that excercise for
that area, it's still not done though, the console nastiness remains
to be handled.

Finally, I would like to say that some very good ideas where hashed
out with respect to screen handling, in particular by Marcel, and
any serious effort in time in this area would be better spent persuing
those ideas.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.