> Although augmenting the kernel development rate would seem like a good
> idea, I don't believe it is. In my oppinion, it'd be better to have fully
> functionnal, complete kernels before moving on. PnP, as has been
> mentionned earlier, is almost vital in the kernel today. Most of the
> hardware selling right now is PnP, therefore we should have a very strong
Luckily this is not true ;) (As my new K6 demonstrates ;) )
But then as a Linux user I shop by first checking the Linux Hardware HOWTO
and other sources, and buy only hardware supported by Linux.
> PnP support in the kernel. Not to say that the isapnp tools aren't good,
> but they should at the very least be included in the kernel, to simplify
> everyone's lives. It'll have to be done eventually, plus I think this is a
> modification that many users were looking forward to in 2.2. Let's get PnP
> included now, even if it takes more time.
Nope, Funny thing, plag-n-pray hasn't bothered me yet, but then, tha's
perhaps because of my shopping-strategy? What would be cool for the
official kernel ASAP (==2.2?):
*) ext2 ACLs
*) ext2 compression (a safe one)
*) ext2 successor: log based, with all interesting features (fsck'ing 7GB
sucks)
*) a better NFS implementation.
*) Swap-over-NFS.
*) TCP based NFS? (v3 was that one, right?)
*) GGI?
compared to these wishes, PnP in the kernel is just unimportant.
(I'd also be very reluctant to let any software decide resource allocation
problems, I'm seeing what a mess even modern BIOSes are in this area.)
So if you want a newbie friendly solution, what about packaging userland
PnP better? It's even not that critical, because it's only ISA-PnP: So
nowadays it's rather unusual that somebody has his root fs on SCSI disc
connected to a ISA Plug-n-Pray SCSI controller, right?
Anything not needed for mounting the rootfs can easily be done from the
userland tools, right?
Andreas