Date: Thu, 18 May 2006 15:47:30 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: hellmuth.michaelis@t-online.de Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Julian Elischer <julian@elischer.org>, cvs-all@freebsd.org Subject: Re: 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 ... Message-ID: <39318.1147960050@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 18 May 2006 15:16:14 %2B0200." <200605181516.15541.hm@kts.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200605181516.15541.hm@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39318.1147960050>