Nice in theory --- but.
The primary rule here is: if it's on our network, WE run it. CMU's a top
target for hackers; we can't afford to have sitting targets outside our
control on our network. (SCS doesn't use that rule... and they appear to
have a *serious* hacker problem, one which occasionally leaks into ECE. But
the concerns below apply even more so for them --- after all, we've only LCS
doing kernel munging, whereas for them it's quite normal.)
Unfortunately, that doesn't quite work with LCS, as they *need* to be able
to boot experimental kernels and the like. These folks spend most of their
time playing with derivatives of the MIT exokernel; they use 2.1/2.2pre on
non-exokernel machines because it gives them more options for testing and
experimenting with the TCP/IP stacks on the exokernel machines.
A separate network has been considered. They've rejected it so far... or
rather, so far they haven't decided what they want a separate network to
handle and what if any outside access they want to allow. And the
development machines pretty much *have* to have access to both ECE's and
SCS's AFS servers... and masquerading for AFS clients is a royal pain; it
looks like I'd have to permanently allocate a block of ports on the
masquerade server and permanently map them to ports 7000-7003/udp (at least)
on the clients. (The AFS servers have long memories as to which ports the
clients are using. I wish rx had a TCP option....)
I'm not in a position to work on 2.1/2.2pre support for them, beyond trying
to make sure things don't break too badly, i.e. fixing the 2.2-unfriendly
warts in Red Hat 5.2 (/etc/rc.d/init.d/kerneld, util-linux-2.8, etc.) and
trying to get a stable enough Arla configuration that they can at least try
to work in the heavily AFS-oriented CMU environment. And I can't build
"approved" 2.1/2.2pre kernels for them because they might well be patching
them (and regularly revising the patches) to support torture of exokernels
:-) (And no, I'm don't claim to be smart enough to keep up with these grad
students. As if I haven't made that obvious regularly on this list :-)
So a decent way to recover the configuration of a running kernel would be a
great help around here.
--
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
We are Linux. Resistance is an indication that you missed the point.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/