当 X 启动时，它会搜索最低的未使用 VT，并附加到它。我的问题是，当有多个正在运行的 X 进程时，我需要能够确定哪个是当前活动的进程。
这是一个 *BSD 问题，因为在 linux 上这很容易：X 将其控制终端设置为ttyN，或者，在非常旧的发行版中，它在命令行中指定为vtN. 所以，我正在运行一个服务，我看到当前活动的VT是tty7，并且有两个X服务器在运行，很容易分辨出哪个对应于当前终端。（这是一个合理的情况：也许用户使用了 GNOME/KDE 的“切换用户”功能或使用 运行了两个服务器startx。）可能想要跟踪活动 X 服务器的示例应用程序是x11vnc（它是从我正在开发的软件中分叉出来的） ）。
但是在 FreeBSD 上，控制终端不会告诉你任何事情。当 X 从 ttyv1 启动时，它仍然是控制终端。
我已经做了尽职调查并阅读了 X 代码。经过一番摸索，我现在更清楚发生了什么。
在lnx_init.c 中，X 服务器确实setsid为自己创建了一个新会话，然后直接打开一个 fd 对其ttyN进行VT_ACTIVATEioctl。相当标准；从没有控制终端的进程向没有控制进程的终端打开 fd 将两者关联起来，服务器保持 fd 打开，因此可以保证终端将保持 X 服务器的控制终端。
现在，在bsd_init.c 中，打开 fd 到 tty 以用作帧缓冲区并不会使其成为控制终端（事实上，如果没有setsid，从xinitttyv2 上启动的 BSD Xserver将保持 ttyv2 作为其 ctty！）。
如何从大于最大 off64_t 的文件中读取或查找？出现问题是因为进程的地址空间在/proc/.../as文件中表示，对于 64 位进程来说，这是一个巨大的稀疏文件。它真的很大：在Solaris x86-64上的示例进程上，argv的地址是0xFFFFFD7FFFxxxxxx，即使用了地址空间的最顶部。指针是无符号的，但 off64_t 是有符号的，因此无法到达地址空间文件上半部分的任何内容。
这显然取决于地址空间的布局。在 32 位系统上，这不是问题（long偏移量不够大，但off64_t很容易工作），在 linux 上的 x86-64 上（例如），进程的顶部是 0x7fffxxxxxxxx（48 位） ，所以 off64_t 再次可以引用进程地址空间中的任何内容。
因此，令人遗憾的是，x86-64 上的 Solaris 似乎使用整个 64 位地址空间，而 50 位已绰绰有余。Sun 使用 psinfo_t.pr_argv 的示例似乎除了在 SPARC 和 x86 上不起作用。有没有办法解决这个问题？
我不是要对这个问题发火！我无法从 Oracle 就 Solaris 的未来发表任何声明，并想知道是否有任何新闻稿或未来版本的官方通知。据我了解，Solaris 上的工作已大大缩减，而且开发速度并不快。Solaris 11 会是最后的派对吗？除了无休止的安全更新之外，别无他物吗？