> I sent an email to tedu@ the other day, but I thought it may be better > to just send it to tech@ to see whether we can sort this out. > > After I implemented utmpx for FreeBSD, I realized OpenBSD is the only > commonly used maintained UNIX-like operating system which doesn't > implement: > > - posix_openpt(), grantpt(), unlockpt() and ptsname(), and > - utmpx. > > This causes a real burden on people trying to write network login > services, terminal emulators, terminal multiplexers, etc.
You are killing us with hyperbole. It is now hard to take anything you say seriously. > It would be so > much easier if authors of (new) pieces of software can just use these > interfaces with confidence and expect things to work properly. I strongly doubt it, since the old and new interfaces both suck, just in different ways. This is apparent from the size of your diff and the number of errors introduced. > So as a proof of concept I am working on a patchset, where I took my > utmpx implementation that I wrote for FreeBSD and added it to OpenBSD's > libc. It also contains patches for various utilities in the base system > to let it use utmpx. It is by no means complete, but should give you at > least an idea of what it's going to look like. Below is a link to the > latest version: > > http://80386.nl/pub/openbsd-utmpx.txt > > Ignoring the build failures, it is already possible to ssh into the > system and send messages to each other using wall/write. > > I have two questions: > > - Is there any interest in getting utmpx support integrated into > OpenBSD? > - If so, is there a developer willing to work with me to get my patchset > smashed into shape and eventually committed? If I recall correctly, we've told you no before, because you've pushed for this about two years ago. First off, to get that off the plate, we don't have the POSIX, no call it what it is --- SVR4 -- pty stuff because it is a gigantic race. It was designed in response to the pty race research by Dan Bernstein, but the result was that the SVR4 guys still got it wrong. But regarding the utmpx stuff, you've now sent us a diff which - writes uninitialized stack data to the file (date.c, init.c, perhaps more) - delete etc/ttys.pty because you don't know what it is for - removes an API from libc which you have not verified is unused - crank the minor of libc, without realizing that since you have changed and removed interfaces, you would need to do a *major* bump of libc, libutil, a few X libraries, and probably 20-30 packages with libraries which will now detect the new interfaces and potentially change the behaviour. - sneaks bits of incompatible behaviour into various programs (ie. last) We have a utmp which was extended a decade ago to have much longer fields. It works just fine. I don't see what benefit the extra junk in the utmpx file provides to anyone. Oh, it's got a pid, so that you can send a signal to the wrong process...
