> > * R/W ntfs would be of use to many people.
> That might not be doable. According to the comments in the ntfs source, it
> is based largely on guesswork. Guesswork is fundementaly unsafe.
That won't change. If you think microsoft are going to tell people how their
stuff works and risk fair competition..
> > formating and stupid DBMS on block devices).
> Changing the kernel's cache behivior (including turning it off) may not be
> easy, but it is at least fundementaly possible. Keeping the phisical device
> from caching isn't so easy.
SCSI has explicit support for this. Real database people use SCSI
> > * All fancy ipv4 stuff (nat, firewall, scheduling) ported to IPV6
> Most of that should be protocol-independent.
Scheduling is protocol independant NAT and Firewalling are not.
> > * Some kind of kernel interface to make high performance encrypted
> > vpn possible
> Same as the last one. However, encription can't be in the kernel proper
> because of iditoic US export restrictions. (Do somthing about it:
> www.distributed.net)
The interface already exists, as does code that uses it - get a copy of CIPE
> > * Ipsec would be nice too
> I don't think the spec is finished yet.
The main spec is finished - but not key exchange - mostly due to US problems
as usual. There's a set of options for this already around.
> > a isa pnp boot device, or a viable userspace solution (like an improved
> > boot loader, initramdisks that must be rebuilt really dont cut it)
> You always could boot from an isapnp boot dev, so long as your BIOS supports
> plug 'n play.
The CVS tree has PnP stuff in it that now patched seems to work. Its not
however quite clean enough for me to send to Linus yet, and since Linus
is fussier than I am I know it will get rejected right now
> > * Sound code cleanup (Alan Cox said this was planned for 2.3)
> Will happen shortly, I hope.
2.2 gets modular OSS, 2.3.x probably gets rewritten stuff. Join Thomas Sailer
who is working on this if you want the ultimate full duplex wonder sound
system in 2.3.x
> > * SMP IRQ balencing (we dont do this yet)
> I think we do on everything but x86.
The only problem here is its too close to 2.2 to put it in. Its on my early
2.3.x list
> > * More/smarter use of spinlocks (networking code?)
> This should be doable.
The only really critical case here is for sk_buff handlers to cut down on
some bad overheads on cli/sti on SMP boxes. Im not going to do that until
the existing net changes have stabilised so I know just _who_ caused a problem
> > * Memory fragmentation Protection
There is some in 2.1.79/pre80
> Well, win3.1 in real mode. Windows in extened mode simply isn't possible...
> it wants to controll things that Linux needs to controll. It simply dosn't
> play fair.
Of course its possible. Its just hard. The big problem here is address
spaces. If you can figure how to allow some user mode linux tasks to have
a 32bit address space - even at a big performance hit on their part then
doing an x86/x86 JIT is quite reasonable. There are only a few "problem"
items with the x86, and by preparsing each block of code and taking the
branch trace traps you can swap the problem instructions for INT3 and emulate
them. All that leaves to emulate aftwards is the MMU (not terribly hard to
turn mmu ops into mmap) and hardware - see dosemu
Alan