Personally, I believe that a Plan9 target for a cross compiler might be more interesting. GCC already added support for the Plan9 dialect of C. If it also could be made to compile Plan9 binaries, it could be used for an alternative self-hosting distro as the one you envisaged.
I am fully aware that this is quite herretic and probably not very interesting for mainline Plan9. 2011/7/11 <rbnsw-pl...@yahoo.com.au>: > Not to rain on anyone's summer of code project but I think producing a Linux > distro that runs on top of Plan 9 would be more beneficial to the Plan 9's > future than a Plan 9 userspace on top of Glendix, though nowhere as > interesting. > > I've no problem with a kernel that could run both Plan 9 and Linux binaries > but if your goal is that Plan 9 binaries run unchanged on such a system then > you will require some sort of device mapping layer, say a FUSE file system > that makes Linux devices look like their Plan 9 counterparts - the chief > problem being mapping between Linux ioctls and the Plan 9 ctl file protocols. > > While you could do that, I have my doubts as to how complete this would be > and whether it would be maintained. Moreover, it doesn't do anything to cause > Linux and Plan 9 to converge. Since it is difficult to make ioctl work over > the network unless source and destination have the same binary architecture > Linux needs to be encouraged to change to be closer to the Plan 9 device > model, or at least to a portable ioctl model. Providing a mapping layer just > entrenches the problem with Linux and moves Linux no closer to a solution. > > Unfortunately, even though there are clustering solutions available which > even address process migration Linux people seems quite happy to address > remote device access with ad hoc solutions. > > I see a GNU/Linux/Plan 9 distro as making Plan 9 more appealing to the > greater public and to aid its domination. Screw fixing Linux to be more Plan > 9 like, lets assume Plan 9 has won and the rest is a mere implementation > detail. Perhaps some of users attracted buy such a disto will be encouraged > to add Plan 9 support for their devices or modify Linux libraries to access > Plan 9 natively rather than via Linux emulation. Nothing should be removed, > where Plan 9 does something in a perfectly acceptable and sensibly complete > way it should be the only mechanism provided (in the long term at least) and > the Linux code reliant on the missing mechanism ported to work natively with > Plan 9 - unless it is much less work to emulate whatever is missing. To take > code using ioctl as an example, the code should be refactored so that both a > Plan 9 and Linux libraries with a portable interface are produced, and the > modified Linux source and libraries submitted to the current > maintainers. However, standard C wchar_t based programs probably should be > left alone rather the modified to use the Plan 9 string processing model. > > Now just for the hell of it, let imagine a world where clustering solutions > are built on a Plan 9 base. I'd certainly like something where my local > processes migrate from my lower powered laptop including the Window manager > migrate to a more powerful CPU when it becomes available and back again when > my laptop becomes disconnected, > > Now, if I ever can decide on a Linux distribution and ever get Plan 9 to > boot, I will see what I can do... > > >
