kcarnold@yahoo.com said:
> With 2.4.0 coming up soon and the split to the new devel following
> very close behind, I was just wondering what everybody's plans are for
> the next kernel release. I know there are a lot of little things that
> people are going to do anyway, but I'm talking about the big stuff. A
> couple of open questions to everybody, especially maintainers, follow.
OK, this is somewhat more intelligent. I'd also be interested in this stuff
from everyone else :-)
I'm going to be putting the user-mode port into an early 2.4, hopefully before
the 2.5 split so I don't have to send it in a second time to get it into 2.5.
> 1. What big internal API &c changes need to be made?
> 2. What new subsystems need to be added?
There are some ports of this port (:-) underway. The fact that it runs on
Linux makes it pretty portable, but the hardware does show through a little.
The infrastructure to do more Linux ports is mostly there. There is a ppc
port underway, and I've got an account on the sourceforge ia64 protos to do
that port. Other ports are welcome. For anyone who's interested, a port
currently involves writing four pretty straightforward procedures (soon to be
six), and some macros, getting the whole thing to build, and debugging it...
Ports to other OS's are another possibility. Other Unices would probably be
easiest. I took a quick look at a FreeBSD system, and it appears not to
support any kind of system call interception, so it is right out. There has
been some discussion of a Windows port, and it seems that the basic
capabilites are present in '98 and NT. This would be interesting because of
the possibility of using a user-mode virtual machine as a jail on Windows (and
other OS's as well, but Windows is in the most dire need of a good jail).
I'm thinking about a 'hostfs' filesystem which would provide convenient access
to the host filesystems.
> 4. What new drivers will be added? Is somebody already working on
> them?
In the driver department, we need an ethertap-based virtual network driver to
replace the existing slip-based driver. This has been partially done already,
but appears to have gone to sleep.
It might also be possible to provide user-mode access to the host I/O space
and registers. This could allow user-space development of native hardware
device drivers.
> 6. What code can be cleaned up? What code can be commented more?
All of it :-) My kernel exit code could do with a drastic cleanup. The
signal handling is a bit disorganized.
Volunteers for any of the above are welcome...
> Again, this is for you, not me.
> Just a minor hint that after all goals stated in maintainers' answers
> to the above questions are attained that there should be a feature
> freeze? Nah, I won't suggest anything that radical.
Sounds like you could still use a good night's sleep...
Jeff
-
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/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:22 EST