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 ...
phk at phk.freebsd.dk
Thu May 18 06:47:35 PDT 2006
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.
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
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.
More information about the cvs-src