I've followed a few of the threads that have been ongoing, and some topics
that continue to re-occur, and while it's great fun to continually argue
something until the overall concept has been disected into so many pieces
that the original idea could never be reconstructed, it's also painful to
watch.
Such an event has been coined as "too many cooks spoil the meal" (or as I
simply use "too many cooks"). Many people spend their time arguing a
point while being on the same side and simply expressing it differently.
Having said that, I have my own spices to add on the topics of
filesystems, stability and bugs.
First filesystems:
- User features, such as viewing tarfiles/zipfiles/etc as a directory have
no place in the kernel or libc.
- There is a completely different paradigm between the above, and writing
less than complete filesystems (ftpfs, davfs, etc.)
- A kernel patch for reading from hardware into a userland memory location
(userdirect) would resolve the major "it's faster in the kernel" issue (if
this is a technically proven issue in this case)
What is needed for "user features" is a LD_PRELOAD style library loading
interface which can be used to add extra functionality (tar files as dirs,
gif files as png's, etc) on a per-process (and spawned process thereof)
basis. This library system should be configurable in a style that is a
cross between ld.so.conf and conf.modules. Without adding too many new
concepts, it would likely be activated by the loader by an env variable.
("export LD_FEATURES=tardir:gfxmangle:hidedotfilesindir" for example).
How one accesses the features in each of the modules ("foo.tar#dir")
becomes somewhat trivial.
Yes, this won't work for statically linked binaries. If you have a
statically linked binary, you are doing so because you want the binary to
operate consistently no matter what the condition of your system is.
Does this mean that your system-recovery version of "mv" won't be able to
dynamically convert gif's to png's when renaming it? You bet.
Next, a feature, demonstrating my ignorance on some of the rough edges of
this implementation, that I call "userdirect" would allow a userland
application pass in a pointer to a buffer into kernel space and the kernel
would read data directly into that buffer without copying into kernel land
first. This may mean doing some pointer mangling, or possibly this is done
already, but from what I can understand this should move the biggest "it's
faster in the kernel" argument that I've heard.
The remaining arguments come wrt the implementation of a "ftpfs" or a
"davfs". To me, these clearly belong in userland, however being able to
hook a userland app into the list of active filesystems would make sense.
If you try to perform an operation that's simply not supported by the
filesystem, it fails. I recall hearing of this hooking feature in the
past (USERFS?), however a quick grep through Configure.help turns up
nothing.
Stability.
I used GNOME many months ago, long before the first binary packages for it
were available. It was slow. It was buggy. It crashed all the time, but
it had promise.
I use GNOME now today as my desktop environment, it's stable and works
well. Even Enlightenment behaves much better than it used to.
If you believe a kernel to be unstable on a specific machine, not from
first hand OOPSes, but simply from what you're reading, I have nothing
more to say than "try it", if it OOPSes, go back to the working version
you have.
I could go on for paragraphs about percieved stability, but it's all
seemingly quite obvious.
The last bit is about bug tracking software. I'm aware that Bugzilla was
rejected as a possibly choice, but I've never heard the real reasons.
Good bug tracking software is tedious to write (trust me :). If
something could be added onto Bugzilla to make it fit the bill, then
perhaps that where those of us who don't enjoy playing small timing
intervals could make ourselves more useful.
Cheers,
JAmes
-
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/